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

Reduce ocean output fields #6095

Merged

Conversation

mark-petersen
Copy link
Contributor

@mark-petersen mark-petersen commented Dec 2, 2023

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]

<config_AM_eddyProductVariables_enable>.true.</config_AM_eddyProductVariables_enable>
<config_AM_eddyProductVariables_enable>.false.</config_AM_eddyProductVariables_enable>
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 this is okay for now but we might want it off for some meshes and on of others in the future.

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 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.

Copy link
Contributor

@xylar xylar left a 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"/>')
Copy link
Contributor

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?

Copy link
Contributor

@xylar xylar Dec 2, 2023

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?

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor

@vanroekel vanroekel left a 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

@mark-petersen
Copy link
Contributor Author

Ran a sanity test, passes SMS_D.T62_oQU120_ais20.MPAS_LISIO_TEST.chrysalis_gnu. Also compiled and launched PEM_Ln9.ne30pg2_EC30to60E2r2.WCYCL1850.chrysalis_intel. It's still in the queue, but produced the namelist and streams options that I expected.

@mark-petersen
Copy link
Contributor Author

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:

pwd
/lcrc/group/e3sm/ac.mpetersen/scratch/chrys/SMS_Ld62.T62_oQU240.GMPAS-IAF.chrysalis_gnu.20231204_152443_hge2j2/run
(dev_compass_1.2.0-alpha.6) chr:run$ ncdump -h SMS_Ld62.T62_oQU240.GMPAS-IAF.chrysalis_gnu.20231204_152443_hge2j2.mpaso.hist.am.timeSeriesStatsMonthly.0001-02-01.nc |grep -i float|grep Times
	float timeMonthly_avg_velocityZonalTimesTemperature_MLE(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_velocityMeridionalTimesTemperature_MLE(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_velocityZonalTimesSalinity_MLE(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_velocityMeridionalTimesSalinity_MLE(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_velocityZonalTimesTemperature_GM(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_velocityMeridionalTimesTemperature_GM(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_normalGMBolusVelocityTimesTemperature(Time, nEdges, nVertLevels) ;
	float timeMonthly_avg_velocityZonalTimesSalinity_GM(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_velocityMeridionalTimesSalinity_GM(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_normalGMBolusVelocityTimesSalinity(Time, nEdges, nVertLevels) ;

@mark-petersen
Copy link
Contributor Author

I ran these tests.

./create_test SMS_Ld62.T62_oQU240.GMPAS-IAF.chrysalis_gnu -q acme-small --walltime 1:00:00
./create_test SMS_Ld62.T62_oQU240.GMPAS-IAF.chrysalis_intel -q acme-small --walltime 1:00:00

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 timeSeriesStatsMonthly netcdf file. You can see the results of my test here:

pwd
/lcrc/group/e3sm/ac.mpetersen/scratch/chrys/SMS_Ld62.T62_oQU240.GMPAS-IAF.chrysalis_gnu.20231204_160734_by1l3f/run
$ f=SMS_Ld62.T62_oQU240.GMPAS-IAF.chrysalis_gnu.20231204_160734_by1l3f.mpaso.hist.am.timeSeriesStatsMonthly.0001-02-01.nc
$ ncdump -h $f |grep Times |grep nCells
$ ncdump -h $f |grep Squa

This is now fully tested.

@mark-petersen
Copy link
Contributor Author

We now have a total of 40 3D fields for low resolution runs, as follows:

details:

pwd
/lcrc/group/e3sm/ac.mpetersen/scratch/chrys/SMS_Ld62.T62_oQU240.GMPAS-IAF.chrysalis_intel.20231204_164954_6gah5l/run
(dev_compass_1.2.0-alpha.6) chr:run$ f=SMS_Ld62.T62_oQU240.GMPAS-IAF.chrysalis_intel.20231204_164954_6gah5l.mpaso.hist.am.timeSeriesStatsMonthly.0001-02-01.nc
(dev_compass_1.2.0-alpha.6) chr:run$ ncdump -h $f |grep 'nCells, nVertLevels'|wc
     35     175    3770
(dev_compass_1.2.0-alpha.6) chr:run$ ncdump -h $f |grep 'nCells, nVertLevels'
	float timeMonthly_avg_velocityMeridional(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_velocityZonal(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_layerThickness(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_density(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_potentialDensity(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_frazilLayerThicknessTendency(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_vertVelocityTop(Time, nCells, nVertLevelsP1) ;
	float timeMonthly_avg_vertMLEBolusVelocityTop(Time, nCells, nVertLevelsP1) ;
	float timeMonthly_avg_vertGMBolusVelocityTop(Time, nCells, nVertLevelsP1) ;
	float timeMonthly_avg_GMBolusVelocityZonal(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_GMBolusVelocityMeridional(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_frazilTemperatureTendency(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_vertDiffTopOfCell(Time, nCells, nVertLevelsP1) ;
	float timeMonthly_avg_vertViscTopOfCell(Time, nCells, nVertLevelsP1) ;
	float timeMonthly_avg_tendLayerThickness(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_BruntVaisalaFreqTop(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_activeTracersTend_temperatureTend(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_activeTracersTend_salinityTend(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_activeTracerHorizontalAdvectionTendency_temperatureHorizontalAdvectionTendency(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_activeTracerHorizontalAdvectionTendency_salinityHorizontalAdvectionTendency(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_activeTracerVerticalAdvectionTendency_temperatureVerticalAdvectionTendency(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_activeTracerVerticalAdvectionTendency_salinityVerticalAdvectionTendency(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_activeTracerVertMixTendency_temperatureVertMixTendency(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_activeTracerVertMixTendency_salinityVertMixTendency(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_activeTracerHorMixTendency_temperatureHorMixTendency(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_activeTracerHorMixTendency_salinityHorMixTendency(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_activeTracerSurfaceFluxTendency_temperatureSurfaceFluxTendency(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_activeTracerSurfaceFluxTendency_salinitySurfaceFluxTendency(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_temperatureShortWaveTendency(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_activeTracerNonLocalTendency_temperatureNonLocalTendency(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_activeTracerNonLocalTendency_salinityNonLocalTendency(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_activeTracerVerticalAdvectionTopFlux_temperatureVerticalAdvectionTopFlux(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_activeTracerVerticalAdvectionTopFlux_salinityVerticalAdvectionTopFlux(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_activeTracers_temperature(Time, nCells, nVertLevels) ;
	float timeMonthly_avg_activeTracers_salinity(Time, nCells, nVertLevels) ;
(dev_compass_1.2.0-alpha.6) chr:run$ ncdump -h $f |grep 'nEdges, nVertLevels'|wc
      5      25     555
(dev_compass_1.2.0-alpha.6) chr:run$ ncdump -h $f |grep 'nEdges, nVertLevels'
	float timeMonthly_avg_normalVelocity(Time, nEdges, nVertLevels) ;
	float timeMonthly_avg_normalMLEvelocity(Time, nEdges, nVertLevels) ;
	float timeMonthly_avg_normalGMBolusVelocity(Time, nEdges, nVertLevels) ;
	float timeMonthly_avg_activeTracerHorizontalAdvectionEdgeFlux_temperatureHorizontalAdvectionEdgeFlux(Time, nEdges, nVertLevels) ;
	float timeMonthly_avg_activeTracerHorizontalAdvectionEdgeFlux_salinityHorizontalAdvectionEdgeFlux(Time, nEdges, nVertLevels) ;

@mark-petersen
Copy link
Contributor Author

Looking at the output fields in the actual tests, I see two we didn’t discuss:

float timeMonthly_avg_GMBolusVelocityZonal(Time, nCells, nVertLevels) ;
float timeMonthly_avg_GMBolusVelocityMeridional(Time, nCells, nVertLevels) ;

These do not appear in MPAS-Analysis and could be computed with a post-processing step from

float timeMonthly_avg_normalGMBolusVelocity(Time, nEdges, nVertLevels) ;

which is recorded. Are there opinions about keeping these? I think it is a convenience versus disk space issue.

@xylar
Copy link
Contributor

xylar commented Dec 5, 2023

Thanks for noticing these. I think they should be removed.

Copy link
Contributor

@alicebarthel alicebarthel left a 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

@jonbob jonbob added the NML label Dec 6, 2023
jonbob added a commit that referenced this pull request Dec 6, 2023
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]
@jonbob
Copy link
Contributor

jonbob commented Dec 6, 2023

passes:

  • PEM_Ln9.ne30pg2_EC30to60E2r2.WCYCL1850.chrysalis_intel

with expected NML DIFF. Merged to next

@jonbob jonbob merged commit 16f7148 into E3SM-Project:master Dec 7, 2023
3 checks passed
@jonbob
Copy link
Contributor

jonbob commented Dec 7, 2023

merged to master and expected NML DIFFs blessed

@rljacob rljacob added this to the v3.0.0-rc milestone Jan 25, 2024
@rljacob rljacob modified the milestones: v3.0.0-rc, v3.0beta03 Feb 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BFB PR leaves answers BFB mpas-ocean NML
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants