Coupled branch easily run with different resolutions

[arunchawla-NOAA]

The coupled crow feature branch should be able to be easily run with different resolutions. This should be as configurable as possible and we should have documentation on what to change.

These are the minimum resolutions that we need to support

1. C384-1/4 ocean/ice-1/2 wave
2. C192-1/2 ocean/ice-1/2 wave
3. C96-1 ocean/ice-1 wave

[pjpegion]

I have the modifications and a case file to run C96-1-deg ocn/ice that i will add into the workflow. It will require some additions to certain fix directories, and staging of the initial conditions. I have already interpolated the ocean and ice ICS to 1-degree for all of the prototype dates, and will have to fill out the atmosphere dates.
I have two issues that I am not sure how to deal with:
1st issue the separate post processing step that creates 1/4 degree and 1-degree output, and I am not sure how to disable creating 1/4 output. Instead, I added inline post to the model and this is activated by pointing to a new workflow file (layout/free_forecast_gfs_no_post.yaml). But the problem there is the workflow is hardcoded to check to see if we are using layout/free_forecast_gfs.yaml to trigger only running 00z forecasts. When I use the no_post yaml file, the workflow wants to also run a 06z initialization. This logic is in workflow/runtime/suite.yaml and I am not sure how to fix this.

2nd issue is that I disabled running with the wave model since I do not know how to make it run at a lower resolution. The 1-degree atm/ocn/ice can run on 80 processor and take about 5 minutes a day. When I added the wave component, I increased to 120 processors and the model slowed to about 10 minutes a day.

[arunchawla-NOAA]

@BrianCurtis-NOAA and @pjpegion what is the status of this?

[BrianCurtis-NOAA]

I've been looking through the code understanding where the PyYAML calls the python and how the process goes from start to finish with the CROW components. It may help me to sit down with someone more familiar with the workings and have a more interactive discussion.

[pjpegion]

no one responded to my issues/questions

[JessicaMeixner-NOAA]

Just an FYI if lower resolutions of the atm model also want to be run with fewer than 127 levels, which is possible, in workflow/config/fcst.yaml the definition of launch level needs to be updated to be the calculation as it is in the develop branch in the config system there. Sorry about that.

[BrianCurtis-NOAA]

fcst.yml in coupled-crow workflow/config has

#export launch_level=27
#This should be: export launch_level=$(echo "$LEVS/2.35" |bc)
# hard coding for 128 LEVS for now:
export launch_level=54

Is there a reason we haven't just uncommented the export with the calculation?

Couldn't we just do something like:

  level_127: !FirstTrue
    - when: !calc doc.fv3_gfs_settings.LEVS==128
      do: !expand |
         export launch_level=54
         export  tau=5.0
         export  rf_cutoff=7.5e2
         export  d2_bg_k1=0.20
         export  d2_bg_k2=0.04
    - otherwise: ""
  
  level_63: !FirstTrue
    - when: !calc doc.fv3_gfs_settings.LEVS==64
      do: !expand |
         export launch_level=27
         export  tau=5.0
         export  rf_cutoff=7.5e2
         export  d2_bg_k1=0.20
         export  d2_bg_k2=0.04
    - otherwise: ""

I imagine there's a simpler way without duplicating code?

[JessicaMeixner-NOAA]

That's a great question @BrianCurtis-NOAA. I don't remember why the calculation didn't work - but I don't think it did (and I really think I would have tried it before commenting it out, but maybe I didn't). That's the calculation in the develop branch configuration system.

I do think you could do what you suggested. I could see the potential downside of what you suggested is it'd be a fixed/duplicated code for each LEVS option. I don't know if people choose any number of LEVS and if we need that flexibility or not.

[WalterKolczynski-NOAA]

I'm testing a better way right now.

[BrianCurtis-NOAA]

@pjpegion I can't say I am confident, but I hope these help move you forward with your questions:

I have two issues that I am not sure how to deal with:
1st issue the separate post processing step that creates 1/4 degree and 1-degree output, and I am not sure how to disable creating 1/4 output. Instead

I have not seen your specific case file, but in the post section there is a master_grid setting that according to schema/post.yaml can be 1deg, 0p5deg, 0p25deg or 0p125deg. I wonder if that will set what output grid you're looking for?

But the problem there is the workflow is hardcoded to check to see if we are using layout/free_forecast_gfs.yaml to trigger only running 00z forecasts. When I use the no_post yaml file, the workflow wants to also run a 06z initialization.

In suite.yaml it shows you can set gfs_cyc to 1 to use the gfs_clock_1 which will only run 0z i am guessing since the time delta is 24 hours, does that answer this?

Once again, hope this helps move forward a bit more with this.

[aerorahul]

According to @WalterKolczynski-NOAA, the issue is not in running of the various resolutions of the coupled model.
The issue is with generating/providing staged IC's for the resolution.
Does the utility scripts have the capability of generating IC's for a given resolution for the various components (similar to chgres for Atm)?

The scope of this issue has changed. Closing. Will open a new one with the correct scope.