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
num
test failures beyond bit-for-bit differences with intrinsic math
#331
Comments
I guess the first question is usually do we even use cash-karp? There's a lot in num and mtx we don't use anymore (or maybe ever) |
Cash–Karp isn't the only one but FWIW
That call is in |
Numerical jacobians will be computed with finite differences, which loses
~most precision right off the bat. Small differences then get magnified
quickly...
…-Adam
On Tue, Oct 05, 2021 at 9:54 AM, Warrick Ball ***@***.***> wrote:
Cash–Karp isn't the only one but FWIW
$ grep cash_karp star/p*/*
star/private/hydro_rotation.f90: call cash_karp_work_sizes(1,liwork,lwork)
star/private/hydro_rotation.f90: call cash_karp( &
That call is in eval_fp_ft.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#331 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABPR5H7VA6PHUQPS3ESHKN3UFL7RJANCNFSM5FLV3ZYA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
the jacobian "only" guides the solution (e.g., how big a step can be taken for some accuracy criteria) and should not change the solution obtained. yes? |
On one hand, I totally agree. That's is also where I expect the problem is. On the other hand, even the finite difference Jacobians appear to only use things like +, -, *, / etc, rather than more troublesome functions like log, exp, pow, sin, cos, etc. I don't think CRMATH replaces those basic operations, so I expect the Jacobians to only differ to within a few orders of machine precision. Will that really be amplified?
The tests still meet their tolerance requirements, though they're usually quite loose (e.g. 1e-4). My question is whether that should be the deciding limit when we switch from CRMATH to intrinsic operations. |
e.g., I presume (wrongly?) that CRMATH and intrinsic math both give the same imprecise difference of two similar floats, so even if that's what leads to an imprecise Jacobian, I still expect the same imprecise Jacobian. |
Right, but imagine if those two large numbers are different. Then the
subtraction is doing the same thing, but it's amplifying a small difference
still.
…-Adam
On Tue, Oct 05, 2021 at 12:06 PM, Warrick Ball ***@***.***> wrote:
e.g., I presume (wrongly?) that CRMATH and intrinsic math both give the
same imprecise difference of two large numbers, so even if that's what
leads to an imprecise Jacobian, I still expect the same imprecise Jacobian.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#331 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABPR5H3CPMQ6C3PUYRGQYZTUFMO6VANCNFSM5FLV3ZYA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
There are several calls to pow in mod_cash_karp.f mesa/num/private/mod_cash_karp.f Line 200 in 0434563
Not sure how significant they are to the final result but still. |
The calls to cash_karp in hydro_rotation come from the old way to compute the rotation corrections that is no longer the default. Kept those as an alternative when we introduced the new method which uses fits for the fp and ft corrections. By this point I say we can just strip that old functionality, the new stuff is working much better and no one has complained about it. |
I think I failed to provide enough context for what I'm getting at in this issue. I don't think it needs to be a priority and I certainly don't think we need to start changing things outside of Regardless of whether any of these routines are being used, I think the first thing to establish is whether or not this level of failure in the The reason I'm not immediately convinced by this is that these routines use very few of the functions that are (as far as I know) replaced by CRMATH. Even if x ≈ y, I expect to get the same (imprecise) x-y whether I use CRMATH or intrinsic. There are a few calls to
so maybe it's just those few calls (I think mostly involving the step adjustments) getting amplified by the Jacobians. Happy to put this aside for a "rainy day". |
Note that those |
Just FYI I've removed |
Added labels 'rainy day' and 'good first issue' (subject to some experience with numerical analysis). |
If you try to build MESA with
USE_CRMATH = NO
inutils/makefile_header
, some of the differences innum
's test results are surprisingly large. You'll need to skipauto_diff
's tests withtouch auto_diff/skip_test
.e.g. for the Cash–Karp method, the expected output is
whereas we get
which differs already at the ~0.001 level. There are also various similarly large differences when calling the implicit solvers with numerical Jacobians (though differences seem to remain small with analytic Jacobians).
I'm personally not worried by differences within a few orders of magnitude of machine precision (say, <1e-10) but I don't understand why these are so different. There are very few calls to functions that are replaced by CRMATH and they seem to be confined to adjusting stepsizes anyway.
The text was updated successfully, but these errors were encountered: