OpenBLAS has issues solving triangular matrices on win32

Using the 32 bit openblas causes timeouts while running the scipy tests:

https://ci.appveyor.com/project/scipy/scipy/build/1.0.40/job/7vqlq835677r4xde

[martin-frbg]

Do I read that correctly - you are using a binary distribution of 0.2.19 from some third party site (which could be one of the sourceforge mirrors sites, but then again could be something else) ? Could you retest with the current "develop" snapshot which has a bunch of fixes vs. 0.2.19 (or at least build 0.2.19 yourself on your platform to see if it passes the built-in tests) ? In any case I guess a minimal example run on a well-defined system would be preferable to a big unedited dump from an appveyor vm.

That was built 12 days ago: scipy/scipy#7616 (comment)

In any case I guess a minimal example run on a well-defined system would be preferable to a big unedited dump from an appveyor vm.

Is there any way to turn on debug output?

excuse me; the URL was not apparently correct. Retrying with 2.20 now.

[martin-frbg]

not sure if 0.2.20 will build in your environment (depending on how and where you build - a cross-compile on linux like the binaries provided on sourceforge will probably go okay. the issue is a botched commit that breaks things on non-glibc systems, waiting for xianyi to release 0.2.21) which is why I suggested taking a snapshot of "develop" (easily done by clicking on the green "Clone or download" button on the "Code" tab here). Normal build from source should run a few tests at the end automatically (though as a Linux guy I am not completely sure it does this on Windows as well.

[martin-frbg]

Thanks for the link to the scipy issue. From reading that, it seems your tests were (at least at some point in the history of that PR) already done with 0.2.20 (?)
Do you still believe the problematic behaviour is with potrf specifically ?

Thanks for the link to the scipy issue. From reading that, it seems your tests were (at least at some point in the history of that PR) already done with 0.2.20 (?)

That's what I thought, but HEAD had 2.19. I updated to 2.20 just now.

Do you still believe the problematic behaviour is with potrf specifically ?

That is my suspicion; @carlkl used a completely different build method and still had issues with OpenBLAS on win32 but not win_amd64. Of course it would be helpful to get more debug output in order to understand what is happening.

That is my suspicion; @carlkl used a completely different build method

Specifically he used cross compiling with gcc rather than building with MSVC.

[martin-frbg]

Cross compiling with gcc will currently get you the hand-optimized assembly functions (which use inline assembly and AT&T notation that MSVC does not support), building with MSVC will use generic C implementations instead (which are possibly still a bit faster than the netlib reference implementation).
Latest commits to "develop" allow compiling with clang which supports the optimized assembly (but will need a windows flang compiler for completeness)

[brada4]

Specifically what lapack is imported by arpack?

Specifically what lapack is imported by arpack?

Lapack and BLAS both come from OpenBLAS.

https://ci.appveyor.com/project/scipy/scipy/build/1.0.44/job/wix716oq76ft44r4

Looks like we still have issues:

  File "C:\Python36\lib\site-packages\scipy\optimize\tests\test_trustregion.py", line 76, in test_solver_concordance
    options={'return_all': True})
  File "C:\Python36\lib\site-packages\scipy\optimize\_minimize.py", line 486, in minimize
    callback=callback, **options)
  File "C:\Python36\lib\site-packages\scipy\optimize\_trustregion_exact.py", line 43, in _minimize_trustregion_exact
    **trust_region_options)
  File "C:\Python36\lib\site-packages\scipy\optimize\_trustregion.py", line 184, in _minimize_trust_region
    p, hits_boundary = m.solve(trust_radius)
  File "C:\Python36\lib\site-packages\scipy\optimize\_trustregion_exact.py", line 418, in solve
    delta, v = singular_leading_submatrix(H, U, info)
  File "C:\Python36\lib\site-packages\scipy\optimize\_trustregion_exact.py", line 185, in singular_leading_submatrix
    return delta, v
+++++++++++++++++++++++++++++++++++ Timeout ++++++++++++++++++++++++++++++++++++
[gw3] node down: Not properly terminated
fReplacing crashed slave gw3
...................F....F..........x................................................

It's not to difficult to reproduce; just download and install python 32 bit, install the wheel from appveyor and run the test. I can also instrument this if you want, just tell me what tooling I need to use.

(but will need a windows flang compiler for completeness)

Yeah, I actually opened an issue on flang for that; if anyone has time, I would be greatly appreciative.