wiki:Documentation/Frac_Nobio

Context Navigation

Version 14 (modified by abierjon, 6 weeks ago) (diff)
--

DESCRIPTION GENERALE (Jan, Agnes)

The usage of the frac_nobio variable in ORCHIDEE

frac_nobio is the variable which describes the fraction of the grid box which will never (in the foreseeable future !) be covered by vegetation. These fraction can be covered by glaciers, cities lakes or any other surface type where no biological activity (transpiration, assimilation, decomposition, ...) will happen. For the moment only glaciers are considered.

Thus the grid box within ORCHIDEE is devided into fractions of no-bio and veget with the following property : 1 = SUM(frac_nobio(:,jn), jn=1,nnobio) + SUM(veget_max(:,jv), jv=1,nvm)

This variable has 2 dimensions : kjpindex and nnobio. In other words, the number of land grid points in ORCHIDEE and the number of no-bio classes. For the moment nnobio=1.

In the following we will go through each of the modules and detail where frac_nobio is used and with which intention.

general comments

the 2 variables frac_nobio and totfrac_nobio are passed to most subroutines. This is redundant information as in principle totfrac_nobio(:) = SUM(frac_nobio(:,jn), jn=1,nnobio). Nowhere is it verified that the this is indeed true and in case of the DVGM activated it will certainly not be the case.

The addition of the second dimension to frac_nobio (nnobio) was not done correctly and is not fully implemented.

A first step in an effort to better handle the no-bio fraction would be to clean-up the code and terminate the implementation of the nnobio dimension. Only frac_nobio should be used and the implementation of the second dimension should be finished.

slowproc

slowproc_veget :

computes the frac_nobio from the vegetation map read. It sums all the fractions which are covered by ice in carteveg5km.nc.
AD: defines soiltile(:,jst=1,3) for hydrol. totfrac_nobio(:) is included in soiltile(:,1), the fraction covered by bare soil (PFT1, jv=1).

slowproc_readvegetmax : derived from the PFT map as the complement needed to bring the sum of veget(ig,jv) to 1. So the other types of non biological active surface types are apparently not documented in the PFT maps.

stomate_main : also returns a new total frac_nobio (totfrac_nobio_new) in case of a dynamic vegetation.

In case totfrac_nobio changes (which can occur through stomate_main) there is no code to adjust frac_nobio. Thus a divergence between these two variables will be created.

There is no code either to update all the prognostic variables of the model which depend on frac_nobio, does this matter ?

condveg

In condveg the frac_nobio is used in the same way as veget in order to derive surface properties.

condveg_snow : uses frac_nobio to add the albedo of ice to the total albedo of the grid box. Should other nobio types be present the model will stop. So only frac_nobio for ice is foreseen for the moment.

condveg_z0logz and condveg_z0cdrag : use the same logic as for the snow and compute the grid box average surface roughness taking into account the properties of the ice (z0_nobio).

diffuco

Ensures that over the frac_nobio only sublimation can occur.

diffuco_snow : in this subroutine vbetaveg1 will be modified assuming that the all frac_nobio types have sublimation.

enerbil

Here frac_nobio is not used. The information about the fraction of the grid box which is not covered by vegetation or bare soil is integrated in the various surface parameters provided to enerbil (vbeta1, soilflx, soilcap).

AD: do the energy and water and fluxes produced by enerbil correspond to vegtot= SUM(veget_max(:,jv), jv=1,nvm), or to vegtot+totfrac_nobio=1 ??

hydrol

hydrol_snow : frac_nobio is used to update the snow mass with the fraction of sublimation attributable to the fraction of the grid not covered by biological active surfaces. It also intervenes in the melting of the snow on (1-totfrac_nobio) and split the falling snow over the 2 sub areas of the grid box.

AD: hydrol_soil treats the soil water balance with the following features, which may not be consistent from the point of view of nobio:

the soil treated in hydrol_soil covers SUM(soiltile(ji,:))=1=vegtot+totfrac_nobio
excluding the water fluxes to/from the routing scheme for simplicity, the soil receives as liquid input fluxes: (i) the snowmelt that was produced from vegtot+totfrac_nobio, and (ii) the rainfall that fell on vegtot only. Here, I am not sure if it's consistent to redistribute this rainfall on vegtot+totfrac_nobio without renormalization...?
the water fluxes that leave the soil are (i) the surface runoff, drainage, and bare soil evaporation (evapnu), which are produced over SUM(soiltile(ji,:))=vegtot+totfrac_nobio, (ii) the transpiration and interception loss, which are only produced from the PFT 2 to nvm, corresponding to soiltile(ji,2)+soiltile(ji,3). This sends back to my question regarding enerbil, although I don't imply this is wrongly done in the code.

AD: a point that raises doubt on the use of frac_nobio and vegtot in hydrol is that it is different from its use in hydrolc (Choisnel), in which the "soil" fraction does not include frac_nobio. Despite this difference, the water budget calculations are very similar in hydrol_waterbal and hydrolc_waterbal:

hydrolc_waterbal:

tot_water_end(ji) = (mean_bqsb(ji) + mean_gqsb(ji))*vegtot(ji) + &
            & watveg(ji) + snow(ji) + sum_snow_nobio(ji)
tot_flux(ji) =  precip_rain(ji) + precip_snow(ji) + returnflow(ji) + reinfiltration(ji) + irrigation(ji) - &
             & sum_vevapwet(ji) - sum_transpir(ji) - vevapnu(ji) - vevapsno(ji) - vevapflo(ji) + &
             & floodout(ji)- run_off_tot(ji) - drainage(ji)

hydrol_waterbal:

tot_water_end(ji) = humtot(ji)*vegtot(ji) + watveg + &
            & snow(ji) + SUM(snow_nobio(ji,:))
tot_flux(ji) =  precip_rain(ji) + precip_snow(ji) + irrigation (ji) - &
            & SUM(vevapwet(ji,:)) - SUM(transpir(ji,:)) - vevapnu(ji) - vevapsno(ji) - vevapflo(ji) + &
            & floodout(ji) - runoff(ji) - drainage(ji) + returnflow(ji) + reinfiltration(ji)

which was the model for the new total water budget residu (twbr) diagnostic:

twbr(ji) = (vegtot(ji)*delsoilmoist(ji) + delintercept(ji) + delswe(ji)) &
            - ( precip_rain(ji) + precip_snow(ji) + irrigation(ji) + floodout(ji) &
               + returnflow(ji) + reinfiltration(ji) ) &
            + ( runoff(ji) + drainage(ji) + SUM(vevapwet(ji,:)) &
                + SUM(transpir(ji,:)) + vevapnu(ji) + vevapsno(ji) + vevapflo(ji) )

thermosoil

thermosoil_coef : frac_nobio is used in the computation of the effective soil heat capacity and heat flux by contributing soilcap_nosnow and soilflx_nosnow over its area.

Is this correct ? : The frac_nobio is today only ice and should thus be covered by snow or material of very similar properties. Thus frac_nobio should contribute to the effective soil heat capacity and heat flux snowcap and snowflux. This is directly related to the discussion started by Sylvie Charbit.

thermosoil_profile : frac_nobio is used to compute the effective surface temperature by combining the snow temperature (bottom of snow pack) an the surface temperature computed by enerbil.

explicitsnow

Somebody else should fill this section !

FRAC_NOBIO AND WATER CONSERVATION (Nicolas)

Traitement du NOBIO dans hydrol (comparativement à hydrolc). Le document initial de Nicolas est aussi visible: ici

Etat des lieux

Pour rappel, dans Choisnel:

Le frac_nobio n'est pas inclus dans les tiles sur lesquels on fait le bilan d'eau. On a un bilan d'eau pour chaque PFT de 1 à 13, le PFT 1 représentant "tout" le sol nu, soit veget_max⁡(1)+∑_(i=2)^{13▒(veget_max⁡(i)-veget(i))
et les PFT i de 2 à 13 représentant veget(i).}

La fonte de la glace/neige présente sur le NOBIO alimente le réservoir d'eau de chacun des 13 tiles; et l'apport d'eau associé est d'autant plus important que la fraction frac_nobio est élevée (vegtot petit), afin justement de conserver l'eau. http://forge.ipsl.fr/orchidee/browser/trunk/ORCHIDEE/src_sechiba/hydrolc.f90#L2716

Le flux vevapnu que reçoit en entrée la routine hydrolc_main correspond au flux d'évaporation du sol nu moyenné sur la maille (en prenant en compte donc le NOBIO) qui est calculé dans enerbil: http://forge.ipsl.fr/orchidee/browser/trunk/ORCHIDEE/src_sechiba/enerbil.f90#L1574

avec vbeta4 fonction de tot_bare_soil (veget_max⁡(1)+∑_(i=2)^{13▒(veget_max⁡(i)-veget(i)) )
http://forge.ipsl.fr/orchidee/browser/trunk/ORCHIDEE/src_sechiba/diffuco.f90#L1313}

Ceci explique que en entrant dans hydrolc, on commence par renormaliser vevapnu par tot_bare_soil de telle sorte de non plus travailler avec un flux moyen sur la maille mais sur un flux moyen sur le PFT 1: http://forge.ipsl.fr/orchidee/browser/trunk/ORCHIDEE/src_sechiba/hydrolc.f90#L2716

Avantage de l'approche Choisnel: l'évaporation du sol nu n'opère que sur le PFT1 Inconvénient: l'entrée d'eau associée à la fonte sur le NOBIO impacte sur tous les bilans d'eau, et ce d'autant plus fortement que frac_nobio est grand.

Dans CWRR:

On a quelque chose de conflictuel dans la représentation du NOBIO dans CWRR. D'un côté, on considère que le NOBIO est représenté puisqu'il est inclus dans la tile 1: soiltile(1) = veget_max(1) + frac_nobio.

De l'autre, on redistribue le fonte de la neige et de la glace du NOBIO (contenu dans tot_melt avec le reste de la fonte) sur toutes les tiles (ce qui est incohérent avec le fait d'envisager que le NOBIO est entièrement inclus dans la tile(1)) http://forge.ipsl.fr/orchidee/browser/trunk/ORCHIDEE/src_sechiba/hydrol.f90#L3573

et on renormalise par 'vegtot' ( ∑_(i=1)^{13▒(veget_max⁡(i)) ) precisol_ns par exemple, laissant à penser que le somme des soiltiles ne vaut pas 1:
http://forge.ipsl.fr/orchidee/browser/trunk/ORCHIDEE/src_sechiba/hydrol.f90#L6215}

avec corr_veg_soil(ji,jv,jst)=veget_max(ji,jv)/soiltile(ji,jst) et precisol calculé ici (http://forge.ipsl.fr/orchidee/browser/trunk/ORCHIDEE/src_sechiba/hydrol.f90#L3560)

Donc il faut à mon avis déjà trancher entre ces deux options. A priori, on a décidé vendredi d'enlever frac_nobio de la soiltile(1) (OPTION A). C'est ce qu'il y a de plus simple à faire et cela correspond à réaliser le même traitement que dans Choisnel, avec le même inconvénient. Si on souhaite garder l'approche "soiltile(1) = veget_max(1) + frac_nobio" (OPTION B), il faut enlever des termes de normalisation (division par vegtot) à plusieurs endroits du code et réattribuer la partie du tot_melt associé au NOBIO exclusivement à la soiltile 1. L'"avantage" de cette dernière approche (si on peut dire) est que 1/ l'impact de l'entrée d'eau associé au NOBIO est limité au bilan d'eau de la soiltile 1 (et non à toutes les tiles, comme pour le 2 couches), 2/ l'impact est moindre que dans le 2 couches, puisqu'à cette entrée d'eau on associe une fraction de sol (frac_nobio), de telle sorte que son effet est "dilué".

Tout ce qui vient d'être dit aboutit à mon avis à de mauvais calculs dans le cas où FRAC_NOBIO est non nul, mais je ne pense pas que cela explique le problème de non fermeture du bilan d'eau.

Problème de non-fermeture du bilan d’eau

Pour ce problème de non-fermeture dans le cas où FRAC_NOBIO est non nul avec CWRR, il faut regarder comme on l'a fait pour Choisnel, le traitement de vevapnu.

Le flux vevapnu que reçoit hydrol est le même qui celui reçu par hydrol, soit un flux moyenné sur la maille (BIO+NOBIO). Le calcul de ae_ns nous permet de passer du flux vevapnu calculé sur la maille à des flux d'évap pour chacune des tiles. Il s'agit donc d'une redistribution/renormalisation d'un flux moyen. http://forge.ipsl.fr/orchidee/browser/trunk/ORCHIDEE/src_sechiba/hydrol.f90#L6243

Pour cela, on utilise donc le rapport evap_bare_lim_ns/evap_bare_lin qui est calculé ici: http://forge.ipsl.fr/orchidee/browser/trunk/ORCHIDEE/src_sechiba/hydrol.f90#L2152

C'est cette ligne qui pose problème, je crois dans le cas de l’option B, qui est celle retenue actuellement dans hydrol. evap_bare_lim_ns représente une résistance du sol à l'évaporation pour chacune des tiles et evap_bare_lim devrait représenter la résistance moyenne sur la maille.

On devrait redistribuer vevap_nu sur les 3 tiles, de telle sorte que ∑_(jst=1)^{3▒(ae_ns(jst)×soitile(jst)) =vevapnu}

<=> ∑_(jst=1)^{3▒(vevapnu×evap_bare_lim_ns(jst)/evap_bare_lim×soitile(jst)) =vevapnu×∑_(jst=1)}3▒(evap_bare_lim_ns(jst)×soitile(jst)/evap_bare_lim)

avec evap_bare_lim=∑_(jst=1)^{3▒(evap_bare_lim⁡_ns(jst)×soitile(jst)×vegtot) (EQ. Pb)
on aboutit à vevapnu⁄vegtot ≠ vevapnu}

Le terme vegtot est de trop dans l'équation (EQ. Pb). Ceci est vrai pour les 2 options (A ou B). Quand on regarde l’équation (EQ. Pb), dans le cas de l'option AB, les 3 soiltiles représentent bien toute la maille (BIO+NOBIO), on n'a donc pas besoin de pondérer par vegtot. Dans le cas de l'option BA, les 3 soiltiles ne représentent que le BIO et la validité de tout ce qui est fait dans hydrol et du traitement de vevapnu en particulier dépend de la manière dont on définit les soiltiles. Après re-lecture du code, tout est codé dans hydrol en pré-supposant que les soiltiles ne représentent que le BIO et que la somme des tiles vaut 1. Il faut donc normaliser par ∑_(i=1)^{13▒〖veget_max⁡(i)〗. Dans le cas de l’option A, les soiltiles doivent être définies comme suit, avec la paramétrisation de pref_soil_veg actuelle :}

soiltile(1)=(veget_max⁡(1))⁄(∑_(i=1)^{13▒〖veget_max⁡(i)〗)}

soiltile(2)=(∑_(i=2)^{9▒〖veget_max⁡(i)〗)⁄(∑_(i=1)}13▒〖veget_max⁡(i)〗)

soiltile(3)=(∑_(i=10)^{13▒〖veget_max⁡(i)〗)⁄(∑_(i=1)}13▒〖veget_max⁡(i)〗)

Si les soiltiles sont définis ainsi, je pense que le traitement du NOBIO dans hydrol est fait correctement et que l’on ne devrait plus avoir le problème de non-fermeture du bilan d’eau.

mais la somme de soiltile(i) i de 1 à 3 ne vaut pas 1, de telle sorte que l'on prend déjà en compte le partitionnnement BIO/NOBIO. evap_bare_lim pouvant s'écrire ainsi: evap_bare_lim=somme(evap_bare_lim_ns(jst)*soiltile(jst))/somme(soiltile(jst))*vegtot avec somme(soiltile(jst))=vegtot

Un dernier point en lien avec ce qui a été discuté plus haut, concerne le calcul de frac_bare_ns(jst), soit la fraction de sol nu associée à la tile jst. Son calcul est fait ici: http://forge.ipsl.fr/orchidee/browser/trunk/ORCHIDEE/src_sechiba/hydrol.f90#L3740

Là encore, le terme '/vegtot' est de trop, quelle que soit l'option choisie (A ou B).