search

ufs-community / UFS_UTILS

Utilities for the NCEP models.
Other
21 stars 104 forks source link

Chgres_cube: Lack of backwards compatibility with non-fractional grid static data #906

Closed LarissaReames-NOAA closed 4 months ago

LarissaReames-NOAA commented 5 months ago

While working on #850 I wasted quite a bit of time trying to figure out why surface.F90 was failing in the soil moisture scaling only to find out that it was because I was using older static data without fractional land use information. Did we intentionally mean for the fractional landcover updates to break attempts to generate input data using older static data? If so, we should probably add some sort of error message when older data (i.e. without fractional lane use) is detected. If we'd like to allow people to still used older static data, perhaps we could either add a namelist flag, or put in some logic to create the seamask the old way if old data is detected.

I'm open to suggestions, but I wanted to bring up this issue so others don't waste as much time as I did with this issue.

GeorgeGayno-NOAA commented 5 months ago

What hash are you using?

LarissaReames-NOAA commented 5 months ago

I'm up to date with the develop branch.

GeorgeGayno-NOAA commented 5 months ago

Sorry you ran into problems. The fractional grid chgres baselined at 7addff5 is not backwards compatible with the old orography/static data. You must use the 20231027 directories linked to by link_fixdirs.sh. Also, the coldstart files output by the latest chgres will not work with versions of the model older than https://github.com/ufs-community/ufs-weather-model/commit/02ecf10df013f8d8922480b1da4ba417efc94dbf

Is your work for the RRFS implementation? I created this branch to support that implementation.

LarissaReames-NOAA commented 5 months ago

Right, I understand in its current form that UFS_UTILS isn't backwards compatible with older static data. What I'm asking is should we have some sort of check to throw out a useful error message if we don't want to support the older static data? I don't think it's unreasonable to think I'd be the only one that might be using older static files for development or research. From what I can tell just from looking at the changes in the fractional grid PR, there's probably no way to tell just from something in the static files that they're incompatible. However, we could make a check for -999 values in target soil and vegetation type arrays (the problem values I was encountering) at the end of the interp routine and provide a useful error message if they're found.

GeorgeGayno-NOAA commented 5 months ago

Right, I understand in its current form that UFS_UTILS isn't backwards compatible with older static data. What I'm asking is should we have some sort of check to throw out a useful error message if we don't want to support the older static data? I don't think it's unreasonable to think I'd be the only one that might be using older static files for development or research. From what I can tell just from looking at the changes in the fractional grid PR, there's probably no way to tell just from something in the static files that they're incompatible. However, we could make a check for -999 values in target soil and vegetation type arrays (the problem values I was encountering) at the end of the interp routine and provide a useful error message if they're found.

Adding a check would be fine with me. I am guessing you were finding missing soil/veg values at points with land fractions greater than zero? Maybe you could add the check to routine read_static_file. https://github.com/ufs-community/UFS_UTILS/blob/develop/sorc/chgres_cube.fd/static_data.F90#L251 There the check could be applied to all files.

LarissaReames-NOAA commented 5 months ago

Right, I understand in its current form that UFS_UTILS isn't backwards compatible with older static data. What I'm asking is should we have some sort of check to throw out a useful error message if we don't want to support the older static data? I don't think it's unreasonable to think I'd be the only one that might be using older static files for development or research. From what I can tell just from looking at the changes in the fractional grid PR, there's probably no way to tell just from something in the static files that they're incompatible. However, we could make a check for -999 values in target soil and vegetation type arrays (the problem values I was encountering) at the end of the interp routine and provide a useful error message if they're found.

Adding a check would be fine with me. I am guessing you were finding missing soil/veg values at points with land fractions greater than zero? Maybe you could add the check to routine read_static_file. https://github.com/ufs-community/UFS_UTILS/blob/develop/sorc/chgres_cube.fd/static_data.F90#L251 There the check could be applied to all files.

Yes, that's correct, landmask = 1 and land fraction > 0. How do these fields differ in the new files at the points that are causing problems in the old ones?

GeorgeGayno-NOAA commented 5 months ago

Right, I understand in its current form that UFS_UTILS isn't backwards compatible with older static data. What I'm asking is should we have some sort of check to throw out a useful error message if we don't want to support the older static data? I don't think it's unreasonable to think I'd be the only one that might be using older static files for development or research. From what I can tell just from looking at the changes in the fractional grid PR, there's probably no way to tell just from something in the static files that they're incompatible. However, we could make a check for -999 values in target soil and vegetation type arrays (the problem values I was encountering) at the end of the interp routine and provide a useful error message if they're found.

Adding a check would be fine with me. I am guessing you were finding missing soil/veg values at points with land fractions greater than zero? Maybe you could add the check to routine read_static_file. https://github.com/ufs-community/UFS_UTILS/blob/develop/sorc/chgres_cube.fd/static_data.F90#L251 There the check could be applied to all files.

Yes, that's correct, landmask = 1 and land fraction > 0. How do these fields differ in the new files at the points that are causing problems in the old ones?

The updated chgres does not use landmask. It maps land-based surface fields to points with at least some land (land fraction > 0). The latest versions of the veg/soil files should also have valid values at points with a land fraction > 0. In the old files landmask is nint(land fraction). And the veg/soil files only have valid values where landmask=1. So, using the old files there will be points with land fractions > 0 and < .5 that will not have a valid veg/soil value.