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.
#1146 (flread loses information in the 69th year of run) – NEMO

Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#1146 closed Defect (fixed)

flread loses information in the 69th year of run

Reported by: mouchet Owned by: nemo
Priority: normal Milestone:
Component: OFF Version: v3.4
Severity: Keywords:
Cc: Anne.Mouchet@…, Olivier.Marti@…, Jean-Claude.Dutay@…

Description

The following behavior is obtained with configuration OFF_MY_TRC & NEMO v3.4

I launched a 100 years experiment (no intermediate restart).
Suddenly (within one time step), in the 69th year of run all concentrations became NaN.

My understanding is that flread suddenly loses the information about the actual record time.

There is nothing more special that year than any other. I use climatological dynamical forcing (perpetual year with values every 5 days). Exactly the same thing happen whether tracers undergo sms or not.

Ch. Ethé obtained exactly the same behavior on a different computer with his own version of the model.

Many thanks for your help,
Anne

Commit History (4)

ChangesetAuthorTimeChangeLog
4104smasson2013-10-22T15:35:12+02:00

v3_4_STABLE: typo introduced in r4086, see #1146

4103smasson2013-10-22T15:34:17+02:00

trunk: typo introduced in r4085, see #1146

4086smasson2013-10-21T15:20:22+02:00

v3_4_STABLE: add a stop if the calendar exceed i4 max value, see #1146

4085smasson2013-10-21T15:16:09+02:00

trunk: add stop if calendar exceed i4 max value, see #1146

Change History (3)

comment:1 Changed 11 years ago by clevy

  • Type changed from Bug to Defect

comment:2 Changed 11 years ago by smasson

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

The problem is that fldread uses the number of seconds since the last restart and store it in an integer. By default you compile NEMO with integer 4, which means that the bigger number you can store is 2(4*8-1)-1 and

2.^31/24./60./60./365. = 68.0963

=> you exceed integer 4 precision when moving to year 69 and you get NaN or other values according to the compiler or the compiler options you use.

Solutions are:

  • you do a maximum of 68 years without restart
  • you recompile everything with integer 8 instead of 4

A stop has been had in the trunk, see r4085 and in v3_4_STABLE, see r4086

comment:3 Changed 11 years ago by smasson

typo correction in the trunk, see r4103 and in v3_4_STABLE, see r4104

Note: See TracTickets for help on using tickets.