Changes between Version 104 and Version 105 of Doc/Running


Ignore:
Timestamp:
03/13/24 16:19:21 (3 months ago)
Author:
falletti
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Doc/Running

    v104 v105  
    3939 
    4040### Launch a simulation test ### 
    41 On config.card :  
     41In `config.card`:  
    4242{{{ 
    4343PeriodLength=1D ou 5D 
    … …  
    4747}}} 
    4848 
    49 Run on test queue: [[BR]] 
    50 modify beginning of main job : 
     49Run on test queue. To do it, modify beginning of main job : 
    5150 * irene : 
    5251{{{ 
    … …  
    6362## Status of the running simulation ##  
    6463### run.card during the simulation ### 
    65 A ''run.card'' file is created as soon as your simulation starts. It contains information about your simulation, in particular the !PeriodState parameter which is:  
     64A `run.card` file is created as soon as your simulation starts. It contains information about your simulation, in particular the `PeriodState` parameter which is:  
    6665 * `Start` or `OnQueue`   if your simulation is queued  
    6766 * `Running`                  if your simulation is being executed  
    … …  
    7069 
    7170### Execution directory ### 
    72 At TGCC your simulation is performed in a $CCCSCRATCHDIR/RUN_DIR/job_number directory. At IDRIS it's on a $SCRATCH/RUN_DIR/job_number directory. You can check the status of your simulation in this directory.  
     71At TGCC, your simulation is performed in a `$CCCSCRATCHDIR/RUN_DIR/job_number` directory. At IDRIS it's on a `$SCRATCH/RUN_DIR/job_number` directory. You can check the status of your simulation in this directory.  
    7372 
    7473 
    … …  
    126125}}} 
    127126 
    128 ### run.card at the end of a simulation ### 
    129 At the end of your simulation, the !PeriodState parameter of the ''run.card'' files indicates if the simulation has been '''completed''' or was aborted due to a '''Fatal''' error. 
     127### `run.card` at the end of a simulation ### 
     128At the end of your simulation, the `PeriodState` parameter of the `run.card` file indicates if the simulation has been '''`Completed`''' or was aborted due to a '''`Fatal`''' error. 
    130129[[BR]]This file contains the following sections : 
    131  * Configuration : allows you to find out how many integration steps were simulated and what would be the next integration step if the experiment would be continued.  
     130 * `Configuration` : allows you to find out how many integration steps were simulated and what would be the next integration step if the experiment would be continued.  
    132131{{{ 
    133132[Configuration] 
    … …  
    144143SubmitPath=   # ---> Submission directory 
    145144}}}      
    146  * !PostProcessing :  returns information about the post processing status 
     145 * `PostProcessing` :  returns information about the post processing status 
    147146{{{ 
    148147[PostProcessing] 
    … …  
    150149TimeSeriesCompleted=20091231   # ---> indicates the date of the last TimeSerie produced by the post processing 
    151150}}} 
    152  * Log : returns technical (run-time) information such as the size of your executable and the execution time of each integration step. 
     151 * `Log` : returns technical (run-time) information such as the size of your executable and the execution time of each integration step. 
    153152{{{ 
    154153[Log] 
    … …  
    161160#           2 |        20000201 |        20000228 | 2013-02-15T16:27:46 | 2013-02-15T16:39:44 |       718.16000 |         0.36000 |         3.39000 | ATM_Feb_15_16:13-OCE_Feb_15_15:56-CPL_Feb_15_15:43 
    162161}}} 
    163 If the run.card file indicates a problem at the end of the simulation, you can check your Script_Output file for more details. See [wiki:Doc/CheckDebug more details here]. 
    164  
    165 ### Script_Output_JobName ### 
    166 A Script_Output_JobName file is created for each job executed. It contains the simulation job output log (list of the executed scripts, management of the I/O scripts). 
     162If the `run.card` file indicates a problem at the end of the simulation, you can check your `Script_Output` file for more details. See [wiki:Doc/CheckDebug more details here]. 
     163 
     164### `Script_Output_JobName` ### 
     165A `Script_Output_JobName` file is created for each job executed. It contains the simulation job output log (list of the executed scripts, management of the I/O scripts). 
    167166[[BR]] 
    168167This file contains mainly three parts :  
    … …  
    194193## The output files ## 
    195194 
    196 The output files are stored on file servers. Their names follow a standardized nomenclature: IGCM_OUT/!TagName/[!SpaceName]/[!ExperimentName]/!JobName/ in different subdirectories for each "Output" and "Analyse" component (e.g. ATM/Output,  ATM/Analyse), DEBUG, RESTART, ATLAS and MONITORING. 
    197 File server where outputs will be stored depends on the [wiki:Doc/Setup#config.card SpaceName] choose for the simulation. Remember : TEST mode is a specific case which deactivate [wiki:Doc/Running#ConcatenationofPACKoutputs pack]. 
     195The output files are stored on file servers. Their names follow a standardized nomenclature: `IGCM_OUT/TagName/[SpaceName]/[ExperimentName]/JobName/` in different subdirectories for each "Output" and "Analyse" component (e.g. `ATM/Output`,  `ATM/Analyse`), DEBUG, RESTART, ATLAS and MONITORING. 
     196File server where outputs will be stored depends on the [wiki:Doc/Setup#config.card SpaceName] choose for the simulation. [[BR]] 
     197Remember : `TEST` mode is a specific case which deactivate [wiki:Doc/Running#ConcatenationofPACKoutputs pack]. 
    198198  
    199199Prior to the [wiki:Doc/Running#ConcatenationofPACKoutputs packs] execution, this directory structure is stored  
    200  * on the $CCCSCRATCHDIR at TGCC 
    201  * on the $SCRATCH at IDRIS 
     200 * on the `$CCCSCRATCHDIR` at TGCC 
     201 * on the `$SCRATCH` at IDRIS 
    202202 
    203203After the [wiki:Doc/Running#ConcatenationofPACKoutputs packs] execution (see diagram below), this directory structure is stored 
    204  * on the $CCCSTOREDIR at TGCC  
    205  * on the $STORE at IDRIS  
     204 * on the `$CCCSTOREDIR` at TGCC  
     205 * on the `$STORE` at IDRIS  
    206206 
    207207To summarize: 
    … …  
    221221[[Image(Resultats-IDRIS.jpg, 50%)]] 
    222222 
    223 ## Debug/ directory ##  
    224 A Debug/ directory is created if the simulation crashed. This directory contains text files from each of the model components to help you finding reasons for the crash. See also [wiki:Doc/CheckDebug#Debug the chapter on monitoring and debugging]. 
     223## `Debug/` directory ##  
     224A `Debug/` directory is created if the simulation crashed. This directory contains text files from each of the model components to help you finding reasons for the crash. See also [wiki:Doc/CheckDebug#Debug the chapter on monitoring and debugging]. 
    225225 
    226226## How to continue or restart a simulation? ## 
    227227 1. If you want to continue an existing and finished simulation  
    228    * change the simulation end date in the `config.card` file. Do not change the simulation start date. 
    229    * launch ../../../libIGCM/clean_or_continue.job from the experment folder. This script will update parmeters in run.def file such as !PeriodState. The script will also change the name of the Script file in the main job Script_Output_JobName_.0000X to correspond to the new period. 
     228   * change the simulation end date in the `config.card` file. ''Do not change the simulation start date''. 
     229   * launch `../../../libIGCM/clean_or_continue.job` from the experment folder. This script will update parmeters in `run.def` file such as `PeriodState`. The script will also change the name of the Script file in the main job `Script_Output_JobName_.0000X` to correspond to the new period. 
    230230   * launch the main job as before 
    231  1. If your simulation has stopped in the middle of an execution and you want to restart it, some cleaning must be done using the script clean_or_continue.job: 
    232    * launch ../../../libIGCM/clean_or_continue.job from the experment folder 
     231 1. If your simulation has stopped in the middle of an execution and you want to restart it, some cleaning must be done using the script `clean_or_continue.job`: 
     232   * launch `../../../libIGCM/clean_or_continue.job` from the experiment folder 
    233233   * launch the main job as before 
    234234 
    235 Note: '''clean_or_continue.job''' was previously named '''clean_PeriodLength.job'''. If in your version of libIGCM, there is no clean_or_continue.job, you can use clean_PeriodLength.job in the same way.  
     235Note: '''`clean_or_continue.job`''' was previously named `clean_PeriodLength.job`. If in your version of libIGCM, there is no `clean_or_continue.job`, you can use `clean_PeriodLength.job` in the same way.  
    236236---- 
    237237 
    238238# Simulation - Post processing # 
    239239## Post processing in config.card ## 
    240 You must specify in ''config.card'' the kind and frequency of the post processing.  
     240You must specify in `config.card` the kind and frequency of the post processing.  
    241241{{{ 
    242242#======================================================================== 
    … …  
    259259#======================================================================== 
    260260}}} 
    261 If no post processing is desired you must specify '''NONE''' for the !TimeSeriesFrequency and !SeasonalFrequency frequencies.  
     261If no post processing is desired you must specify '''NONE''' for the `TimeSeriesFrequency` and `SeasonalFrequency` frequencies.  
    262262 
    263263## Rebuild ##  
    264264[[NoteBox(note, For almost all configurations\, the rebuild phase is not needed. Single files are directly written in parallel by XIOS, 600px)]] 
    265265 * `rebuild` is a tool which allows you to combine several files created by a parallel program (sub domains) to a single file. Note that if you use XIOS as output library (XIOS is used in v6 configurations), the rebuild step could not be needed : it depends on the writing mode (parallel or not, server or not) you have activated.   
    266  * `rebuild` is available with IOIPSL package. See http://forge.ipsl.jussieu.fr/igcmg/browser/IOIPSL/trunk/tools (it can therefore be distributed via modipsl)  
     266 * `rebuild` is available with IOIPSL package. See http://forge.ipsl.fr/igcmg/browser/IOIPSL/trunk/tools (it can therefore be distributed via modipsl)  
    267267 * `rebuild` is installed on the IDRIS and TGCC front-end machines.  
    268268 * `rebuild` is only needed and launched in following cases :   
    269269  * IOIPSL is used as output writing library and you run in parallel mode. 
    270270  * XIOS is used as output writing library, you run in parallel mode, you run in XIOS attached mode (or server mode with several servers) and you activate multiple_file XIOS mode.  
    271  * If needed, `rebuild` is automatically called at the !RebuildFrequency frequency and it is usually the very first step of post processing. Specifying NONE for !RebuildFrequency will start the file combining on the computing machine instead of doing it on the post processing machine. This is strongly discouraged. !RebuildFrequency=1Y indicates the frequency of running REBUILD. The files to be combined by `rebuild` are stored on a buffer space $CCCSCRATCHDIR/IGCM_OUT/../!JobName/REBUILD/ at TGCC and $WORK/IGCM_OUT/.../!JobName/REBUILD at IDRIS. Note: if !JobType=DEV the parameter is forced to have the !PeriodLength value. 
    272  * !RebuildFromArchive=NONE is the option to be used on all machines. The REBUILD job first looks for the files to be assembled on the buffer space. Then it assembles them (''rebuild''), applies requested Patchs and stores them in the usual COMP/Output/MO or COMP/Output/DA directories for monthly or daily files of the COMP component (OCE, ICE, ATM, SRF, ...). Note: REBUILD does the ordering of other post processing jobs ran by the create_ts.job and create_se.job jobs. 
     271 * If needed, `rebuild` is automatically called at the `RebuildFrequency` frequency and it is usually the very first step of post processing. Specifying `NONE` for `RebuildFrequency` will start the file combining on the computing machine instead of doing it on the post processing machine. This is strongly discouraged. `RebuildFrequency=1Y` indicates the frequency of running REBUILD. The files to be combined by `rebuild` are stored on a buffer space `$CCCSCRATCHDIR/IGCM_OUT/../JobName/REBUILD/` at TGCC and `$WORK/IGCM_OUT/.../JobName/REBUILD` at IDRIS. Note: if `JobType=DEV` the parameter is forced to have the PeriodLength` value. 
     272 * `RebuildFromArchive=NONE` is the option to be used on all machines. The REBUILD job first looks for the files to be assembled on the buffer space. Then it assembles them (''rebuild''), applies requested Patchs and stores them in the usual `COMP/Output/MO` or `COMP/Output/DA` directories for monthly or daily files of the COMP component (OCE, ICE, ATM, SRF, ...). Note: REBUILD does the ordering of other post processing jobs ran by the `create_ts.job` and `create_se.job` jobs. 
    273273  
    274274## Concatenation of "PACK" outputs ## 
    275 The model outputs are concatenated before being stored on archive servers. The concatenation frequency is set by the '''!PackFrequency''' parameter (NONE means no concatenation, not recommended). If this parameter is not set the rebuild frequency !RebuildFrequency is used.  
    276 This packing step is performed by the PACKRESTART, PACKDEBUG(started by the main job) and PACKOUTPUT (started by the rebuild job or the main job) jobs.  
     275The model outputs are concatenated before being stored on archive servers. The concatenation frequency is set by the '''`PackFrequency`''' parameter (`NONE` means no concatenation, ''not recommended''). If this parameter is not set, the rebuild frequency `RebuildFrequency` is used. [[BR]] 
     276This packing step is performed by the `PACKRESTART`, `PACKDEBUG` (started by the main job) and `PACKOUTPUT` (started by the rebuild job or the main job) jobs.  
    277277 
    278278### How are the different kinds of output files treated ? ### 
    279279 
    280 All files listed below are archived or concatenated at the same frequency (!PackFrequency)  
    281  * ''' Debug ''' : those files are archived and grouped in a single file with the `tar` command. They are then stored in the IGCM_OUT/!TagName/.../!JobName/DEBUG/ directory.  
    282  * ''' Restart''' : those files are archived and grouped in a single file with the `tar` command. They are then stored in the IGCM_OUT/!TagName/.../!JobName/RESTART/ directory. 
    283  * ''' Output ''' : those files are concatenated by type (histmth, histday ...) with the `ncrcat` command in the IGCM_OUT/!TagName/.../!JobName/_comp_/Output/ directories. 
     280All files listed below are archived or concatenated at the same frequency (`PackFrequency`):  
     281 * ''' Debug ''' : those files are archived and grouped in a single file with the `tar` command. They are then stored in the `IGCM_OUT/!TagName/.../JobName/DEBUG/` directory.  
     282 * ''' Restart''' : those files are archived and grouped in a single file with the `tar` command. They are then stored in the `IGCM_OUT/!TagName/.../JobName/RESTART/` directory. 
     283 * ''' Output ''' : those files are concatenated by type (`histmth`, `histday` ...) with the `ncrcat` command in the `IGCM_OUT/TagName/.../JobName/_comp_/Output/` directories. 
    284284 
    285285### Specification of output pack frequency per file (available from libIGCM rev 1603) ### 
    286286 
    287 In order to reduce the number of inodes, it is possible to specify the frequency of output packing per file. The syntax to do that is in the 4th column of !OutputFiles section of the component.card, for example as follows in lmdz.card : 
     287In order to reduce the number of inodes, it is possible to specify the frequency of output packing per file. The syntax to do that is in the 4th column of !OutputFiles section of the `component.card`, for example as follows in lmdz.card : 
    288288 
    289289{{{ 
    … …  
    296296In this example, histmth files will be packed every 100 years and histday files will be packed every 10 years. 
    297297 
    298 The pack frequency you defined in config.card is the frequency of pack by default, that means if a specific frequency of pack is specified for a file in a component.card, this file will be packed at the specific frequency whereas all other files will be packed at global pack frequency (specified in config.card) and in this case, the frequency pack (from the config.card) is the frequency the pack_output job will be launched at. 
    299  
    300 There is a constraint to use this fonctionality : the Packfrequency you defined in config.card must be greater or equal to the pack frequencies you specified for each type of file in component.card, otherwise the computing job will be stopped (with an explicit error message). 
     298The pack frequency you defined in `config.card` is the frequency of pack by default, that means if a specific frequency of pack is specified for a file in a `component.card`, this file will be packed at the specific frequency whereas all other files will be packed at global pack frequency (specified in `config.card`) and in this case, the frequency pack (from the `config.card`) is the frequency the `pack_output` job will be launched at. 
     299 
     300There is a constraint to use this fonctionality : the `Packfrequency` you defined in `config.card` must be greater or equal to the pack frequencies you specified for each type of file in `component.card`, otherwise the computing job will be stopped (with an explicit error message). 
    301301 
    302302### Surpack functionality (available from libIGCM rev 1603) ### 
    303303 
    304 A surpack mode functionality is available through the use of pack_output.job in order to (sur) pack output file which have been already packed to generate bigger files. To enable this functionality, you have to put "surpack_mode=y" (default value is n). The way to use is similar to restart post-processing pack_output jobs, as indicated here : http://forge.ipsl.jussieu.fr/igcmg_doc/wiki/Doc/CheckDebug#RestartPack_output. You can either use a global pack frequency in config.card or specific pack frequency per file, as explained above.  
     304A surpack mode functionality is available through the use of `pack_output.job` in order to (sur) pack output file which have been already packed to generate bigger files. To enable this functionality, you have to put `surpack_mode=y` (default value is n). The way to use it is similar to restart post-processing pack_output jobs (as indicated [wiki:Doc/CheckDebug#RestartPack_output here]. You can either use a global pack frequency in `config.card` or specific pack frequency per file, as explained above.  
    305305 
    306306## Time Series ## 
    307 A Time Series is a file which contains a single variable over the whole simulation period (ChunckJob2D = NONE) or for a shorter period for 2D (ChunckJob2D = 100Y) or 3D (ChunckJob3D = 50Y) variables.  
    308  * The write frequency is defined in the ''config.card'' file: !TimeSeriesFrequency=10Y indicates that the time series will be written every 10 years and for 10-year periods. 
    309  * The Time Series are set in the COMP/*.card files by the TimeSeriesVars2D and TimeSeriesVars3D options. 
     307A Time Series is a file which contains a single variable over the whole simulation period (`ChunckJob2D = NONE`) or for a shorter period for 2D (`ChunckJob2D = 100Y`) or 3D (`ChunckJob3D = 50Y`) variables.  
     308 * The write frequency is defined in the `config.card` file: `TimeSeriesFrequency=10Y` indicates that the time series will be written every 10 years and for 10-year periods. 
     309 * The Time Series are set in the `COMP/*.card` files by the `TimeSeriesVars2D` and `TimeSeriesVars3D` options. 
    310310 
    311311Example for lmdz : 
    … …  
    323323}}} 
    324324 
    325  * Each output file (section [!OutputFiles]) is related to a post processing job: Post_1M_histmth in the example.  
    326  * Post_1M_histmth is a section (starting by "[Post_1M_histmth]") 
    327  * This section contains the variables : Patches= , !GatherWithInternal = , TimeSeriesVars2D = , ChunckJob2D , TimeSeriesVars3D and ChunckJob3D. 
    328   * Patches= (), this functionality is not used anymore. Before, the patch was applied to the output file. The old patches can be found here: [http://forge.ipsl.jussieu.fr/libigcm/browser/trunk/libIGCM/libIGCM_post libIGCM_post] Different Patches can be applied consecutively.  
    329   * !GatherWithInternal = (lon, lat, presnivs, time_counter, aire) These are the variables to be extracted from the initial file and to be stored with the Time Series variable. 
    330   * TimeSeriesVars2D/3D = those are variable lists of time series to create.  
    331   * ChunckJob2D/3D = if the simulation is too long you can cut the time series into x-year long chunks (ChunckJob2D=50Y for example).  
    332   * ChunckJob2D = OFF (or ChunckJob3D = OFF) means no Times Series. 
    333  
    334  
    335 The Time Series coming from monthly (or daily) output files are stored on the archive server in the IGCM_OUT/!TagName/[!SpaceName]/[!ExperimentName]/!JobName/Composante/Analyse/TS_MO and TS_DA directories. 
     325 * Each output file (section `[OutputFiles]`) is related to a post processing job: `Post_1M_histmth` in the example.  
     326 * `Post_1M_histmth` is a section (starting by `[Post_1M_histmth]`). 
     327 * This section contains the variables : `Patches=`, `GatherWithInternal =`, `TimeSeriesVars2D =`, `ChunckJob2D`, `TimeSeriesVars3D` and `ChunckJob3D`. 
     328  * `Patches= ()`: this functionality is not used anymore. Before, the patch was applied to the output file. The old patches can be found here [http://forge.ipsl.fr/libigcm/browser/trunk/libIGCM/libIGCM_post libIGCM_post]. Different Patches can be applied consecutively.  
     329  * `!GatherWithInternal = (lon, lat, presnivs, time_counter, aire)`: These are the variables to be extracted from the initial file and to be stored with the Time Series variable. 
     330  * `TimeSeriesVars2D/3D` : those are variable lists of time series to create.  
     331  * `ChunckJob2D/3D` if the simulation is too long you can cut the time series into x-year long chunks (`ChunckJob2D=50Y` for example).  
     332  * `ChunckJob2D = OFF` (or `ChunckJob3D = OFF`) means no Times Series. 
     333 
     334 
     335The Time Series coming from monthly (or daily) output files are stored on the archive server in the `IGCM_OUT/TagName/[SpaceName]/[ExperimentName]/JobName/Composante/Analyse/TS_MO` and `TS_DA` directories. 
    336336 
    337337 
    338338You can add or remove variables to the !TimeSeries lists according to your needs.  
    339339 
    340 [[NoteBox(note, There are as many time series jobs as there are ChunckJob3D values. This can result in a number of create_ts jobs (automatically started by the computing sequence).,600px)]] 
     340[[NoteBox(note, There are as many time series jobs as there are `ChunckJob3D` values. This can result in a number of `create_ts` jobs (automatically started by the computing sequence).,600px)]] 
    341341 
    342342 
    343343## Monitoring and intermonitoring ## 
    344 The monitoring is a web-interface tool that visualizes the global mean over time for a set up of key variables. Access the monitoring using the esgf/thredds address for your machine ending with yourlogin/TagName/SpaceName/JobName/MONITORING. If you have a new account, you might need to contact the assistant team at the computer center to activate your write access to esgf/thredds.  
     344The monitoring is a web-interface tool that visualizes the global mean over time for a set up of key variables. Access the monitoring using the esgf/thredds address for your machine ending with `yourlogin/TagName/SpaceName/JobName/MONITORING`. If you have a new account, you might need to contact the assistant team at the computer center to activate your write access to esgf/thredds.  
    345345 * esgf/thredds at TGCC:  
    346346   * https://thredds-su.ipsl.fr/thredds/catalog/tgcc_thredds/work/catalog.html 
    … …  
    348348   * https://thredds-su.ipsl.fr/thredds/catalog/idris_thredds/work/catalog.html 
    349349 
    350 The key variables plotted in the monitoring are computed using Time Series values. The monitoring is updated at the !TimeSerieFrequency set in ''config.card'' if the time series were successfully done. 
     350The key variables plotted in the monitoring are computed using Time Series values. The monitoring is updated at the `TimeSerieFrequency` set in `config.card` if the time series were successfully done. 
    351351This allows you to monitor a simulation. 
    352352By monitoring your simulations you can detect anomalies and evaluate the impact of changes you have made. We suggest to create a tab in your browser allowing you to frequently monitor your simulation. If a few key variables start looking suspicious you might want to stop your simulation. By doing so, you will save computing time. 
    353353 
    354354 
    355 Here is an example for the IPSLCM5A coupled model and a 10-year period. Once you are in yourlogin/TagName/SpaceName/JobName/MONITORING, you have to click on index.html. The first tab called '''Analysis Cards''' gives a summary of dates and execution times obtained from the ''config.card'' and ''run.card'' files. The second tab called '''Monitoring Board''' presents a monitoring table for the key variables (selecting one or more model components is optional). 
     355Here is an example for the IPSLCM5A coupled model and a 10-year period. Once you are in `yourlogin/TagName/SpaceName/JobName/MONITORING`, you have to click on `index.html`. The first tab called '''`Analysis Cards`''' gives a summary of dates and execution times obtained from the `config.card` and `run.card` files. The second tab called '''`Monitoring Board`''' presents a monitoring table for the key variables (selecting one or more model components is optional). 
    356356 
    357357[[Image(monitoring_01.jpg, 50%)]] 
    … …  
    359359[[Image(monitoring_02.jpg, 50%)]] 
    360360 
    361  * The diagnostics of each experiment are stored in the MONITORING directory following the IGCM_OUT/TagName/SpaceName/ExperimentName/MONITORING nomenclature (on the $CCCWORKDIR at TGCC and on $WORK at IDRIS). 
     361 * The diagnostics of each experiment are stored in the MONITORING directory following the `IGCM_OUT/TagName/SpaceName/ExperimentName/MONITORING` nomenclature (on the `$CCCWORKDIR` at TGCC and on `$WORK` at IDRIS). 
    362362 
    363363 * The diagnostics starts automatically after the Time Series are created. See the diagram on the computing sequence. 
    … …  
    368368By default, the monitoring is defined here: `~compte_commun/atlas` For example for LMDZ : `monitoring01_lmdz_LMD9695.cfg` 
    369369 
    370 You can change the monitoring by creating a `POST` directory which is part of your configuration. Copy a  `.cfg` file and change it the way you want. You will find  examples in [https://forge.ipsl.jussieu.fr/igcmg/browser/CONFIG/UNIFORM/v6/IPSLCM6/GENERAL/POST special post processing] 
     370You can change the monitoring by creating a `POST` directory which is part of your configuration. Copy a  `.cfg` file and change it the way you want. You will find  examples in [https://forge.ipsl.fr/igcmg/browser/CONFIG/UNIFORM/v6/IPSLCM6/GENERAL/POST special post processing] 
    371371 
    372372'''Be careful''' : to calculate a variable from two variables you must define it within parenthesis :  
    … …  
    390390 nettop_global | "tops topl"                  | LMDZ4.0_9695_grid.nc | "(tops[d=1]-topl[d=2])" | "TOA. total heat flux (GLOBAL)"         | "W/m^2"     | "aire[d=3]"  
    391391}}} 
    392  * by default monitoring is based on TS_MO files, but it is possible to change the frequency by adding '''FreqTS''' in the configuration file monitoring*.cfg 
     392 * by default monitoring is based on `TS_MO` files, but it is possible to change the frequency by adding '''`FreqTS`''' in the configuration file monitoring*.cfg 
    393393{{{ 
    394394#!sh  
    … …  
    426426The plots done by the intermonitoring will be kept 30 days. During these days you can visualize using the same link the plots done. To keep them permanently, do as follow: 
    427427 * Create the intermonitoring using the webservices interface (see mini howto or audio guide above) 
    428  * Save the .jnl script and the .bash script created by the webservices to your computer, together in the same directory.  
    429  * Edit the .bash and modify as follows : 
    430   * source of ferret configuration files. Here are examples to uncomment if needed :   
     428 * Save the `.jnl` script and the `.bash` script created by the webservices to your computer, together in the same directory.  
     429 * Edit the `.bash` and modify as follows : 
     430  * source of ferret configuration files. Here are examples to uncomment if needed:   
    431431{{{ 
    432432#  # IPSL (webservices) 
    … …  
    451451 
    452452}}} 
    453   * define the name and the path where you saved the .jnl script.  
     453  * define the name and the path where you saved the `.jnl` script.  
    454454{{{ 
    455455scriptname=./intermonit_CM6.jnl 
    … …  
    457457  * uncomment and adapt the last line in the script with copy to esgf/thredds. For example at ciclad :  
    458458{{{ 
    459 # for ciclad 
     459# for ciclad: 
    460460cp -fR ${scriptname%%.jnl}_prod /prodigfs/ipslfs/http/dods/web/html/login/INTERMONITORING 
    461461   
    … …  
    463463cp -fR ${scriptname%%.jnl}_prod $CCCWORKDIR/../../thredds/login/INTERMONITORING 
    464464}}} 
    465  * On Ciclad you will have an error on '''-batch''' option of pyferret but it will still work 
    466  
    467  * For irene you need to edit the .jnl script as follows: 
     465 * On Ciclad you will have an error on '''`-batch`''' option of pyferret but it will still work 
     466 
     467 * For irene you need to edit the `.jnl` script as follows: 
    468468   * change the path of the netCDF file to plot, inserting the !SpaceName, !ExperimentName, !JobName related to your run: 
    469469{{{ 
    470470use "$CCCWORKDIR/../../thredds/login/TagName/SpaceName/ExperimentName/JobName/MONITORING/files/($FILE)" 
    471471}}} 
    472  * change permissions on .bash  
     472 * change permissions on `.bash`:  
    473473{{{ 
    474474chmod 755 *.bash 
    475475}}} 
    476476 * Run the .bash script. A new directory will appear on your computer. This is the directory that is also copied to esgf/thredds. 
    477  * The intermonitoring is now on esgf/thredds and you can keep the link permanently. For example for irene, you can find intermonitoring following the link below, where XXXXX is the name of the .jnl file (without .jnl) : 
     477 * The intermonitoring is now on esgf/thredds and you can keep the link permanently. For example for irene, you can find intermonitoring following the link below, where XXXXX is the name of the `.jnl` file (without `.jnl`) : 
    478478{{{ 
    479479http://vesg.ipsl.upmc.fr/thredds/fileServer/work/login/INTERMONITORING/XXXXX_prod/index.html 
    … …  
    481481  
    482482## Seasonal means ## 
    483  * The SE (seasonal means) files contain averages for each month of the year (jan, feb,...) for a frequency defined in the ''config.card'' files 
    484    * !SeasonalFrequency=10Y The seasonal means will be computed every 10 years. 
    485    * !SeasonalFrequencyOffset=0 The number of years to be skipped for calculating seasonal means. 
    486  * The SE files will automatically start at the !SeasonalFrequency=10Y frequency (pay attention to !SeasonalFrequencyOffset=0) when the last parameter in the file of the '[!OutputFiles]' section is not NONE. 
    487  * All files with a requested Post are then averaged within the ncra script before being stored in the directory: [[BR]]IGCM_OUT/IPSLCM5A/DEVT/pdControl/MyExp/ATM/Analyse/SE. There is one file per !SeasonalFrequency=10Y 
     483 * The SE (seasonal means) files contain averages for each month of the year (jan, feb,...) for a frequency defined in the `config.card` files. 
     484   * `SeasonalFrequency=10Y`: the seasonal means will be computed every 10 years. 
     485   * `SeasonalFrequencyOffset=0`: he number of years to be skipped for calculating seasonal means. 
     486 * The SE files will automatically start at the `SeasonalFrequency=10Y` frequency (pay attention to `SeasonalFrequencyOffset=0`) when the last parameter in the file of the `[OutputFiles]` section is not `NONE`. 
     487 * All files with a requested `Post` are then averaged within the ncra script before being stored in the directory: [[BR]] 
     488`IGCM_OUT/IPSLCM5A/DEVT/pdControl/MyExp/ATM/Analyse/SE` [[BR]] 
     489There is one file per `SeasonalFrequency=10Y`. 
    488490 
    489491## Atlas ## 
    490492### C-esm-ep Atlas ### 
    491 Automatic atlas can be generate during your simulation, or on post-processing, using libIGCM environment and C-ESM-EP softwar. For use them you can read the [https://forge.ipsl.jussieu.fr/igcmg_doc/wiki/Doc/DataAnalyse#UseC-ESM-EPinlibIGCM documentation] available in [https://forge.ipsl.jussieu.fr/igcmg_doc/wiki/Doc/DataAnalyse Data and Analyse] part.  
     493Automatic atlas can be generate during your simulation, or on post-processing, using libIGCM environment and C-ESM-EP software. For use them you can read the [wiki:Doc/DataAnalyse#UseC-ESM-EPinlibIGCM documentation] available in [wiki:Doc/DataAnalyse Data and Analyse] part.  
    492494 
    493495### Climaf Atlas ### 
    … …  
    495497 
    496498### Ferret Atlas (not supported anymore) ###  
    497  * The ferret atlas is a result of the automatic post processing, which will creates a collection of plots presented as a web tree. Each plot is available as image and pdf file. The plots are made with the software ferret and the FAST and ATLAS libraries. More information on ferret and on those libraries can be found here  http://wiki.ipsl.jussieu.fr/IGCMG/Outils/ferret/Atlas 
     499 * The ferret atlas is a result of the automatic post processing, which will creates a collection of plots presented as a web tree. Each plot is available as image and pdf file. The plots are made with the software ferret and the FAST and ATLAS libraries. More information on ferret and on those libraries can be found here  http://wiki.ipsl.jussieu.fr/IGCMG/Outils/ferret/Atlas (login needed). 
    498500 * By default, automatic ferret atlas are disabled. To activate automatic ferret atlas, you have to specify {{{config_Post_AtlasIPSL=TRUE}}} in [wiki:Doc/Running#Postprocessinginconfig.card Post part] of ''config.card'' 
    499501 * There are at least 8 directories with ferret Atlas for the coupled model. They are based on atlas_composante.cfg files. You can look at them on the file servers in the IGCM_OUT/IPSLCM5A/DEVT/pdControl/MyExp/ATLAS directories. 
    … …  
    502504## Storing files like ATLAS, MONITORING and ANALYSE ## 
    503505The files produced by ATLAS, MONITORING, Time series and Seasonal means are stored in the following directories:  
    504  * '''ANALYSE''': copied to !JobName/_comp_/Analyse on the file server '''store''' or '''ergon''' (to be modified) 
    505  * '''MONITORING''': copied to !JobName/MONITORING on the file server '''work''' or '''ergon''' (to be modified) 
    506  * '''ATLAS''': copied to !JobName/Atlas on the file server '''work''' or '''ergon''' (to be modified) 
     506 * '''ANALYSE''': copied to `JobName/_comp_/Analyse` on the file server `store` 
     507 * '''MONITORING''': copied to !JobName/MONITORING on the file server `work` 
     508 * '''ATLAS''' (note use anymore): copied to `JobName/Atlas` on the file server `work` 
    507509 
    508510They are available through esgf/thredds server at IDRIS and at TGCC. 
    509  * at TGCC with the new one called esgf/thredds: 
    510   * https://vesg.ipsl.upmc.fr/thredds/catalog/catalog.html click on work_thredds, click on your login and... for ATLAS and MONITORING 
    511   * https://vesg.ipsl.upmc.fr/thredds/catalog/catalog.html click on store_thredds, click on your login and... for Analyse files (TS or SE) 
    512  * at IDRIS: https://prodn.idris.fr/thredds 
     511 * at TGCC https://thredds-su.ipsl.fr/thredds/catalog/tgcc_thredds/catalog.html 
     512  * click on `work`, your login and... for MONITORING 
     513  * click on `store`, your login and... for Analyse files (TS or SE) 
     514 * at IDRIS: https://thredds-su.ipsl.fr/thredds/catalog/idris_thredds/catalog.html 
    513515 
    514516## How to check that the post processing was successful ##