Opened 3 years ago

Closed 3 years ago

#463 closed defect (fixed)

No GPP when using FLUXNET forcing files

Reported by: mmcgrath Owned by: mmcgrath
Priority: major Milestone: IPSLCM6.v2
Component: Driver files Version:
Keywords: Cc:

Description

Running tests to compare against FLUXNET data using the scripts in config/ORCHIDEE_OL/ENSEMBLE, I noticed something unusual: the metaclasses produced no GPP. Not just one site, but all of them I looked at (CA-SF1,DK-Ris,FR-Fon,ID-Pag,IT-Lec,NL-Lan,RU-Ha3,US-SP4,BR-Sa3), which cover eight different metaclasses from the tropics to northern climates.

Using the run_dir for BR-Sa3, changing the forcing file to NCC two-degree, and selecting a region of four pixels around the latitude and longitude of the BR-Sa3 site resulted in GPP production in all four pixels. This suggests a driver issue.

Further testing suggests it's related to the sun angle, which we need to calculate absorption in the canopy. Temperature, humidity, and swdown seem fine, but the sun appears to never rise (according to the sun angle), which means photosynthesis is never triggered. This suggests the sun angle not properly calculated (possibly not calculated at all) for these driver files.

Change History (6)

comment:1 Changed 3 years ago by mmcgrath

Revision: ORCHIDEE-CN-CAN, r5597
Computer: Obelix
Compile flags: -DBZ_DEBUG -g -fno-inline -ggdb --debug (for mpicc), -fpe0 -O0 -g -traceback -fp-stack-check -ftrapuv -check bounds -check all -check noarg_temp_created (for mpif90)

comment:2 Changed 3 years ago by mmcgrath

In readdim2.f90, calculation of the solar angle is protected by an IF statement.

IF ( dt_force .GT. 3600. ) THEN

For the FLUXNET driver files, the timestep is 1800, so these loops don't get triggered. mean_coszang, julian, and daylength_n are therefore unmodified.

The only indication I can see giving a reason for doing this is a comment, 'This is needed because we lack the precision on 32 bit machines.'

By changing 3600 to 1799 in seven places, the values are now calculated and I have GPP. Simulations run for a hundred years with no crash and full debug flags over a single pixel. However, I'm not sure if there are other consequences that I am not seeing. Needs further debugging.

Commited in r5619.

comment:3 Changed 3 years ago by mmcgrath

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

comment:4 Changed 3 years ago by mmcgrath

  • Resolution fixed deleted
  • Status changed from closed to reopened

Re-opening. My fix was not the correct fix. Have discussed in more detail with Nicolas Vuichard to figure out the best solution. I do not yet have a course of action to take.

The problem appears to be a difference in the day as defined by ORCHIDEE (UTC time) and the day as defined by the site-level forcing file (local time). ORCHIDEE's calculation of the solar angle does not align with the forcing file's shortwave radiation in regards to the timestep (i.e., at a given timestep, ORCHIDEE may think it is night based on the solar angle, while the forcing file thinks it is day based on SWdown). As ORCHIDEE-CN-CAN relies on both to calculate GPP, this leads to incorrect calculations using site-level forcings.

comment:5 Changed 3 years ago by mmcgrath

  • Milestone set to IPSLCM6.v2
  • Owner changed from somebody to mmcgrath
  • Status changed from reopened to assigned

comment:6 Changed 3 years ago by mmcgrath

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

After talking to Nicolas, we figured the best solution (for the moment) is to compute the solar angle at the beginning of the routine for this specific case (high frequency, single grid point), exiting with an error message if any related, but untested cases, may arise. We don't foresee these other cases occurring (e.g., global run with 1800s forcing data).

In theory, the solar angle could be computed all the time, but that would not address the time difference issue.

This should not affect the TRUNK, as the TRUNK does not use solar angle for GPP calculation.

Change was committed in r5657.

Note: See TracTickets for help on using tickets.