test on humidity in sbcblk?

[smasson]

Context

A test on humidity has been added in sbcblk

            SELECT CASE( nhumi )
            CASE( np_humi_sph ) ! specific humidity => expect: 0. <= something < 0.065 [kg/kg] (0.061 is saturation at 45degC !!!)
               IF(  (ztmp < 0._wp) .OR. (ztmp > 0.065)  ) ztmp = -1._wp
            CASE( np_humi_dpt ) ! dew-point temperature => expect: 110. <= something < 320. [K]
               IF( (ztmp < 110._wp).OR.(ztmp > 320._wp) ) ztmp = -1._wp
            CASE( np_humi_rlh ) ! relative humidity => expect: 0. <= something < 100. [%]
               IF(  (ztmp < 0._wp) .OR.(ztmp > 100._wp) ) ztmp = -1._wp
            END SELECT1

The test is performed on the mean value if there is more than 8-ocean points in the subdomain:

         ztmp = SUM(tmask(:,:,1)) ! number of ocean points on local proc domain
         IF( ztmp > 8._wp ) THEN ! test only on proc domains with at least 8 ocean points!

Analysis

There are 2 issues:

1) On large MPI subdomains, a few absurd values won't come out in the mean value. The result of this test is changing according to the number of MPI task we use. For example, when running ORCA2_ICE_PISCES on 32 cores everything is OK but when using 192 cores, the model stops as the mean value of one of the subdomains does not pass the test...
This won't happen if we test the min instead of the mean. Any subdomain decomposition will stop the model if an absurd value is found, even if this is a local min.

2) the forcing file of (at least) ORCA2_ICE does contain some absurd values (humidity < 0).

Recommendation

1) Which test do we want to do?

• if we want to exclude any absurd value, then we should use min instead of mean as soon as there is 1 ocean point in the subdomain.
• if we accept a few absurd values and we only want to check if there is no error on the definition of humidity variable (specific humidity vs. dew-point temperature vs. relative humidity), I think a test on the global mean (implying a global communication) at the first time step should be enough.

2) We can remove absurd values in forcing file with one of these commands:

ncap2 -s "where(Q_10 < 0.0) Q_10 = 0.0" q_10.15JUNE2009_fill.nc out.nc
cdo -expr,"Q_10=(Q_10<0.0)?0.0:Q_10;" q_10.15JUNE2009_fill.nc out.nc # warning: output file must differ from the input file
cdo setrtoc,-inf,0.,0.  q_10.15JUNE2009_fill.nc out.nc  # warning: output file must differ from the input file

[gsamson]

see ticket #2572 for more informations about negative humidities in CORE2 forcing files
I think Andrew has already corrected them in the new SETTE files ?

[smasson]

Sorry I did not found #2572...
If I understand correctly, this means that :
1) we should use the min as soon as there is 1 ocean point (-> do be commited, so why #2572 was closed?)
2) we should update the input file so they don't contain any absurd value (-> do be done in the updated set of forcing files).

[laurent]

Hello,

I wrote this test.

It is not primarily intended to spot absurd values, but to make sure that the user PAID ATTENTION TO, and adapted accordingly, the "ln_humi_*" flag he/she is using in the namelist!

Example: too many times, someone will provide the dew point temperature (d2m) as humidity forcing files and forget to use the appropriate "ln_humi_*" in the namelist, leaving for example:

ln_humi_sph=.true.

instead of adapting accordingly to the use of "d2m" instead of "q2m":

ln_humi_sph=.false.
ln_humi_dpt=.true.

Typically, such a mistake will not necessarily make the code crash, instead it will compute crazy surface fluxes, but not crazy enough for a crash... Hope you get what I mean...

Absurd values should not exist over the ocean in the input netcdf file, period. (hence the use of "tmask" in the test, to restrict it over open ocean)
For me, absurd values over ocean in the forcing netcdf files are of the responsibility of the user, it is not NEMO's responsibility hehe...

So yes CORE input "q10m" files have to be cleaned to remove these negative tiny values over ocean.

Cheers, /laurent

[smasson]

OK. We need to cleanup the input files we provide with the reference configurations.

I agree, the forcing files are of the responsibility of the user and we do not want to test the existence of absurd values.

We just want to avoid the user to run the code with an inappropriate namelist setup (which can easily happen in this case...).

In consequence, I propose to change the existing test by a call to glob_sum at the first time step.
I agree, this won't change anything if the input files are OK but this will be safer (the result of the test won't depend on the domain decomposition) if the user uses a file with a few absurd values, which is in fact quite common for example in atm model outputs (and explained by the occurrence of dew?).

[laurent]

Seb,

Sounds fine with me!

Cheers, /laurent

[smasson]

In 14402:

Error: Failed to load processor CommitTicketReference

No macro or processor named 'CommitTicketReference' found