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 MHD Support to Projection and Rotated Projection Outputs #366

Merged
merged 9 commits into from
Jan 24, 2024

Conversation

bcaddy
Copy link
Collaborator

@bcaddy bcaddy commented Jan 23, 2024

Summary

Per the discussion in PR #365 I've added MHD support to the projection and rotated projection outputs along with a minor refactor to those functions to accomplish this and utilize more of the utility functions we've written.

I also added a utility function for computing the temperature from the conserved variables (hydro_utilities::Calc_Temp_Conserved). Internally it simply calls hydro_utilities::Calc_Pressure_Conserved and hydro_utilities::Calc_Temp to compute the temperature.

Duel Energy + Dust Fixes

Dust_Kernel had few DE related bugs in it that I fixed with help from @helenarichie. While doing that I also slightly redefined hydro_utilities::Calc_Temp_DE to take the total gas energy instead of the specific gas energy and density.

src/io/io.cpp Outdated Show resolved Hide resolved
src/io/io.cpp Outdated Show resolved Hide resolved
@bcaddy bcaddy force-pushed the dev-mhdProjections branch from 2cabdc3 to ddd046e Compare January 23, 2024 19:17
src/io/io.cpp Outdated Show resolved Hide resolved
The gas energy was being loaded then checked for correctness against a
variable that didn't exist. The gas energy was also being updated when
it shouldn't be. Fixed those bugs and added MHD support to the
temperature calculations.

Also, updated the hydro_utilities::Calc_Temp_DE function to use the
total, not specific, gas energy and added documentation for clarity
@bcaddy bcaddy force-pushed the dev-mhdProjections branch from 8c7d46e to 80cd55e Compare January 23, 2024 21:22
@bcaddy bcaddy marked this pull request as ready for review January 23, 2024 21:38
src/dust/dust_cuda.cu Outdated Show resolved Hide resolved
/*!
* \brief Compute the temperature when DE is turned on
*
* \param total_gas_energy The total gas energy in the cell. This is the value stored in the grid
Copy link
Collaborator

@helenarichie helenarichie Jan 23, 2024

Choose a reason for hiding this comment

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

Might be clearer to specifically say the name of the grid_enum index where the value is stored

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

done

Copy link
Collaborator

@helenarichie helenarichie Jan 23, 2024

Choose a reason for hiding this comment

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

Also, I'm not sure that total_gas_energy is the clearest variable name. In the style guide, that's a combination of two different variable names we decided on for different forms of energy (gas_energy and total_energy). I'm a little unclear on which one would be correct to use here (we should probably clarify that in the naming guide)

Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't think we want energy_tot, since that would imply the total energy, i.e. thermal + kinetic + magnetic etc. etc. My reading of the style guide is that it should be total_gas_energy.

Copy link
Collaborator

Choose a reason for hiding this comment

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

My impression is that the total is not actually necessary, since we usually mean the total when we say any of these (energy, kinetic energy, etc.) and really what we should be doing is clarifying when we are using the specific version (i.e. the old ge should be specific_gas_energy).

Copy link
Collaborator Author

@bcaddy bcaddy Jan 23, 2024

Choose a reason for hiding this comment

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

I don't think we want energy_tot, since that would imply the total energy, i.e. thermal + kinetic + magnetic etc. etc. My reading of the style guide is that it should be total_gas_energy.

It is total_gas_energy I'm confused

My impression is that the total is not actually necessary...

Sure, but I'd rather be extra clear since the ambiguity is what led to this multi-hour debacle.

Copy link
Collaborator

Choose a reason for hiding this comment

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

In fact, I don't see energy_total anywhere in the code, and would advocate for this approach. I think gas_energy is consistent with the way this is labeled elsewhere (i.e. in reconstruction.h).

Copy link
Collaborator

@helenarichie helenarichie Jan 23, 2024

Choose a reason for hiding this comment

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

Sorry, I think I created a bit of confusion because I was still editing my comments before I realized that you guys were replying. However, I agree that the total_ isn't that clear. I think the clarification in the doc string and following what's done elsewhere in the code by calling it gas_energy should alleviate any confusion.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I've changed the variable name to gas_energy.

gas_energy is the total gas energy and specific_gas_energy is the
specific version
Now you only use magnetic variables when MHD is enabled
Copy link
Collaborator

@evaneschneider evaneschneider left a comment

Choose a reason for hiding this comment

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

I think it would be more consistent if n and T were treated the same way between the two versions (projections versus rotated projections), since in the first function d and n and T are all redefined as Real const within the loop and in the second only T is, which makes them superficially appear to be doing different things. I also think it would be clearer if the non-MHD case didn't define the empty B-fields (as we discussed offline), so that it is clear the Calc_Temp function can be called without them. Otherwise, I think this is ready to go.

@bcaddy
Copy link
Collaborator Author

bcaddy commented Jan 24, 2024

I believe those things are done now.

@bcaddy
Copy link
Collaborator Author

bcaddy commented Jan 24, 2024

Everything is passing except a single clang-tidy warning in unrelated code. I don't know why that warning didn't pop up in a previous PR but it is fixed in PR #364. IMO, either that PR should be merged in first or this one is OK to merge.

@evaneschneider evaneschneider merged commit 70341bd into cholla-hydro:dev Jan 24, 2024
9 of 10 checks passed
@bcaddy bcaddy deleted the dev-mhdProjections branch February 2, 2024 15:54
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