AOT40 at global scale

[mvieno]

Hi, I am thinking to add a "global" call to the AOT40 calculation. As far as I understood (it is a big assumption!) the AOT40 for "EU" and "MM" uses the SGS and EGS based on the North Hemisphere and EU in particular and applied everywhere even if a global run.

For my global runs I use the "MM" as it uses daylight rather than the fix 08:00 -- 20:00, and then I set the growing season in the Landuse_Input definition to 0-366 (all year) at least it is consistent everywhere, or better this is what I am aiming for.

Name,code,type,PFT,hveg,Alb,eNH4,SGS50,DSGS,EGS50,DEGS,LAImin,LAImax,SLAIlen,ELAIlen,BiomasD,Eiso,Emtl,Emtp,#HEADERS,!,,Eiso-m2,Emt-m2,G12-Eiso,G12-Emt,

,m,(%),day,days/d,day,days/d,m2/m2,m2/m2,days,days,g/m2,ug/g/h,ug/g/h,ug/g/h,#SKIP

IAM_CR,IAM_CR,ECR,NOLPJ,1,20,1,0,0,366,0,3.5,3.5,1,1,700,0,0,0,,,,0,0 IAM_DF,IAM_DF,EDF,NOLPJ,20,16,0,0,0,366,0,0,4,15,30,0,0,0,0,,,,0,0 IAM_MF,IAM_MF,EMF,NOLPJ,8,12,0,0,0,366,0,5,5,1,1,0,0,0,0,,,,0,0

I was thinking we could modify the the function Calc_GridAOTx( iX ) to calcuate the AOT fro each grid with a latitude function to set the SGS and EGS for the relevant latitude.

Massimo

[mvieno]

The EMEP model calculates the SGS and EGS using a latitude function. So if SGS50=120 and EGS50=240, means that at 50N the SGS is 1st of May and EGS the 29th of Aug.

if ( LandDefs(lu)%DSGS > 0 )  then ! calculate
    SGS = int ( 0.5 +  LandDefs(lu)%SGS50 + LandDefs(lu)%DSGS * (lat-50.0) )
    EGS = int ( 0.5 +  LandDefs(lu)%EGS50 + LandDefs(lu)%DEGS * (lat-50.0) )
  else
    SGS = LandDefs(lu)%SGS50
    EGS = LandDefs(lu)%EGS50
  end if

For example using SGS50 = 120, EGS50=240, DSGS=DEGS=2.5, x-axes is the latitude and the y-axes is the SGS and EGS.

[mifads]

Hi Massimo, The latitude function only makes sense for European runs, and is hopeless elsewhere. For global scale it is better to set USES%PFT_MAPS = T, then LAI is controlled by the monthly LPJ-GUESS scaling from GLOBAL_LAInBVOC.nc file. I need to double-check how AOT is calculated, but in the past we just used monthly outputs, and decided which months to accumulate over, similar to the procedure we used in Mills et al., GCB (See Table S1): https://doi.org/10.1111/gcb.14157

[mifads]

Hi again, Looks like the module AOTnPOD_mod needs some hacking for global scale AOT. There are various assumptions about using GMT time, or STARTMONTH_FOREST, etc., which are mainly aimed at Europe. A quick fix might be to use the Calc_GridAOTx routine, but comment out the lines:

    !--------- ONLY April-Sept -------------------------
!CAREFUL!!!
!Keep for now. Irrelevant for global studies though
    if(  current_date%month<STARTMONTH_FOREST&
     .or.current_date%month>ENDMONTH_FOREST   )  RETURN
    !--------- ONLY April-Sept -------------------------

which would give output every month, and then you could choose which months to use in different parts of the world.

[dave]

Wrong dave 😉

[mvieno]

@mifads what I used are the MM which only uses the SGS and EGS , and I setup the SGS50=0 and EGS50=366, (also DSGS and DEGS =0). I then output the daily AOT40 that way we have very day. Thanks.

[mvieno]

Wrong dave 😉 @Dave oops sorry :)

[mifads]

Hi Massimo,

@mifads what I used are the MM which only uses the SGS and EGS , and I setup the SGS50=0 and EGS50=366, (also DSGS and DEGS =0). I then output the daily AOT40 that way we have very day. Thanks.

Sounds ok too! Remember also that the MM_ methods use O3 at the top of the vegetation, whereas the Calc_GridAOT40x just uses the 3m grid-average O3 regardless of underlying landcover.

[mifads]

No follow-ups here, so I close the issue. Just re-open if needed.