{5} Assigned, Active Tickets by Owner (Full Description) (33 matches)

List tickets assigned, group by ticket owner. This report demonstrates the use of full-row display.

Ticket Summary Component Milestone Type Created
#56 Fruit and seed production Biogeochemical processes Not scheduled yet enhancement 12/17/12

to add a PFT-dependency and limitation dependency on tax for fruits and seeds variables in stomate_alloc

aducharne (2 matches)

Ticket Summary Component Milestone Type Created
#350 Improper use of vbeta in enerbil Physical processes Not scheduled yet defect 02/28/17

This ticket has links with #331 and #60.

In diffuco, 5 vbeta are defined for 5 evaporation fluxes (subli, inetrception loss, transpiration, soil evap, and flood plain evap). These vbeta account for both the "specific beta" of each flux (reduction factor compared to evapot, thus conveying information of the stresses), but they also account for the effect of the grid-cell fraction assigned to each flux on the grid-cell average (the larger the fraction, the larger the contribution of the subflux).

In doing so, it is assumed that each sub-flux originates from an independent fraction of the grid-cell: a particular fraction cannot contribute to two different sub-fluxes.

Two different problems are identified:

1) in diffuco_trans_co2, the fraction used for vbeta3 is veget_max*(un - zqsvegrap), which is not consistent with assuming that evapnu proceeds from (veget_max-veget). For comparaison, in diffuco_trans, the fraction used for vbeta3 is veget*(un - zqsvegrap). => The proposed solution is to weight vbeta3 in diffuco_trans_co2 like in diffuco_trans (preliminary tests over 10 yrs with WFDEIv1 show that it reduces the transpiration of 4% on global average, and the total ET of 1.5%)

2) in diffuco, the vbeta for transpir, interception loss, and evapnu, are calculated as if there was no snow nor floodplains (while the vbeta1 and vbeta5 for subli and vevapflo respectively depend on the fraction covered by snow and floodplains).

The reduction of transpir, interception loss, and evapnu, as a function of the fraction occupied by snow and floodplains, is performed in enerbil, with conceptual errors: basically, vbeta1 and vbeta5 are used correctly to define subli and vevapflo, but they are also used as the effective snow and floodplain fraction to calculate transpir, interception loss, and evapnu, and this is wrong. More specifically, I see a problem :

  • with this use of vbeta1 as an effective snow fraction if frac_snownobio is not 1,
  • with this use of vbeta5 as a floodplain fraction because evapot_penm/evapot is smaller than 1

I think this does not induce conservation problems, but just incorrect estimations of the fluxes. Yet, I may be wrong...

=> There are two ways to solve this:

  • either by fully accounting for the fractions in diffuco (implying to make vbeta2, vbeta3, and vbeta4 dependent on the snow and floodplain fractions); then, enerbil becomes very easy, since we just add the different vbeta_i * evapot
  • else, we can choose to correct the weighting scheme used in enerbil and replace some uses of vbeta1 and vbeta5 by the correct fractions.

#60 Re-write formulation of evap in fdiffuco Physical processes Not scheduled yet enhancement 12/17/12

Re-write formulations of evap by deleting vbeta and valphas in order to be closer to the original equations.

ajornet (1 match)

Ticket Summary Component Milestone Type Created
#391 problem with ipslerr_p(MPI_ABORT) at obelix : model stays hanging Model architecture Not scheduled yet defect 09/12/17

Using the current trunk (rev 4600) the ipslerr_p is called from the model with stop level 3, the model stays hanging. The error message is printed in out_orchidee in the run directory but the job stay running in queue.

For a simple test case, set in run.def


This will activate the coherence test in the code. If you set a RUN_DIR_PATH in the main job, you can see during run time that the model has written the output messages

0FATAL ERROR FROM ROUTINE control_initialize
0 --> Too shallow soil chosen for the thermodynamic for soil freezing
0 --> Adapt run.def with at least DEPTH_MAX=11
0 -->
0Fatal error from ORCHIDEE. STOP in ipslerr_p with code

but the job is still running in the queue (use qstat).


  • This is only seen when running with XIOS. When using only IOIPSL, the model stops correctly.
  • When the model stops from IOIPSL, for example if an input file is missing (for example soils_param.nc), the execution is stopping correctly, even if XIOS is activated.

Tested modifications

Currently in ORCHIDEE/src_parallel/ioipsl_para.f90:


Changing into


seems to solve the case using XIOS in attached mode but still not the server mode. A better solution is needed.

These problems at obelix seems to be related to the problem at curie in ticket #236

alanso (1 match)

Ticket Summary Component Milestone Type Created
#567 Check that ok_mleb=T does not change the results Anthropogenic processes Not scheduled yet task 06/03/19

Confirm that multi energy buget using one layer gives the same results as enerbil (standard version which is still kept in CAN).

To be done after #511

bguenet (1 match)

Ticket Summary Component Milestone Type Created
#123 Simplification or revision of stomate_litter Biogeochemical processes ORCHIDEE 3.0 enhancement 02/10/14

Following ticket #80, we think that stomate_litter.f90 could be simplified as it appears that litterpart equals always 1 and that litter_inc_PFT equals litter_inc. This complex calculation seems inherited from the partitioning of the litter between natural and agricultural vegetation. Now we have one litter pool per PFT and so we think that the code can be corrected. To be confirmed

bgunet (1 match)

Ticket Summary Component Milestone Type Created
#81 Moisture control on OM decomposition only defined per grid cell - Need changes Biogeochemical processes ORCHIDEE 3.0 enhancement 01/22/13

The Moisture control on OM decomposition is currenlty defined per grid cell. The soil water content is defined per PFT with Choisnel scheme and per type of soil (bare soil, forest and herbaceous) for the CWRR scheme. So, the moisture control on OM decomposition should be defined per PFT or per soil type.

cottle (2 matches)

Ticket Summary Component Milestone Type Created
#352 Error in computation of vbeta3pot Physical processes Not scheduled yet defect 03/23/17

vbeta3pot is used for the irrigation. Based on diffuco_trans routine, it seems that it corresponds to a vbeta3 value when there is no water stress. In diffuco_trans_co2, the computation of vbeta3pot does account for water stress as it is embedded into rstruct+rveget (=1/gs). This is probably not correct. No clear solution to fix this.

#642 snowdz with zero values at the end of explicitsnow_main Biogeochemical processes ORCHIDEE 3.0 defect 12/17/19

After the inclusion of the discretized carbon forcesoil file, the following issue raised up:

[irene1014:97517:0] Caught signal 8 (Floating point exception)
==== backtrace ====
 2 0x000000000006ba2c mxm_handle_error()  /var/tmp/OFED_topdir/BUILD/mxm-3.7.3111/src/mxm/util/debug/debug.c:641
 3 0x000000000006bf7c mxm_error_signal_handler()  /var/tmp/OFED_topdir/BUILD/mxm-3.7.3111/src/mxm/util/debug/debug.c:616
 4 0x000000000000f5d0 _L_unlock_13()  funlockfile.c:0
 5 0x0000000000fefe86 stomate_soil_carbon_discretization_mp_soil_gasdiff_coeff_()  /ccc/work/cont003/dsmipsl/p529jorn/modipsl_trunk/modeles/ORCHIDEE_trunk_cforcing_ch4soil/build/ppsrc/stomate/stomate_soil_carbon_discretization.f90:1652
 6 0x0000000000fd971d stomate_soil_carbon_discretization_mp_soil_gasdiff_main_()  /ccc/work/cont003/dsmipsl/p529jorn/modipsl_trunk/modeles/ORCHIDEE_trunk_cforcing_ch4soil/build/ppsrc/stomate/stomate_soil_carbon_discretization.f90:1447
 7 0x0000000000fbdc9c stomate_soil_carbon_discretization_mp_stomate_soil_carbon_discretization_deep_somcycle_()  /ccc/work/cont003/dsmipsl/p529jorn/modipsl_trunk/modeles/ORCHIDEE_trunk_cforcing_ch4soil/build/ppsrc/stomate/stomate_soil_carbon_discretization.f90:1001
 8 0x0000000000b12740 stomate_mp_stomate_main_()  /ccc/work/cont003/dsmipsl/p529jorn/modipsl_trunk/modeles/ORCHIDEE_trunk_cforcing_ch4soil/build/ppsrc/stomate/stomate.f90:1472
 9 0x00000000009d7847 slowproc_mp_slowproc_main_()  /ccc/work/cont003/dsmipsl/p529jorn/modipsl_trunk/modeles/ORCHIDEE_trunk_cforcing_ch4soil/build/ppsrc/sechiba/slowproc.f90:734
10 0x000000000091f425 sechiba_mp_sechiba_main_()  /ccc/work/cont003/dsmipsl/p529jorn/modipsl_trunk/modeles/ORCHIDEE_trunk_cforcing_ch4soil/build/ppsrc/sechiba/sechiba.f90:839
11 0x00000000005a91a9 intersurf_mp_intersurf_main_2d_()  /ccc/work/cont003/dsmipsl/p529jorn/modipsl_trunk/modeles/ORCHIDEE_trunk_cforcing_ch4soil/build/ppsrc/sechiba/intersurf.f90:579
12 0x000000000050bc1b MAIN__()  /ccc/work/cont003/dsmipsl/p529jorn/modipsl_trunk/modeles/ORCHIDEE_trunk_cforcing_ch4soil/build/ppsrc/orchidee_ol/dim2_driver.f90:1285
13 0x000000000044695e main()  ??:0
14 0x0000000000022495 __libc_start_main()  ??:0
15 0x0000000000446869 _start()  ??:0

By taking a look were the floating pointing exception takes place:

    DO il = 1,nsnow-1
       WHERE ( snow_height_mask_2d(:,:) .AND. veget_mask_2d(:,:) )
          xcO2_snow(:,il,:) = ( zf_snow(:,il,:) - zf_snow(:,il-1,:) ) * &
               totporO2_snow(:,il,:) / time_step
          xcCH4_snow(:,il,:) = ( zf_snow(:,il,:) - zf_snow(:,il-1,:) ) * &
               totporCH4_snow(:,il,:) / time_step
          xdO2_snow(:,il,:) = diffO2_snow(:,il,:) /  &
               (zi_snow(:,il+1,:)-zi_snow(:,il,:)) <<-------------HERE, division by 0
          xdCH4_snow(:,il,:) = diffCH4_snow(:,il,:) /  &
    END DO

zi_snow is variable calculated by using snowdz. For that reason, snowdz is deeply checked throughout the code by tracing its changed values:

 explicitsnow_main:: begin, snowdz=  9.971282281093744E-004 0.000000000000000E+000  0.000000000000000E+000
 explicitsnow_fall:: snowdz=  9.971282281093744E-004  0.000000000000000E+000  0.000000000000000E+000
 explicitsnow_levels:: snowdz=  3.323760760364581E-004  3.323760760364582E-004   3.323760760364581E-004
 explicitsnow_main:: after levels, snowdz=  3.323760760364581E-004  3.323760760364582E-004  3.323760760364581E-004
 explicitsnow_transf:: snowdz=  3.323760760364581E-004  3.323760760364581E-004   3.323760760364581E-004
 explicitsnow_compactn:: snowdz=  3.307082347811091E-004  3.307071684104765E-004   3.307061020467210E-004
 explicitsnow_main:: after compactn, snowdz=  3.307082347811091E-004   3.307071684104765E-004  3.307061020467210E-004
 explicitsnow_main:: after profile, snowdz=  3.307082347811091E-004   3.307071684104765E-004  3.307061020467210E-004
 explicitsnow_main:: after gone, snowdz=  0.000000000000000E+000 0.000000000000000E+000  0.000000000000000E+000    <----- Snow removed !
 explicitsnow_melt_refrz:: snowdz=  0.000000000000000E+000  0.000000000000000E+000  0.000000000000000E+000
 explicitsnow_main:: after metl_refrz, snowdz=  0.000000000000000E+000  0.000000000000000E+000  0.000000000000000E+000
 explicitsnow_main:: 1st snowmelt_from_maxmass, subsnowveg=  -5.589300636728523E-002
 explicitsnow_main:: 1st snowmelt_from_maxmass, snowrho=   55.5706140888494
 explicitsnow_main:: 1st snowmelt_from_maxmass, ZSNOWEVAPS=  -1.005801488497506E-003
 explicitsnow_main:: 1st snowmelt_from_maxmass, ZSNOWDZ=  1.005801488497506E-003
 explicitsnow_main:: 1st snowmelt_from_maxmass, snowdz=  1.005801488497506E-003
 explicitsnow_main:: before snowmelt_from_maxmass, snowdz=   1.005801488497506E-003  0.000000000000000E+000  0.000000000000000E+000  <---- Snow introduced in the 1st layer
 explicitsnow_main:: before snowgrain, snowdz=  1.005801488497506E-003   0.000000000000000E+000  0.000000000000000E+000
 explicitsnow_main:: after snowgrain, snowdz=  1.005801488497506E-003  0.000000000000000E+000  0.000000000000000E+000
 explicitsnow_main:: end, snowdz=  1.005801488497506E-003 0.000000000000000E+000  0.000000000000000E+000
 snowlevels:: snowdz=  1.005801488497506E-003  0.000000000000000E+000   0.000000000000000E+000

After the call "before snowmelt_from_maxmass", a minimum amount of snow is introduced in the first layer. But it is never scattered across the different layers before leaving explicitsnow_main.

cpipsl (2 matches)

Ticket Summary Component Milestone Type Created
#477 Adding nitrogen-related variable outputs - CMIP6 data request Documentation ORCHIDEE 3.0 task 12/11/18

Most of nitrogen-related variables can now be output in the trunk version with the N cycle. One needs now to prepare/adjust the data request for CMIP6 for these new variables

#543 Prepare Nitrogen-related input files for CMIP6 Driver files ORCHIDEE 3.0 task 03/11/19

Forcing files for Nitrogen deposition, fertilisation, manure application have been prepared within the frame of CMIP6 for being used by LSM. One should possibly adapt these forcings for being used by ORCHIDEE (format, variable's name, ...)

fcheruy (3 matches)

Ticket Summary Component Milestone Type Created
#94 Hauteur de deplacement dans l'interface surface atmosphere Model architecture Not scheduled yet enhancement 03/29/13

The driver interpolates the wind (usually at 10m) to the level at which T and q are available (usually 2m). This done simply by assuming a logarithmic profile in the surface layer. It has to carried out each time the wind and the scalar variables are not at the same level (i.e. in most cases).

So the interpolation is written as :

u_2m = u_10m * log(zlev_tq/z0)/log(zlev_uv/z0)

This produces non sense as soon as z0 is larger than zlev_tq (i.e. 2m). Furthermore this is not consistent with what is assumed for the vertical wind profile in diffuco_aero when the neutral drag coefficient is computed.

So we need to replace this interpolation by the following formula :

u_2m = u_10m * log((zlev_tq+roughheight/z0)/log((zlev_uv+roughheight)/z0)

This means that roughheight has to come out of the sechiba_main and through intersurf so that it can be used in dim2_driver. This changes the interface !!

The consequence of this change will be that the wind over rough terrain will be higher and thus we are likely to generate more turbulence and higher fluxes. The consequences of this change need to be studied in detail.

#468 Inexpected differences in t2m when forcing ORCHIDEE with qair and tair Physical processes Not scheduled yet defect 12/03/18

Analysing the differences between 2 runs done when forcing ORCHIDEE with t2m (q2m) or with tair (qair), unexpected differences appear in the t2m diagnostic in winter https://orchidas.lsce.ipsl.fr/mapper/?set=rev.5229&mode=CL5 They are not linked with differences in the surface temperature nor in the energy budget (according to the mapper) Need to be investigated further. Also an unexepted checkered pattern over the ice caps for t2m (probably linked to the interpolation method)

#29 Parameters values : z0_over_height, height_displacement, ct_karman Physical processes Not scheduled yet enhancement 10/30/12

Jan suggested to modify the following parameters values :

  • z0_over_height : from 0.0625 to 0.046
  • height_displacement : from 0.75 to 0.67
  • ct_karman : from 0.35 to 0.40

To note: z0_over_height and height_displacement are externalized, so if needed these parameters can be reset before validation. See Branches/MergeHydro/logz0_note.


Sensitivity tests need to be done for evaluation and validation (off-line/coupled).

jgipsl (1 match)

Ticket Summary Component Milestone Type Created
#601 Add reading with XIOS for new files in sapiens_forestry.f90 Anthropogenic processes Not scheduled yet task 10/03/19

Files read in sapiens_forestry must also be read with XIOS. This must be done to keep possible running with DYNAMICO.

Ticket #665 must be done first.

Note also ticket #472 which must be closed before running XIOS_INTERPOLATION=y at obelix when compilation in mode debug is used.

jpolcher (2 matches)

Ticket Summary Component Milestone Type Created
#363 Implementation of XIOS and interaction with MPI Anthropogenic processes Not scheduled yet defect 04/21/17

The current implementation of XIOS and its interactions with MPI assumes that the model is all alone. Thus it fails when used in conjuncture with OASIS for instance.

Two things need to be done :

  • Test whether MPI is already initialized and differentiate the initialisation of MPI in the presence of XIOS. We know that when MPI is already initialized then OASIS must have done this before.
  • xios_orchidee_comm_init is given the possibility to return a communicator in case it needs to.

Another minor detail is that CALL xios_orchidee_context_finalize needs to be called at the end of the off-line drivers.

#575 Problems with CRU-NCEP/v7.2/twodeg with orchideedriver ("new driver") Driver files Not scheduled yet defect 06/19/19

Following were corrected but there are still 1 known problem with the orchideedriver (new driver):

  • [6040] : correction for initialization of XIOS
  • [6041] : correction to run with forcing time step 6h. Note a variable could be used instead of one_day/3.0.

Following have been tested succesfully with ORCHIDEE/trunk rev 6041

  • OOL_SEC_STO_FG3nd using WFDEI_GPCC/v2 halfdeg, on global and regional domain. Tests are done for a couple of days at irene.
  • OOL_SEC_STO_FG3nd using CRU-NCEP/v7.2/halfdeg, on global and regional domain. Tests are done for a couple of days at irene.

Problem: Using CRU-NCEP/v7.2/twodeg forcing
Running on the global grid, using the default values do not work. Having following in run.def do not work:

WEST_EAST = -180.0, 180.0
SOUTH_NORTH = -90.0, 90.0

Error message:

 Zoom forcing : lon =   -180.000000000000        180.000000000000
 Zoom forcing : lat =   -90.0000000000000        90.0000000000000
 forcing_givegrid:: nbpoint_loc=        5220
 forcing_givegrid:: nbland_loc=        5219

 --> nbpoint_loc and nbland_loc do match
 --> The calculation of land points is not correct

Running on regional grid works. For example following works:

WEST_EAST = -180.0, 180.0
SOUTH_NORTH = -80.0, 80.0

luyssaert (3 matches)

Ticket Summary Component Milestone Type Created
#476 Improvement/Tuning of the modelling of the Autotrophic Respiration Anthropogenic processes ORCHIDEE 3.0 task 12/11/18

Since the inclusion of the N cycle into the trunk, the tuning of the autotrophic respiration has to be done, as it has been done with the version prior to ORCHIDEE_2.0 few months ago. One particular focus should be put on the contribution of the labile C, which is partly respired, when it is in excess. Is it a feature/process one wants to keep or not ? If not, what do we do when labile C is excessively high ?

#633 Review bark beetle code Biogeochemical processes ORCHIDEE 4.3 task 11/29/19

The bark beetle code has been added to CN-CAN. This code runs only after activiting the proper flags. As a first order quality check, this code and its documentation should be reviewed (line-by-line) by someone who was not actively involved in writing it.

#774 Check product pools and fluxes Anthropogenic processes ORCHIDEE 4.1 task 04/26/21

With the bug fix in r7161, the cProduct pool is being output again. The spatial patterns for the 1800s look reasonable (highest fluxes in Europe and the Eastern US), but two questions remain:

1) Are the units correct? Doing some back of the envelope checks suggest that the fluxes shown are several orders of magnitude too small.

2) Why is there cProduct flux in year 1 of FG1trans? The short-lived product pool is set to one year, which means everything is decomposed from croplands and grasslands immediately and does not get carried over to the next year (consistent with a flux of 0.0 for cProduct throughout the FG1 simulation). Land use change happens at the beginning of the year. The map changes from 1860 to 1861 with the change from FG1 to FG1trans. Some cProduct flux is present in 1861, the first year of FG1trans. Should there be? Or should it start in 1862?

maignan (2 matches)

Ticket Summary Component Milestone Type Created
#324 Which thermal properties on the nobio fraction Anthropogenic processes Not scheduled yet defect 12/13/16

Since ticket r3588 (see Ticket #222), the nobio fraction has been excluded from soiltile 1, so it has no related soil moisture.

1) The contribution of the nobio fraction to the thermal properties may need to be revised accordingly (for instance assuming a pre-defined soil moisture, or that the nobio fraction has the average soil moisture of the bio fraction).

2) Please check the eventual choices are consistent with the assumptions regarding the calculation of the variables transmitted to thermosoil (mc_layh, etc., shumdiag_perma), for which a grid-cell average has been preferred to an average over the nofraction (https://forge.ipsl.jussieu.fr/orchidee/ticket/222#comment:5).

#419 Modification on co2_to_bm and respiration maintenance Anthropogenic processes ORCHIDEE 3.0 defect 01/25/18

Description a remplir par Nicolas Vioy

mguimberteau (1 match)

Ticket Summary Component Milestone Type Created
#35 Do we apply irrigation water to soil moisture of forests? Physical processes Not scheduled yet enhancement 11/05/12

Version: Trunk

Water from irrigation (computed in routing.f90) is applied to soil moisture. In hydrolc.f90, irrigation water is applied to the vegetated fraction for the PFT 2 to 13 (jv > 1). hydrolc_soil (line 2548):

              IF ( jv > 1 ) THEN

                 ! Only add the irrigation to the upper soil if there is a reservoir.
                 ! Without this the water evaporates right away.
                 IF ( gqsb(ji,jv) > zero ) THEN
                    gqsb(ji,jv) = gqsb(ji,jv) + irrigation(ji)/(vegtot(ji)-tot_bare_soil(ji))
                    bqsb(ji,jv) = bqsb(ji,jv) + irrigation(ji)/(vegtot(ji)-tot_bare_soil(ji))

Why do we apply the irrigation water for the forest (for fruit trees? => negligible)? In Guimberteau's phD version, only the PFTs 10 to 13 (ie grassland and crops) were irrigated.

For the 11-layer hydrology in hydrol.f90, irrigation is applied on the three tiles. (Tile 1 = frac_nobio and desert, Tile 2 = forest, Tile 3 = grassland & crops). Why do we apply irrigation to tiles 1 and 2?

Irrigation should be only applied to PFTs 10 to 13 (hydrolc.f90) or to tile 3 (hydrol.f90). The results may be very different if we concentrate irrigation water only on selected PFTs than all the PFTs of the grid-cell (not tested).

nicolasviovy (2 matches)

Ticket Summary Component Milestone Type Created
#546 Problem in Woody biomass Biogeochemical processes ORCHIDEE 3.0 enhancement 03/19/19

Woody biomass is ~2 times too high, compare to the version 2.0 and to acceptable values from literature. Based on the monitoring diagnostics, the gpp and the allocated npp to wood are not so different between versions (although they are higher with the current trunk version with the nitrogen).

The flow of carbon from wood to litter is also similar from one version to another. This seems to indicate a problem in the residence time of the woody pool (a priori it should be the same value than in the version 2.0) but maybe not...

This needs a deeper analysis. This global behavior may hide specific regional patterns or differences for only few PFTs.

#396 Carbon mass conservation problem Biogeochemical processes Not scheduled yet defect 09/27/17

When performing spinup run for TRENDY, I diagnosed a problem in the closure of the carbon balance. nbp variable has a value of -0.02 Pg/yr-1 (= a source for surface to atm) over the 10 year of climate forcings (used for the spinup) while stocks of carbon increase of ~0.02 Pg/yr-1.

nvuilsce (1 match)

Ticket Summary Component Milestone Type Created
#474 Adapt configurations after inclusion of ORCHIEE-CN in the trunk Anthropogenic processes ORCHIDEE 3.0 enhancement 12/04/18

When branch ORCHIDEEE-CN was merged into the trunk, some of the ORCHIDEE offline experiments were updated but not all. Following has been done:

  • OOL_SEC_STO_FG1trans

Following must be done:

  • LMDZOR_v6.3 (it is not clear yet which experiments should be done)

For information about the inclusion of ORCHIDEE-CN in the trunk, see ticket #469

peylin (4 matches)

Ticket Summary Component Milestone Type Created
#491 Reference Article corresponding to version V2.0 used in CMIP6 Project management Objective 2019 task 01/28/19

Finalise the paper describing the new version of ORCHIDEE used for CMIP6. Objective to submit the paper before June 2019. Philippe

#388 Incoherence in qsatcalc when temperature is too high Physical processes Not scheduled yet enhancement 08/24/17
Sujet : 	Re: [orchidee-help] soil temperature exceed threshold (of 1M K) in grid w/o vegetation: model stops
Date : 	Thu, 24 Aug 2017 11:38:12 +0200
De : 	Fabienne Maignan <maignan@lsce.ipsl.fr>
Pour : 	Daniel Goll <dsgoll123@gmail.com>, orchidee-help@listes.ipsl.fr


Le 11/08/2017 à 12:03, Daniel Goll a écrit :
> Hi
> my simulation stop because the soil temperature in a gridbox without vegetation growing since 1yr of the simulation exceeds the temperature of the core of the sun (1M K; threshold 'missing insrc_sechiba/enerbil.f90) after several hundred of years. (The gridbox is a coastal point (where there is actually ocean in real life); so no vegetation is okay.)
> 1. Are you serious about the threshold? What is the rational behind this threshold? 
The logic is the following one:
In qsat_moisture.f90, the temperature is tested against the threshold max_temp defined in the module as 370K.

In the old version (subroutine qsat_old) if the temperature exceeded the threshold and the flag diag_qsat was activated (TRUE is the default value), the return value for qsat was set to 999999.
This mechanism has disappeared in the new version (qsatcalc).

In enerbil_begin, qsatcalc is called, if the flag diag_qsat is activated qsol_sat is tested against missing = 999998 and then stops if qsol_sat is higher.

> 2. Any suggestion what to do?
To be coherent, the return value for qsat should be set again to 999999 if the temperature is too high, or another more elegant solution should be implemented.
However I'm not aware of the reasons why the qsat subroutines were modified.
I'll open a ticket to track this.

#478 Check-list to do in order to run properly the Trunk Documentation Not scheduled yet enhancement 12/11/18

Define a check-list of specific points to run properly the TRUNK with specific informations on

  • Spin up of main variables: how long should we do the spin up ? for which variable ?
  • Which forcing and configuration are best suited for a given version, in particular the new CN - TRUNK

==> Need to define 2 how-to wiki pages

  • 1 for all check-list points to verify in order to do a simulation
  • 1 for the specific case of the spin up of the main variables


#547 Analysis of the Spatial heterogeneity of gpp Biogeochemical processes ORCHIDEE 3.0 enhancement 03/19/19

The gpp with the trunk version with nitrogen is probably too heterogeneous from one region to another, and also from one pixel to another within the same region. For instance gpp in Amazonia is quite low compare to its value in Central Africa, and there are large differences between pixels in Amazonia region. A deeper analysis is needed for explaining what drives these differences.

somebody (2 matches)

Ticket Summary Component Milestone Type Created
#467 Understand the abrupt changes of vbeta Physical processes Not scheduled yet defect 12/03/18

Exploring the reasons why t2m_max and q2m (interpolated between the surface and the first atmospheric level owing to MO laws) it appeared that the problem occured for near saturation values of qsurf. For the cases investigated, the problem shows up only for one time-step (during the night, without rain, over semi-arid areas). It is related to abrupt change in vbeta1 and vbeta3. The problem exists even when ORCHIDEE is forced with tair and qair from LMDZ so it is not a consequence of the irrealistic values of t2m.

Abrupt change in vbeta1 and vbeta3 can occur when there is no turbulence and no wind and when the soil moisture is far from the wilting point. This can give unrealistc values of qsurf when the atmosphere is dry. It has been limited by avoiding too low values for qc ( qc=speed*drag ) in enerbil, see [6018], [6019].

It would be safe to understand if the abrupt changes of vbeta in ORCHIDEE are realistic.

#552 Propose to remove option ALMA_OUTPUT=y with IOIPSL output Model architecture Not scheduled yet task 05/02/19

XIOS output is what we advice for simulations and what we develop in the model but still we do not want to remove completely IOIPSL output from the model.

To simplify the maintenance, I suggest to remove option ALMA_OUTPUT=y with IOIPSL output from the trunk ORCHIDEE.

If there are variables currently written only if ALMA_OUTPUT=y, they can be moved and kept after the cleaning. If so, please write them below in the ticket.

vladislav (1 match)

Ticket Summary Component Milestone Type Created
#395 ORCHIDEE crashes when using a land-use map with negative maxvegetfrac values Driver files Not scheduled yet defect 09/22/17

When performing trendy simulations, there were land-use maps with near-zero negative values (-1e-7). Using this map leads to the crash of the model without error message.

Note: See TracReports for help on using and creating reports.