APR in MCFOST

[JotaRata]

Description:
Pass apr_level as an optional argument to run_mcfost_phantom.
Requires cpinte/mcfost#148
Requires cpinte/mcfost#151

Components modified:

• Setup (src/setup)
• Main code (src/main)
• Moddump utilities (src/utils/moddump)
• Analysis utilities (src/utils/analysis)
• Test suite (src/tests)
• Documentation (docs/)
• Build/CI (build/ or github actions)

Type of change:

• Bug fix
• Physics improvements
• Better initial conditions
• Performance improvements
• Documentation update
• Better testing
• Code cleanup / refactor
• Other (please describe)

Testing:

Ran test Phantom simulations with MCFOST=yes APR=yes.
Temperature profile matches the control even inside the APR regions.

Did you run the bots? yes

Did you update relevant documentation in the docs directory? no

Did you add comments such that the purpose of the code is understandable? no

Is there a unit test that could be added for this feature/bug? no

If so, please describe what a unit test might check:

There are still bugs to be fixed, per example, Phantom freezes after deleting dump_00000.tmp

[JotaRata]

Rebase notes: I rewrote the commits to not sabotage the git blame history and to incorporate the changes from cpinte/mcfost#151 which is the current merge candidate for the APR implementation in MCFOST.

I also removed the conditional logic around calling MCFOST’s init/run routines based on whether Phantom was compiled with APR. This breaks backwards compatibility and it will crash if the caller and callee interfaces mismatch.

also why does gemini hate me:(

[danieljprice]

now that cpinte/mcfost#151 is merged into MCFOST I am happy to merge this, however there is still a compilation failure on the Phantom side that needs to be fixed (related to the use_apr flag)

[JotaRata]

Yes, unfortunately the use_apr and apr_levels variables didn't make it. Should I revert the latest commit that includes those changes in Phantom (3198595)?

[danieljprice]

mcfost took more than 6 hours to complete (should normally be 5 mins) so the job timed out. This smells like a bug to me...

[JotaRata]

Also, according to the logs, the first run was completed in one minute and after it's completed it calls mcfost again and it hangs, which is weird..

I reported this behavior a while ago and it was fixed, now it seems it's back.

[JotaRata]

I downloaded and used the exact parameters as in the test and was unable to reproduce this on my machine.

I did have a "Floating-point exception" when compiling phantom with DEBUG=yes and the backtrace pointed at line 129:
https://github.com/JotaRata/phantom/blob/bfb0cfad5e61606ef4d582bdaad5b9943645f1b1/src/utils/analysis_mcfost.f90#L129
And pointing inside of MCFOST in read_phantom.f90:932
pmassi = pmassi / (2.**(apr_level(i) - 1))

Could be that MCFOST expects apr_level to have a size equal to npart as defined here (line 192):
https://github.com/cpinte/mcfost/blob/9805b5a2c858fe453c0e4e851a0d816a5d23cc39/src/mcfost2phantom.f90#L192

[JotaRata]

Two tests fail with a message "fatal: No names found, cannot describe anything." that appears to be generated by git