Context Navigation

FLUXNETValidation

Timestamp:: 2020-02-28T17:45:25+01:00 (4 years ago)
Author:: bguenet
Comment:: --

Legend:

: Unmodified
: Added
: Removed
: Modified

Documentation/UserGuide/FLUXNETValidation

-                      v21
+                      v22
 XXXXXXXXXXXXXX
 From here, the Job_ENSEMBLE script is not used anymore.  Now the independent spinup jobs control the show.  Things are a little more difficult to follow here unless you are really used to libIGCM.  libIGCM does a very good job of generalizing functions, but that can make it more difficult to find what you are looking for.  It helps to remember that each file name in the COMP directory is a "component", and libIGCM treats them all identically: initilizing with IGCM_comp_Initialize, for example.  As defined in SPINUP/config.card, we only have a single component in a spinup job: SPIN.
+From here, the Job_ENSEMBLE script is not used anymore.  Now the independent spinup jobs control the show.  Things are a little more difficult to follow here unless you are really used to libIGCM.  libIGCM does a very good job of generalizing functions, but that can make it more difficult to find what you are looking for.  It helps to remember that each file name in the COMP directory is a "component", and libIGCM treats them all identically: initializing with IGCM_comp_Initialize, for example.  As defined in SPINUP/config.card, we only have a single component in a spinup job: SPIN.
 A spinup job runs like the following.  Notice that all of this is carried out in ${}, which is a new directory the above script has created in the FLUXNET directory (e.g., FLUXNET/FI_HyyFLUXNET), NOT in the SPINUP directory.
 ) IGCM_comp_Initialize/libIGCM_comp.ksh reads in the UserChoices from ${}/COMP/spinup.card, which was created in step (2) above and modified in steps (3) and (7)
 ) IGCM_comp_Update/libIGCM_comp.ksh calls SPIN_Update from ${}/COMP/spinup.driver, which determines we are on the "start" stage and therefore need to follow STOI instructions for the next step (referred to as SECSTOINI inside spinup.driver)
 ) ${}/COMP/spinup.driver copies ${}/SUBJOB/OOL_SEC_STO to the STOI directory
 ) ${}/COMP/spinup.driver forces the value of FOREST_MANAGED_FORCED in ${}/STOI/PARAM/run.def.  Other values are taken from UserChoices in ${}/COMP/spinup.card.
 ) SPIN_prepare from ${}/COMP/spinup.driver sets the values of several variables in ${}/STOI/COMP/sechiba.card, based on UserChoices in ${}/COMP/spinup.card.  The same for ${}/STOI/COMP/orchidee_ol.card
 ) SPIN_OptionsSechiba from ${}/COMP/spinup.driver sets the values of TimeSeriesVars3D and TimeSeriesVars2D in ${}/STOI/COMP/sechiba.card.
 ) SPIN_OptionsStomate from ${}/COMP/spinup.driver sets the values of SPINUP_ANALYTIC, TimeSeriesVars3D and TimeSeriesVars2D in ${}/STOI/COMP/sechiba.card, as well as the values of FORCESOIL_STEP_PER_YEAR, STOMATE_FORCING_NAME, and STOMATE_CFORCING_NAME in ${}/STOI/PARAM/run.def.
 ) Execute the STOI run
 …
 }}}
 Make sure the following line exists in the [UserChoices] section of new fluxnet.card (not all of the fluxnet files in the ENSEMBLE directory have them, but it causes a problem if this flag is turned on):
+Make sure the following line exists in the [!UserChoices] section of new fluxnet.card (not all of the fluxnet files in the ENSEMBLE directory have them, but it causes a problem if this flag is turned on):
 {{{
 CRUP=n
 …
 }}}
 I have noticed that the script will complain if a value is specified in fluxnet.card but not the run.def.  It will not complain if a value is specified in run.def and not fluxnet.card.  Check the [UserChoices] and [SubJobParams] sections of fluxnet.card.  Many of the UserChoices are already in SPINUP/COMP/spinup.card, and many of the SubJobParams are in the run.def.  It seems that the scripts make decisions based on what is in fluxnet.card, so this should typically take precedence.  I will point out the exact changes I make for r6414 below.
+I have noticed that the script will complain if a value is specified in fluxnet.card but not the run.def.  It will not complain if a value is specified in run.def and not fluxnet.card.  Check the [!UserChoices] and [!SubJobParams] sections of fluxnet.card.  Many of the !UserChoices are already in SPINUP/COMP/spinup.card, and many of the !SubJobParams are in the run.def.  It seems that the scripts make decisions based on what is in fluxnet.card, so this should typically take precedence.  I will point out the exact changes I make for r6414 below.
 Before we get to some specifics, let's create the jobs.
 …
 Best to run a small test with a single site.  Based on the flunxet.card you copied earlier, the number of species and age classes should all be set up fine.
 Always launch a test run before doing a production run, i.e. a single site.  The Job_ENSEMBLE sript will launch a full spinup job for every site in every group in the fluxnet.card.  To limit this to one, do something like the following:
+Always launch a test run before doing a production run, i.e. a single site.  The Job_ENSEMBLE script will launch a full spinup job for every site in every group in the fluxnet.card.  To limit this to one, do something like the following:
 {{{
 …
 }}}
+(I use duree_sechiba=50 for my test run, so that it goes a little faster).  All of the other duree values I set to 0.  This launches a simulation over one loop of the forcing file, then 500 years (regardless of the length of the forcing file), and then one final loop for analysis.
+The section in the fluxnet.card with [SubJobParams] deserves special mention.  As of a recent version of CAN, the run.def has been restructured to include two files: orchidee.def, orchidee_pft.def. This makes the run.def much neater and matches what is done in the coupled simulations.  However, the Job_ENSEMBLE script attempts to change some variables in the run.def that fall under the [SubJobParams] section.  To do this, it looks at the actual run.def file, not any included file.  If it does not find a line in the run.def corresponding to the lines in [SubJobParams], it will crash.  So make sure all the lines you specify under [SubJobParams] in fluxnet.card also explicitly appear in the PARAM/run.def file.
+This launches a simulation over one loop of the forcing file, then 500 years (regardless of the length of the forcing file), and then one final loop for analysis.
+Note that for my test run, I use duree_sechiba=50 and all of the other duree values I set to 0 , so that it goes a little faster.
+The section in the fluxnet.card with [!SubJobParams] deserves special mention.  As of a recent version of CAN, the run.def has been restructured to include two files: orchidee.def, orchidee_pft.def. This makes the run.def much neater and matches what is done in the coupled simulations.  However, the Job_ENSEMBLE script attempts to change some variables in the run.def that fall under the [!SubJobParams] section.  To do this, it looks at the actual run.def file, not any included file.  If it does not find a line in the run.def corresponding to the lines in [!SubJobParams], it will crash.  So make sure all the lines you specify under [!SubJobParams] in fluxnet.card also explicitly appear in the PARAM/run.def file.
 {{{
 …
 }}}
 For FLUXNET jobs, we generally impose vegetation at the site.  While this is set in fluxnet.card in the UserChoices, this doesn't seem to get passed to the run.def in the spinup unless we also place it in the run.def.
+For FLUXNET jobs, we generally impose vegetation at the site.  While this is set in fluxnet.card in the !UserChoices, this doesn't seem to get passed to the run.def in the spinup unless we also place it in the run.def.
 {{{
 …
 The addition of the orchidee.def and orchidee_pft.def required adding them to the [ParametersFiles] in SPINUP/SUBJOBS/OOL_SEC_STO/COMP/orchidee_ol.card, so that libIGCM copies the new files to the PARAM directory of the running code.  It also required changes to the driver, to select from the correct orchidee_pft.def file.  To fix this, I simply copied OOL_SEC_STO_FG2/COMP/orchidee_ol.* to SPINUP/SUBJOB/OOL_SEC_STO/COMP/.
+The addition of the orchidee.def and orchidee_pft.def required adding them to the [!ParametersFiles] in SPINUP/SUBJOBS/OOL_SEC_STO/COMP/orchidee_ol.card, so that libIGCM copies the new files to the PARAM directory of the running code.  It also required changes to the driver, to select from the correct orchidee_pft.def file.  To fix this, I simply copied OOL_SEC_STO_FG2/COMP/orchidee_ol.* to SPINUP/SUBJOB/OOL_SEC_STO/COMP/.
 {{{
 cp ../OOL_SEC_STO_FG2/COMP/orchidee_ol.* ../SPINUP/SUBJOB/OOL_SEC_STO/COMP/
 }}}
 This also required adding the following to the [UserChoices] section in SPINUP/SUBJOB/OOL_SEC_STO/COMP/orchidee_ol.card, since the SPINUP/COMP/spinup.driver looks for them:
+This also required adding the following to the [!UserChoices] section in SPINUP/SUBJOB/OOL_SEC_STO/COMP/orchidee_ol.card, since the SPINUP/COMP/spinup.driver looks for them:
 {{{
 …
 Make sure this matches with the fluxnet.card that you copied at the beginning!
 The script adds any variables in the NameSitesParam keyword of fluxnet.card in the PARAM/run.def.  SECHIBA_VEGMAX is currently in PARAM/orchidee_pft.def_*.  So, depending on what you have present in SPINUP/SUBJOB/OOL_SEC_STO/COMP/orchidee_ol.card for DefSuffix, you need to remove the following lines in PARAM/orchidee_pft.def_DefSuffix, and the Job_ENSEMBLE script will add them to the end of the run.def as it copies it around.  The specific case of 28 PFTs that we are using here:
+The script adds any variables in the !NameSitesParam keyword of fluxnet.card in the PARAM/run.def.  SECHIBA_VEGMAX is currently in PARAM/orchidee_pft.def_*.  So, depending on what you have present in SPINUP/SUBJOB/OOL_SEC_STO/COMP/orchidee_ol.card for !DefSuffix, you need to remove the following lines in PARAM/orchidee_pft.def_DefSuffix, and the Job_ENSEMBLE script will add them to the end of the run.def as it copies it around.  The specific case of 28 PFTs that we are using here:
 {{{
 …
 }}}
 I noticed that the names of the following filenames did not match what is written in the [BoundaryFiles] of SPINUP/SUBJOB/OOL_SEC_STO/COMP/stomate.card file, which will cause problems later.  Make sure the filenames in the run.def/flunxet.card/stomate.card all match, and then copy PARAM/*def to SPINUP/SUBJOB/OOL_SEC_STO/PARAM/.
+I noticed that the names of the following filenames did not match what is written in the [!BoundaryFiles] of SPINUP/SUBJOB/OOL_SEC_STO/COMP/stomate.card file, which will cause problems later.  Make sure the filenames in the run.def/flunxet.card/stomate.card all match, and then copy PARAM/*def to SPINUP/SUBJOB/OOL_SEC_STO/PARAM/.
 {{{
 …
 }}}
 Similarly, values found in fluxnet.card [UserChoices] seem to be required in SPINUP/COMP/spinup.card, else it crashes.  So, assuming that you have made the correct choices in fluxnet.card, just copy the whole [UserChoices] section to the spinup.card.
+Similarly, values found in fluxnet.card [!UserChoices] seem to be required in SPINUP/COMP/spinup.card, else it crashes.  So, assuming that you have made the correct choices in fluxnet.card, just copy the whole [!UserChoices] section to the spinup.card.
 {{{
 emacs fluxnet.card &
 …
 IGCM_debug_Exit :  IGCM_comp_modifyDefFile : Error in run.def: Variable=STOMATE_HIST_DT is set 2 times
 }}}
 Either you added a variable to FLUXNET/PARAM/run.def and forgot to delete it from FLUXNET/PARAM/orchidee.def or FLUXNET/PARAM/orchidee_pft.def_28pft.1ac, OR the variable appears in FLUXNET/PARAM/*def and it gets added to the run.def by the ensemble (doesn't appear to be possible, even if there is a line written in the run.def indicating it happens...the script crashes if the option doesn't already exist) or spinup (SubJobParams in ${}/COMP/spinup.card or ${}/COMP/spinup.driver).
+Either you added a variable to FLUXNET/PARAM/run.def and forgot to delete it from FLUXNET/PARAM/orchidee.def or FLUXNET/PARAM/orchidee_pft.def_28pft.1ac, OR the variable appears in FLUXNET/PARAM/*def and it gets added to the run.def by the ensemble (doesn't appear to be possible, even if there is a line written in the run.def indicating it happens...the script crashes if the option doesn't already exist) or spinup (!SubJobParams in ${}/COMP/spinup.card or ${}/COMP/spinup.driver).
 == Cleaning ==
 …
 I take timings from four locations: ``CPU Time Global'' and ``Real Time Global'' from out\_orchidee, and then the real and user times reported by ``time -p ./orhcidee\_ol''.  For the most part, they are similar.  For clairity, I only report ``Real time Global'' from out\_orchidee below.  Error bars are the standard deviation from 5 independent runs to show the variance.
 The TRUNK and TAG21 have 15 PFTs, CAN has 28 PFTs, but they are all set to zero except for NeedleleafEvergreenTemperate (PFT4...4), Deciduous temperate (PFT6...8), C3Grass (PFT10..23), and C3Crop (PFT12...26), which are all set to 0.25.  I wanted to simulate a somewhat realistic pixel with a mix of vegetation.
+The TRUNK and TAG21 have 15 PFTs, CAN has 28 PFTs, but they are all set to zero except for !NeedleleafEvergreenTemperate (PFT4...4), Deciduous temperate (PFT6...8), C3Grass (PFT10..23), and C3Crop (PFT12...26), which are all set to 0.25.  I wanted to simulate a somewhat realistic pixel with a mix of vegetation.
 '''Using NBUFF=1'''