-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add astropy-7.0.0 for 2023b #916
base: 2023.06-software.eessi.io
Are you sure you want to change the base?
Conversation
Instance
|
Instance
|
Instance
|
Instance
|
Instance
|
Instance
|
bot: build repo:eessi.io-2023.06-software instance:eessi-bot-mc-aws arch:zen2 |
Updates by the bot instance
|
Updates by the bot instance
|
Updates by the bot instance
|
Updates by the bot instance
|
Updates by the bot instance
|
Updates by the bot instance
|
New job on instance
|
Hm... not a real issue:
but the question is, how do I make it pass... |
Let me try that one more time. If it's a rare enough hickup and it passes, I'm fine with it. |
bot: build repo:eessi.io-2023.06-software instance:eessi-bot-mc-aws arch:zen2 |
Updates by the bot instance
|
Updates by the bot instance
|
Updates by the bot instance
|
Updates by the bot instance
|
Updates by the bot instance
|
Updates by the bot instance
|
New job on instance
|
bot: build repo:eessi.io-2023.06-software instance:eessi-bot-mc-aws arch:zen3 |
Updates by the bot instance
|
Updates by the bot instance
|
Updates by the bot instance
|
Updates by the bot instance
|
Updates by the bot instance
|
Updates by the bot instance
|
New job on instance
|
New job on instance
|
New job on instance
|
New job on instance
|
New job on instance
|
New job on instance
|
New job on instance
|
New job on instance
|
New job on instance
|
Ok, more of these test-timing failures. E.g. for 45929:
For haswell:
on all aarch architectures:
Now that might be an actual issue. I'll see if I can find anything upstream and/or report it back. It could also be an issue with the test initialization, I'm not sure which values this gets initialized with. |
Seems to be a known issue. Some discussion on whether it is an issue with the underlying numpy/openblas, or the tolerance of the test astropy/astropy#15650 |
Changing the initial values for the fit slightly seems to make the test pass according to astropy/astropy#15650 (comment) It seems to be a numerical issue specific to the particular initial conditions of this test. I'll see if I can do a build with This is almost without a doubt the result of slightly different numerical behavior, as astropy/astropy#15650 states that it only happens for particular builds of OpenBLAS (the one from miniforge). It makes sense that if your BLAS implementation has different optimization you get slightly different numerical results. If that is used on a numerical algorithm with an initial condition that is already very nearly unstable, it might make the difference between convergence and no convergence. I would not consider that an issue with the underlying OpenBLAS, nor with the numerical algorithm. It is simply a fact of life that certain algorithms at certain precisions may or may not convergence for certain initial conditions. If anything, the astropy test should be adapted so that it starts from a more stable initial condition - you don't want to test for differences in numerical behavior as long as these are within acceptable numerical precision - which is likely the case here. Note that our OpenBLAS installations runs the LAPACK test suite, and (for real and doubles) passed all tests. I'm not sure if that includes a test for the particular routine invoked here, but it makes it seem unlikely that the precision of our OpenBLAS build is somehow unacceptably low. |
No description provided.