missing oro data to run Noah MP suite

Submitted by helin.wei on Thu, 04/15/2021 - 19:35

Hi Grant,


I tried to run the case with Noah MP with SCM v5:

run_scm.py -c fv3_model_point_noahmp -s SCM_GFS_v16beta_noahmp

The run was stopped with this message:

Setting internal physics variables from the orographic section of the case input file (scalars)...
The variable 'oro' in the case data file had missing data, but it is required for the given physics configuration. Stopping...

Have anyone successfully run this case before?




This answer may be confusing, so bear with me. 

As of v5, the way that the extra NoahMP variables are initialized has changed since the case fv3_model_point_noahmp was created, so that case is now obsolete. It had contained the same initial conditions as the fv3_model_point_noah case, but it also had the NoahMP variables written out as part of the UFS_IC_generator.py script. In v5, the SCM expects to read in the regular Noah LSM initial conditions, and it runs the NoahMP cold start algorithm that had been in FV3GFS_io.F90 in FV3 as part of the physics setup if NoahMP is in the suite being used. So, this case has not been updated to use changes to the case input data files in the past year or so, which is why you're getting the error, so I'm going to delete it from the repository: https://github.com/NCAR/ccpp-scm/issues/253

By running

run_scm.py -c fv3_model_point_noah -s SCM_GFS_v16beta_noahmp

you should be able to run the exact same case that had been represented by fv3_model_point_noahmp, except now the extra NoahMP variables are initialized within the SCM code, as I explained above.

As of the latest "master" code, the way the extra NoahMP variables are initialized has changed yet again, since the extra NoahMP variables can now be initialized in the init phase of the GFS_phys_time_vary interstitial scheme within the physics. So, now, the SCM is not doing anything special to initialize the extra NoahMP variables -- it is all handled in the physics. Running the case as above should still work in the latest "master" code.

To summarize, if you're wanting to try the example FV3 initial condition case, use the fv3_model_point_noah case. If you're using v5, the extra NoahMP variables are initialized in the SCM code. In the master branch of SCM (and in future releases) the extra NoahMP variables are initialized within the physics.




In reply to by grantf



Thanks for your explanation. That really helps. I just tested. It works for both v5 and master version.

Now  I have another question about UFS_IC_generator.py. Since Noah MP initialization is taken place in the physics now, the ICs will be the same for both running Noah and Noah MP cases. So I just need to use UFS_IC_generator.py to create ICs for Noah, and then they can be used for Noah MP cases, right?





In reply to by helin.wei

Yes, you are correct. If using UFS_IC_generator.py, you should never need to specify --noahmp (or -mp) anymore. As long as Noah ICs are present, both for v5 and master, you should be able to run NoahMP using the cold start initialization algorithm, which exists either in the SCM code for v5 or the physics for master and future releases.

If only the initial forcing is provided like this case, the whole integration (runtime = 86400 in fv3_model_point_noah.nml) will be like free forecast Anning mentioned in other thread? If I want to create forcing every 3hr from UFS, is it easy to modify UFS_IC_generator.py to get this done? Thanks.