ESM1.5 - questions on translating ocean diag_table into yaml format

COSIMA Ocean
1

Hi everyone, I’m hoping to get some advice on setting up a diag_table for ESM1.5 via the make_diag_table script. I’ve translated the existing diag_table into a diag_table_source.yaml file here which mostly works but I’ve run into a few questions.

  1. Good settings for max_files, max_num_axis_sets, and max_axes. The new diag_table requests 273 output files, and trying to run produced errors from these parameters being exceeded. I added in the following settings to input.nml to avoid the crashes with some added wiggle room:

    &diag_manager_nml
 ... 
max_num_axis_sets = 400 
max_axes = 600 
max_files = 400 
/

    Are there any downsides with setting these values this much higher? Maybe a dumb question but I’m wondering what max_num_axis_sets vs max_axes mean?

  1. Missing outputs after translation. The existing diag_table includes these two variables:

    "ocean_model","rhobarz","rhobarz" ,"ocean_month","all",.true.,"none",2 
"ocean_model","temp_runoffmix","temp_runoffmix" ,"ocean_month","all",.true.,"none",2

    and these two variables are present in the output. The diag_table produced from the yaml file
    includes the corresponding requests:

    "ocean-2d-rhobarz-1monthly-mean-ym%4yr%2mo", 1, "months", 1, "days", "time", 1, "years" 
"ocean_model", "rhobarz", "rhobarz", "ocean-2d-rhobarz-1monthly-mean-ym%4yr%2mo", 
"all", "average", "none", 2 

"ocean-3d-temp_runoffmix-1monthly-mean-ym%4yr%2mo", 1, 
"months", 1, "days", "time", 1, "years" "ocean_model", "temp_runoffmix", "temp_runoffmix", 
"ocean-3d-temp_runoffmix-1monthly-mean-ym%4yr%2mo", "all", "average", "none", 2

    When I run the model with the new diag table, these two variables are missing from the output. I’m wondering if there’s any obvious errors that I might have made here.

  1. Missing outputs before translation. The following variables were requested in the original diag_table, but aren’t in the output when I run the original configuration

    "ocean_model","rhobarz_global","rhobarz_global"  ,"ocean_scalar","all",.true.,"none",2

"ocean_model","temp_adv_flux_x_int_z","temp_adv_flux_x_int_z"        
,"ocean_month","all",.true.,"none",2

"ocean_model","temp_adv_flux_y_int_z","temp_adv_flux_y_int_z"        ,"ocean_month","all",.true.,"none",2

"ocean_model","temp_xflux_neutral_int_z","temp_xflux_neutral_int_z"  ,"ocean_month","all",.true.,"none",2

"ocean_model","temp_yflux_neutral_int_z","temp_yflux_neutral_int_z"  ,"ocean_month","all",.true.,"none",2

"ocean_model","temp_xflux_gm_modes_int_z","temp_xflux_gm_modes_int_z" ,"ocean_month","all",.true.,"none",2

"ocean_model","temp_yflux_gm_modes_int_z","temp_yflux_gm_modes_int_z" ,"ocean_month","all",.true.,"none",2

"ocean_model","f_vis","f_vis" ,"ocean_month","all",.true.,"none",2

"ocean_model","con_temp","con_temp" ,"ocean_month","all",.true.,"none",2

"ocean_model","neutral_temp","neutral_temp"             ,"ocean_month","all",.true.,"none",2

"ocean_model","neutral_salt","neutral_salt"             ,"ocean_month","all",.true.,"none",2

"ocean_model","salt_adv_flux_x_int_z","salt_adv_flux_x_int_z"        ,"ocean_month","all",.true.,"none",2

"ocean_model","salt_adv_flux_y_int_z","salt_adv_flux_y_int_z"        ,"ocean_month","all",.true.,"none",2

"ocean_model","salt_xflux_gm_modes_int_z","salt_xflux_gm_modes_int_z" ,"ocean_month","all",.true.,"none",2

"ocean_model","salt_yflux_gm_modes_int_z","salt_yflux_gm_modes_int_z" ,"ocean_month","all",.true.,"none",2

"ocean_model","salt_xflux_overflow_int_z","salt_xflux_overflow_int_z", "ocean_month","all",.true.,"none",2

"ocean_model","salt_yflux_overflow_int_z","salt_yflux_overflow_int_z", "ocean_month","all",.true.,"none",2

"ocean_model","steep_depth","steep_depth"                     ,"ocean_month","all",.true.,"none",2

"ocean_model","slope_blayer_base","slope_blayer_base"         ,"ocean_month","all",.true.,"none",2

"ocean_model","depth_blayer_base","depth_blayer_base"         ,"ocean_month","all",.true.,"none",2

"ocean_model","surf_trans_thick","surf_trans_thick"           ,"ocean_month","all",.true.,"none",2

"ocean_model","surf_turb_thick","surf_turb_thick"             ,"ocean_month","all",.true.,"none",2

"ocean_model","surf_blayer_depth","surf_blayer_depth"         ,"ocean_month","all",.true.,"none",2

"ocean_model","export_prod","export_prod",   "ocean_bgc","all",.true.,"none",2

"ocean_model","export_inorg","export_inorg",   "ocean_bgc","all",.true.,"none",2

"ocean_model","export_prod","epn100_raw",   "ocean_bgc_mth","all",.true.,"none",2

"ocean_model","export_inorg","eparag100_raw",   "ocean_bgc_mth","all",.true.,"none",2

"ocean_model","cfc_11","cfc11_raw" ,"ocean_bgc_ann","all",.true.,"none",2

"ocean_model","cfc_12","cfc12_raw" ,"ocean_bgc_ann","all",.true.,"none",2

    I haven’t included these in the new diag_table yet, but I’m wondering whether there’s any known reason that the model wouldn’t be saving these variables.

  1. Patching variable names. The existing diag_table replaces the output_name of a few variables, e.g:

    "ocean_model", "surface_no3", "no3os_raw", "ocean-2d-surface_no3-1monthly-mean-ym%4yr%2mo", "all", "average", "none", 2

    I’ve added the same name changes to the translated yaml file, but with the one variable per file setup, it means that the nc filename and variable name don’t match. E.g:

    > ncdump -h ocean-2d-surface_no3-1monthly-mean-ym_0101_01.nc 
... 
> float no3os_raw(time, yt_ocean, xt_ocean) ;

    Does anyone know whether this could cause issues down the line for the intake/MED?

Thank you!

2

Pinging @rbeucher about question 4 relating to MED.

3

Can confirm that after adding in the variables missing from the original output (Q3) to the new yaml setup, they are still missing from the output.

4

I don’t know in detail how max_num_axis_sets, and max_axes differ. I’ve just used trial and error to determine useable values. I’m not sure if there’s a downside to excessive values but presumably it increases memory requirements. FYI this is what was done in ACCESS-OM2-01:

    max_axes          = 400
    max_files         = 300
    max_num_axis_sets = 300
2 Likes
5

“ocean-2d-rhobarz-1monthly-mean-ym%4yr%2mo”, 1, “months”, 1, “days”, “time”, 1, “years”
“ocean_model”, “rhobarz”, “rhobarz”, “ocean-2d-rhobarz-1monthly-mean-ym%4yr%2mo”,
“all”, “average”, “none”, 2

I ran a quick test on this parameter using ACCESS-OM2, and it seems to be working.

6

Are those really the linebreaks in the output from make_diag_table.py?
The field data should be a single, separate line starting with "ocean_model".

7

Does the model output log include complaints that these diagnostics are not available? Perhaps see if they exist in this (incomplete) list.

8

The missing parameters might also be due to certain parameters not being enabled during the setup, which would result in no output for some related diagnostics.

For example, in your input.nml, f_vis (the fraction of incoming shortwave in the visible range) is diagnosed only in the gfdl version, but not in the csiro version.

2 Likes
9

Apologies, I’d messed up the formatting copying and pasting. The formatting in the output from make_diag.py for these two looks like:

"ocean-2d-rhobarz-1monthly-mean-ym%4yr%2mo", 1, "months", 1, "days", "time", 1, "years"
"ocean_model", "rhobarz", "rhobarz", "ocean-2d-rhobarz-1monthly-mean-ym%4yr%2mo", "all", "average", "none", 2

"ocean-3d-temp_runoffmix-1monthly-mean-ym%4yr%2mo", 1, "months", 1, "days", "time", 1, "years"
"ocean_model", "temp_runoffmix", "temp_runoffmix", "ocean-3d-temp_runoffmix-1monthly-mean-ym%4yr%2mo", "all", "average", "none", 2
1 Like
10

Thanks for linking to the list of diagnostics. I just checked the ocean logs saved at the end of the simulation, and they don’t appear to mention any of the missing variables.

Of the missing variables, the following are mentioned in the list of MOM diagnostics:

f_vis
steep_depth
slope_blayer_base
depth_blayer_base
surf_trans_thick
surf_turb_thick

and the following aren’t listed:

rhobarz_global
temp_adv_flux_x_int_z
temp_adv_flux_y_int_z
temp_xflux_neutral_int_z
temp_yflux_neutral_int_z
temp_xflux_gm_modes_int_z
temp_yflux_gm_modes_int_z
con_temp
neutral_temp
neutral_salt
salt_adv_flux_x_int_z
salt_adv_flux_y_int_z
salt_xflux_gm_modes_int_z
salt_yflux_gm_modes_int_z
salt_xflux_overflow_int_z
salt_yflux_overflow_int_z
surf_blayer_depth
export_prod
export_inorg
export_prod
export_inorg
cfc_11
cfc_12
11

Unfortunately the reason why these are missing might be different for each case.

For example

It looks like these are only available for the ocean_nphysicsA and ocean_nphysicsB schemes, but ESM1.5 seems to use ocean_nphysicsC. I guess one of the other schemes was used at one point and the diag_table wasn’t updated when the scheme was changed.

Also,

This PR suggests that these are WOMBAT diagnostics that exist in some version of WOMBAT somewhere… I don’t know whether we should be concerned that they are not in the version we’re using?

1 Like
12

This won’t be a problem for the Intake catalog, though it’s probably not a bad idea for make_diag_table.py to use the user-defined variable name in the filename.

13

Thanks @aekiss, @minghangli, and @dougiesquire. That makes sense then why a couple of those fields weren’t being saved either before or after the using the make_diag_table.py, at least for f_vis, neutral_salt, and neutral_temp.

In that case I’m guessing the most concerning part is the rhobarz and temp_runoffmix that were saved with the old diag_table but not after using the make_diag_table.py script. Would it be useful to upload the whole diag_table and diag_table.yaml files I’ve been using?

14

yep! :slight_smile:

15

Thanks @aekiss! Hive doesn’t allow .yaml attachments and so I’ve uploaded both the old and new diag tables over here: GitHub - blimlim/diag_tables-: mom diag tables for ESM1.5 for debugging

16

It does now :slight_smile:

Feel free to complain loudly when things like that happen. Could even make a topic and tag with help

17

In that case I’m guessing the most concerning part is the rhobarz and temp_runoffmix that were saved with the old diag_table but not after using the make_diag_table.py script.

This is very odd, and may be a bug in MOM. The diag_table generated using make_diag_table.py looks fine, but it differs from the old one in specifying new_file_freq*

, 1, "years"

and using "average" instead of .true.. What happens if you make those the same as in the old diag_table?

18

Also, does your configuration use river_diffuse_temp?

19

Thanks for looking into this more @aekiss!
I dug a bit further into the previously output rhobarz and temp_runoffmix from the old diag_table. I should have looked at it earlier, but they are both zero everywhere:

download-16

and the same for rhobarz.

I also looked at the wrong log files earlier. While the MOM5 logs don’t mention these fields, the general access.err file includes:

WARNING from PE    0: diag_manager_mod::closing_file: module/output_field ocean_model/temp_runoffmix, skip one time level, maybe send_data never called

WARNING from PE    0: diag_manager_mod::closing_file: module/output_field ocean_model/rhobarz, skip one time level, maybe send_data never called

The simulations with the new diag_table don’t mention these fields in any of the logs though.

river_diffuse_temp is set to false in the ESM1.5 configs. Would this mean the temp_runoffmix field isn’t available for ESM1.5 in the first place?

It looks like temp_runoffmix is written when discharge_combine_runoff_calve = false. I think for ESM1.5 it takes the default value of true.

I had a quick look at where rhobarz is written, which I think might be here:

I couldn’t spot anything that would stop this from running, though it is good to know that data wasn’t being saved for it with the previous diag_table.