LDT and LIS (possible) domain mismatch

[pratiman-91]

Bug Description

I have generated the parameters files and metforcings for noahmp401 using LDT. Both the LDT and LIS domains are of the same gridpoints. However, I am getting this error when Spatial interpolation method (met forcing): "none" in LIS:

[INFO] == NO spatial transform of input forcing (only subset may occur). 
 ERR MSG: The number of *subsetted* row or column points
           EXCEEDS the total *global* row or column points 
           for the input parameter file, respectively.
  
   - The subsetted, global row points ::         120 >      -40076
  
   Please check your specified upper-right corner longitude and 
    latitude extents, especially if you have entered a gridcell 
    resolution that does not divide *nicely* into a 1-deg gridcell.
   Program stopping ...
 [ERR] endrun is being called

and Spatial interpolation method (met forcing): "bilinear" in LIS:

.//FORCING/200101/LDT_HIST_200101040000.d01.nc
  - Reading and spatially reprojecting forcing fields - 
  Done reading and spatially reprojecting forcing fields - 
 [ERR] SW radiation is negative!!
 [ERR] sw=  -4685.05957     ... negative
 [ERR] LDT-generated SWdown=  -9999.00000    
 [ERR] endrun is being called

Steps to Replicate

File required to replicate:
ldt_config_noahmp401_params.txt [LDT Config File for NoahMP401 Parameters]
ldt_config_princeton.txt [LDT Config File for Princeton Forcings]
ldtlog_params.txt [LDT log file for Parameters]
ldtlog_princeton.txt [LDT log file for Forcings]
lis_config_noahmp401.txt [LIS Config File]
lislog_1.txt [LIS log file for ERR 1]
lislog_2.txt [LIS log file for ERR 2]
FORCING.zip [LDT output forcings]
lis_input.noah401.d01.zip [LDT output parameteres]

It seems like there is a possibility of a domain mismatch between LDT and LIS. I have also tried with the overlay with original Princeton forcings which works.

[bmcandr]

Hi @pratiman-91, thanks for the detailed report. I have converted this Issue to a Discussion until we can confirm it is indeed a bug.

[karsenau]

Hi @pratiman-91,

I went through most of the LDT and LIS config files and log files that you provided, and I also went through trying to process each step with them.

I ran into the same error as you have in your "lislog_2.txt" file. I believe that this is mainly caused by processing the Princeton forcing output with LDT to daily output files, which may have caused some solar radiation values to result in negative values near the early morning / late evening somewhere in the domain.

Also, NoahMP401, will have a problem with daily files and a daily model timestep. NoahMP should be run with an hourly or less timestep, and it is not set up like VIC, which can run on daily model timesteps (in the water balance mode).

See if switching to 3-hourly forcing output and, at least, 1-hourly, NoahMP model timestep helps.

[pratiman-91]

@karsenau Thank you for your work and advice. I will work on the recommendations and will update you.

[pratiman-91]

Hi @karsenau,

I tried 3-hourly forcing outputs from LDT and 15-min, 30-min, 1-hourly, and 3-hourly Noah-MP model timesteps. Unfortunately, the results remain the same (SW radiation is negative!!) for the 15-min and 30-min timesteps. However, for the 1-hourly and 3-hourly timesteps, the error is different:

undefined value found for forcing variable tair in NoahMP401
 for tile            1 latitude =    20.1250000     longitude =   -105.375000

Yes, I confirm that there is an undefined value of tair over that point. However, LIS should not be looking over there, as it is out of land and domain mask.

Kindly suggest.

[karsenau]

Hi @pratiman-91,

I looked a bit closer at your situation and have a couple of new insights, based on how the forcing reader in LIS was originally written. When originally developed, the design of the metforcing reader, "LDT-generated", was to provide flexibility of reading in any LDT "FORCING" directory, netcdf-formatted files, so the user wouldn't have to enter all the information again in the lis.config file, but it would be pulled ideally from the LDT-generated netcdf files themselves.

With that, the original design used a "CONSTANT" landcover type and landmask, so the meteorological forcing could expand beyond continental land boundaries, for interpolation cases, like budget-bilinear.

The point where the run is stopping actually has a landmask (and domainmask) point. You selected "bilinear" for the interpolation method and was taking information from neighboring points to perform the downscaling. However, you are running on the same domain that you processed the forcing files onto, thus either "neighbor" or "none" would be the most proper options to select from.

I traced down the problems of going with "neighbor" and "none". By not imposing a landmask on the processed metforcing files via LDT, you shouldn't run into the issues you encountered. However, in tracking down this issue, I have found a possible bug in the code that may have shown up later (after the original implementation), and I am working on a solution now for that.

So take a look and test what I've shared so far, and use a "CONSTANT" landcover source, given the below options:

Landcover data source: "CONSTANT"
Landcover classification: "UMD" # Enter land cover classification type
Landcover file: none # Landcover map path
Landcover spatial transform: neighbor # none | mode | neighbor | tile
Landcover fill option: neighbor # none | neighbor (Not needed if creating landmask)
Landcover fill radius: 1
Landcover fill value: 1
Landcover map projection: latlon

I will pass along soon and try to commit the code update(s), when they are completed with testing.

Thanks again!

[pratiman-91]

Thanks, @karsenau, for the details. I will try to implement it. However, it might take some time, as I am busy with other commitments.