Opened 6 years ago

Closed 6 years ago

Last modified 3 years ago

#1403 closed Bug (invalid)

Use of uninitialised arrays leads to floating point exceptions

Reported by: ufla Owned by: nemo
Priority: normal Milestone:
Component: LIM3 Version: release-3.6
Severity: Keywords: LIM*
Cc:

Description

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 Total View?) 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 Total View? 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.

Commit History (0)

(No commits)

Attachments (1)

ocean.output (76.7 KB) - added by ufla 6 years ago.
Log file ocean.output for a test run that is interrupted by floating point overflow.

Download all attachments as: .zip

Change History (9)

comment:1 follow-up: Changed 6 years ago by 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?

comment:2 in reply to: ↑ 1 Changed 6 years ago by 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?

I tested it and 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.

Last edited 6 years ago by ufla (previous) (diff)

Changed 6 years ago by ufla

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

comment:3 Changed 6 years ago by 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

comment:4 Changed 6 years ago by 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.

comment:5 Changed 6 years ago by smasson

  • Resolution set to invalid
  • Status changed from new to closed

comment:6 Changed 3 years ago by nemo

  • Keywords LIM* added

comment:7 Changed 3 years ago by nemo

  • Keywords release-3.6* added

comment:8 Changed 3 years ago by nemo

  • Keywords release-3.6* removed
Note: See TracTickets for help on using tickets.