Persistent wind speed interpolation issue when using MPI-ESM1-2-HR data as input

[shellyzh]

sup3r_fwp_step1_log.zip

Bug Description
Sup3rcc keeps failing to interpolate windspeed at 100m and 200m levels due to NaN in outputs, when using MPI-ESM1-2-HR data as inputs.

Full Traceback
MPI-ESM1-2-HR daily data was downloaded from ESGF MetaGrid website: https://aims2.llnl.gov/search. The full list of variables are as follows:

However, when running fwp_step1, the wind speed interpolation at 100m and 200m keeps reporting errors due to NaN in outputs. The screenshot below shows the tail part of the log, and the full logs are attached for reference.

In comparison, the code works fine when using GFDL-ESM4 as input. The only difference between the two input data are whether the ua, va, zg data are masked. I used my preprocessing codes to mask out areas where surface pressure is lower than the pressure levels, but the issue persists. Therefore, I wonder if there are any issues with the interpolation code which could possibly be creating the NaN values? Are there any ways to fix this issue?

System:
OS: CentOS Linux 7 (Core)
CPE OS Name: cpe:/o:centos:centos:7
Kernel: Linux 3.10.0-957.27.2.el7.x86_64
Architecture: x86-64
CPU: Intel Xeon Gold 6230R
Compute hardware: on-premises HPC

[grantbuster]

Sounds like you're setting 4D windspeed values to NaN when zg<orog. While this makes sense in theory, you can imagine how this would create NaN when interpolating to ws at a height just above surface. We recommend using the raw ua/va/zg values from the GCM even if the levels are technically below surface.

There are actually a few GCMs that do what you're doing (NaNs below surface). I think MRI-ESM-2.0 and the CESM models. We had to patch the raw CMIP6 data from these models (see attached notebook). If my memory serves, i think we used the uas/vas fields to fill any data where the levels were below orog. I feel like there may have been issues filling zg because the interpolator will fail if you have multiple zg values at the exact same level but i can't remember if we solved that in the code or in the notebook.

So our recommendations: 1) maybe most precise, fill your ua/va/zg levels below surface with uas/vas/orog and ensure there are no NaNs in the vertical levels before running sup3r. 2) leave the data alone, use the raw ua/va/zg values without NaN even if there are levels below surface. 3) only use uas/vas instead of ua/va/zg; the code will use power law to extrapolate from 10m uas/vas to your hub height but you will never get any wind shear 4) if you're using bias correction (usually important for most GCM downscaling) this will help make sure that any of the options above result in sensible outputs.

clean_nan_wind_data.ipynb

[shellyzh]

Thanks for the suggestions. I want to stay away from bias correction now, so I tried the first three options, which all failed unfortunately. The output log for option 1:

The output log for option 2 is:

The output log for option 3 is:

My input GCM data (ua, va, zg) all have 0 NaN value, either they are original or masked (through the same method in the code you shared), so I am really not sure where the huge amount (68.18%) of NaN value come from in level arrays.

Are there other methods I can adopt to debug and solve this issue? Thank you so much.

[shellyzh]

Additionally, the current code of preprocessing/derivers/base.py line 401-404 terminates the run before the error message "NaN values found in the interpolated output for {feature}. Make sure there are no NaN values in the level or variable data." is reported. I suggest outputing the error message first by changing this section of code as follows: