source: NEMO/branches/2020/dev_r13648_ASINTER-04_laurent_bulk_ice/tests/STATION_ASF/SANITY_CHECK/README.rst @ 13837

Boolean Sanity Test of the SBCBLK interface of NEMO via the ``STATION_ASF`` test-case
=====================================================================================

Context
-------

Many *idealized/academic* test-cases included in NEMO can potentially be
used in a manner that could detect potential inconsistencies or bugs
mistakenly introduced in a particular "part/region" of the NEMO source
code. The test-case would then return a green or a red light.

In the future, this could help to build an automatized chain command to
check that no bug is introduced at each new commit. As we are dealing
with *idealized/academic* test-cases (which are typically designed to
run on 1 processor), this approach has the advantage of being
substantially faster and cheaper than the SETTE set of test experiments
in terms of computational requirements. Because test-cases

SBCBLK and ``STATION_ASF``
--------------------------

The primary goal of the bulk interface of NEMO (SBCBLK), is to provide
NEMO with the surface boundary conditions (as fluxes):

-  momentum flux (*a.k.a* wind stress)
-  net heat flux (as *net non-solar* and *net solar* components)
-  net freshwater flux (*a.k.a* E-P-R)

``STATION_ASF`` is used to compute all these surface fluxes at
particular spot (1D), based on time series of the sea-surface state
(mainly SST) and near-surface atmospheric variables (air temperature,
humidity, wind speed and downwelling radiative fluxes). Depending on the
bulk parameterization chosen by the user (5 different algorithms used to
estimate bulk transfer coefficients) these fluxes can differ
significantly from one another significantly. Yet the magnitude of these
fluxes is expected to remain within a certain "reasonable range" as
these algorithms have all been designed to fit flux observations.

The idea, here in this current sanity check, has been to define, for a
given input pattern of atmospheric state and SST, the deviation from a
normal + confidence range that clearly highlights a
"non-realistic/crazy" value, hence revealing the existence of a bug
somewhere...

Just as an example, in the following conditions:

-  *zu* = 10 m

-  *zt* = 2 m

-  *SST* = 22°C

-  *tzt* = 20°C

-  *RHzt* = 90 %

-  *Uzu* = 5 m/s

   ::

       =========================================================================================================================
       Algorithm:      coare3p0   |  coare3p6   |    ncar     |    ecmwf    |   andreas   || <units>  |  <mean>   |   <std dev>
       =========================================================================================================================
       Wind stress  =   35.93964      32.35383      35.64660      38.58376      30.10945     [mN/m^2]    34.52666     2.964582
       Evaporation  =   2.288606      2.349655      2.300673      2.250562      1.936906     [mm/day]    2.225281     0.147623
          QL        =  -64.86662     -66.59695     -65.20865     -63.78834     -54.89828     [W/m^2]    -63.07177     4.184117
          QH        =  -17.76094     -18.23470     -16.66991     -16.74091     -14.39284     [W/m^2]    -16.75986     1.325787

One can expect two typical outcomes for a non-successful sanity check:

-  All bulk algorithms yield non-realistic fluxes, the cause for error
   is therefore to be found outside of each algorithm. This can
   typically be caused by corrupted input fields being passed to all
   algorithms, for example it can be caused by a unit inconsistencies in
   input variables (ex: atmospheric pressure provide in hPa rather than
   Pa in the netCDF files, which yields corrupted air density, and in
   turn will affect all flux estimates, regardless of the choice of the
   bulk algorithm).
-  Only a subset of bulk algorithms yield non-realistic fluxes, the
   cause for error is therefore to be found inside these particular
   algorithms.

.. raw:: html

   <!---
   There are two main sources of errors to expect:
   - 1 of the bulk algorithm is buggy, and will provide erroneous fluxes with respect to the other algorithms
   - a more likely source of error is the presence of a bug outside the algorithm part, which, will lead to all algorithms to provide erroneous fluxes (example error linked to the unit of an input field, sign error, etc...), ex: broken computation of the air density, all fluxes are affected!
   --->

It is therefore not enough to test the fluxes against each other (from
different algorithms); it is necessary to check all fluxes against a
trustable reference plus/minus a tolerance for a particular set of
conditions, that has been computed independently from NEMO!