Use of uninitialised arrays leads to floating point exceptions

[ufla]

While testing the current trunk (as of r4820) I experience model crashes with floating point exceptions in the following line from LIM_SRC_3/limthd.F90:

! --- Energy received in the lead, zqld is defined everywhere (J.m-2) --- !
zqld =  tms(ji,jj) * rdt_ice *                                       &
   &  ( pfrld(ji,jj)         * ( qsr(ji,jj) * oatte(ji,jj)           &   ! solar heat + clem modif
   &                           + qns(ji,jj) )                        &   ! non solar heat
   ! latent heat of precip (note that precip is included in qns but not in qns_ice)
   &    + ( pfrld(ji,jj)**betas - pfrld(ji,jj) ) * sprecip(ji,jj)         &
   &    * ( cpic * ( MIN( tatm_ice(ji,jj), rt0_snow ) - rtt ) - lfus )    &
   &    + ( 1._wp - pfrld(ji,jj) ) * ( tprecip(ji,jj) - sprecip(ji,jj) )  &
   &    * rcp * ( tatm_ice(ji,jj) - rtt ) )

It turns out (by using TotalView?) that the qsr and qns arrays contain both de-normalised as well as very large (>1e200) values. Since I have seen such behaviour in earlier NEMO/LIM3 versions, I suspected uninitialised allocatables.

To confirm this, I added an initialisation in OPA_SRC/SBC/sbc_oce.F90:

ALLOCATE( qns_tot(jpi,jpj) , qns  (jpi,jpj) , qns_b(jpi,jpj),        &
   &      qsr_tot(jpi,jpj) , qsr  (jpi,jpj) ,                        &
   &      emp    (jpi,jpj) , emp_b(jpi,jpj) ,                        &
   &      sfx    (jpi,jpj) , sfx_b(jpi,jpj) , emp_tot(jpi,jpj), fmmflx(jpi,jpj), STAT=ierr(2) )
   !
qns = HUGE(qns)
qsr = HUGE(qsr)

This modification triggered indeed identical floating point exceptions and TotalView? confirmed that the arrays were filled with the HUGE values.

As a further test, I changed the initialisation to zero, which prevents the exceptions.

Note that whether or not you experience a crash may depend on arbitrary conditions, such as the number of cores or whether the run is a restart or not. Nevertheless, the uninitialised arrays are used in all cases.

[smasson]

Hi,

In theory, qsr and qns are read/computed over the ocean (for example by sbc_blk_core) before calling the sea-ice. So having an initialization to any value should have no impact...

With Totalview and keeping the initialization to HUGE, could you have a look at qsr and qns arrays before calling the sea-ice in sbcmod (after the SELECT CASE( nsbc ) and before the SELECT CASE( nn_ice ))? Do you see any huge values? where?

Could you send us your ocean.output file, so I can see which configuration and options you are using?

[ufla]

Replying to smasson:

Hi,

In theory, qsr and qns are read/computed over the ocean (for example by sbc_blk_core) before calling the sea-ice. So having an initialization to any value should have no impact...

Maybe I'm missing this initiallisation due to wrong configuration?

With Totalview and keeping the initialization to HUGE, could you have a look at qsr and qns arrays before calling the sea-ice in sbcmod (after the SELECT CASE( nsbc ) and before the SELECT CASE( nn_ice ))? Do you see any huge values? where?

It is identically HUGE in all array elements.

Could you send us your ocean.output file, so I can see which configuration and options you are using?

I attach the file.

[ufla]

Log file ocean.output for a test run that is interrupted by floating point overflow.

[smasson]

Uwe,

I did not understood that you are in coupled mode. You are using the trunk with LIM3 in coupled mode which is supposed to work!
In coupled mode, qns and qsr are not yet defined when entering the ice model as sbccpl defines only qns_tot/qsr_tot and qns_ice/qsr_ice. A working interface with LIM3 will be available by the end of this year (and is under development in the following branch: dev_4728_CNRS04_coupled_interface).

Seb

[ufla]

Hi Sebastien,

Okay, thanks for pointing out! I will be looking at dev_4728_CNRS04_coupled_interface and probably contact Martin Vancoppenolle. I would really like to continue testing the new NEMO version, being aware that things are still under development.