Feature to read in FVCOM lake surface conditions into FV3-LAM

[dmwright526]

DESCRIPTION OF CHANGES:

Add feature to allow user to use data generated by FVCOM in FV3-LAM as initialization of lake surface properties over the Great Lakes. FVCOM data must be interpolated to FV3-LAM grid for this routine to work. Following additions were made:

• Generated 3 new variables: USE_FVCOM, FVCOM_DIR, and FVCOM_FILE. These are user defined variables available for config.sh:
  USE_FVCOM: TRUE/FALSE flag to use FVCOM data
  FVCOM_DIR: Directory path for local FVCOM files
  FVCOM_FILE: Name of file (.nc) that contains FVCOM data

• Added to exregional_make_ics.sh to run the fortran code to replace lake surface conditions with those in FVCOM_FILE.

• Created sorc/fvcom_to_FV3 which contains fortran code to modify sfc_data.tile7.halo0.nc with new lake surface conditions. This code is not automatically compiled at this point. To compile, run the following commands:
  cd sorc/fvcom_to_FV3
  source PATH/TO/ufs-srweather-app/src/ufs_weather_model/modulefiles/MACHINE.COMPILER/fv3
  cmake .
  make
  This will create an executable (fvcom_to_FV3.exe) which should then be moved to ufs-srweather-app/exec.

TESTS CONDUCTED:

Tests have only be done on Jet using the Intel compilers. I am waiting on final version of FVCOM data interpolated to the 3km CONUS grid for final testing.

[dmwright526]

@JeffBeck-NOAA One thing to note, when using Rocoto, that make_ics will be marked as "failed" if it can't find the FVCOM data file, even though sfc_data.tile7.halo0.nc was successfully created. This probably isn't the best for an operational setting, but wanted your opinion. It could be changed to simply write a warning without a hard failure if needed.

[JeffBeck-NOAA]

@dmwright526 I'm glad you worked out the source of the climo lake surface properties! I'm curious to know the details of that if you'd be willing to send me an email. Regarding the PR:

1. If the user sets "USE_FVCOM" to true, and the workflow can't find the FVCOM NetCDF file, I think a Rocoto failure would be correct to alert the user that the sfc_data.nc file wasn't updated with the FVCOM data, right? Otherwise, I would think it's dangerous to allow the run to continue, with the user unaware (unless they saw a warning) that the FVCOM data wasn't included in the sfc_data.nc file.
2. Regarding the Fortran source code, once my large UFS_UTILS PR goes in, the /sorc directory will be removed from regional_workflow, with the final three source codes moved to UFS_UTILS. I'm wondering if you would object to including your FVCOM code in that repo? Our thought is to have all source code included in the UFS_UTILS (pre-processing), ufs-weather-model (FV3), or EMC_post (post-processing) repositories. If you are OK with that, we could then include your FVCOM build step in our build_UFS_UTILS.sh shell script in the ufs-srweather-app repo. You could open a PR in UFS_UTILS to add this code there, likely in a /sorc/FVCOM.fd directory. I'm happy to help facilitate this addition with George Gayno, the code manager for UFS_UTILS.

[dmwright526]

@JeffBeck-NOAA I will send you an email regarding the climate lake surface properties. In short, this does not answer the question regarding the smaller inland lakes. Since this routine is being run after sfc_data.tile7.halo0.nc has been created, it has already gone through the make_sfc_climo task. This routine, while could be used for other lake masks, is currently being tested for the Great Lakes only and data being generated by FVCOM/Great Lakes Operational Forecast System (GLOFS). This routine does a similar processing (with some more QC) as to what is being done with HRRRv4 for the Great Lakes.

1. My thought is failure here is fine for one-off runs/testing. It will become a problem if it is for real-time runs and the data is not available. This could be avoided by the user doing real-time runs to check for the data availability and then set the flag accordingly.

2. I don't have any problems moving this over to UFS_UTILS. I will start to look into getting a PR over there for this code. Do you want me to go ahead and remove the Fortran source code from this PR?

[JeffBeck-NOAA]

@dmwright526 Thanks for the clarification on which lakes this PR impacts! Regarding the two other points:

1. Yep, agree. Should be fine for one-offs. I will add that GSL has recently created a fork of regional_workflow to continue development for operational purposes, apart from the community-based, authoritative repo. This will enable us to make changes specific to our real-time needs, and then issue PRs back into the authoritative repo when necessary. Real-time decision tree checks on observational data availability already exist for other purposes, so that can certainly be adapted to this data too.

2. Sounds great! Yes, please feel free to remove the source code from this PR. If you'd like, you're also more than welcome to look into incorporating an automatic build step into the build_UFS_UTILS.sh script in the ufs-srweather-app repository (note that, for now, this script only exists in my PR here, but it should be merged in the next few days, I hope).

[JeffBeck-NOAA]

@dmwright526, I just tested your Hera executable and was able to complete a run with the FVCOM data. I also ran an identical case without it, and produced an 'ncdiff' of the surface file produced by chgres_cube. The appropriate variables appear to have modifications where they should (over the Great Lakes), see screenshot below.

I'll go ahead and approve this PR now. Thanks for your work on getting this implemented!

[JeffBeck-NOAA]

@dmwright526, feel free to merge at your leisure!

[dmwright526]

Thanks, @JeffBeck-NOAA! I don't have have write access for the repository, but the branch should be up to date now.

[JeffBeck-NOAA]

Thanks, @JeffBeck-NOAA! I don't have have write access for the repository, but the branch should be up to date now.

Thanks for merging develop back into your PR. I just upgraded you to have write access. Can you give it a shot by squashing and merging your PR? Thanks!