Implemented Sunny Wong rotation brunt change

[rjfarmer]

People seemed happy to merge this in #372 so let's check to see if the test suite passes and then merge it.

Closes #372

[rjfarmer]

https://testhub.mesastar.org/brunt_in_rotation/commits/3f511c0

[evbauer]

Hmmm, looks like we have another instance of a photo checksum failure without an fpe: https://testhub.mesastar.org/brunt_in_rotation/commits/69b4927/test_cases/star/ppisn

I suspect there's something non-trivial going on related to the state of brunt-related quantities.

[evbauer]

Actually, it looks like this change is definitely not equivalent to the previous way of doing things. We have a line specifically skipping updates to s% brunt_N2 during solver iterations:

mesa/star/private/hydro_vars.f90

Lines 596 to 598 in 3fb7174

	if (.not. skip_brunt) then ! skip_brunt during solver iterations
	if (dbg) write(*,*) 'call do_brunt_N2'
	call do_brunt_N2(s, nzlo, nzhi, ierr)

mesa/star/private/solver_support.f90

Line 844 in 3fb7174

skip_brunt = .true., &

So the quantities we're trying to take advantage of here are actually going to become stale during solver iterations. I'll push an experimental commit getting rid of that check to see what testing looks like, but I'd definitely like some input from @orlox before proceeding with a merge.

[evbauer]

Actually, I'm realizing that was probably a red herring, as we don't update mixing info during solver iterations anyway, so it shouldn't matter if the brunt is getting updated during the iterations here. I'll revert that.

The photo checksum failure does seem to be telling us something important, and it's happening quite consistently, so we'll have to track that down.

[rjfarmer]

If you diff the output of two runs it looks like there are differences immediately after the restart. So I'm guessing there is an issue with how the Brunt is computed at the start of a run that differs from how the old form worked.

Also, https://testhub.mesastar.org/brunt_in_rotation/commits/e03088c/test_cases/star/ppisn shows it's not a parallelisation issue.

[evbauer]

@orlox and I discussed working on this some more today. Not clear on what our timeline will be yet, but I think we at least see a path forward that involves mostly trying to work through all the fpe's we can squash related to rotation and mixing.

[evbauer]

@pmocz It looks like this branch has been rebased on main several times. Is that intentional? Just a heads up that this can put a large load on testing infrastructure because every rebase means that all commits on the branch get new hashes and therefore appear as new commits to be tested.

[pmocz]

No, it's not intentional, that's my bad! I messed up the rebase somehow and was trying to fix it. I won't touch it anymore and just squash when we merge. Sorry about the testing load. Is there a way to cancel those jobs, these don't need to be all tested

…

On Mon, Jan 27, 2025, 1:20 PM Evan Bauer ***@***.***> wrote: @pmocz <https://github.com/pmocz> It looks like this branch has been rebased on main several times. Is that intentional? Just a heads up that this can put a large load on testing infrastructure because every rebase means that all commits on the branch get new hashes and therefore appear as new commits to be tested. — Reply to this email directly, view it on GitHub <#553 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABZESVMCI2IS2REPTH6DAQL2MZ2HVAVCNFSM6AAAAABKW3IKT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMJWGU3DQMRWHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[evbauer]

No worries! My cluster was backed up with a bunch of other stuff I'm running anyway, so I happened to have paused automated testing anyway. So nothing even needs to be canceled in this case.