Changes between Version 20 and Version 21 of Documentation/UserGuide/FLUXNETValidation
- Timestamp:
- 2020-02-28T15:46:52+01:00 (4 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Documentation/UserGuide/FLUXNETValidation
v20 v21 1 == How to compare against Fluxnet data == 2 3 Author: M. !McGrath [[BR]] 4 Last revision: B. Guenet (2020/02/28) [[BR]] 5 1 6 This was tested for ORCHIDEE-CN-CAN (r5678 of ORCHIDEE and r5673 of ORCHIDEE_OL) on obelix. 2 7 … … 8 13 And then look at the README file in config/ORCHIDEE_OL/ENSEMBLE. And then read this whole page before really starting to create a run. 9 14 10 Be sure you have checked out both CN-CAN modeles/ORCHIDEE and config/ORCHIDEE_OL ( Documentation/UserGuide/ORCHIDEEDOFOCOInstall).15 Be sure you have checked out both CN-CAN modeles/ORCHIDEE and config/ORCHIDEE_OL (https://forge.ipsl.jussieu.fr/orchidee/wiki/Documentation/UserGuide/ORCHIDEEDOFOCOInstall ). 11 16 12 17 Be sure that ioipsl_debug=.FALSE. in modeles/IOIPSL/src/errioipsl.f90. Otherwise, the output files become huge because of the high frequency writes combined with the debug information. … … 41 46 42 47 The following gives a general flow of how the script works, which should give an idea of the priority. 43 1) ENSEMBLE_initialize/ensemble.ksh reads in the options from fluxnet.card (launching the script as "./Job_ENSEMBLE fluxnet" copies fluxnet.card to ensemble.card...Job_ENSEMBLE always reads all options from ensemble.card). These are global variables while the runs are being set-up. But, when the individual runs (each stage/site) launch, they may get overwritten by PARAM and COMP options in the launch directory. The following sections are parsed in fluxnet.card: 48 49 1) ENSEMBLE_initialize/ensemble.ksh reads in the options from fluxnet.card (launching the script as "./Job_ENSEMBLE fluxnet" copies fluxnet.card to ensemble.card...Job_ENSEMBLE always reads all options from ensemble.card). These are global variables while the runs are being set-up. But, when the individual runs (each stage/site) launch, they may get overwritten by PARAM and COMP options in the launch directory. 50 51 The following sections are parsed in fluxnet.card: 44 52 a) Section [SPINUP] 45 b) Section [UserChoices] 46 c) Section [CONFIG] (explicitly looks for ForcingPath, NbPFTs, NbSitesParam, NameSitesParam, Groups) 53 54 b) Section [!UserChoices] 55 56 c) Section [CONFIG] (explicitly looks for !ForcingPath, NbPFTs, !NbSitesParam, !NameSitesParam, !Groups) 47 57 48 58 The JOB_ENSEMBLE script and the spinup.driver create multiple new submission directories, using the SPINUP and SPINUP/SUBJOBS directories as templates. I use the notation ${}/PARAM/run.def and ${}/COMP/*card to refer to the run.def and various .card files **after** they have been copied from their original locations. 49 59 50 60 The following is then done for every site in Groups in fluxnet.card: 61 51 62 2) The directory is created for the spinup (spinup.card is taken from SPINUP/) 52 3) spinup.card is modified based on the Job_ENSEMBLE script, including adding UserChoices from fluxnet.card 53 4) the Job_ file for the spinup is modified 63 64 3) spinup.card is modified based on the Job_ENSEMBLE script, including adding !UserChoices from fluxnet.card 65 66 4) the Job_* file for the spinup is modified 67 54 68 5) The FLUXNET/PARAM/run.def is copied to the spinup directory ${}/PARAM/run.def 55 6) The script checks that all options which appear in fluxnet.card[SubJobParams] also appear in FLUXNET/PARAM/run.def 69 70 6) The script checks that all options which appear in fluxnet.card[!SubJobParams] also appear in FLUXNET/PARAM/run.def 71 56 72 7) The script writes all of these options into the ${}/COMP/spinup.card and ${}/PARAM/run.def 57 8) The script checks to make sure that the NbSitesParam variables in the fluxnet.card appear in the ${}/PARAM/run.def 73 74 8) The script checks to make sure that the !NbSitesParam variables in the fluxnet.card appear in the ${}/PARAM/run.def 75 58 76 9) The script writes all of these options into the ${}/PARAM/run.def 77 59 78 10) The spinup job is launched 79 80 XXXXXXXXXXXXXX 60 81 61 82 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.
