Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add derived fields to cluster pgen #63

Merged
merged 26 commits into from
Jun 2, 2023
Merged

add derived fields to cluster pgen #63

merged 26 commits into from
Jun 2, 2023

Conversation

BenWibking
Copy link
Contributor

@BenWibking BenWibking commented May 18, 2023

This adds various derived fields to the cluster pgen:

  • cell radius
  • entropy
  • sonic Mach number
  • plasma beta
  • temperature
  • cooling time

@forrestglines
Copy link
Contributor

@par-hermes format


// get prim vars
auto &data = pmb->meshblock_data.Get();
auto const &prim = data->Get("prim").data;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we sure prim is up-to-date here? Would it be correct at the start of the simulation? Should we add a ConsToPrim in the kernel?

Copy link
Contributor Author

@BenWibking BenWibking May 23, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pgrete is there a flowchart showing the tasks/kernels called during the hydro update? We keep coming back to the question of when prim is consistent with cons in multiple PRs, and it would be good to have a reference/doc to resolve this in general.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we sure prim is up-to-date here? Would it be correct at the start of the simulation? Should we add a ConsToPrim in the kernel?

Fairly sure. Because this function is called for the output (i.e., outside of a cycle) and the design/assumption is that data is consistent at the beginning/end of a cycle.

@pgrete is there a flowchart showing the tasks/kernels called during the hydro update? We keep coming back to the question of when prim is consistent with cons in multiple PRs, and it would be good to have a reference/doc to resolve this in general.

Unfortunately, there is not, but at the Athena meeting multiple people requested this feature.
It should be fairly straightforward to automatically create a flowchart with a small PR in Parthenon that dumps the task list in a format that is understood by some graph library.
Any volunteers? ;)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"""
Fairly sure. Because this function is called for the output (i.e., outside of a cycle) and the design/assumption is that data is consistent at the beginning/end of a cycle.
"""
I'm assuming that includes ghost zones too so this isn't the cause for Ascent meshblock boundary artifacts.

"""
It should be fairly straightforward to automatically create a flowchart with a small PR in Parthenon that dumps the task list in a format that is understood by some graph library.
Any volunteers? ;)
"""
Sounds interesting to me at least! I might take a stab at it

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

""" Fairly sure. Because this function is called for the output (i.e., outside of a cycle) and the design/assumption is that data is consistent at the beginning/end of a cycle. """

I'm assuming that includes ghost zones too so this isn't the cause for Ascent meshblock boundary artifacts.

Correct, ghost cells are up-to-date when outputs are called.

""" It should be fairly straightforward to automatically create a flowchart with a small PR in Parthenon that dumps the task list in a format that is understood by some graph library. Any volunteers? ;) """

Sounds interesting to me at least! I might take a stab at it

For reference, my first attempt/thoughts parthenon-hpc-lab/parthenon#880

src/pgen/cluster.cpp Outdated Show resolved Hide resolved
src/hydro/srcterms/tabular_cooling.cpp Show resolved Hide resolved
src/pgen/cluster.cpp Outdated Show resolved Hide resolved
Co-authored-by: forrestglines <[email protected]>
src/hydro/srcterms/tabular_cooling.cpp Show resolved Hide resolved
src/hydro/srcterms/tabular_cooling.hpp Outdated Show resolved Hide resolved
src/pgen/cluster.cpp Outdated Show resolved Hide resolved
src/pgen/cluster.cpp Outdated Show resolved Hide resolved

// get prim vars
auto &data = pmb->meshblock_data.Get();
auto const &prim = data->Get("prim").data;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we sure prim is up-to-date here? Would it be correct at the start of the simulation? Should we add a ConsToPrim in the kernel?

Fairly sure. Because this function is called for the output (i.e., outside of a cycle) and the design/assumption is that data is consistent at the beginning/end of a cycle.

@pgrete is there a flowchart showing the tasks/kernels called during the hydro update? We keep coming back to the question of when prim is consistent with cons in multiple PRs, and it would be good to have a reference/doc to resolve this in general.

Unfortunately, there is not, but at the Athena meeting multiple people requested this feature.
It should be fairly straightforward to automatically create a flowchart with a small PR in Parthenon that dumps the task list in a format that is understood by some graph library.
Any volunteers? ;)

src/pgen/cluster.cpp Outdated Show resolved Hide resolved
src/pgen/cluster.cpp Outdated Show resolved Hide resolved
Comment on lines 506 to 507
const Real edot = cooling_table_obj.DeDt(eint, rho);
const Real t_cool = eint / edot;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably need a check for edot = 0 here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is NaN a bad answer here? What should it return in this case?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We really really should since below the cooling table it will be effectively zero. For consistency we could set it to positive infinity.

Ideally we'd treat cold gas separately or ignore it for calculation of 1D profiles. Deovrat might have a more informed opinion.

src/pgen/cluster.cpp Outdated Show resolved Hide resolved
const Real Pmag = 0.5 * (SQR(B1) + SQR(B2) + SQR(B3));

// compute plasma beta
plasma_beta(0, k, j, i) = Pgas / Pmag;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should check that if Pmag == 0 we set it to sth tiny.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As before, is NaN a bad answer? What would be more sensible?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think NAN would be good but hack in NAN exclusion into the Ascent 1d profiles and projects if that's possible

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if that's possible. We'd need to ask the Ascent devs.

@forrestglines
Copy link
Contributor

@par-hermes format

src/pgen/cluster.cpp Outdated Show resolved Hide resolved
pgrete and others added 3 commits May 25, 2023 15:30
Piggyback removal of labels for acceleration fields in turb generator as
the (new) default ones are effectively identical.
@forrestglines
Copy link
Contributor

@par-hermes format

@forrestglines
Copy link
Contributor

@par-hermes format

@forrestglines
Copy link
Contributor

forrestglines commented Jun 1, 2023

I think I've fixed the cooling time bug. It looks good from vim-inspection of 1D profile data given by Ascent

This is once again ready for review, given that the CI passes

Copy link
Contributor

@pgrete pgrete left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the fix. Looks good to me now.

@pgrete
Copy link
Contributor

pgrete commented Jun 2, 2023

CI passed (though still not reported yet). I'm merging now.

@pgrete pgrete merged commit 8f04e18 into main Jun 2, 2023
@BenWibking BenWibking deleted the cluster-derived-vars branch August 1, 2023 13:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants