The model land mask passed to routine fixrdc is not correct for GLDAS data.
else ! the new gldas data. it does not have data defined at landice
! points. so for efficiency, don't have fixrdc try to
! find a value at landice points as defined by the vet type (vet).
allocate(slmask_noice(len))
slmask_noice=1.0
do i = 1, len
if (nint(vet(i)) < 1 .or.
& nint(vet(i)) == landice_cat) then
slmask_noice(i) = 0.0
endif
enddo
.......
call fixrdc(lugb,fnsmcc,kpdsmc,kpd7,mon,slmask_noice,
& smc(1,k,nn),len,iret
&, imsk, jmsk, slmskh, gaus,blno, blto
&, outlat, outlon, me)
The GLDAS data should be interpolated to model points with some land, but excluding those land points identified as permanent land ice. This is done by checking each point's vegetation type (vet). Water points are screened out by checking if the vegetation category is a negative fill value. However, newer versions of the tiled vegetation type data have a non-negative water category at non-land points. As a result, fixrdc attempts to interpolate GLDAS data to water points. This bogs down the interpolation so that running a C768 case with UFS_UTILS program global_cycle can take over 15 minutes. Normally, a C768 case should run in under one minute using one MPI task per model tile.
UFS_UTILS regression tests for the global_cycle program all passed with this fix. So, the bug does not give bad results. Rather, it is computationally inefficient.
Description
The model land mask passed to routine
fixrdcis not correct for GLDAS data.The GLDAS data should be interpolated to model points with some land, but excluding those land points identified as permanent land ice. This is done by checking each point's vegetation type (vet). Water points are screened out by checking if the vegetation category is a negative fill value. However, newer versions of the tiled vegetation type data have a non-negative water category at non-land points. As a result,
fixrdcattempts to interpolate GLDAS data to water points. This bogs down the interpolation so that running a C768 case with UFS_UTILS programglobal_cyclecan take over 15 minutes. Normally, a C768 case should run in under one minute using one MPI task per model tile.Steps to Reproduce
This bug was reported in https://github.com/NOAA-EMC/global-workflow/issues/2498
The Fix
A simple fix has been tested - initialize "slmask_noice" to "slmskl".
UFS_UTILS regression tests for the global_cycle program all passed with this fix. So, the bug does not give bad results. Rather, it is computationally inefficient.