M I T R A I L L E T T E
Procedure to validate a release of the code Aladin

Vanda Sousa da Costa

April 25, 2001

Version 3

Updated November 13, 2001
Alex Deckmyn
Updated March 8, 2004

Adam Dziedzic
Updated December 15, 2005
Nihed Bouzouita

Updated December 18, 2006

Gergely Bölöni



 
1. Generalities
2. Localization of the input and output data
2.1. Input ICMSH files
2.2. Namelists files
2.3. Scripts files
2.4. Output files
3. Nomenclature of configurations and returned jobs
4. Available configurations and validation script file


1. Generalities

Mitraillette is a script designed to validate ALADIN configurations and is particularly useful to test a new cycle. This script uses a chain of jobs: when a job is finished it launches the following job, in a predetermined order.

Localization: Tora: /u/gp/mrpe/mrpm608/mitraille

Use: mitraillette.x CYCLE PRO_FILE mono|multi|all

Other used files:
Tora: /u/gp/mrpm/mrpm608/mitraille/test.ref
Tora: /u/gp/mrpm/mrpm608/mitraille/clean
Tora: /u/gp/mrpm/mrpm608/mitraille/protojobs/memtable

Mitraillette establishes and starts the jobs sequence and then each job launches the next job, using the script test.x$$ (where $$ is the process number, e.g. test.x1594). This script allows to execute the qsub command in the right directory (which corresponds to the directory of the new cycle to be validated) and allows also to stop Mitraillette automatically after all the jobs have finished.

For the chaining jobs Mitraillette initializes two temporary files: rank_file.x$$ and rank_end.x$$. The rank_file.x $$ file contains the rank of the actual running job and the rank_end.x $$ contains the total number of ranks.

The configuration or the list of configurations that the user wants to validate are read by Mitraillette from the file: PRO_FILE. This file must contain on each line the sequence of each configuration to be validated and the ALADIN binary to be used. (Note, that we use the name “PRO_FILE” in this documentation for simplicity, but this file can have any name you want.) The configurations required by the user in the PRO_FILE file should respect the nomenclature sequence A[B][n][C] (see Section 3 to known the meaning of each variable in the brackets and Section 4 to know which are the available configurations). Beside a valid GCO ALADIN binary, which is compulsory in the PRO_FILE file, the user can add his own binary (in this case the validation scripts will automatically use this latter one).
For example, to validate the hydrostatic E001 configuration for all the advection schemes the PRO_FILE file, must contain:

ah1e gourou_bin

ah1s gourou_bin

ah1t gourou_bin

where gourou_bin is the ALADIN binary, or,

ah1e gourou_bin mybin

ah1s gourou_bin

ah1t gourou_bin

where mybin is the user’s own binary with a full path. If the user wants to test his own binary to validate hydrostatic E001 configuration with eulerian advection scheme (NB: gourou_bin is mandatory while mybin is optional). If a mybin is specified in the PRO_FILE, the variable “$EXECBIN/$MYOWNBIN” in your chainjob _$RANK validation scripts (see later) will point on your mybin, otherwise it remain empty, so the GCO binary will be used.

For each Mitraillette execution it creates an historical file log_file_$CYCLE_$$ under $HOME/mitraille directory (e.g. log_file_AL15_1594). This log_file lists the configurations and their rank inside the validation jobs chain which allows to identify more easily the output listings of each job.

Mitraillette creates also the directory mitraille _$$ below $HOME/mitraille/[vers] directory (where vers is the cycle name to validate in lower case characters format, e.g. $HOME/ mitraille/al15). This directory contains the scripts chainjob _$RANK used in the validation chain, their output listings as well as a copy of the file log_file_$CYCLE_$$.

As a result of the execution of mitraillette script an output listing mitraille.o$$ is created in $HOME/mitraille directory (e.g. mitraille.o1594).

When the last job of the validation chain is finished a compression of the mitraille_$$ directory is realized, by tar and gzip. The compressed file (mitraille_$$.tar.gz) is located in $HOME/mitraille /[vers] (e.g. $HOME/mitraille/al15/mitraille_1594.tar.gz) and is also saved on archive machine (delage):

directory: $HOME/OUTPUT_FILES/$CYCLE{

Finally, the temporary files (rank_file.x$$, rank_end.x $$ and test.x$$) are removed from $HOME/mitraille directory by the script clean.

NOT AUTOMATIC issues to be performed by the user:

ˇ creation of the local directory $HOME/mitraille

ˇ placing the test.ref and clean script files in $HOME/mitraille directory

ˇ creation of a file PRO_FILE in the $HOME/mitraille directory (the name of this file is chosen by the user, for example, my_profile)

ˇ creation of a directory $HOME/ mitraille/[vers]

ˇ placing the validation scripts that correspond to the configuration to validate in $HOME/mitraille /[vers] directory (see Subsection 2.3 and Section 4)

ˇ execution of Mitraillette: /u/gp/mrpm/mrpm608/mitraille/mitraillette.x CYCLE PRO_FILE mono|multi|all
For instance: /u/gp/mrpm/mrpm608/mitraille/mitraillette.x AL29 my_profile multi
The "mono" option will run the test in monoprocessor mode, "multi" in a multiprocessor mode and "all" on monoprocessor and multiprocessor modes in the same mitraillette test.

NB:

ˇ the name of the CYCLE must be in upper case characters format (e.g. AL29) and correspond to the directory $HOME/mitraille/[vers] where the validation scripts of this cycle (see Subsection 2.3 and Section 4) are.

ˇ for E601 configuration it is necessary to compile the MACHAR routine (lib XRD) in debugging mode (g - sc).

2. Localization of the input and output data

2.1. Input ICMSH files

The ICMSH files used by Mitraillette are on delage:

user: /home/m/mrpm/mrpe692

directory: $HOME/INPUT_FILES/AL11T2/[dir]

where dir can be:

ˇ E001 (for hydrostatic Aladin-France domain)

ˇ E001NHS (for non-hydrostatic Pyrex case)

ˇ SENS (for hydrostatic Belgium and non-hydrostatic Portugal domaines)

ˇ E927 (Arpege files and climatology files for fullpos)

Others directories have been created for E701, E923 and E131 configurations but they are not used at the moment. The user does not need to get these input files because Mitraillette gets them automatically.

2.2. Namelists files

The namelist files are stored on delage:

user: /home/m/mrpm/mrpm608

directory: $HOME/namelist/[vers]

As what happens for the input files the user does not need to get the namelist files to run Mitraillette.

A new directory with all the namelists files should be created for each new cycle.

The namelists might contain characters chains for substitution by the scripts:

- substr1: number of processors (NPROC, NPRGPNS, etc.)

- substr2: value of the key LMPOFF (before cycle 24 was the value of the key LMESSP)

- substr3: non-hydrostatic iteration (NSITER)

- substr4: DFI activation (NEINI)

- substr5: echkevo activation (LECHKEVO)

- subatrA: number of processors for A level parallelisation

- substrB: number of processors for B level parallelisation

- nam_*: other (nam_lpc_full, nam_lpc_nesc etc.)

2.3. Scripts files

The script files are on kami:

user: /u/gp/mrpm/mrpm608

directory: $HOME/mitraille/protojobs

However, and as it was remarked before, the user should put the script(s) which correspond to the configuration(s) to validate in his own directory $HOME/mitraille/[vers], previously created. To know the available configurations and to know which script or scripts correspond to each configuration see Section 4.

A safeguard copy of the script files for each cycle can be stored on delage:

user: /home/m/mrpm/mrpm608

directory: $HOME/script/[vers]

The script files of the validation chain (e.g. chainjob _0, chainjob_1, chainjob_2, etc.) will be in $HOME/mitraille /[vers]/mitraille_$$ directory (e.g. $HOME/mitraille /al15/mitraille_1594).

2.4. Output files

The historical output files are stored by Mitraillette on delage:

directory: $HOME/OUTPUT_FILES/$CYCLE

3. Nomenclature of configurations and returned jobs

The nomenclature of returned jobs is: A[B][n][C]_[i]. The first 4 characters A[B][n][C] indicate the type of configuration and the last [i] character indicate the rank of the job inside the validation chain. In Table 1 is presented the meaning of each variable in brakets. For example, for hydrostatic adiabatic E001 configuration with eulerian advection scheme the nomenclature is AH1E, for non-hydrostatic 2D model with 3TLSL advection sheme the nomenclature is AN2S.

Table 1 - Nomenclature of configurations and returned jobs
 

A

Limited area model (use G for global model)

[ B ]

 

H

for hydrostatic adiabatic

G

with physics in the non-linear trajectory

N

for non-hydrostatic adiabatic

M

with physics

Q

for hydrostatic with physics, var.Q in grid point

[ n ]

Configuration

1

for E001 configuration

2

for ALADIN 2D vertical plane model

4

for E401 configuration

5

E501

6

E601

8

E801

9

E927/EE927

F

Fullpos

I

Incremental DFI

C

E923 / Clim files preparation

[ C ]

Advection scheme and coupling

E

for eulerian advection

S

for 3 time level semi-lagrangian advection scheme

T

for 2 time level semi-lagrangian advection scheme

C

without coupling files

O

Old equivalent of AG1T

R

AROME (=> 2tl semi-lagrangian with PC)

X

not applicable to choosen configuration

[ i ]

A number between 0000 and 9999 that gives the rank of the job in the validation chain (I4 format)

4. Available configurations and validation script files

The available configurations on mitraillette as well as their nomenclature and their scripts are presented in the following Table.

Table 2 - Configurations: their nomenclature and validation script files
 

Configurationmitraillette.x.new

Nomenclature

Script

Hydrostatic adiabatic E001 with eulerian advection scheme

AH1E

job_fr01_euler

Hydrostatic adiabatic E001 with 3TLSL advection scheme

AH1S

job_fr01_3tlsl

Hydrostatic adiabatic E001 with 2TLSL advection scheme

AH1T

job_fr01_2tlsl

Hydrostatic oper-type E001 (3 hour+2TLSL+oper physics) with echkevo and B-level

AG1T

job_newfr01_oper

Hydrostatic oper-type E001 (3 hour+2TLSL+oper physics) with echkevo without B-level

AG1O

job_newfr01_oper_old

Non-hydrostatic adiab. E001 with eulerian adv. scheme (var. d3 and d4)

AN1E

job_nhsad_d3_euler
job_nhsad_d4_euler

Non-hydrostatic adiab. E001 with 3TLSL adv. scheme (var. d3 and d4)

AN1S

job_nhsad_d3_3tlsl
job_nhsad_d4_3tlsl

Non-hydrostatic adiab. E001 with 2TLSL adv. scheme and PC (var. d3 and d4)

AN1P

job_nhsad_d3_2tlsl_pc
job_nhsad_d4_2tlsl_pc

Non-hydrostatic with physics E001 with 2TLSL adv. scheme and PC (variable d4)

AM1P

job_nhalpia_d4_2tlsl_pc

Hydrostatic adiabatic E501 (Eulerian adv. scheme)

AH5E

job_e501_euler_nofrein

Hydrostatic adiabatic E501 (2TLSL adv. scheme)

AH5T

Job_e501_2tlsl_nofrein

Hydrostatic adiabatic E401

AH4E

job_e401

Hydrostatic E601 with simplified Buizza physics

AH6E

job601_adiab

Hydrostatic E601 with physics but without ISBA

AG6E

job601_phys

Hydrostatic adiabatic E801

AH8E

job_e801_test

Hydrostatic E927 and EE927

AH9E

 

coupling ARPEGE-ALADIN

 

jobe927_cou

hydrostatic to non-hydrostatic EE927

 

jobee927_nes

Hydrostatic fullpos tests

AHFE

 

basic ARPEGE fullpos CFPFMT=MODEL

 

jobfp_mod

basic ALADIN fullpos (LELAM) subgrid without E-zone

 

jobfp_gri1

basic ALADIN fullpos native grid without E-zone 

 

jobfp_gri2

basic ALADIN fullpos CFPFMT=LALON

 

jobfp_lal

basic ALADIN fullpos CFPFMT=LELAM with E-zone

 

jobfp_lam1

basic ARPEGE fullpos CFPFMT=LELAM with E-zone

 

jobfp_lam2

operational fullpos CFPFMT=LALON

 

jobfp_ope2

export-like fullpos CFPFMT=LELAM (extract of C+I)

 

jobfp_opex

basic in-line fullpos

 

jobfp_inl

Non-hydrostatic in-line fullpos

ANFS

jobfp_inl_nh

Non-hydrostatic 2D model with 3TLSL advection scheme (var. d0, d3 and d4)

AN2S

job_nh2dm_3tlsl
job_nh2dm_d3_3tlsl
job_nh2dm_d4_3tlsl

Non-hydrostatic 2D model with 2TLSL advection scheme and PC (var. d0, d3 and d4)

AN2P

job_nh2dm_d3_2tlsl_pc
job_nh2dm_d4_2tlsl_pc

Hydrostatic 2D model with 3TLSL advection scheme

AH2S

job_2dm_3tlsl

Hydrostatic 2D model with 2TLSL advection scheme

AH2T

job_2dm_2tlsl

Hydro. ad. E001 without coupling, physics, coriolis forcing

AH1C

job_001_acadcase_alps

Hydrostatic Incremental DFI 

AGIT

job_idfi

Hydrostatic with physics E001, with 2TLSL advection scheme (var.Q in a grid point)

AQ1T

job_Q_en_pt_grille

Non-Hydrostatic AROME with SL2TL advection scheme (var.Q in a grid point) and full physics

AM1R

job_arome

Non-Hydrostatic adiabatic AROME with SL2TL advection scheme (var.Q in a grid point)

AN1R

job_arome

Climatologic files preparation E923 for ALADIN FRANCE

AXCX

job_e923

Non-hydrostatic adiabatic E501 (not validated any more)

AN5E

job_e501_nhs

Non-hydrostatic adiabatic E401 (not validated any more)

AN4E

job_e401_nhs

For more details about jobs, namelists and CPU/memory usage per processor, please refer to Karim YESSAD document:"Code validation for ALADIN (Mitraillette): cycle AL30".

Remark: Except for fullpos and 927 configurations each configuration has only one job. To validate fullpos (AHFE) or 927 configurations (AH9E) the user must put all the corresponding job's scripts in his $HOME/mitraille/[vers] directory.