Add output of ocean scalar variables for quick diagnostics

[sanAkel]

Commit Queue Requirements:

• Fill out all sections of this template.
• All sub component pull requests have been reviewed by their code managers.
• Run the full Intel+GNU RT suite (compared to current baselines) on either Hera/Derecho/Hercules
  Tested on Orion.
• Commit 'test_changes.list' from previous step
  Changes in output only, hence no changes to report here!

[santa@hercules-login-3 tests]$ ls -al test_changes.list
-rw-r--r-- 1 santa marine 0 Mar  3 19:26 test_changes.list

---

Description:

The ocean model (MOM6) part of the diag_table for SFS does not write out time averaged global means (for example global mean sea surface height).

This PR modifies the ⬆️ mentioned SFS diag_table with the addition of 3-hourly global mean values from the MOM6 ocean model; the output fields are similar to these except instead of monthly, 3-hourly. With this addition, it is trivial to plot out a time-series of global means of SST, SSS, SSH, total mass, etc; such capability allows quick diagnostics and identification of any major issues without having to read through many 2-d or 3-d files just to calculate such averages.

The memory footprint (increase) is few KB for this test case, see ⬇️ ocn_scalar_2021_03_22.nc:

[santa@hercules-login-2 MOM6_OUTPUT]$ ls  *.nc
ocean_geometry.nc  ocn_2021_03_22_09.nc  ocn_2021_03_22_21.nc  ocn_scalar_2021_03_22.nc  Vertical_coordinate.nc
ocean.stats.nc     ocn_2021_03_22_15.nc  ocn_2021_03_23_03.nc  SST_2021_03_22.nc

 [santa@hercules-login-2 MOM6_OUTPUT]$ du -h *.nc
17M     ocean_geometry.nc
16K     ocean.stats.nc
87M     ocn_2021_03_22_09.nc
87M     ocn_2021_03_22_15.nc
87M     ocn_2021_03_22_21.nc
87M     ocn_2021_03_23_03.nc
**116K    ocn_scalar_2021_03_22.nc**
1.4M    SST_2021_03_22.nc
4.0K    Vertical_coordinate.nc

Commit Message:

There is no change in MOM6 or any other components. Above simply modifies run-time configuration,

Priority:

• Normal.

Git Tracking

• Closes What global means from the ocean are of interest? NOAA-EMC/global-workflow#3274

Sub component Pull Requests:

N/A

UFSWM Blocking Dependencies:

• None

---

Changes

• No Baseline Changes.

Input data Changes:

• None.

Library Changes/Upgrades:

N/A

• Required

• No Updates

Testing Log:

• RDHPCS
  • Hera
  • Orion
  • Hercules
  • GaeaC5
  • GaeaC6
  • Derecho
• WCOSS2
  • Dogwood/Cactus
  • Acorn
• CI
• opnReqTest (complete task if unnecessary)

[sanAkel]

@NickSzapiro-NOAA, @DeniseWorthen would you able to review this PR?

[NickSzapiro-NOAA]

Thanks @sanAkel. Seems like a good idea to me. Would you mind writing/plotting the global means you get?

I would check in with @XiaqiongZhou-NOAA when modifying SFS test. Should ocn_scalar file be added to the cpld_control_sfs baseline as well (if doing so still passes opnReqTest "ORTs")?

[sanAkel]

Thanks @sanAkel. Seems like a good idea to me. Would you mind writing/plotting the global means you get?

@NickSzapiro-NOAA see ⬇️ for:

1. A listing of output variables
2. A plot of global mean SST and potential temperature.

As for:

I would check in with @XiaqiongZhou-NOAA when modifying SFS test.

👍 I plan on meeting Kate [@XiaqiongZhou-NOAA], but please note: this PR does not modify any SFS test(s). Only adds a few variables to output.

Should ocn_scalar file be added to the cpld_control_sfs baseline as well (if doing so still passes opnReqTest "ORTs")?

No, I do not think it should be added to such tests. Intention of this PR is to provide developers data for quick diagnostics.

Since you seem to agree with this addition and have no objection, would you approve this PR?

[XiaqiongZhou-NOAA]

It looks OK for me. I agree that ocn fields are not necessarily included in baseline.

[DeniseWorthen]

There is current a file produce in MOM6_OUTPUT called ocean_stats.nc containing

7:	double Layer(Layer) ;
12:	double Interface(Interface) ;
17:	double Time(Time) ;
21:	double Ntrunc(Time) ;
24:	double En(Time) ;
27:	double APE(Time, Interface) ;
30:	double KE(Time, Layer) ;
33:	double H0(Time, Interface) ;
36:	double Mass_lay(Time, Layer) ;
39:	double Mass(Time) ;
42:	double Mass_chg(Time) ;
45:	double Mass_anom(Time) ;
48:	double max_CFL_trans(Time) ;
51:	double max_CFL_lin(Time) ;
54:	double Salt(Time) ;
57:	double Salt_chg(Time) ;
60:	double Salt_anom(Time) ;
63:	double Heat(Time) ;
66:	double Heat_chg(Time) ;
69:	double Heat_anom(Time) ;

Can additional scalars be added to that file, rather than adding a new file?

[sanAkel]

There is current a file produce in MOM6_OUTPUT called ocean_stats.nc containing

7:	double Layer(Layer) ;
12:	double Interface(Interface) ;
17:	double Time(Time) ;
21:	double Ntrunc(Time) ;
24:	double En(Time) ;
27:	double APE(Time, Interface) ;
30:	double KE(Time, Layer) ;
33:	double H0(Time, Interface) ;
36:	double Mass_lay(Time, Layer) ;
39:	double Mass(Time) ;
42:	double Mass_chg(Time) ;
45:	double Mass_anom(Time) ;
48:	double max_CFL_trans(Time) ;
51:	double max_CFL_lin(Time) ;
54:	double Salt(Time) ;
57:	double Salt_chg(Time) ;
60:	double Salt_anom(Time) ;
63:	double Heat(Time) ;
66:	double Heat_chg(Time) ;
69:	double Heat_anom(Time) ;

Can additional scalars be added to that file, rather than adding a new file?

@DeniseWorthen The ocean_stats.nc is nothing but the default value for ENERGYFILE , set like this

Any modifications to what's written out to that file, which is also written to STDOUT requires code change, because what's output is coded:

• ASCII ocean_stats
• NC ocean_stats.nc

Therefore does this PR make sense to you?

[DeniseWorthen]

I have no objection in principle to adding this to one (or all) diag_tables. It might be especially useful if we ever had the capability for 'quick-look' fields generated by the RTs.

[sanAkel]

I have no objection in principle to adding this to one (or all) diag_tables.

Thanks @DeniseWorthen would you please approve it?

It might be especially useful if we ever had the capability for 'quick-look' fields generated by the RTs.

I can suggest a few options - let's chat offline ...

[jkbk2004]

merged with #2625