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.
#1037 (calendar problems) – NEMO

Opened 12 years ago

Closed 9 years ago

#1037 closed Defect (fixed)

calendar problems

Reported by: poddo Owned by: nemo
Priority: low Milestone:
Component: OCE Version: v3.4
Severity: Keywords:
Cc:

Description

The daymod routine has some limitations not present in the 2.3 NEMO version.
The code does not consider the possibility to perform simulations shorter than 1 day.
If I start from midnight with 3 simulations of 12hr each the calendar does not work and fldread as consequence read the wrong input file.

Commit History (0)

(No commits)

Attachments (3)

daymod.F90 (17.5 KB) - added by poddo 12 years ago.
new version of daymod, more general and flexible
daymod.2.F90 (17.6 KB) - added by poddo 11 years ago.
more portable
daymod.3.F90 (17.9 KB) - added by poddo 11 years ago.
fixed minor bug when simulation finishes exactly at 00:00

Download all attachments as: .zip

Change History (7)

Changed 12 years ago by poddo

new version of daymod, more general and flexible

comment:1 Changed 12 years ago by poddo

Attached to this ticket there is a new version of daymod.F90 I modified.
I have done some tests starting from rest and using the restart.
Now it is possible to start at any time of the day (using nit000 in the namelist).
It is possible to perform simulations shorter than 1 day and restart with the correct date.
Since this routine is used in several different ways, maybe, it is better to test it under different conditions before upgrade the official code.
Paolo

comment:2 Changed 12 years ago by smasson

After v2.3, I completely rewrote the calendar to be able to work with any calendar in fldread and to be able to do a simulation encompassing several years. I faced tricky rounding errors and I had to switch all the calendar variables from real to integer.
Note that since that time NEMO time step must me a multiple of 2...

I think this ticket is linked with the action 9 of the UKMet in 2013 workplan. Working with run shorter than days should be associated with an extension of ndate0 definition including seconds or faction of days...

I checked your code. I think if daymod is ok there is no problems with fldread. I propose the following changes (that have to be verified)

      nsec_day=NINT(fracday)
               ndastp = NINT( zndastp ) + 1

the following ligne should be removed. this is needed to avoid rounding errors

      ! Maybe the following statement can be removed

I am not sure to understand the need of the rounding of adatrj. I would have done that:

      nsec_day= NINT((adatrj-INT(adatrj))*rday)

As the time step must in fact be an integer multiple of 2.

A few more comments would be welcome (the fact that we go 1/2 time step before ndate0, for example).

This needs further tests and very careful checks...

comment:3 Changed 11 years ago by poddo

Here I'm attaching a new version of daymod wich differ a little from the previous one.
In calling the F90 function NINT I'm forcing to "i8" to avoid machine limits.
This should make the routine more portable.

Changed 11 years ago by poddo

more portable

Changed 11 years ago by poddo

fixed minor bug when simulation finishes exactly at 00:00

comment:4 Changed 9 years ago by clevy

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.