Eos MESA updated tables + entropy tables for GRTDE#850
Conversation
…sity for GR, I want to change as little as possible though and preferably get away with GR users setting the same EOS number too
…d now, in eos, eos_mesa and eos_mesa_microphysics, now I need to add the entropy tables here, and also see if they get allocated correctly, I am only adding 4 variables in these tables so they occupy less size, other than that the compositions will be the same, but the minimum density should go as low as 1e-25 g/cm as fitz' simulations show. also this is not tested so I should do that
…adly I don't have fitz to double check it rn, but I think it should work. Also, I still need to figure out why my tables aren't being read.
…es still crashes. idk why yet
…about GR only working for ieos2,12, or 11
… there is an issue probably with the tables themselves which I'll need to test
…sa tables, because they are specific entropy divided by avo*kboltz
…k and forth was getting insane
… in log, so you need to specify which are and areny
…ed in eosvars but now has to somehow go to be used in relaxstar
…es for eosmesa, this well affect classical star relaxing as well as grstar and make them dependent on entropy
…also to see whehter Daniel is happy with this at all
…axation because the entropy at that stage shouldn't be tampered with
… and now things work! I am testing it now!
…o false by default to use thomas reichardt's old tables
…anged opacs table to be read separately for eos mesa as I have not updated them so they would just be downloaded from Thomas old link
…osmesa_version. also the gr tables will be uploaded in the same place that the classic tables will be
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughThis PR adds GR MESA EOS support for ChangesMESA GR EOS Support
Estimated code review effort: 4 (Complex) | ~60 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Warning Gemini encountered an error creating the review. You can try again by commenting |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
src/main/eos.f90 (1)
1223-1235: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winStale fatal message:
ieos=10is now handled but not mentioned.The
case defaultfatal inget_p_from_rho_sstill reads "only implemented for eos 2 and 12", even thoughcase(10)was just added above. The analogous message incons2primsolver.f90(Line 215) was correctly updated to mention eos 10; this one was missed.🐛 Proposed fix
- call fatal('eos','[get_p_from_rho_s] only implemented for eos 2 and 12') + call fatal('eos','[get_p_from_rho_s] only implemented for eos 2, 10 and 12')🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/main/eos.f90` around lines 1223 - 1235, Update the stale fatal message in get_p_from_rho_s so it matches the actual supported EOS cases in the select case on ieos. Since case(10) now routes to get_eos_ptemp_from_rhos_mesa_gr, change the case default call to fatal to mention eos 10 as supported as well, mirroring the updated message used in cons2primsolver.f90.src/main/cons2primsolver.f90 (1)
194-219: 🚀 Performance & Scalability | 🟠 Major | ⚡ Quick winRedundant per-iteration MESA GR table lookup for
ieos==10.Inside the Newton loop,
case(10)callsget_u_from_rho_severy iteration, but its result (u) is never used before being overwritten next iteration — for theentropy_sbranch,enthis updated purely fromgamfac*P/dens(Line 236), andgamfacis only ever refreshed insidecase(12), nevercase(10). Contrast this withcase(12), whereuis genuinely needed to updategamma/gamfacfor the next iteration.The final
uforieos==10is already (correctly) recomputed once after convergence (Lines 264-267), so the in-loop call just adds an unnecessary table interpolation on every Newton iteration for every GR-MESA particle.⚡ Proposed fix
select case(ieos) case (10) - ! inputs and outputs are all in code units - call get_u_from_rho_s(ieos,en,dens,u) - + ! u is not needed until after convergence; computed post-loop + ! to avoid redundant per-iteration table lookups case (12)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/main/cons2primsolver.f90` around lines 194 - 219, The Newton-loop branch in cons2primsolver for ien_entropy_s / case (10) is doing a redundant get_u_from_rho_s lookup every iteration even though u is not used to update enth or gamfac there; only case (12) needs u to refresh gamma and gamfac. Remove the per-iteration get_u_from_rho_s call from the ieos==10 path in the select case block and keep the single post-convergence recomputation of u for ieos==10 so the final value is still set correctly.
🧹 Nitpick comments (1)
src/main/eos_mesa.f90 (1)
150-171: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winMissing extrapolation/error signalling for the new GR accessors.
get_eos_ptemp_from_rhos_mesa_grandget_eos_u_from_rhos_mesa_grcallgetvalue_mesa_grwithout anierroutput, unlikeget_eos_pressure_temp_gamma1_mesa, whoseierris used ineos.f90(case 10) to warn when "extrapolating off tables". Silent off-table extrapolation in the GR hot loop (called every Newton iteration incons2primsolver.f90) could produce unphysical results without any diagnostic.If
getvalue_mesa_grsupports an optionalierrargument (mirroringgetvalue_mesa), consider threading it through here and up throughget_p_from_rho_s/get_u_from_rho_sineos.f90.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/main/eos_mesa.f90` around lines 150 - 171, The new GR accessors `get_eos_ptemp_from_rhos_mesa_gr` and `get_eos_u_from_rhos_mesa_gr` currently ignore table-boundary failures by calling `getvalue_mesa_gr` without surfacing any `ierr` status. Thread an optional error/status output through these routines, mirroring the existing `get_eos_pressure_temp_gamma1_mesa` handling, and propagate it upward through `get_p_from_rho_s` and `get_u_from_rho_s` in `eos.f90` so off-table extrapolation can be warned about instead of happening silently in the GR solve path.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/main/datafiles.f90`:
- Around line 70-77: The invalid eosmesa_version branch in datafiles.f90
currently uses a plain stop, which can strand other MPI ranks at barrier_mpi().
Replace the stop path in the select case around eosmesa_version with the
project’s MPI-aware error/abort handling so all ranks exit cleanly; keep the
change localized to the version switch and use the existing MPI
error/termination helper already used elsewhere in the codebase.
In `@src/main/eos_mesa_microphysics.f90`:
- Around line 850-856: `deallocate_arrays_mesa` is missing cleanup for the GR
composition arrays, so update the deallocation block to also release
`mesa_eos_gr_z` and `mesa_eos_gr_h` alongside the existing GR arrays. Use the
same allocation checks already used for `mesa_eos_gr0`, `mesa_eos_gr_logss`, and
the other `mesa_eos_gr_*` symbols, and keep the GR teardown consistent with the
non-GR cleanup in `deallocate_arrays_mesa`.
- Around line 683-693: In getvalue_mesa_gr, the GR fallback branch is
exponentiating all columns, which incorrectly transforms ivout=4 (Gamma1)
outside the table; update the fallback logic to keep column 4 in linear form,
matching the existing spline path where only the first three log10 columns are
converted back. Also update deallocate_arrays_mesa to release the GR grid arrays
allocated by get_eos_constants_mesa_gr, specifically mesa_eos_gr_z and
mesa_eos_gr_h, alongside the other mesa_eos_gr_* arrays.
In `@src/main/eos_mesa.f90`:
- Around line 144-171: The header comments for get_eos_ptemp_from_rhos_mesa_gr
and get_eos_u_from_rhos_mesa_gr still say "NOT TESTED YET!", which is now stale.
Update or remove those banner comments so they match the current tested status
described for the new GR-table EOS routines, keeping the documentation in
eos_mesa accurate for future readers.
- Around line 61-67: The GR initialization path in eos_mesa.f90 can hide a
failure from get_eos_constants_mesa_gr because read_eos_mesa_gr may reset ierr
back to zero. Update the gr branch in eos_mesa so it checks ierr immediately
after calling get_eos_constants_mesa_gr and returns at once on failure, before
invoking read_eos_mesa_gr; keep the existing final ierr guard only for the read
step.
In `@src/main/eos.f90`:
- Around line 167-171: The fatal error message in the GR compatibility check is
out of sync with the allowed `eos_type` values in `eos` because it omits
`ieos=4`. Update the `fatal` call in the `eos` logic so the message matches the
expanded `any((/2,4,10,11,12/)==eos_type)` check and explicitly includes `4`
alongside the other supported values.
- Around line 1280-1290: get_u_from_rho_s_vec is missing the same caller-size
guard that get_entropy_vec uses, so a mismatched n can cause out-of-bounds
access. Update get_u_from_rho_s_vec to validate that n matches the actual sizes
of S, rho, and u before the loop, and call fatal with a clear message if they
differ. Use the existing get_entropy_vec size-check pattern and keep the fix
localized to get_u_from_rho_s_vec/get_u_from_rho_s.
---
Outside diff comments:
In `@src/main/cons2primsolver.f90`:
- Around line 194-219: The Newton-loop branch in cons2primsolver for
ien_entropy_s / case (10) is doing a redundant get_u_from_rho_s lookup every
iteration even though u is not used to update enth or gamfac there; only case
(12) needs u to refresh gamma and gamfac. Remove the per-iteration
get_u_from_rho_s call from the ieos==10 path in the select case block and keep
the single post-convergence recomputation of u for ieos==10 so the final value
is still set correctly.
In `@src/main/eos.f90`:
- Around line 1223-1235: Update the stale fatal message in get_p_from_rho_s so
it matches the actual supported EOS cases in the select case on ieos. Since
case(10) now routes to get_eos_ptemp_from_rhos_mesa_gr, change the case default
call to fatal to mention eos 10 as supported as well, mirroring the updated
message used in cons2primsolver.f90.
---
Nitpick comments:
In `@src/main/eos_mesa.f90`:
- Around line 150-171: The new GR accessors `get_eos_ptemp_from_rhos_mesa_gr`
and `get_eos_u_from_rhos_mesa_gr` currently ignore table-boundary failures by
calling `getvalue_mesa_gr` without surfacing any `ierr` status. Thread an
optional error/status output through these routines, mirroring the existing
`get_eos_pressure_temp_gamma1_mesa` handling, and propagate it upward through
`get_p_from_rho_s` and `get_u_from_rho_s` in `eos.f90` so off-table
extrapolation can be warned about instead of happening silently in the GR solve
path.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 11d48c7b-d454-4506-af1e-6fff3d5f9582
📒 Files selected for processing (5)
src/main/cons2primsolver.f90src/main/datafiles.f90src/main/eos.f90src/main/eos_mesa.f90src/main/eos_mesa_microphysics.f90
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/main/eos.f90 (1)
1222-1233: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winUpdate the unsupported-EOS fatal message.
get_p_from_rho_snow implements2,5,10, and12, but the fatal text still says only2 and 12.🐛 Proposed fix
- call fatal('eos','[get_p_from_rho_s] only implemented for eos 2 and 12') + call fatal('eos','[get_p_from_rho_s] only implemented for eos 2, 5, 10 and 12')🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/main/eos.f90` around lines 1222 - 1233, The fatal message in get_p_from_rho_s is outdated and still claims only EOS 2 and 12 are supported, even though the select case now handles 2, 5, 10, and 12. Update the default-case fatal call in eos.f90 so the error text accurately lists the supported EOS values, keeping the message aligned with the select case branches in get_p_from_rho_s.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@src/main/eos.f90`:
- Around line 1222-1233: The fatal message in get_p_from_rho_s is outdated and
still claims only EOS 2 and 12 are supported, even though the select case now
handles 2, 5, 10, and 12. Update the default-case fatal call in eos.f90 so the
error text accurately lists the supported EOS values, keeping the message
aligned with the select case branches in get_p_from_rho_s.
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
src/main/eos.f90 (2)
1210-1213: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winStale fatal message:
case defaultnow omitsieos=5andieos=10.The
select casenow handles 2, 5, 10, and 12, but the fallthrough message still reads "only implemented for eos 2 and 12".🐛 Proposed fix
- call fatal('eos','[get_p_from_rho_s] only implemented for eos 2 and 12') + call fatal('eos','[get_p_from_rho_s] only implemented for eos 2, 5, 10 and 12')🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/main/eos.f90` around lines 1210 - 1213, The fallback fatal message in get_p_from_rho_s is stale because the select case now supports more EOS values than the message says. Update the case default branch in the get_p_from_rho_s logic to reflect the current supported set handled by the surrounding select case, namely eos 2, 5, 10, and 12, so the fatal text is accurate and consistent.
1196-1213: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winRestore the missing
kboltzfactor for GR entropy
get_entropyalready storesSas entropy divided bykboltz, socgss = S*unit_erggpassesentropy_cgs/kboltzinto the GR MESA wrappers.getvalue_mesa_grexpects cgs entropy and converts it withs/(kboltz*avogadro), so this path is off by another factor ofkboltz. Apply the same fix inget_u_from_rho_stoo.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/main/eos.f90` around lines 1196 - 1213, The GR entropy conversion is missing the kboltz factor in the EOS-to-MESA path, so the entropy passed from get_p_from_rho_s (and the matching get_u_from_rho_s helper) is still scaled incorrectly before calling the GR wrappers. Update the cgs entropy calculation near cgss in both routines to restore the entropy units expected by get_eos_ptemp_from_rhos_mesa_gr / getvalue_mesa_gr, and keep the fix aligned with how get_entropy stores S and how the ieos = 10 branch handles GR conversions.
🧹 Nitpick comments (1)
src/main/eos.f90 (1)
1224-1255: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueDoc header describes temperature, but the routine returns internal energy
u.The banner says "Calculate temperature given density and entropy", yet
get_u_from_rho_soutputsu. Correct the comment to avoid confusion. (Units concern already raised at theget_p_from_rho_sroot cause.)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/main/eos.f90` around lines 1224 - 1255, The header comment for get_u_from_rho_s is misleading because it says the routine calculates temperature, but the subroutine actually returns internal energy u. Update the banner/docstring near get_u_from_rho_s to describe internal energy from density and entropy, and keep the implementation and unit conversion logic unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@src/main/eos.f90`:
- Around line 1210-1213: The fallback fatal message in get_p_from_rho_s is stale
because the select case now supports more EOS values than the message says.
Update the case default branch in the get_p_from_rho_s logic to reflect the
current supported set handled by the surrounding select case, namely eos 2, 5,
10, and 12, so the fatal text is accurate and consistent.
- Around line 1196-1213: The GR entropy conversion is missing the kboltz factor
in the EOS-to-MESA path, so the entropy passed from get_p_from_rho_s (and the
matching get_u_from_rho_s helper) is still scaled incorrectly before calling the
GR wrappers. Update the cgs entropy calculation near cgss in both routines to
restore the entropy units expected by get_eos_ptemp_from_rhos_mesa_gr /
getvalue_mesa_gr, and keep the fix aligned with how get_entropy stores S and how
the ieos = 10 branch handles GR conversions.
---
Nitpick comments:
In `@src/main/eos.f90`:
- Around line 1224-1255: The header comment for get_u_from_rho_s is misleading
because it says the routine calculates temperature, but the subroutine actually
returns internal energy u. Update the banner/docstring near get_u_from_rho_s to
describe internal energy from density and entropy, and keep the implementation
and unit conversion logic unchanged.
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
src/main/eos_mesa_microphysics.f90 (1)
559-569: 🩺 Stability & Availability | 🟡 Minor | ⚡ Quick winFix the GR X-selection indices
mesa_eos_gr_data_exists(i, ...)uses the exhausted file-loop index, so this reads past the first dimension;j-2is also 0 whenj==2. Use the selected Z index (nz2) and a 1-based column index here.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/main/eos_mesa_microphysics.f90` around lines 559 - 569, The GR X-selection logic in mesa_eos_microphysics should stop indexing mesa_eos_gr_data_exists with the exhausted file-loop variable and an invalid zero column. Update the nx2 selection block to use the chosen Z index (nz2) instead of i, and ensure the column lookup is 1-based when checking adjacent entries in the mesa_eos_gr_data_exists array. Keep the fix localized to the do j loop that computes nx2 so the boundary cases at j==2 and j==mesa_eos_gr_nh remain valid.src/main/eos.f90 (1)
1205-1213: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winUpdate stale fatal message in
get_p_from_rho_s.The routine now handles
ieos2, 5, 10 and 12, but the default-branch message still reads "only implemented for eos 2 and 12", which will mislead users hitting an unsupportedieos.🐛 Proposed fix
- call fatal('eos','[get_p_from_rho_s] only implemented for eos 2 and 12') + call fatal('eos','[get_p_from_rho_s] only implemented for eos 2,5,10 and 12')🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/main/eos.f90` around lines 1205 - 1213, Update the stale fatal message in get_p_from_rho_s so it matches the actual ieos cases handled by the select case. The default branch currently says only eos 2 and 12 are implemented, but the routine also supports 5 and 10; revise the fatal('eos', ...) text in that function to accurately list all supported values so users get the correct unsupported-model message.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@src/main/eos_mesa_microphysics.f90`:
- Around line 559-569: The GR X-selection logic in mesa_eos_microphysics should
stop indexing mesa_eos_gr_data_exists with the exhausted file-loop variable and
an invalid zero column. Update the nx2 selection block to use the chosen Z index
(nz2) instead of i, and ensure the column lookup is 1-based when checking
adjacent entries in the mesa_eos_gr_data_exists array. Keep the fix localized to
the do j loop that computes nx2 so the boundary cases at j==2 and
j==mesa_eos_gr_nh remain valid.
In `@src/main/eos.f90`:
- Around line 1205-1213: Update the stale fatal message in get_p_from_rho_s so
it matches the actual ieos cases handled by the select case. The default branch
currently says only eos 2 and 12 are implemented, but the routine also supports
5 and 10; revise the fatal('eos', ...) text in that function to accurately list
all supported values so users get the correct unsupported-model message.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: ce80e499-8e30-4af3-a11b-5b07056dd231
📒 Files selected for processing (3)
src/main/eos.f90src/main/eos_mesa.f90src/main/eos_mesa_microphysics.f90
|
@AliPourmand the test is failing because the binary test now takes more than 6 hours to run when it has to download the new MESA tables. Also the opacity table repeatedly downloads to the run directory because the mesa_opac directory does not exist. Need to put a README in an empty eos/mesa_opac directory to avoid this Are the data files a lot larger than the previous tables? (and if so, do they need to be this large?) |
|
@danieljprice The old link on zenodo for the tables are 29.4 MB and the new one is 33.2MB so the size shouldn't be the problem. |
|
@danieljprice I tested running the binary workflow. When doing the final test
Unfortunately me manually trying to set np2=5000 didn't fix this. I have never seen this issue before in my previous pull requests. Has anything in |
|
@danieljprice I get a similar problem on my main branch too. I wasn't getting this error the last time I pulled, so I think something else changed in the past 1-2 weeks? |
|
this test is not failing on main |
|
@danieljprice I have pinpointed the problem, in the last test 
Unfortunately, the specific internal energy is not included among the default columns in This is similar to the issue we encountered for white dwarfs, and we suggest using the Helmholtz EOS instead for any highly degenerate object such as Brown Dwarfs too. The old tables did contain values in this region, but these were not physically accurate — they were simply continuous extrapolated values. This likely allowed the simulation to continue, although particles could still drift into this regime. I suspect the new tables are failing because they correctly expose this unsupported region rather than providing continuous but unphysical values. 
|
|
This makes sense. Please discuss the correct approach with Mike Lau who contributed the brown dwarf example. It's not possible to use the zero T eos here as there is both a brown dwarf and a giant in the simulation. Ideally the tables should still work for this situation. |
|
My concern is that this may not be possible with the current MESA EOS implementation. During Thomas Reichardt's time the MESA's EOS module may have behaved differently, but with the current version there are regions above the zero-temperature boundary where the MESA EOS solver simply does not return valid values: 
Just to remind you, this is what the profile would look like for a white dwarf with a highly degenerate core. Even before Phantom starts evolving the system, some particles already lie slightly outside the tabulated EOS domain, probably due to effects such as interpolation between neighbouring metallicity tables: 
@themikelau @danieljprice what do you think about this? I would strongly suggest we not "force" to make this work, because if it was an easy fix, we would have been using eos_mesa instead of eos_helmholtz for our white dwarf simulations. |
|
I did not actually contribute the brown dwarf example, and so I don't think you need my confirmation to determine the outcome of this discussion. My opinion is that we should continue the previous approach of throwing an extrapolation warning when falling outside the limits of the EoS table. But both |
|
@themikelau I think there are two distinct issues here. The extrapolation issue is the case where the EOS table have not been tabulated far enough into a physically valid region (e.g., below a certain internal energy), and in that case an extrapolating makes sense. The issue I am referring to above the zero-temperature line is different. It corresponds to combinations of density and internal energy that are thermodynamically impossible for a given composition. In other words, there is no physical EOS solution for those states. In that situation, I don't think Phantom should continue evolving with an extrapolated value, because the particle has entered a state that cannot exist according. @danieljprice I would rather change this test to be an MS star instead of a brown dwarf. There are two catches though: This would force the users to add the MESA internal energy as a column in their profiles too, which Phantom does not require right now. Also, to do this I'd have to add the equation for zerotemperature in the eos-mesa subroutines too. (They exist in The two catches are why I hadn't suggested it earlier. |
|
we should discuss , we should 100% find a way make the test pass rather than changing the test |
|
@danieljprice Sure, we can discuss. P.S. This particular setup also represents the brown dwarf with only 92 SPH particles, compared to about 5000 particles for the giant. At that resolution, the brown dwarf is not really being modelled in a physically meaningful way anyway. 
|
3 participants
Description:
I have updated EOS MESA tables to be made with version: mesa-24.08.1
keeping EOS MESA tables of Reichardt 2020 as a hidden option that can be modified.
Additionally, I have changed cons2primsolver so that now the gr code can use eos_mesa by adding new tables tabulated with entropy. This has been tested and it works.
Along with bug fixes and changes in datafile among others.
Components modified:
Type of change:
Testing:
By running sample eos mesa stars and comparing with old runs.
By running eos_mesa runs with grtde
Did you run the bots? no
Did you update relevant documentation in the docs directory? no
Did you add comments such that the purpose of the code is understandable? yes
I
Summary by CodeRabbit
ieos=10.eosmesa_versionto select the appropriate Zenodo-hosted MESA EOS table set.eos_type=10and broadening unsupported-EOS error messaging.