Hi Tristan:
It seems that according to that webpage:
https://code.metoffice.gov.uk/trac/jules/wiki/JulesConfigurations,
the latest official GL release is 9.
There is a link on that webpage called testing, which links to:
https://code.metoffice.gov.uk/trac/jules/wiki/gl9_testing,
and that link shows that the GL9 configuration has can_rad_mod=6.
But the suite u-bu288 for GL9 that is referred to in the JulesConfigurations link above seems to have can_rad_mod=4 in it, at least when I looked the other day.
I will certainly do the comparison study when I can, between can_rad_mod=4 and can_rad_mod=6 for the layered-canopy branch version of JULES that I have, using GL9.
But that is a little ways down the road. I think it is important first to get the layered-canopy branch version working completely for JULES7.0. It still crashes as I said before in the physiol( ) module sometimes after only 1 timestep. I don’t think it will take a huge amount of time to fix this, but it might take a little while.
The GL9 configuration in the suite u-bu288 appears to use JULES6.0. Maybe the better way to go is to port the canopy-layer branch changes you made to JULES5.0 to a canopy-layer branch of JULES6.0. Currently, I have almost finished porting the changes to a canopy-layer branch of JULES7.0, thinking that in order to get the canopy-layer code into the JULES trunk, that we would need to at least port it to the most-recent version (or almost-most-recent version) of the JULES trunk.
For now, however, I will spend some more time trying to get the JULES7.0 branch working without crashing, before trying to create a JULES6.0 branch of the canopy-layer code.
Patrick
Hi Tristan:
I think I tracked down and possibly fixed the bug that was causing the JULES7.0 canopy-layer branch to crash early in the run.
In src/science/surface/sf_stom_jls_mod.F90, there is code that only calculates some things for C3 plants:
IF ( c3(ft) == 1 ) THEN
! Calculate terms that are only needed for C3 plants.
! Although oa, kc and ko are always used together we keep them separate
! to maintain bit comparability.
tau = 2600.0 * (0.57 ** power)
ccp(l) = 0.5 * oa(l) / tau
kc(l) = 30.0 * (2.1 ** power)
ko(l) = 30000.0 * (1.2 ** power)
ENDIF
When I get rid of this if statement, so that these numbers are calculated for all plant types, then the code runs without crashing for the UK region, and with can_rad_mod=6, it produces non-zero output for gpp_lay.
Patrick
OK… but are you sure that doesn’t introduce errors in the C4 calculation? I honestly have no idea, but it feel a bit dangerous to me.
Hi Tristan:
Yes, it could possibly introduce C4-grass errors. I will try to study it further. I looked at some of the code already, and it might be that some/all(?) those variables are either only used by C3 plants or there is other code further down that modifies the C4 plants. There are certainly other ways to remove the run-time error, like having an else statement here. I think the If (c3==1) statement here is mainly to save some compute time.
Patrick
Hi Tristan:
In the JULES7.0 canopy-layer branch code, I think I can re-enable the if(c3==1) condition I was referring to. Instead, I think I just need to delete this line:
ccp(l) = 0.5 * oa(l) / tau(l) * REAL(c3(ft))
which was right before:
cmpf_lay(l,n)=(ci(l) - ccp(l)) / (ci(l) + 2.0 * ccp(l)) .
The ccp was computed previously, so computing it again here will lead to errors if tau(l) isn’t defined properly (i.e., for c4 plants).
Patrick
Hi Tristan:
I think that last change (to delete the 2nd ccp calculation line in the JULES7.0 canopy-layer branch) did indeed work.
The next step could be to get the canopy-layer code working with either GL7 or GL9 configuration. I think the GL7 configuration has been developed with JULES5.2 trunk, whereas the GL9 configuration has been developed with the JULES6.0 trunk. I have experience already with the GL7 suite u-bb316, so I will start porting the canopy-layer branch from JULES5.0 to JULES5.2.
I think the GL9 suite might still also be an experimental suite, but I am not sure.
Patrick
Hi Tristan:
So I now have ported your canopy-layer code from your JULES5.0 branch to JULES7.0, JULES5.2, and JULES6.0 branches. This was done manually, using recursive diff to highlight the changes needed. Adjustments from a straightforward merge were necessary.
The JULES5.2 branch is being used with the canopy-layered-output-enabled GL7-configuration suite u-cv054. This suite is adapted from suites u-bb316 and u-bx723, which are GL7-configuration N96-resolution suites that use the JULES5.2 trunk but don’t have canopy-layered output capability for GPP, FAPAR and CMPF. This u-cv054 GL7 suite is running through spinup now.
The JULES6.0 branch is being used with the canopy-layered-output-enabled GL9-configuration suite u-cv055 . This suite is adapted from the suite u-bu288, which is a GL9-configuration N96-resolution suite that uses the JULES6.0 trunk but doesn’t have canopy-layered output capability for GPP, FAPAR and CMPF.
This u-cv055 GL9 suite has some run-time errors that I need to sort out. The JULES6.0 canopy-layer branch previously ran ok on the region around the UK when using my modified version of the namelists you gave me (located on JASMIN in: /gws/nopw/j04/odanceo/pmcguire/jules_sif/global_v6.0pw).
The JULES7.0 and the JULES5.2 branches were ported from the JULES5.0 branch, directly. The JULES6.0 branch for canopy-layering was ported from the JULES7.0 branch, mostly. There seems to have been some significant changes to the trunk between JULES5.2 and JULES6.0, which made the changes needed for the JULES6.0 branch more similar to the JULES7.0 branch than to the JULES5.2 branch.
Patrick
Hi Martin
(from an email to MartinB, cc: TristanQ)
The multi-platform GL9 suite u-bu288 described on:
https://code.metoffice.gov.uk/trac/jules/wiki/JulesConfigurations
has GL9 ancillaries for the MO XC40 computer
ANCIL_DIREC= "/home/d03/mbest/ancil/global/n96e_orca025_go6_GL9_JLMP"
but it has GL7 ancillaries for the JASMIN computer:
ANCIL_DIREC= "/gws/nopw/j04/jules/data/Ancillary/n96e/GL7/fixed/"
ANCIL_TIME_DIREC= "/gws/nopw/j04/jules/data/Ancillary/n96e/GL7/time_varying/"
I looked for the MO XC40 ancillaries on MONSOON, but there is no home directory for ~mbest there. Are these ancillaries available somewhere? Or can they be made available?
Patrick
Hi Martin:
I read the docs further:
https://code.metoffice.gov.uk/trac/jules/wiki/running_gl9
and it says that for the GL9 suite on JASMIN, GL7 ancillaries should be used instead of GL9 ancillaries.
And it explains the suite changes necessary to do this. So I guess it should run now.
Do you know if there have been any updates to the GL9 ancillaries since the documentation page was last updated on 24/3/21?
Patrick
Hi Tristan:
The GL7 & GL9 JULES suites with the canopy-layering (u-cv054 and u-cv055) are both running on JASMIN now at N96 resolution, with the appropriate version of JULES for each suite. They’re both using can_rad_mod=6.
We’ll know if there are any run-time errors associated with canopy-layer output in the main run, once the single cycle of spinup is over.
For some reason, these two suites also seem slower than their non-canopy-layered GL7 counterpart (u-bx723). It is taking more than 2 hours for a spinup cycle from 1914-2014 for the canopy-layered versions, and I think it was faster for the non-canopy-layered version. (I am starting at 1914 instead of 1860 since there is a missing driving-data file for 1913.)
Patrick
Hi Tristan:
The GL7 & GL9 N96 global suites with the canopy-layering (u-cv054 and u-cv055) have both made it into the main run. The GL7 suite (JULES5.2 branch) has made it up to 1927 after starting at 1914, but its canopy layered output is all 0, at least for 1915. I will have to fix that. The GL9 suite (JULES6.0 branch) has made it to 1924, and its canopy-layered output is non-zero!
I also ran another copy of the GL7 N96 global suite (u-bx723) with the JULES5.2 trunk, without the canopy-layered code. It runs quite a bit faster. It got to 1940, before crashing, due to another missing driver-data file. I was starting at 1914 instead of 1860 since there was a missing CRUNCEP driving data file for 1913.
Patrick
Hi Tristan:
I hadn’t properly set can_rad_mod=6 for the GL7 N96 run that I am running now. When I properly do set can_rad_mod=6 (instead of can_rad_mod=4), it does produce non-zero output.
Patrick
Brilliant. Thanks for doing all of this Patrick.
MartinB has replied, and he is not aware of there being any updates to the JASMIN versions of the GL9 ancillaries, which are currently set to be the same as the GL7 ancillaries.
Patrick