New URL for NEMO forge!   http://forge.nemo-ocean.eu

Since March 2022 along with NEMO 4.2 release, the code development moved to a self-hosted GitLab.
This present forge is now archived and remained online for history.
#1973 (Floating invalid in limvar.f90 and limthd_dh.f90) – NEMO

Opened 7 years ago

Closed 6 years ago

Last modified 3 years ago

#1973 closed Bug (wontfix)

Floating invalid in limvar.f90 and limthd_dh.f90

Reported by: mcastril Owned by: vancop
Priority: normal Milestone:
Component: LIM3 Version: v3.6
Severity: major Keywords: LIM* v3.6
Cc: ufla

Description (last modified by nemo)

Hi,

This issue is much similar to #1954. The problem is that we get a floating invalid in limvar.f90, line 135:

forrtl: error (65): floating invalid
Image              PC                Routine            Line        Source             
nemo.exe           0000000001B558B2  Unknown               Unknown  Unknown
libpthread-2.22.s  00002B5D8ABCDB10  Unknown               Unknown  Unknown
nemo.exe           0000000000F4AA69  limvar_mp_lim_var         135  limvar.f90
nemo.exe           0000000000CFA705  sbcice_lim_mp_sbc         389  sbcice_lim.f90
nemo.exe           000000000045CA63  sbcmod_mp_sbc_ini         374  sbcmod.f90
nemo.exe           000000000043CE20  nemogcm_mp_nemo_i         330  nemogcm.f90
nemo.exe           0000000000438D93  nemogcm_mp_nemo_g         120  nemogcm.f90
nemo.exe           0000000000438D5D  MAIN__                     18  nemo.f90
nemo.exe           0000000000438D1E  Unknown               Unknown  Unknown
libc-2.22.so       00002B5D8B0F76E5  __libc_start_main     Unknown  Unknown
nemo.exe           0000000000438C29  Unknown               Unknown  Unknown
forrtl: error (65): floating invalid
Image              PC                Routine

In that line there is this operation:

smt_i(ji,jj) = smt_i(ji,jj) + r1_nlay_i * rswitch * s_i(ji,jj,jk,jl) * v_i(ji,jj,jl) &

Apparently, looking at sbcice routine, the use of the s_i variable is the following:

    ierr = ice_alloc () ! ice variables       <-- Variables are allocated
      (Some stuff)
      CALL lim_itd_init ! ice thickness distribution initialization          <--  Does not use nor modify s_i
      CALL lim_hdf_init ! set ice horizontal diffusion computation parameters         <--  Does not use nor modify s_i 
      CALL lim_thd_init ! set ice thermodynics parameters              <--  Does not use nor modify s_i
      CALL lim_thd_sal_init ! set ice salinity parameters            <--  Does not use nor modify s_i  (only reads namelist parameters)
      CALL lim_msh ! ice mesh initialization               <--  Does not use nor modify s_i
      CALL lim_itd_me_init ! ice thickness distribution initialization for mecanical deformation   <--  Does not use nor modify s_i  (only reads namelist parameters)
      ! ! Initial sea-ice state
      IF( .NOT. ln_rstart ) THEN ! start from rest: sea-ice deduced from sst              <- Only if not a restart
         numit = 0
         numit = nit000 - 1
         CALL lim_istate           <-  Here the s_i variables are modified (only happens in the first chunk)
      ELSE ! start from a restart file
         CALL lim_rst_read        <--   Does not use nor modify s_i ( except if nn_icesal == 1, that in our case is 2)
         numit = nit000 - 1
      ENDIF
      CALL lim_var_agg(2)       < ---- Here the model crash    

Hence in our experiments, when we start a second year of simulation starting from restarts from the previous year, the run crashes at the beginning, presumably because the s_i variable has not been initiated due to the use of restarts.

We could solve this bug by initializing all the LIM variables at the ice.f90 routine.

Commit History (0)

(No commits)

Attachments (2)

ice.F90 (43.3 KB) - added by mcastril 7 years ago.
thd_ice.F90 (13.3 KB) - added by mcastril 7 years ago.

Download all attachments as: .zip

Change History (14)

comment:1 Changed 7 years ago by clevy

  • Owner set to vancop
  • Status changed from new to assigned

comment:2 Changed 7 years ago by mcastril

  • Summary changed from Floating invalid in limvar.f90 to Floating invalid in limvar.f90 and limthd_dh.f90

comment:3 Changed 7 years ago by nemo

  • Description modified (diff)

comment:4 Changed 7 years ago by mcastril

Hi,

We had more floating point issues at limthd_dh.f90, line 701. Using a debugger we could verify some NaN values in ht_i_1d variable, because this one was never initialized. We solved it by initializing to zero all arrays allocated in thd_ice.F90.

I can attach both files (ice.F90 and thd_ice.F90).

Changed 7 years ago by mcastril

Changed 7 years ago by mcastril

comment:5 Changed 7 years ago by ufla

  • Cc ufla added
  • workplan_status set to unknown

Adding some information about ht_i_1d in limthd_dh.F90:

The problem is that it is allocated for all points (jpij) in thd_ice_alloc, but only gets assigned values for indices kideb:kiut (1:nbpb when called from lim_thd) in lim_thd_dh. However, the statement

! --- ensure that a_i = 0 where ht_i = 0 ---
WHERE( ht_i_1d == 0._wp ) a_i_1d = 0._wp

(line 701 of limthd_dh.F90) accesses the full array. This will cause floating point exceptions, and crashes on systems that do not ignore these.

Besides, comparing ht_i_1d (or any other floating point number) to zero is not safe.

Last edited 7 years ago by nemo (previous) (diff)

comment:6 Changed 7 years ago by nemo

  • Keywords LIM* added

comment:7 Changed 7 years ago by nemo

  • Keywords release-3.6* added

comment:8 Changed 7 years ago by nemo

  • Keywords release-3.6* removed

comment:9 Changed 7 years ago by mcastril

Hi,

the assignation statement of ht_i_1d is an operation involving previous values (uninitialized) of ht_i_1d, so we can consider it "uninitialized" over all the longitude of the array, due to that values (involving NaN or random ones) can propagate though the operation (MAX).

comment:10 Changed 6 years ago by vancop

  • Resolution set to wontfix
  • Status changed from assigned to closed

comment:11 Changed 6 years ago by vancop

obsolete for nemo v4

comment:12 Changed 3 years ago by nemo

  • Keywords v3.6 added
Note: See TracTickets for help on using tickets.