Opened 3 years ago

Closed 2 years ago

Last modified 3 months ago

#433 closed defect (fixed)

no leap years on gregorian forcing files when more than 1y in forcing file (e.g: fluxnet)

Reported by: ajornet Owned by: maignan
Priority: major Milestone: ORCHIDEE 3.0
Component: Driver files Version: trunc
Keywords: leap, forcing, fluxnet Cc:


Orchidee is not correctly doing leap years when the forcing is based in a gregorian calendar which has more than one year (e.g: Fluxnet forcing files) of data.
Forcing files and XIOS properly work.

It happens because the length of the simulation is calculated like this:

  • dim2_driver.f90:
    CALL tlen2itau (time_str, dt_force, date0, itau_len) ! "1Y" + date0 = 365/366 days of timestep
  • (in) time_str = TIME_LENGTH option defined in run.def
  • (in) date0: date (in julian days) of origin of the forcing file.
  • (out) itau_len: number of timesteps to run.

So for the 2nd, 3rd, ... year of simulation it takes always into account the starting date (date0) of the forcing file. For 1 year simulation it means 365 days. In case the next year is a leap year, it won't run for 366 days for but 365 days. This will delay the coming simulations for one day. Outputs will be affected in different ways.

To reproduce this issue using libIGCM:

  • 1 year simulation length steps
  • must include a leap year. e.g: From 1998 to 2002 (2000 is leap year)
  • fluxnet forcing file
  • monthly XIOS output
    • For daily: no error shown
    • For annual: no error shown

The error shown below will be raised after the leap year. The data sent to XIOS is corrupted due to this problem. For the exact same simulation, a different variable can crash. XIOS uses its own calendar to properly fit its data:

> Error [CNc4DataOutput::writeFieldData_ (CField*  field)] : In file
line 2736 -> On writing field data: ptn_pftmean
In the context : orchidee_server
Error when calling function ncPutVaraType(ncid, varId, start, count, data)
NetCDF: Numeric conversion not representable
Unable to write data given the location id: 65536 and the variable whose
id: 53 and name: ptn_pftmean

The error itself might be missleading because data is corrupted.

Proposed fix:

  • In src_driver/dim2_driver.f90
[ajornet@obelix5 ORCHIDEE]$ svn diff src_driver/dim2_driver.f90
Index: src_driver/dim2_driver.f90
--- src_driver/dim2_driver.f90	(révision 5117)
+++ src_driver/dim2_driver.f90	(copie de travail)
@@ -46,7 +46,8 @@
   INTEGER :: iim, jjm, llm
   INTEGER :: im, jm, lm, tm, is, force_id, itest, jtest
   REAL :: dt, dt_force, dt_rest, date0, date0_rest 
+  REAL :: date_cur  ! Starting date of the simulation
   REAL :: zlflu
   REAL :: alpha
@@ -552,7 +553,8 @@
 ! Transform into itau
-  CALL tlen2itau (time_str, dt_force, date0, itau_len)
+  date_cur = itau2date(itau_dep, date0, dt_force) 
+  CALL tlen2itau (time_str, dt_force, date_cur, itau_len)
   itau_fin = itau_dep+itau_len
  • itau_dep: timestep where the simulation start from date0

Calculating a new date date_cur including the already ran timesteps + date0 (forcing starting date data). This will ensure the length of the new simulation can take into account the comming (leap) year.

Hopefully, the explanation is clear.

Change History (7)

comment:1 Changed 3 years ago by ajornet

In the webpage :

Several notes point out:

NOTE: You have to loop over multiples of four years. If you do not, something strange happens in the leap years and only 11 out of the 12 months are printed in the history files sometimes. I talked to Josefine about it and we couldn't figure out why, so we're just using this as a fix. I have no idea how this works for things like FLUXNET validation. 

NOTE2: Because of the previous note, take care to make sure your leap years line up in your looping years and your "real" years. I'll explain this more below. 

It could be related to this issue.

comment:2 Changed 3 years ago by ajornet

Commit for the MICT branch: [5138/branches/ORCHIDEE-MICT/ORCHIDEE]

comment:3 Changed 3 years ago by jgipsl

  • Milestone orchidee_1_9_6 deleted

comment:4 Changed 3 years ago by aducharne

  • Milestone set to ORCHIDEE 3.0
  • Owner changed from somebody to maignan
  • Status changed from new to assigned

comment:5 Changed 2 years ago by jgipsl

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

Done in the trunk [5867]

comment:6 Changed 3 months ago by nvuilsce

This bug fix corrupts the possibility of using yearly forcings defined on a gregorian calendar. The driver does not compute a correct length in days for the different years (leap or no leap), while it did it well before.

comment:7 Changed 3 months ago by nvuilsce

I think that replacing
date_cur = itau2date(itau_dep, date0, dt_force)


date_cur = itau2date(itau_dep, date0_rest, dt_force)

may enable to correct for the bug initially reported in this ticket, without creating a but when using yearly forcings based on a gregorian calendar. I'll test this fix on FG1, FG1trans and FG2 configs for noleap and gregorian calendars

Note: See TracTickets for help on using tickets.