very large values in bias correction file

[mvertens]

Brief summary of bug

Very large values in bias correction file.

General bug information

In testing the nuopc cmeps/cdeps bias correction compset - I am seeing the following large values in the bias correction file
/glade/p/cesmdata/cseg/inputdata/atm/datm7/clm_output/cruncep_precip_1deg/gpcp_1deg_bias_correction/bias_correction.Prec.2000.nc. Is this to be expected.

$ ncdump -ff -v BC_PREC /glade/p/cesmdata/cseg/inputdata/atm/datm7/clm_output/cruncep_precip_1deg/gpcp_1deg_bias_correction/bias_correction.Prec.2000.nc | grep -v 0, | grep e\+
    1.347598e+14,   // BC_PREC(204,124,3)
    5.916577e+14,   // BC_PREC(204,125,3)
    2.547022e+13,   // BC_PREC(96,64,5)
    7.637063e+13,   // BC_PREC(96,65,5)
    4.458091e+13,   // BC_PREC(96,62,6)
    5.322113e+13,   // BC_PREC(96,63,6)
    4.535007e+15,   // BC_PREC(24,81,6)
    1.51875e+15,   // BC_PREC(24,82,6)
    1.523223e+15,   // BC_PREC(24,83,6)
    3.946236e+13,   // BC_PREC(96,71,7)
    7.028679e+13,   // BC_PREC(96,72,7)
    7.000657e+14,   // BC_PREC(24,77,7)
    3.654295e+14,   // BC_PREC(24,78,7)
    2.51628e+15,   // BC_PREC(24,73,8)
    4.9347e+14,   // BC_PREC(24,74,8)
    3.130425e+16,   // BC_PREC(24,75,8)
    2.447011e+13,   // BC_PREC(204,142,8)
    1.176623e+14,   // BC_PREC(198,143,8)
    1.969341e+13,   // BC_PREC(204,143,8)
    4.993199e+13,   // BC_PREC(198,144,8)
    6.292274e+13,   // BC_PREC(198,145,8)
    6.604107e+13,   // BC_PREC(198,146,8)
    2.288727e+13,   // BC_PREC(96,66,9)
    2.742293e+13,   // BC_PREC(96,67,9)
    1.215204e+14,   // BC_PREC(96,68,9)
    8.807233e+13,   // BC_PREC(96,64,10)
    3.590253e+16,   // BC_PREC(24,105,11)
    1.530637e+15,   // BC_PREC(24,107,11)
    1.650805e+14,   // BC_PREC(204,122,12)
    1.623885e+14,   // BC_PREC(204,125,12)
    2.443766e+15,   // BC_PREC(204,126,12)

CTSM version you are using: ctsm5.1.dev038

Does this bug cause significantly incorrect results in the model's science?
Yes - if this is a problem with the data and this would only appear in a configuration with datm using the bias correction data.

**Configurations affected:
SMS_Ld1_P48x1_Vnuopc.f19_f19_mg17.I2000Clm50BgcCru.cheyenne_intel.clm-af_bias_v7
SMS_Ld1_P48x1_Vmct.f19_f19_mg17.I2000Clm50BgcCru.cheyenne_intel.clm-af_bias_v7.validate/

Details of bug

In addition to the appearance of these large values - the nuopc configuration the datm appears to be doing the interpolation for stream->model correctly whereas this is not the case in mct. I have overwritten the values of rainc in the coupler history file so that it only

The following file is the actual bias correction plot:

This file is the mct version of interpolation from f09->f19 (I think the problem is the fill that is occurring with mct - I don't think its doing it correctly)

This file is the cdeps version of interpolation from f09->f19 (there is still a problem on the coastlines of the fill values from f09 being mapped to the coastlines of f19 - but the rest of the plot looks reasonable)

Important details of your setup / configuration so we can reproduce the bug

The following two compsets were run:
SMS_Ld1_P48x1_Vnuopc.f19_f19_mg17.I2000Clm50BgcCru.cheyenne_intel.clm-af_bias_v7
SMS_Ld1_P48x1_Vmct.f19_f19_mg17.I2000Clm50BgcCru.cheyenne_intel.clm-af_bias_v7.validate/

In both cases user_nl_datm was modified to include the following:

bias_correct = 'BC.CRUNCEP.GPCP.Precip' added to user_nl_datm
./xmlchange RUN_STARTDATE=2000-01-16

Important output or errors that show the problem

Please see the plots above.

[mvertens]

@erik, @swensosc - could you please let me know how to proceed with this in the nuopc validation. Should the bias correction runs only be done at the same resolution as the bias correction file - i.e. f09_f09_mg17. those results look fine.

[swensosc]

Functionally, the bias correction stream should work just like the anomaly forcing stream. The difference is that the bias correction file was meant to match a particular month of one dataset with that of a different dataset (e.g. some observations). So those values are probably technically correct, i.e. the ratio of those particular months, presumably when the reference data was close to zero. In any case, as they were constructed, the bias correction stream was meant to be applied to a particular forcing dataset, and the months were meant to match, in contrast to the anomaly forcing, which was meant to be applied to any forcing data. Interpolating those large values would lead to unrealistic values, and wouldn't be the right thing to do. Practically speaking, I don't know if anyone uses (or even is aware of) the bias correction stream.

…

On Wed, Jun 2, 2021 at 10:25 AM mvertens ***@***.***> wrote: @erik <https://github.com/erik>, @swensosc <https://github.com/swensosc> - could you please let me know how to proceed with this in the nuopc validation. Should the bias correction runs only be done at the same resolution as the bias correction file - i.e. f09_f09_mg17. those results look fine. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1386 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGRN57DVMOKR7FEYXKJV5M3TQZLQZANCNFSM453RZOQQ> .

[billsacks]

From ctsm-software discussion today: What we really want is to validate an anomaly forcing case, not a bias correction case (since the former is what people use and care about).

@swensosc - when you get a chance, can you please do a run with anomaly forcing (using whatever setup would be a typical one to use) using the nuopc driver (by specifying --driver nuopc in your create_newcase command using the latest version of CTSM), to verify that it looks like things are working correctly in the nuopc version (which uses datm from CDEPS instead of the mct datm)?