Fix accurate AD summation in residual equations

[Debraheem]

I believe the accurate AD summation types in mesa's residual equations were just being assigned the result of a normal AD expression sum, so the (dp) cancellation had already happened before the compensated summation logic even runs. So the accurate AD summation was not really being leveraged at all. I would call this an inconsequential bug, but fixing it could yield benefits.

This pr fixes the accurate AD sums to accumulate term-by-term through the accurate type, so each add/subtract actually uses the compensation algorithm. I added this type to a couple other locations where it might make sense (summing sources in hydro energy and in RSP2 turbulent energy and luminosity equations), and I did some minor clean up.

I'm not sure if this will help mesa convergence or not, it could in principle, but the point remains: this branch makes the intended behavior on main actually happen in practice. We will have to test and see if any thing changes in practice...

[warrickball]

LGTM but double_bh is failing. I'll try to run this on bluebear tomorrow and see if I can get some output.

[warrickball]

Not sure if you just need to rebase/merge main. The preceding commits also look like they had failures but main is clean.

[Debraheem]

yeah, i plan to take a closer look soon as well. Might just need to merge main in.

[Debraheem]

@warrickball i rebased to main and checked the double_bh test case photo checksum locally. Hopefully it passes the test_suite now and we can merge.

[warrickball]

I've just launched a test on bluebear, too. 🤞

[warrickball]

We've got different failures on different machines, possibly related to bluebear running full inlists (i.e., including optional parts). I'll have a look at the output of make_o_ne_wd a bit later.

[warrickball]

There's no smoking gun in the logs IMO. There's a minor convergence issue at model 639 with inlist_c_burn_header first then a major problem around model 920 with inlist_o_ne_wd_header. There are then sporadic problems that I guess keep the timestep lower than expected and the model stops because it hits the max model number of 3500.

I guess try a local run with all inlists? 🤷 I don't know these tests at all.

[Debraheem]

Interesting. I would definitely put this down to sensitivity. LLNL DANE might need the mod files regenerated to work as well on a partial test. but I'm not sure. If you share the terminal output with me for the make_o_ne_wd i could tweak it. But i will run these both locally as well.

[warrickball]

All passing on bluebear! 🥳