-
Notifications
You must be signed in to change notification settings - Fork 15
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
Conversation
@par-hermes format |
|
||
// get prim vars | ||
auto &data = pmb->meshblock_data.Get(); | ||
auto const &prim = data->Get("prim").data; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 aConsToPrim
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? ;)
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
Co-authored-by: forrestglines <[email protected]>
|
||
// get prim vars | ||
auto &data = pmb->meshblock_data.Get(); | ||
auto const &prim = data->Get("prim").data; |
There was a problem hiding this comment.
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 aConsToPrim
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
const Real edot = cooling_table_obj.DeDt(eint, rho); | ||
const Real t_cool = eint / edot; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
const Real Pmag = 0.5 * (SQR(B1) + SQR(B2) + SQR(B3)); | ||
|
||
// compute plasma beta | ||
plasma_beta(0, k, j, i) = Pgas / Pmag; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
Co-authored-by: Philipp Grete <[email protected]>
Co-authored-by: Philipp Grete <[email protected]>
Co-authored-by: Philipp Grete <[email protected]>
Co-authored-by: Philipp Grete <[email protected]>
Co-authored-by: Philipp Grete <[email protected]>
…thenapk into cluster-derived-vars
@par-hermes format |
Piggyback removal of labels for acceleration fields in turb generator as the (new) default ones are effectively identical.
@par-hermes format |
@par-hermes format |
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 |
There was a problem hiding this 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.
CI passed (though still not reported yet). I'm merging now. |
This adds various derived fields to the cluster pgen: