Ultra low resolution configuration for testing

[danholdaway]

Description

In order to test changes to the global-workflow system we have to run the cycled system. Currently this is done with a C48 atmosphere and 127 level / 5 degree ocean model configuration. However this is not fast enough for performing the testing and is limiting the number of pull requests that can be merged in global-workflow. Additionally the ensemble and deterministic forecasts are both run using C48, meaning we are not replicating the dual resolution setup that is used in production.

Note that the configuration does not have to produce anything scientifically sound, just be able to reliably run in order to test the connection between tasks of the workflow.

Solution

• Develop a C12 and 32 level atmosphere with 10 degree ocean configuration for the ensemble.
• Develop a C18 and 32 level atmosphere with 5 degree ocean configuration for the deterministic. If C18 is not a permissible configuration in FV3 then C24.

Note that the ocean can already by run at 5 degrees.

The data assimilation group at EMC will work on the enabling these configurations with GSI and JEDI.

[JessicaMeixner-NOAA]

@danholdaway - Please let me know if ultra-low wave configurations are also required and I'm happy to help provide those parts. (Also fine to turn off waves for various tests too).

[danholdaway]

Thank you @JessicaMeixner-NOAA I think it would be useful to include waves in this effort. We aren't currently testing with waves turned on but we should start to include that.

[junwang-noaa]

@danholdaway Our team will look into atm/ocn/ice components for the test you requested. May I ask some background questions:

1. For atmosphere, is the choice of C12/C18/C24 (800km/500km/400km resolution) coming from the running speed only or are there some other reasons? Do you have test cases with 32 vertical levels for us as a configuration reference? I am thinking that we may have to use a different atm physics package at this coarse resolution from those used for GFS/GEFS/SFS, and the dycore needs to be hydrostatic, which is different from GFS/GEFS.
2. For ocean, do you know if there is 10 degree super grid available? I assume you are OK with 5 degree ocean/ice if we can't find a 10 degree super grid
3. How long do you expect these tests to run? I assume these tests only need to run 15hrs with IAU. There might be some coupling configuration change if longer running time is expected. Thanks

[danholdaway]

Thanks for looking into this @junwang-noaa, we very much appreciate the help.

1. I had a quick play around with JEDI and found that I couldn't create a C18 geometry with FV3 so that might be out of the question. The choice of C12/C24 is driven by running speed. For most of the PRs we are creating we don't want to test what the model does but rather test the connections between the tasks of the workflow. We need the model to run from one cycle to the next and output files for the DA to pick up. If we change the model configuration, e.g. physics or non-hydro -> hydro it should be fine though we might need to be aware that we might be reading less from the files, e.g. no delz to pick up. We don't have any configuration for 32 levels yet. We thought about starting with the 127 level file and taking ~every 4th level. Do you think that would work?

2. @guillaumevernieres do you know if there exist any 10degree grids for MOM6? I think you mentioned you'd testing something at that resolution in SOCA.

3. We don't need long forecasts with the coupled model. Just long enough to cycle. I think that's just 12h with IAU.

[guillaumevernieres]

@danholdaway , we do have a 10deg grid for mom6. Something would need to be done for cice6 as well.

[DeniseWorthen]

We create the CICE6 fix files from the MOM6 supergrid and mask. We'd need a MOM_input consistent w/ a 10deg MOM6 physics.

[junwang-noaa]

@danholdaway Thanks for the information.
@guillaumevernieres Would you please share the 10deg mom6 super grid and run configuration with us?

[guillaumevernieres]

@danholdaway Thanks for the information. @guillaumevernieres Would you please share the 10deg mom6 super grid and run configuration with us?

Let me see what we have. We did that work ages ago and I don't remember if we went beyond being able to use it within soca/jedi.

[guillaumevernieres]

@DeniseWorthen , @junwang-noaa , here's link to the jcsda soca repo with hopefully all the needed bits and pieces:
https://github.com/JCSDA/soca/tree/develop/test/Data/36x17x25

[DeniseWorthen]

To utilized the cpld_gridgen utility, we need a ocean_hgrid.nc file, a topography file and a mask file for MOM6. The grid_spec file you point to seems to already be at the target resolution (17x36x35).

I see that MOM_input is asking for the super grid file GRID_FILE = "ocean_hgrid_small.nc and topography file ocean_topog_small.nc. Those are the files we'd need. Do you have those somewhere?

[guillaumevernieres]

To utilized the cpld_gridgen utility, we need a ocean_hgrid.nc file, a topography file and a mask file for MOM6. The grid_spec file you point to seems to already be at the target resolution (17x36x35).

I see that MOM_input is asking for the super grid file GRID_FILE = "ocean_hgrid_small.nc and topography file ocean_topog_small.nc. Those are the files we'd need. Do you have those somewhere?

yes, sorry, I thought these were in one of the sub-dir but apparently not. I'll get back to you when I find these files.

[guillaumevernieres]

@DeniseWorthen , the files are on MSU:

/work/noaa/da/gvernier/mom6-10geg/36x17x25

do you need the MOM.res.nc restart as well?

[junwang-noaa]

@yangfanglin do you have a physics package for the ultra low resolutions (~800km/400km) that we can use to set up the C12/C24 with 32 vertical level tests? Thanks

[DeniseWorthen]

@DeniseWorthen , the files are on MSU:

/work/noaa/da/gvernier/mom6-10geg/36x17x25

do you need the MOM.res.nc restart as well?

I don't need restarts to generate the fix files. Are you setting the land mask = 0 where depth =0 (unless you have a mask file somewhere).

[GeorgeGayno-NOAA]

Note: UFS_UTILS requires some slight updates to create low-resolution grids. This is being worked here:
ufs-community/UFS_UTILS#1000

[DeniseWorthen]

@guillaumevernieres I'm not making sense of the ocean_hgrid_small file. This should contain 2x the desired resolution, so for a final resolution of 36x17, it should be 72x34. I see 72x70 in the file.

[DeniseWorthen]

Establishing a 10-deg ocean resolution is going to play havoc w/ the naming convention and have knock-on impacts from fix file generation down through the regression test scripts and inputs etc. This is because currently we use a 3-character string to denote the ocean/ice resolution. For example, mx050 is 1/2 deg, mx100 is one deg etc. Creating a 10-deg resolution will require a 4 character string--so the 1/2 deg will need to be mx0050 and 5-deg will be mx0500 and 10-deg will be mx1000.

I wonder if a 9-deg ocean/ice resolution would be a better idea. That would be a 40x20 grid (vs 10deg = 36x17) but would avoid the issue with file naming and file regeneration, RT modifications etc.

[danholdaway]

Thanks for reporting this @DeniseWorthen. Probably not worth changing the entire naming convention for this and I think 9 degree would suffice.

[DeniseWorthen]

I've been able to create a 9-deg configuration for ocean and produce the associated CICE grid files using the ufs-utils/cpld_gridgen utility. I'll also document this in the ufs-utils PR I'll open. I have not tried to run this yet, but I'll try w/ a DATM-OCN-ICE configuration next.

The ufs-utils repo has some of the require fre-nctools available to build, but not the make_topog tool, which is also required. I found the tools were installed system-wide on Gaea-C5, so I was able to use those to do the following:

1. make the supergrid for 9deg

/ncrc/home2/fms/local/opt/fre-nctools/2024.04/ncrc5/bin/make_hgrid --grid_type tripolar_grid --nxbnd 2 --nybnd 2 --xbnd -280,80 --ybnd -85,90 --nlon 80 --nlat 40 --grid_name ocean_hgrid --center c_cell

2. make the ocean mosaic

/ncrc/home2/fms/local/opt/fre-nctools/2024.04/ncrc5/bin/make_solo_mosaic --num_tiles 1 --dir ./ --mosaic_name ocean_mosaic --tile_file ocean_hgrid.nc --periodx 360

3. make the ocean topog

/ncrc/home2/fms/local/opt/fre-nctools/2024.04/ncrc5/bin/make_topog --mosaic ocean_mosaic.nc --topog_type realistic --topog_file /ncrc/home2/fms/archive/mom4/input_data/OCCAM_p5degree.nc --topog_field TOPO --scale_factor=-1

4. make the ocean mask

ncap2 -s 'maskdpt=0.0*depth;where(depth>=10.)maskdpt=1.0;tmask=float(maskdpt);tmask(0,:)=0.0' topog.nc ocean_mask.nc
ncks -O -x -v depth,maskdpt ocean_mask.nc ocean_mask.nc
ncrename -v tmask,mask ocean_mask.nc
ncatted -a standard_name,,d,, -a units,,d,, ocean_mask.nc

@guillaumevernieres

[danholdaway]

Great progress, thank you @DeniseWorthen

[DeniseWorthen]

Well, by golly, it ran! I completed 24 hours using the DATM coupled to the 9deg MOM6/CICE6.

/work2/noaa/stmp/dworthen/CPLD_GRIDGEN/rt_349784/datm.mx900

[guillaumevernieres]

Well, by golly, it ran! I completed 24 hours using the DATM coupled to the 9deg MOM6/CICE6.

You rock @DeniseWorthen 🎉 🎉 Thanks for doing this!

[DeniseWorthen]

The next step is to generate the mapped ocean masks for the new ATM resolutions. These are used by chgres to create the oro-data and ICs. It sounds like you definitely want C12+9deg and C18/24+5deg, but there's some question of what ATM configuration (# levels, physics) will work?

George has created the required low-res C-grids, and I've created the mapped ocean masks (eg. C12.mx900.tile1.nc) on hercules here

/work2/noaa/stmp/dworthen/CPLD_GRIDGEN/rt_2310699

It seems like the best next step is to try to create the atm ICs and see if any of them run?

[LarissaReames-NOAA]

Yeah, my plan is to try using global_hyblev.l28.txt for vertical levels to create ATM ICs from existing chres_cube regression test input GFS data once we have C12.mx900 orography files. It looks like George was able to create C12mx100 files on Hera (/scratch1/NCEPDEV/da/George.Gayno/ufs_utils.git/UFS_UTILS/fix/orog.lowres) so hopefully the mx900 files shouldn't give us problems.

[DeniseWorthen]

OK, thanks. After generating the mapped ocean masks, I'm not well-versed on the process so I won't be much help.

[LarissaReames-NOAA]

I'm not sure setting a CMAKE_BUILD_TYPE in the actual rt.conf is expected. Maybe that applicable for build.sh ? @DusanJovic-NOAA would know.

Currently, we only use DEBUG flag in rt.conf to specify whether to build the executable in debug mode or not. It is used for historical reasons, the same flag was used even before we used cmake as a build system. We could get rid of it and switch to just use cmake specific flags, 'Debug' or 'Release' and set CMAKE_BUILD_TYPE directly in rt.conf, if that's what people prefer.

I don't have any problem with continuing the use of DDEBUG, but I think having the build system not override user-provided DCMAKE_BUILD_TYPE would be a very tiny but useful change. Or am I mis-understanding how it works and the two are not interchangeable?

[DeniseWorthen]

@LarissaReames-NOAA We're missing a frac_grid = .true. in the input.nml. Using that gets me back to my tracer index error.

[LarissaReames-NOAA]

@DeniseWorthen I thought it might be something like that. Thanks for debugging.

After the discussion on slack about export_fv3_v16 going away soonish, I changed the RT to use export_fv3 and modified the scheme/test accordingly. Main change was just switching to Thompson MP. I compiled the RT with -DDEBUG=ON and now have a successful C12 run here: /scratch1/NCEPDEV/stmp2/Larissa.Reames/FV3_RT/rt_148030/cpld_control_c12_intel/

I'm guessing that frac_grid option is probably set correctly in export_fv3.

[DeniseWorthen]

You'll need a place to slot in the variable to the cpld_lowres.nml.IN (assuming you'll still be using it?)

....
  frac_grid    = @[FRAC_GRID]
  cplchm       = @[CPLCHM]
....

[LarissaReames-NOAA]

Yep, you're right. I have a new test with the frac_grid line added to cpld_lowres.nml.IN here: /scratch1/NCEPDEV/stmp2/Larissa.Reames/FV3_RT/rt_545552/

[DeniseWorthen]

Both cpld_c12 and cpld_c24 now run to completion in debug mode. I'm going to now create the warmstart files and turn those tests on.

[DeniseWorthen]

@danholdaway or @guillaumevernieres Can either of you say whether the C48-5deg configuration is still desired? If we're maintaining it, I need to organize the RT input-data one way vs a different way.

[guillaumevernieres]

@danholdaway or @guillaumevernieres Can either of you say whether the C48-5deg configuration is still desired? If we're maintaining it, I need to organize the RT input-data one way vs a different way.

@DeniseWorthen , I don't see a need for it anymore but give us a day to poll the interested parties.

[DeniseWorthen]

@LarissaReames-NOAA Do we know what the CDMBWD settings should be for the C12 and C24---or is it even used w/ the physics setup you've created?

For my current tests, I set it to 1.0,1.0,1.0,1.0. I think you had it set to the C48 values.

[aerorahul]

When these are eventually used for cycling in the global-workflow, having the ocean resolution be the same between the deterministic and the ensemble will expedite cycling with hybrid DA.

[DeniseWorthen]

@aerorahul I'm afraid I don't understand---could you be more explicit as to what combinations would be most useful for your purposes?

[aerorahul]

@aerorahul I'm afraid I don't understand---could you be more explicit as to what combinations would be most useful for your purposes?

Sure.
If there is a C12 atmosphere with a 10-degree ocean/ice resolution combination, then the C24 atmosphere should also have a 10-degree ocean/ice resolution.
This is similar to C96mx500 and C48mx500; the atmosphere is at C96 and C48, but the underlying ocean/ice for both are at 5 degrees.

[DeniseWorthen]

@aerorahul I see. So currently I set the new RTs up as two new combinations: C24-5deg and C12-9deg, in addition to retaining C48-5deg.

You want:
C48-5deg (existing)
C24-9deg (new)
C12-9deg (new)

C24-5deg not needed?

[aerorahul]

@aerorahul I see. So currently I set the new RTs up as two new combinations: C24-5deg and C12-9deg, in addition to retaining C48-5deg.

You want: C48-5deg (existing) C24-9deg (new) C12-9deg (new)

C24-5deg not needed?

C48-5deg
C24-5deg (not needed, but would be used with C48-5deg for testing if it was available)
C24-9deg (needed because there is a C12-9deg)
C12-9deg

[DeniseWorthen]

@aerorahul Another question, w/rt the change I'm making in UFS-UTILS to add the 9-deg configuration. Do you need additional weights files associated w/ post to test your system?

Currently, we generate weights to go from a given tripole resolution to a "matching" rectilinear resolution (ie, mx025->1/4deg rectilinear) as well as all lower resolutions. Right now, the lowest rectilinear we map to is 5 deg. So I generate weights for mx025->5deg, but I don't know if they are used anywhere.

Do you need to extend that to 9 deg (eg mx025->9deg through to mx500->9deg)?

[aerorahul]

Don't think we will need that. Its pointless to make a 9 deg rectilinear grid from mx025. We will need mx900 -> 9 deg for sure. mx500 -> 9 deg will allow us to test multiple output grid array, but that's just plumbing (that is the purpose of these resolutions)

[DeniseWorthen]

@JessicaMeixner-NOAA I was not able to use the mod_def.uglo_900km file in the directory you pointed to (/scratch1/NCEPDEV/climate/Jessica.Meixner/LowResWave/WW3_input_data_20241206). I got a error

 WAVEWATCH III log file                                 version 7.14
 =====================================================================
                                                  date : 2025/02/10
                                                  time :  16:04:04

 *** WAVEWATCH III ERROR IN W3IOGR :
     ERROR IN READING FROM mod_def.ww3 FILE
     IOSTAT =   67     MOD DEF FILE WAS GENERATED WITH A DIFFERENT
     WW3 VERSION OR USING A DIFFERENT SWITCH FILE.
     MAKE SURE WW3_GRID IS COMPILED WITH SAME SWITCH
     AS WW3_SHEL OR WW3_MULTI, RUN WW3_GRID AGAIN
     AND THEN TRY AGAIN THE PROGRAM YOU JUST USED.

Did you create these using the develop branch (I think that has a version update). I was able to create my own though, using dev/ufs-weather-model at 8e676278

[JessicaMeixner-NOAA]

Using the develop branch, you probably do need an updated hash.

For develop, I believe the file can be found here: /work/noaa/epic/UFS-WM_RT/NEMSfv3gfs/input-data-20240501/WW3_input_data_20250114/mod_def.uglo_900km
or in the main WW3_input data

I will have both both the 900km unstructured and 9 degree structured for an upcoming WW3 hash.

[DeniseWorthen]

@aerorahul has said we don't need a 9-deg structured (ultra-low will only be for unstructured), so a 5-deg unstructured would be more useful, if you're making new mod_defs.

[JessicaMeixner-NOAA]

Creating a new 5-deg model will take creating the new unstructured grid. I unfortunately have other work to prioritize and I do not know when I'll be able to create the 5-degree grid. It will likely be a month or more.

[DeniseWorthen]

Yes, I am also putting higher-priority work aside to do this.

[DeniseWorthen]

@LarissaReames-NOAA I've been asked (@aerorahul) to create a C24-9deg ocean/ice configuration. I don't have the ATM files for that. I have the first step (the mapped ocean mask) but I need either you or @GeorgeGayno-NOAA to generate the orography and surface files. The mapped ocean masks are located

/scratch1/NCEPDEV/stmp4/Denise.Worthen/CPLD_GRIDGEN/BASELINE/900

[GeorgeGayno-NOAA]

@LarissaReames-NOAA I've been asked (@aerorahul) to create a C24-9deg ocean/ice configuration. I don't have the ATM files for that. I have the first step (the mapped ocean mask) but I need either you or @GeorgeGayno-NOAA to generate the orography and surface files. The mapped ocean masks are located

/scratch1/NCEPDEV/stmp4/Denise.Worthen/CPLD_GRIDGEN/BASELINE/900

I can generate the orog/sfc files.

[GeorgeGayno-NOAA]

Looks like I already made these files. See: /scratch1/NCEPDEV/da/George.Gayno/ufs_utils.git/UFS_UTILS/fix/orog.lowres

[DeniseWorthen]

@GeorgeGayno-NOAA Great! Got them.

[DeniseWorthen]

I'v found the oro files and the fix files for C24mx900, but I believe I still need the ICs for C24mx900. @LarissaReames-NOAA For the C24-mx500, I had copied these from a run directory you had

/scratch1/NCEPDEV/stmp2/Larissa.Reames/FV3_RT/rt_3367148/control_c24_intel/INPUT/

Did you at some point make the ATM IC (sfc_,gfs_*) for C24mx900?