Changes between Initial Version and Version 1 of Doc/Running


Ignore:
Timestamp:
03/24/14 16:17:26 (10 years ago)
Author:
trac
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Doc/Running

    v1 v1  
     1{{{ 
     2#!html 
     3<h1>Simulation and post-processing</h1> 
     4}}} 
     5---- 
     6[[NoteBox(note,In this chapter you will learn about how to start a simulation and how to use the IPSL models and tools, from the beginning of the simulation to the post processing of the outputs., 600px)]] 
     7 
     8[[TOC(heading=Table of contents,depth=1,inline)]] 
     9[[PageOutline(1,Table of contents,pullout)]] 
     10---- 
     11 
     12# Submitting your simulation # 
     13Once you have [wiki:DocEsetup defined and setup your simulation] you can submit it. The run scripts are:  
     14 * ccc_msub at TGCC 
     15 * llsubmit at IDRIS 
     16 
     17{{{ 
     18curie > ccc_msub Job_MYJOBNAME 
     19ada   > llsubmit Job_MYJOBNAME 
     20}}} 
     21 
     22These scripts return a job number that can be used with the machine specificities to manage your job. Please refer to the [wiki:DocBenv environment] page of your machine.  
     23 
     24[[NoteBox(warn, Before starting a simulation it is very important to double check that it was properly setup. We strongly encourage you to perform a short test before starting a long simulation., 600px)]] 
     25 
     26The job you just submitted is the first element of a chain of jobs, depending on the kind of jobs you submitted. These jobs include the production job itself and post processing jobs like: rebuild, pack, create_ts, create_se, monitoring and atlas which are started at given frequencies. 
     27 
     28[[NoteBox(note, Post processing jobs will be automatically started at the end of the simulation., 600px)]] 
     29 
     30[[NoteBox(warn, If you recompile the modele during a simulation, the new executable will be used in the next period of the running job. ,600px)]] 
     31 
     32---- 
     33# Status of the running simulation #  
     34## run.card during the simulation ## 
     35A run.card file is created as soon as your simulation starts. It contains information about your simulation, in particular the !PeriodState parameter which is:  
     36 * Start or !OnQueue   if your simulation is queued  
     37 * Running                  if your simulation is being executed  
     38 * Completed              if your simulation was successfully completed  
     39 * Fatal                       if your simulation was aborted due to a fatal error  
     40 
     41## Execution directory ## 
     42 * At TGCC your simulation is performed in a $SCRATCHDIR/RUN_DIR/job_number directory. You can check the status of your simulation in this directory.  
     43 * [[Span(id=run_dir_path)]]At IDRIS your simulation is performed in a temporary directory. You must first specify '''RUN_DIR_PATH=$WORKDIR''' in your production job if you want to monitor it. 
     44 
     45[[BR]] 
     46---- 
     47# End of the simulation # 
     48 
     49## messages received ## 
     50 
     51=== Example of message for a successfully completed simulation === 
     52 
     53{{{ 
     54From : no-reply.tgcc@cea.fr  
     55Object : CURFEV13 completed 
     56 
     57Dear Jessica, 
     58 
     59 Simulation CURFEV13 is completed on supercomputer curie3820. 
     60 Job started : 20000101 
     61 Job ended   : 20001231 
     62 Output files are available in /ccc/store/.../IGCM_OUT/IPSLCM5A/DEVT/pdControl/CURFEV13 
     63 Files to be rebuild are temporarily available in /ccc/scratch/.../IGCM_OUT/IPSLCM5A/DEVT/pdControl/CURFEV13/REBUILD 
     64 Pre-packed files are temporarily available in /ccc/scratch/.../IGCM_OUT/IPSLCM5A/DEVT/pdControl/CURFEV13 
     65 Script files, Script Outputs and Debug files (if necessary) are available in /ccc/work/.../modipsl/config/IPSLCM5_v5/CURFEV13 
     66 
     67}}} 
     68=== Example of message when the simulation failed === 
     69{{{ 
     70From : no-reply.tgcc@cea.fr  
     71Object : CURFEV13 failed 
     72 
     73Dear Jessica, 
     74 
     75 Simulation CURFEV13 is failed on supercomputer curie3424. 
     76 Job started : 20000101 
     77 Job ended   : 20001231 
     78 Output files are available in /ccc/store/.../IGCM_OUT/IPSLCM5A/DEVT/pdControl/CURFEV13 
     79 Files to be rebuild are temporarily available in /ccc/scratch/.../IGCM_OUT/IPSLCM5A/DEVT/pdControl/CURFEV13/REBUILD 
     80 Pre-packed files are temporarily available in /ccc/scratch/.../IGCM_OUT/IPSLCM5A/DEVT/pdControl/CURFEV13 
     81 Script files, Script Outputs and Debug files (if necessary) are available in /ccc/work/.../modipsl/config/IPSLCM5_v5/CURFEV13 
     82 
     83}}} 
     84## How to continue or restart a simulation ## 
     85 1. If you want to continue an existing or finished simulation, change the simulation end date in the `config.card` file. Do not change the simulation start date. 
     86 1. In the `run.card` file you must:  
     87  * check that the `PeriodDateBegin` and `PeriodDateEnd` variables match with the next integration step of your simulation (e.g. if you just finished May 2000 and you want to integrate one month, set `PeriodDateBegin= 20000601` and `PeriodDateEnd= 2000630`)  
     88  * specify `PeriodState = OnQueue` 
     89 1. You must change the output file number in your job to make sure that the job doesn't fail by trying to replace an existing `Script_Output` file. By default it is `Script_Output_NomJob_.0001` but you can replace it by `Script_Output_NomJob_.CumulPeriod` (you will find `CumulPeriod` in `run.card`)  
     90 1. If your simulation has stopped in the middle of a month and you want to restart it, you must delete the files created during this month (pack period) in your archives (`$CCCSTOREDIR/IGCM_OUT/etc`...). You can use the scripts [wiki:DocGmonitor#Tipsforidentifyingcomputingenvironmenterrors `modipsl/libIGCM/clean_month.job` and `modipsl/libIGCM/clean_year.job`]. 
     91 {{{ 
     92#!sh 
     93 cd $SUBMIT_DIR (ie modipsl/config/LMDZOR_v5/DIADEME) 
     94 cp ../../../libIGCM/clean_month.job . ; chmod 755 clean_month.job  # Once and for all 
     95 ./clean_month.job   #   Answer to the questions 
     96 
     97same for clean_year.job 
     98 
     99ccc_msub Job_EXP00 or llsubmit Job_EXP00 
     100}}} 
     101 
     102## The output files ## 
     103 
     104The output files are stored on file servers. Their name follows 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. 
     105 
     106Prior to the packs execution, this directory structure is stored  
     107 * on the $SCRATCHDIR at TGCC 
     108 * on the $WORKDIR at IDRIS 
     109 
     110After the packs execution (see diagram below), this tree is stored 
     111 * on the $CCCSTOREDIR and the $CCCWORKDIR at TGCC  
     112 * on the Gaya machine at IDRIS  
     113 
     114### Here is the storage directory structure of the output files produced at TGCC ### 
     115 
     116[[Image(Resultats-TGCC.jpg, 50%)]] 
     117 
     118### Here is the storage directory structure of the output files produced at IDRIS ### 
     119 
     120[[Image(Resultats-IDRIS.jpg, 50%)]] 
     121 
     122## run.card at the end of a simulation ## 
     123At 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. 
     124[[BR]]This files contains the following sections : 
     125 * 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.  
     126{{{ 
     127[Configuration] 
     128#last PREFIX 
     129OldPrefix=        # ---> prefix of the last created files during the simulation = JobName + date of the last period. Used for the Restart 
     130#Compute date of loop 
     131PeriodDateBegin=   #  --->start date of the next period to be simulated 
     132PeriodDateEnd=     # ---> end date of the next period to be simulated 
     133CumulPeriod=       # ---> number of already simulated periods  
     134# State of Job "Start", "Running", "OnQueue", "Completed" 
     135PeriodState="Completed"    
     136         
     137SubmitPath=   # ---> Submission directory 
     138}}}      
     139 * !PostProcessing :  returns information about the post processing status 
     140{{{ 
     141[PostProcessing] 
     142TimeSeriesRunning=n   # ---> indicates if the timeSeries are running 
     143TimeSeriesCompleted=20091231   # ---> indicates the date of the last TimeSerie produced by the post processing 
     144}}} 
     145 * Log : returns technical (run-time) information such as the size of your executable and the execution time of each integration step. 
     146{{{ 
     147[Log] 
     148# Executables Size 
     149LastExeSize=() 
     150 
     151#--------------------------------- 
     152# CumulPeriod | PeriodDateBegin |   PeriodDateEnd |        RunDateBegin |          RunDateEnd |     RealCpuTime |     UserCpuTime |      SysCpuTime | ExeDate 
     153#           1 |        20000101 |        20000131 | 2013-02-15T16:14:15 | 2013-02-15T16:27:34 |       798.33000 |         0.37000 |         3.05000 | ATM_Feb_15_16:13-OCE_Feb_15_15:56-CPL_Feb_15_15:43 
     154#           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 
     155}}} 
     156 
     157 
     158## Script_Output_JobName ## 
     159A 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). 
     160[[BR]] 
     161This file contains three parts :  
     162 * copying the input files 
     163 * running the model  
     164 * post processing 
     165These three parts are defined as below :  
     166{{{ 
     167####################################### 
     168#       ANOTHER GREAT SIMULATION      # 
     169####################################### 
     170 
     171 1st part (copying the input files) 
     172 
     173####################################### 
     174#      DIR BEFORE RUN EXECUTION       # 
     175####################################### 
     176 
     177 2nd part (running the model) 
     178 
     179####################################### 
     180#       DIR AFTER RUN EXECUTION       # 
     181####################################### 
     182 
     183 3rd part (post processing) 
     184 
     185}}} 
     186If the [#run.cardattheendofasimulation run.card] file indicates a problem at the end of the simulation, you can check your Script_Output file for more details. See [wiki:DocGmonitor more details here]. 
     187 
     188 
     189## Debug/ directory ##  
     190A Debug/ directory is created if the simulation crashed. This directory will contain text files from each of the model components to help you finding reasons for the crash. See also [wiki:DocGmonitor#Debug the chapter on monitoring and debugging]. 
     191 
     192---- 
     193# Simplified diagram of the jobs executed by the IPSL models and tools # 
     194The job automatically runs post processing jobs during the simulation and at different frequencies. There are two kinds of post processing: required post processing such as rebuild and pack, and optional post processing such as !TimeSeries and seasonal means.  
     195[[BR]] 
     196Here is a diagram describing the job sequence.  
     197 
     198[[Image(chaine.jpg, 50%)]] 
     199 
     200# Post processing with libIGCM # 
     201 
     202## Post processing in config.card ## 
     203You must specify in config.card the kind and frequency of the post processing.  
     204{{{ 
     205#======================================================================== 
     206#D-- Post - 
     207[Post] 
     208#D- Do we rebuild parallel output, this flag determines 
     209#D- frequency of rebuild submission (use NONE for DRYRUN=3) 
     210RebuildFrequency=1Y 
     211#D- frequency of pack post-treatment : DEBUG, RESTART, Output 
     212PackFrequency=1Y 
     213#D- Do we rebuild parallel output from archive (use NONE to use SCRATCHDIR as buffer) 
     214RebuildFromArchive=NONE 
     215#D- If you want to produce time series, this flag determines 
     216#D- frequency of post-processing submission (NONE if you don't want) 
     217TimeSeriesFrequency=10Y 
     218#D- If you want to produce seasonal average, this flag determines 
     219#D- the period of this average (NONE if you don't want) 
     220SeasonalFrequency=10Y 
     221#D- Offset for seasonal average first start dates ; same unit as SeasonalFrequency 
     222#D- Usefull if you do not want to consider the first X simulation's years 
     223SeasonalFrequencyOffset=0 
     224#======================================================================== 
     225}}} 
     226If no post processing is desired you must specify '''NONE''' for the !TimeSeriesFrequency and !SeasonalFrequency frequencies.  
     227 
     228## Rebuild ##  
     229 * rebuild is a tool which allows you to combine several files created by a parallel program (sub domains) to a single file.  
     230 * rebuild is available with IOIPSL. See http://forge.ipsl.jussieu.fr/igcmg/browser/IOIPSL/trunk/tools (it can therefore be distributed via modipsl)  
     231 * rebuild is installed on the IDRIS and TGCC front-end machines. It is automatically called at the !RebuildFrequency frequency and it is usually the very first step of post processing. 
     232 * You can not skip rebuilds. 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. 
     233 * !RebuildFrequency=1Y indicates the frequency of running REBUILD. The files to be combined by Rebuild are stored on a buffer space $SCRATCHDIR/IGCM_OUT/../!JobName/REBUILD/ at TGCC and $WORKDIR/IGCM_OUT/.../!JobName/REBUILD at IDRIS (in old libIGCM version, before libigcm_v2.0, it was $SCRATCHDIR/REBUILD/ at TGCC and $WORKDIR/REBUILD at IDRIS)  Note: if !JobType=DEV the parameter is forced to have the !PeriodLength value. 
     234 * !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. 
     235[[NoteBox(warn,Note: if !JobType=DEV \ the !RebuildFrequency parameter is forced to be the !PeriodLength value and one rebuild job per simulated period is started. Discouraged for long simulations., 600px)]] 
     236  
     237## Concatenation of "PACK" outputs ## 
     238The model outputs are concatenated before being stored on file servers. The concatenation frequency is set by the '''!PackFrequency''' parameter. If this parameter is not set the rebuild frequency !RebuildFrequency is used. [[BR]] 
     239This packing step is performed by the PACKRESTART, PACKDEBUG jobs (started by the main job) and PACKOUTPUT (started by the Rebuild job).  
     240 
     241### How are the different kinds of output files treated ### 
     242 
     243All files listed below are archived or concatenated at the same frequency (!PackFrequency)  
     244 * ''' 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.  
     245 * ''' 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. 
     246 * ''' Output ''' : those files are concatenated by type (histmth, histday ...) with the `ncrcat` command in the IGCM_OUT/!TagName/.../!JobName/_comp_/Output/ directories. 
     247## Time Series ## 
     248A 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.  
     249 * 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. 
     250 * The Time Series are set in the COMP/*.card files by the !TimeSeriesVars2D and !TimeSeriesVars3D options. 
     251 
     252Example for lmdz : 
     253{{{ 
     25445  [OutputFiles] 
     25546  List=   (histmth.nc,      ${R_OUT_ATM_O_M}/${PREFIX}_1M_histmth.nc,      Post_1M_histmth), \ 
     256... 
     25753  [Post_1M_histmth] 
     25854  Patches= (Patch_20091030_histcom_time_axis) 
     25955  GatherWithInternal = (lon, lat, presnivs, time_counter, aire) 
     26056  TimeSeriesVars2D = (bils, cldh, ... ) 
     26157  ChunckJob2D = NONE 
     26258  TimeSeriesVars3D = () 
     26359  ChunckJob3D = NONE 
     264}}} 
     265 
     266 * Each output file (section [!OutputFiles]) is related to a post processing job: Post_1M_histmth in the example.  
     267 * post_1M_histmth is a section (starting by "[Post_1M_histmth]") 
     268 * This section contains the variables : Patches= , !GatherWithInternal = , !TimeSeriesVars2D = , !ChunckJob2D , !TimeSeriesVars3D and !ChunckJob3D. 
     269  * Patches= (Patch_20091030_histcom_time_axis) : this is the Patch which will be applied to the output file before being stored on the file server. The available Patches can be found here: [http://forge.ipsl.jussieu.fr/libigcm/browser/trunk/libIGCM/libIGCM_post libIGCM_post] Different Patches can be applied consecutively.  
     270  * !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. 
     271  * !TimeSeriesVars2D/3D = those are variable lists of time series to create.  
     272  * !ChunckJob2D/3D = if the simulation is too long you can cut the time series into x-year long chunks (!ChunckJob2D=50Y for example).  
     273 
     274 
     275The Time Series coming from monthly (or daily) output files are stored on the file server in the IGCM_OUT/!TagName/[!SpaceName]/[!ExperimentName]/!JobName/Composante/Analyse/TS_MO and TS_DA directories. 
     276 
     277 
     278You can add or remove variables to the !TimeSeries lists according to your needs.  
     279 
     280[[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)]] 
     281## Monitoring ## 
     282 * This allows you to monitor a simulation and to check the status of a few key variables.  
     283 
     284 * By 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. 
     285 
     286 * The key variables plotted in the monitoring are computed using Time Series values. A full documentation is available at http://wiki.ipsl.jussieu.fr/IGCMG/Outils/ferret/Monitoring. 
     287 
     288 * Here is an example for the IPSLCM5A coupled model and a 10-year period. 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). 
     289 
     290[[Image(monitoring_01.jpg, 50%)]] 
     291 
     292[[Image(monitoring_02.jpg, 50%)]] 
     293 
     294 * 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 GAYA at IDRIS). 
     295 
     296 * The diagnostics starts automatically after the Time Series are created. See the diagram on the computing sequence. 
     297 
     298### Adding a variable to the monitoring ### 
     299You can add or change the variables to be monitored by editing the configuration files of the monitoring. Those files are defined by default for each component. 
     300 
     301The monitoring is defined here: `~compte_commun/atlas` For example for LMDZ : `monitoring01_lmdz_LMD9695.cfg` 
     302 
     303You 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 two examples in [http://forge.ipsl.jussieu.fr/igcmg/browser/CONFIG/IPSLCM/IPSLCM5A/EXP00/POST special post processing] 
     304 
     305'''Be careful''' : to calculate a variable from two variables you must define it within parenthesis :  
     306{{{ 
     307#!sh 
     308#----------------------------------------------------------------------------------------------------------------- 
     309#  field | files patterns | files additionnal | operations | title | units | calcul of area 
     310#----------------------------------------------------------------------------------------------------------------- 
     311 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]"  
     312}}} 
     313 
     314 ### Inter Monitoring ### 
     315 * To simultaneously monitor various simulations, a web application has been created to monitor the evolution of different variables at once. 
     316 
     317[[Image(intermonitoring_01.jpg, 50%)]]  
     318 
     319[[Image(intermonitoring_02.jpg, 50%)]] 
     320 
     321 * This application is available on '''[http://webservices.ipsl.jussieu.fr/ ICMC Web Applications]'''. 
     322 * A video tutorial is available [http://dods.ipsl.jussieu.fr/brocksce/screencast/InterMonitoring.html here].  
     323 * In the '''Step 1''' tab, specify URLs which give access to the MONITORING directory  
     324    * http://dods.extra.cea.fr/cgi-bin/nph-dods/work/YourLogin/TagName/SpaceName/ExperimentName for dods under cccwork at TGCC 
     325    * http://dods.extra.cea.fr/cgi-bin/nph-dods/data/YourLogin/TagName/SpaceName/ExperimentName for dods under dmnfs at TGCC (read-only since April 2012) 
     326    * http://dods.idris.fr/cgi-bin/nph-dods/YourLogin/TagName/SpaceName/ExperimentName for dods at IDRIS  
     327 
     328## Seasonal means ## 
     329 * The SE (seasonal means) files contain averages for each month of the year (jan, feb,...) for a frequency defined in the config.card files 
     330   * !SeasonalFrequency=10Y The seasonal means will be computed every 10 years. 
     331   * !SeasonalFrequencyOffset=0 The number of years to be skipped for calculating seasonal means. 
     332 * 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. 
     333 * 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 
     334 
     335## Atlas ## 
     336 * The atlas is a result of the post processing, which will create 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 
     337 * Here is an example of atlas for the coupled IPSLCM5A available on dods : [http://dods.idris.fr/rpsl003/IPSLCM5A/DEVT/pdControl/BAL1210/ATLAS/SE_2000_2009/ATM/ATM.html ATM] 
     338 * There are at least 8 directories with 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. 
     339 * The script libraries fast/atlas are installed in shared directories.  
     340 
     341## Storing files like ATLAS, MONITORING and ANALYSE ## 
     342The files produced by ATLAS, MONITORING, time series and seasonal means are stored in the directories:  
     343 * '''ANALYSE''': copied to !JobName/_comp_/Analyse on the file server '''cccstore''' or '''gaya''' 
     344 * '''MONITORING''': copied to !JobName/MONITORING on the file server '''cccwork''' or '''gaya''' 
     345 * '''ATLAS''': copied to !JobName/Atlas on the file server '''cccwork''' or '''gaya''' 
     346 
     347# How to check that the post processing was successful # 
     348 
     349The post processing output log files are : 
     350 * on Ada: `$WORKDIR/IGCM_OUT/TagName/.../JobName/Out` 
     351 * on Curie: `$SCRATCHDIR/IGCM_OUT/TagName/.../JobName/Out` 
     352 
     353In these directories, you find the job output files: `rebuild`, `pack*`, `ts`, `se`, `atlas`, `monitoring `.  
     354 [[BR]] 
     355Note :  The scripts to transfer data on dods are run at the end of the monitoring job or at the end of each atlas job. 
     356 
     357