-
Notifications
You must be signed in to change notification settings - Fork 374
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
Reduce ocean output fields #6095
Reduce ocean output fields #6095
Conversation
<config_AM_eddyProductVariables_enable>.true.</config_AM_eddyProductVariables_enable> | ||
<config_AM_eddyProductVariables_enable>.false.</config_AM_eddyProductVariables_enable> |
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 this is okay for now but we might want it off for some meshes and on of others in the future.
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 we can put this on the back burner until we develop the RRS6to18 compset for v3, then we'll want to have the mesh specific enabling.
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.
This looks like what we've been able to agree to. Thanks @mark-petersen!
@@ -1222,7 +1219,6 @@ def buildnml(case, caseroot, compname): | |||
lines.append(' <var name="iceRunoffFlux"/>') | |||
lines.append(' <var name="rainFlux"/>') | |||
lines.append(' <var name="snowFlux"/>') | |||
lines.append(' <var name="vertNonLocalFlux"/>') |
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.
Sorry, I don't remember the discussion on this one: is it possible this is needed for budget calculations?
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 couldn't find it in any budget calculations involving vertNonLocalFlux
in E3SM:
https://github.com/search?q=repo%3AE3SM-Project%2FE3SM%20vertNonLocalFlux&type=code
Could there be any that are post-processed? Even if so, it this something we want to support in every simulation?
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.
yes, I am also not sure how we would use that variable, to be honest. Just making sure.
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.
vertNonLocalFlux
is easily recalculable from the surface flux field and the boundary layer depth, no need to keep this. It is only for simulations where we want to reconstruct turbulent fluxes of heat and salinity, so definitely specialized.
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.
This looks good to me. Thanks @mark-petersen
Ran a sanity test, passes |
Please wait on this PR. I ran a two month test and these variables are still in the time monthly output. I think it is because they were mistakenly put in two packages. details:
|
I ran these tests.
I found that I had to remove the second package, as well as remove variables from the stream for all of the undesired variables to be removed from the
This is now fully tested. |
We now have a total of 40 3D fields for low resolution runs, as follows: details:
|
Looking at the output fields in the actual tests, I see two we didn’t discuss:
These do not appear in MPAS-Analysis and could be computed with a post-processing step from
which is recorded. Are there opinions about keeping these? I think it is a convenience versus disk space issue. |
Thanks for noticing these. I think they should be removed. |
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.
This looks good to me given our discussions. Thanks @mark-petersen
Reduce ocean output fields This PR reduces the number of variables written in the time-averaged monthly output. It is the result of discussions with the ocean modeling team. This removes the 3D fields zMid and gmKappaScaling, as well as several 2D fields. We decided to turn off the eddy product variables analysis member by default, which saves a large number of 3D fields. These are all variables with 'Times' and 'Squared' in the name, which is up to 20 3D fields, depending on whether GM and the mesoscale eddy parameterization are on. Eddy product variables are typically used at high resolution to compute eddy kinetic energy and similar fields. They are not typically needed at lower resolutions or during spin-up. [NML] [BFB]
passes:
with expected NML DIFF. Merged to next |
merged to master and expected NML DIFFs blessed |
This PR reduces the number of variables written in the time-averaged monthly output. It is the result of discussions with the ocean modeling team, as documented on this confluence page.
This removes the 3D fields zMid and gmKappaScaling, as well as several 2D fields. We decided to turn off the eddy product variables analysis member by default, which saves a large number of 3D fields. These are all variables with 'Times' and 'Squared' in the name, which is up to 20 3D fields, depending on whether GM and the mesoscale eddy parameterization are on. Eddy product variables are typically used at high resolution to compute eddy kinetic energy and similar fields. They are not typically needed at lower resolutions or during spin-up.
[NML]
[BFB]