Opened 2 years ago

Closed 2 years ago

#719 closed defect (fixed)

Mass balance closure when starting FGtrans

Reported by: luyssaert Owned by: mmcgrath
Priority: blocker Milestone: ORCHIDEE 4.1
Component: Biogeochemical processes Version: trunc
Keywords: Cc:

Description (last modified by luyssaert)

When starting FG1trans from the analytical spinup the model crashes at the first time step with a mass balance error in PFT1.

FG1 simulations run fine with r6858 of the trunk (both modeles/ORCHIDEE and config/ORCHIDEE_OL). When switching to a global FG1trans on Irene with 127 CPUS (15 PFTs, one age class. svn defaults except for: forcing FM to be 1, adding a couple extra flags (USE_RESERVE_N = y, OK_DYNROOT_HA = y, HACK_E_FRAC = y), turning off river routing), the code crashed with the following

34 Error: mass balance is not closed in stomate_lpj for carbon
34 ipts, 1
34 Difference is, -52.6484613368733
34 pool_end,pool_start: 1029.76295684005 1029.76940083970
34
34FATAL ERROR FROM ROUTINE stomate_lpj
34 --> Mass balance error
34 -->
34 -->
34
34Fatal error from ORCHIDEE. STOP in ipslerr_p with code

The big difference between FG1 and FG1trans is land cover change.

The test was reproducible from a single pixel (81N, 21W), first running five years of FG1 (no land cover change) and then running FG1trans. The code crashes quickly in the first year. One major change in previous revisions has been the product pools.

Change History (4)

comment:1 Changed 2 years ago by luyssaert

  • Description modified (diff)

comment:2 Changed 2 years ago by luyssaert

  • Description modified (diff)

comment:3 Changed 2 years ago by mmcgrath

Chao proposed to remove three variables from the restart file. He found it by carefully tracking the source of the imbalance term in the error message. Sebastiaan agrees that it's unusual to have flux variables in the restart file, since they are generally recalculated at every step. I have removed them in commit r6868.

There are still two crashes, though.

1) Using a debug executable, there is a crash in stomate_growth_fun_all.f90 with en error from XIOS on the following line: CALL xios_orchidee_send_field('C0_ALLOC', c0_alloc(:,:)). The values of c0_alloc are between 0.2 and 999999 if I print them before this call, so the crash is unusual. This happens before the crash in this ticket.

2) One year after the previous crash (with the optimized production executable), there is an other XIOS error near the end of the simulation year (perhaps right at the end...a number of the 127 processors finish)

In file "nc4_data_output.cpp", function "void xios::CNc4DataOutput::writeFieldData_(xios::CField *)", line 2669 -> On writing field data: fDeforestToProduct
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: 196608 and the variable whose id: 99 and name: fDeforestToProduct

These may not be related to this bug, though.

comment:4 Changed 2 years ago by mmcgrath

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