Changes for CLM lake to work in CCPP SCM

[dustinswales]

@grantfirl @ligiabernardet @lulinxue @scrasmussen This PR contains changes to get the CLM lake scheme working in the SCM:

• A few more orographic IC variables needed for lake. (Lake is triggered if lake-fraction and lake-depth from the ICs are valid).
• Remove 0.5 offset in conditional applied to surface type, this is not in the FV3 io. (There are two classification methods for surface-type, "STATSGO" and "Zobler", where water is defined as 14 or 0, respectively. Adding the "0.5" would omit the LSMs that use the Zobler soil-type classification system)
• Add pieces from physics time-vary step that were added to the fv3 code, but not the scm counterpart.

Also, there is a change that I added to #473 to get the correct orographic file extension. In the UFS IC directory there are 3 sets of orographic files, oro_data, oro_data_ls, and oro_data_ss. We want to use the oro_data files, but the way the wildcard was constructed we ended up using the oro_data_ls files. I wonder if this makes an impact on the UFS case generation over land and ice? (Below are current plots, but I will rerun with the this change and report back)

Here are the mean 2D errors for the c48 ensemble, partitioned by surface type.
Ocean is great. Land is bad. Ice is terrible.

OCEAN Points:

LAND Points:

ICE Points:

ALL Points:

[grantfirl]

See ufs-community/ccpp-physics@23290c3 for original implementation.

[grantfirl]

@dustinswales I don't understand why this is needed. If one is using only ICs for LSMs (i.e. the GABLS3 canned cases), you don't need all of the orographic data. Are you saying that we need landfrac, lakefrac and lakedepth as additional variables when importing LSM ICs?

[dustinswales]

Yeah, if the LSM is coupled to a lake model, we need landfrac, lakefrac and lakedepth as ICs.
I didn't want to add a new flag for "lake_ics", so I did this. I'm open to alternatives.

[grantfirl]

It's weird that these variables are included in the "oro" files rather than the "sfc" files. I'm going to push a commit to this that needs to be tested for both a canned GABLS3 case and a UFS lake case to make sure that it's doing the right thing. As-is, this will break the GABLS3 canned cases, I think.

[grantfirl]

I'm going to test it real quick before I try to "fix" anything.

[grantfirl]

@dustinswales Please see dustinswales#13.

[grantfirl]

Regarding the oro data file, I think this code was written before Mike Toy changed the data to be divided into ss, ls, etc, so, yes we need to double check that we're reading in the data as expected. We may need to double check that we're not supposed to be linking files differently in the run script when various GWD options are being used.

[dustinswales]

Regarding the oro data file, I think this code was written before Mike Toy changed the data to be divided into ss, ls, etc, so, yes we need to double check that we're reading in the data as expected. We may need to double check that we're not supposed to be linking files differently in the run script when various GWD options are being used.

Dang. The GWD scheme making things simple for us once again!
(I wasn't aware of the linking of files, which complicates things).

[grantfirl]

Regarding the oro data file, I think this code was written before Mike Toy changed the data to be divided into ss, ls, etc, so, yes we need to double check that we're reading in the data as expected. We may need to double check that we're not supposed to be linking files differently in the run script when various GWD options are being used.

Dang. The GWD scheme making things simple for us once again! (I wasn't aware of the linking of files, which complicates things).

@dustinswales @ligiabernardet OK, after looking into this a bit, I think that your fix is fine, as long as it is reading in the oro_data files by default and not, oro_data_ls, as you said. According to https://github.com/NOAA-EMC/fv3atm/blob/927261d3916c8e96e7ebe38fe86f06f7aab0abc2/io/fv3atm_restart_io.F90#L611, it looks like for some GWD options, the data in oro_data_ls replaces some of the data in oro_data and adds additional variables from oro_data_ss. Since this depends on runtime options, and the UFS_case_gen script isn't really even part of the SCM "workflow" (i.e. the cases are generated and then used for a variety of physics configurations, in addition to the configuration used in UFS), this is a tough problem to solve. My thinking is that after the release, we should provide an option to follow the logic in fv3atm_restart_io.F90 and use the data from oro_data_ls/ss if a script flag is set, just so that it is at least possible to create a case with oro_data_ls/ss.

Regarding differences from the oro data introduced in our analysis, I agree that it can certainly be adding to differences that we see. I.e. if the script, before your fix, is using data from oro_data_ls files, but the UFS run expected data from oro_data files, that could certainly cause "extra" differences. It is also possible that the UFS run expected data from oro_data_ls (as was apparently being done by our script before the fix), but it ALSO expected the additional variables from oro_data_ss, which we were never reading in, so how "wrong" our SCM runs are depend son what was used for GWD physics in the UFS run and what is subsequently used for GWD physics in the SCM.

With your fix, we will definitely be reading in the oro_data files, as intended, but it's possible that this will still be "wrong" given how GWD physics were run in the UFS. Unless/until we fix this, we should probably have a caveat in our release notes that the UFS_case_gen.py is only suited to run GWD physics that don't take oro_data_ll/ss into account.

[dustinswales]

@grantfirl Thanks for the background information. I'm either still confused, or this makes no sense?
The orographic _ls/_ss files are read in during the restart step, not with the other oro data in fv3atm_oro_io.F90? (why o why)

For simplicity, SCM simulations cold-start when using a suite with an LSM. Recall that restart data is not read in as part of the case generation script, since it would be a modest amount of work to add this.

[grantfirl]

@grantfirl Thanks for the background information. I'm either still confused, or this makes no sense? The orographic _ls/_ss files are read in during the restart step, not with the other oro data in fv3atm_oro_io.F90? (why o why)

For simplicity, SCM simulations cold-start when using a suite with an LSM. Recall that restart data is not read in as part of the case generation script, since it would be a modest amount of work to add this.

sfc_prop_restart_read() looks like it is called for both cold starts and warm starts, so, oro_data is read first, then if conditions are met, oro_data_ls replaces some of the data, then oro_data_ss adds additional data. When lsm_ics is True in the SCM, it is supposed to be using all of the data that is read in from LSM ICs (which come from the UFS_case_gen script). So, even though it is a "cold start", it is using read-in data regardless.

[grantfirl]

Looks good!

[grantfirl]

@dustinswales NCAR/ccpp-physics#1080 is merged. Please revert .gitmodules and update ccpp-physics submodule pointer to NCAR/ccpp-physics@62f7656