Update pgstar EOS regions to reflect new defaults

[evbauer]

A lot of this is hard coded, so we'll need to check right before release to make sure that the EOS region labels actually reflect the EOS that we're using by default.

[rjfarmer]

I wonder if we can automate things? Get the pgstar code to read the limits between boundaries at runtime?

[adamjermyn]

This should be doable with the polygon version of the boundaries (just read in the polygon edges). I think it's harder to do with the boundaries stated in terms of nested if's, because the shape can change (e.g. Josiah explained to me last week that the number of vertices defining the boundary of FreeEOS changes as a function of metallicity). That sort of thing probably needs hard-coding.

-Adam

On Sun, Oct 11, 2020 at 10:27 AM, Robert Farmer < notifications@github.com > wrote:

I wonder if we can automate things? Get the pgstar code to read the limits between boundaries at runtime?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub ( https://github.com/MESAHub/mesa/issues/91#issuecomment-706712722 ) , or unsubscribe ( https://github.com/notifications/unsubscribe-auth/ABPR5HY6YQI7TXQKLUDIABTSKG6FDANCNFSM4RIWHBGA ).

[evbauer]

At the moment it looks like things are fine in the PC region for what we plan to release since we decided to leave PC as the default for now. In the short term, I think we just need to add something about FreeEOS in the region that is currently labeled as OPAL. I'll add the release-blocker tag here until that is fixed, but I think after that we can leave this open as a longer-term issue to figure out after release when we start rearranging the EOS.

@rjfarmer, as you probably know, a lot of the boundary drawing is already automated up to a point, but pgstar assumes it know which EOSs are being used, and sometimes it gets that wrong (e.g. the PC boundaries get drawn even when Skye is on instead). And all the text for names of EOS regions is hard-coded, both for the location and text string. So @adamjermyn we would also need to be able to automate where that gets written within a polygon and which name actually gets written. Do you think that is doable?

[evbauer]

For reference, here is what the EOS regions look like at the moment:

[rjfarmer]

Theres's almost zero automation for the eos/opacity boundaries in the T-Rho plot. See do_eos_regions and do_kap_regions in pgstar_trho_profile.f90 and the sheer number of hard coded numbers defining the edges of the logT/Rho regions

[adamjermyn]

I'm punting on this one until post-release, when I'll be working on a new blend/combining system for the EOS (polygon-based)...

-Adam

On Fri, Oct 30, 2020 at 5:15 PM, Robert Farmer < notifications@github.com > wrote:

Theres's almost zero automation for the eos/opacity boundaries in the T-Rho plot. See do_eos_regions and do_kap_regions in pgstar_trho_profile.f90 and the sheer number of hard coded numbers defining the edges of the logT/Rho regions

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub ( https://github.com/MESAHub/mesa/issues/91#issuecomment-719803142 ) , or unsubscribe ( https://github.com/notifications/unsubscribe-auth/ABPR5H6XCONCUIGGKZEZUHTSNMUHRANCNFSM4RIWHBGA ).

[jschwab]

I'm OK with punting on making these lines accurate, as I think that is a lot of effort in the given framework (and much easier in our glorious polygon future). But I'd like to have something a little less misleading for release if we can come up with a simple-to-implement idea.

[rjfarmer]

Can we just hard code the boundaries from a solar composition 1Msun model with default options? It seems the easiest default to use.

[rjfarmer]

I'm removing release blocker as i did update the labels (14890) even if the plot is probably still got problems. We can leave the bug open to make sure we fix this later.

[evbauer]

Thanks. I agree that this is no longer a release blocker. For reference, here is what we currently show after your update, which I think is good enough for now, though definitely not accurate in every detail.

[adamjermyn]

I think we can now come back to this one. Once Skye_on_PC_off merges into main we can:

1. Remove the PC lines.
2. Put the HELM label in dragons-land.
3. Put a 'Skye' label somewhere in Skye-land.
4. Put a new set of lines for Skye and update the FreeEOS lines accordingly.

The Skye boundaries are composition-dependent, but are roughly

logT = 7.3 (for anything even vaguely solar-like) logRho = 3.5 (for C/O)

[evbauer]

I'm going to work on this, but first I need help settling what's going on with the EOS regions diagram that I just updated on the docs website: https://docs.mesastar.org/en/latest/eos/overview.html

There's now a region labeled "none" where MESA is reporting that there is no EOS coverage. That looks like something that needs to be fixed. Once we have that figured out, we can regenerate the true EOS coverage diagram for the docs page (which calls the EOS directly to find which EOS is being called where), and then I'll update the pgstar plots once that's settled.

I'm adding the release-blocker tag at least until we have the diagram for the docs page sorted out.

[adamjermyn]

These plots look like they were generated with the EOS plotter, so they're probably reporting correctly that no EOS wants to lay claim to those regions.

Does the EOS actually return something in those regions? Is there an ultimate fallback like the ideal gas law?

Note that the Skye blend locations depend on abar and zbar, so they will shift around depending on exact composition.

-Adam

On Mon, Sep 27, 2021 at 7:06 PM, Evan Bauer @.***> wrote:

I'm going to work on this, but first I need help settling what's going on with the EOS regions diagram that I just updated on the docs website: https://docs.mesastar.org/en/latest/eos/overview.html

There's now a region labeled "none" where MESA is reporting that there is no EOS coverage. That looks like something that needs to be fixed. Once we have that figured out, we can regenerate the true EOS coverage diagram for the docs page (which calls the EOS directly to find which EOS is being called where), and then I'll update the pgstar plots once that's settled.

I'm adding the release-blocker tag at least until we have the diagram for the docs page sorted out.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MESAHub/mesa/issues/91#issuecomment-928413961, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABPR5H4XTJLWTN6V4TYOIKLUED2I7ANCNFSM4RIWHBGA . 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.

[evbauer]

It's just returning NaN in those regions!

[adamjermyn]

Ok good! That's what I'd hope it does!

We can introduce a new EOS (ideal ion gas + radiation, perhaps?) that serves as an ultimate backstop if we need coverage over the whole plane. If you think that's a good idea I'm happy to add it: it's a pretty straightforward thing to do with the Skye machinery (though I'd make it it's own thing to avoid any confusion).

-Adam

On Tue, Sep 28, 2021 at 12:37 PM, Evan Bauer @.***> wrote:

It's just returning NaN in those regions!

[image: iTerm2 zDUN4h eos_plotter] https://user-images.githubusercontent.com/18405113/135128944-017b8da2-b176-4b31-931a-14905ae767a2.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MESAHub/mesa/issues/91#issuecomment-929394013, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABPR5HY5ZLO6FJCPI32ZB4TUEHVMJANCNFSM4RIWHBGA . 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.

[warrickball]

It's just returning NaN in those regions!

I realise the gas pressure probably doesn't contribute much there but I can see the blend (HELM-FreeEOS?) around logT=7.2, logρ=-7.

[evbauer]

Oh good point. Maybe the blend is way too narrow there? I can smooth that significantly by setting logQ_min_FreeEOS_hi = -9.0d0.

[warrickball]

I'll leave it to the EoS experts to judge. I think I've learned that things that are surprising to the untrained eye can be justified or benign. It just surprised me to be able to see the blend in something like the gas pressure.

[evbauer]

Here's what it looks like after what I just committed (91f3064) to fix up the pgstar issue. I've moved toward simplifying what we try to show in pgstar so that we can avoid having any hardcoded boundaries. It clearly doesn't capture the full complexity, but I think we can leave that to the docs page (https://docs.mesastar.org/en/latest/eos/overview.html) now that we have a much more thorough description there.

This does still make the assumption that we're using FreeEOS, but as long as we're using the current MESA default EOS, at least the boundaries here should sensibly move around to reflect where the blends are actually occurring.

If others are happy with this, I think we can close this issue.

[adamjermyn]

This seems fine to me. Most of the region out-of-bounds is in Skye-land but in a funny composition-dependent way that would be hard to depict accurately, so I think this is a good summary. And the Skye-HELM boundaries are smooth enough that it's not operationally important that people see where they are...

-Adam

On Mon, Oct 25, 2021 at 3:41 PM, Evan Bauer @.***> wrote:

[image: iTerm2 lmSsyb trho_profile_000165] https://user-images.githubusercontent.com/18405113/138780004-ce5dd8b9-355e-47c1-b7ba-8b732e015049.png

Here's what it looks like after what I just committed to fix up the pgstar issue. I've moved toward simplifying what we try to show in pgstar so that we can avoid having any hardcoded boundaries. It clearly doesn't capture the full complexity, but I think we can leave that to the docs page ( https://docs.mesastar.org/en/latest/eos/overview.html) now that we have a much more thorough description there.

This does still make the assumption that we're using FreeEOS, but as long as we're using the current MESA default EOS, at least the boundaries here should sensibly move around to reflect where the blends are actually occurring.

If others are happy with this, I think we can close this issue.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MESAHub/mesa/issues/91#issuecomment-951388961, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABPR5H7VF4P6ZSNZH4ETZ7TUIXMLHANCNFSM4RIWHBGA . 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.

[rjfarmer]

Could we put "Helm/Skye" somewhere in that top right region (if we dont want to specify the helm and skye regions?)

[fxt44]

or just skye ...

[evbauer]

How about something like this? I agree with Adam that we don't want to actually try showing where the HELM/Skye blends are occurring, but it's nice to give a vague sense that it's mostly Skye with some HELM up at very high temperatures and low densities.

[evbauer]

Committed in 5f2edda