add backup calculation for orography and mask generation

[barlage]

DESCRIPTION OF CHANGES:

Current orography and mask generation fails to create a value for high resolution grids when no source inputs are contained in an FV3 grid. These changes add a backup calculation based on surrounding source grids.

The current code takes a subset of source points surrounding the fv3 grid to create a mask and orography stats based on the source points that are in the fv3 grid. The current failure happens when there are no source points in the fv3 grid. The proposed solution calculates the stats for all the source points in the subset (there will always be some) and if there are not any in the fv3 grid, it uses the full subset stats as a backup. Also the code will fail if there still is no valid value.

TESTS CONDUCTED:

See below.

DEPENDENCIES:

none

ISSUE:

Fixes issue mentioned in #714

CONTRIBUTORS:

George Gayno

[GeorgeGayno-NOAA]

I think your idea will work. Be aware that those loops are threaded, so some of your new variables will need to be declared 'private'.

[GeorgeGayno-NOAA]

@barlage Do we still want to merge this, or work to add the higher-resolution input data? If the latter, I will close this PR.

[barlage]

@GeorgeGayno-NOAA it seems there is no harm in merging this. It solves the short-term issue with high-res fire weather domain until we can get the higher resolution terrain and mask data in.

[GeorgeGayno-NOAA]

@GeorgeGayno-NOAA it seems there is no harm in merging this. It solves the short-term issue with high-res fire weather domain until we can get the higher resolution terrain and mask data in.

Ok. Be sure to merge the latest updates from 'develop' to your branch. Then I can do the final review.

[GeorgeGayno-NOAA]

Checked out the branch at 95ad0a0. Tested it on the fire weather nest where the problem was observed:

  export res=-999              # equivalent resolution is computed
  export target_lon=-118.7      # Center longitude of grid
  export target_lat=36.3       # Center latitude of grid
  export idim=350              # Dimension of grid in 'i' direction
  export jdim=350              # Dimension of grid in 'j' direction
  export delx=0.00675           # Grid spacing (in degrees) in the 'i' direction
                               # on the SUPERGRID (which has twice the resolution of
                               # the model grid).  The physical grid spacing in the 'i'
                               # direction is related to delx as follows:
                               #    distance = 2*delx*(circumf_Earth/360 deg)
  export dely=0.00675           # Grid spacing (in degrees) in the 'j' direction.
  export halo=3                # number of row/cols for halo

The problem was fixed. Additionally, I ran the code with 12 and 24 threads and got the same result.

[GeorgeGayno-NOAA]

@barlage I merged from 'develop' to your branch locally on Hera. May I push these changes to your fork on Github?

[JeffBeck-NOAA]

@DavidWright-NOAA, I'm tagging you on this PR, since @GeorgeGayno-NOAA mentioned an effort is underway at EMC to upgrade the orography climatology files for use in higher resolution simulations. My understanding is that this PR is a temporary fix in the meantime, and I wanted to get your input, as I know you've worked on a fix for these issues as well. Thank you!

[barlage]

@GeorgeGayno-NOAA sure, update as you wish. I believe you should have access.

[DavidWright-NOAA]

@JeffBeck-NOAA thank you! This fix is more robust than my ad hoc increase of LATO and LONO search distance from +1 to +2. I still have some concerns with using the lower resolution data at a 1km grid spacing for things like warm season convective initiation, but the higher resolution data should be better for that. I don't know if there should be any warning/documentation to users trying to run at these resolutions once this fix goes in?

[barlage]

Hi @JeffBeck-NOAA and @DavidWright-NOAA, this change in particular is to fix some missing values due to approximately equal input dataset resolution and model grid. Since here we are not increasing the input resolution, there are still issues with the more detailed sub-grid statistics used by the gravity wave drag routine, but GWD will not be used in the current 1.5km fire weather domain so we are hoping for a more permanent solution for that.

I have started on clarifying and making more consistent the input datasets by moving away from the binary read to netcdf described in #786. We have 7.5" terrain and land mask in hand that are more consistent with the land mask used in other routines, but are trying to bring these into orog more transparently, i.e., with netcdf files that have metadata.

[GeorgeGayno-NOAA]

I will do some final checks before merging.

[GeorgeGayno-NOAA]

Checked out the branch at 7419b13 on Hera. Successfully compiled it with Intel and GNU. All grid_gen consistency tests passed as expected.

Checked out the branch on Jet and Orion. All grid_gen consistency tests passed as expected.

[GeorgeGayno-NOAA]

Checked out branch at 7419b13 on WCOSS2. Successfully built the doxygen. Successfully built the repository in 'Debug' mode. All grid_gen consistency tests passed. All unit test passed.

Ready to merge.

[JeffBeck-NOAA]

@DavidWright-NOAA, thanks for reviewing! I agree with a warning (until higher resolution data are available) for users running at < 3 km. I think a brief comment would be sufficient in the UFS_UTILS documentation.

[GeorgeGayno-NOAA]

@DavidWright-NOAA, thanks for reviewing! I agree with a warning (until higher resolution data are available) for users running at < 3 km. I think a brief comment would be sufficient in the UFS_UTILS documentation.

Should the warning be added here? https://noaa-emcufs-utils.readthedocs.io/en/latest/ufs_utils.html#orog

Or somewhere else?

[JeffBeck-NOAA]

@DavidWright-NOAA, thanks for reviewing! I agree with a warning (until higher resolution data are available) for users running at < 3 km. I think a brief comment would be sufficient in the UFS_UTILS documentation.

Should the warning be added here? https://noaa-emcufs-utils.readthedocs.io/en/latest/ufs_utils.html#orog

Or somewhere else?

@GeorgeGayno-NOAA, I think that's the right location. A warning in the introduction referencing the datasets in 3.6.3 should be fine.

[GeorgeGayno-NOAA]

@DavidWright-NOAA, thanks for reviewing! I agree with a warning (until higher resolution data are available) for users running at < 3 km. I think a brief comment would be sufficient in the UFS_UTILS documentation.

Should the warning be added here? https://noaa-emcufs-utils.readthedocs.io/en/latest/ufs_utils.html#orog
Or somewhere else?

@GeorgeGayno-NOAA, I think that's the right location. A warning in the introduction referencing the datasets in 3.6.3 should be fine.

Is this ok? 1c3870c

[GeorgeGayno-NOAA]

@DavidWright-NOAA, thanks for reviewing! I agree with a warning (until higher resolution data are available) for users running at < 3 km. I think a brief comment would be sufficient in the UFS_UTILS documentation.

Should the warning be added here? https://noaa-emcufs-utils.readthedocs.io/en/latest/ufs_utils.html#orog
Or somewhere else?

@GeorgeGayno-NOAA, I think that's the right location. A warning in the introduction referencing the datasets in 3.6.3 should be fine.

Is this ok? 1c3870c

See: https://barlage.readthedocs.io/en/oro_mask_fill/ufs_utils.html#orog

[JeffBeck-NOAA]

Is this ok? 1c3870c

See: https://barlage.readthedocs.io/en/oro_mask_fill/ufs_utils.html#orog

I think there are concerns even with 30-arc-second data when running at 1-km resolution, as mentioned by @DavidWright-NOAA.

[GeorgeGayno-NOAA]

Is this ok? 1c3870c

See: https://barlage.readthedocs.io/en/oro_mask_fill/ufs_utils.html#orog

I think there are concerns even with 30-arc-second data when running at 1-km resolution, as mentioned by @DavidWright-NOAA.

Is this better? 7e7b70b

[JeffBeck-NOAA]

Is this better? 7e7b70b

This looks good! Thanks!