Suivi du projet amélioration de la gestion des traceurs

Voici les caractéristiques du nouveau "traceur.def", qui répond aux caractéristiques fixées au cours discussion du bocal du 3 octobre:

• fichier texte de même nom lu par un parseur dédié
• possibilité d'ajouter des commentaires (ici: toutes les chaînes précédées par le caractère "#" sont des commentaires).
• subdivision en sections, signalées par le caractère "&" en première position (inspiré des namelists fortran).
  1. "version", donnant le numéro de version du fichier présent
  2. "default", donnant les paramètres par défaut sous la forme <clef>=<valeur>
  3. -... une section par composante. Le nombre de traceurs en entête est supprimé.
• dans chaque section "composante":
  • OBLIGATOIRE: nom du(des) traceur(s) (séparateur: "," si plusieurs traceurs). Premier élément de la ligne.
  • OPTIONNEL (la valeur correspondante de la section "default" est adoptée si elle est absente):
  1. nom du(des) parent(s) (séparateur: "," si plusieurs parents, ce qui n'est possible que pour des traceurs de tagging)
  2. hadv et vadv (schéma d'advection horizontal et vertical)
  3. phases: "g"as, "l"iquid, "s"olid
  4. type de traceur (pour l'instant: "tracer" ou "tag" uniquement)

Ce format permet de compacter fortement les listes et d'éviter des erreurs. Il laisse la possibilité d'ajouter d'autres clefs par la suite (les coefficients de fractionnement notamment).

• on peut utiliser la clef "trac_type" de "run.def" pour lister les composantes qu'il faut lire et fusionner les sections. Exemple: trac_type=merge:repro,inca

Par défaut, les listes sont fusionnées ("merge"): les traceurs de même noms sont fusionnés. Avec plutôt trac_type=cumulate:..., on choisit de les cumuler: le nom de section est ajouté en suffixe aux noms de traceurs identiques dans plusieurs sections.

Quelques décisions complémentaires:

• utilisation de noms plus explicite pour les isotopes: l'atome de masse non nominale est précédé par sa masse atomique entre crochets. Ainsi:

    O17 => H2[17]O
    O18 => H2[18]O
    DHO => H[2]HO
    THO => H[3]HO
  

• utilisation des suffixes "-g", "-l", "-s" pour les phases "g"aseuse, "l"iquide et "s"olide, plus généraux que "v" et "i" ("v"apour et "i"ce)

Le séparateur "-" permet d'éviter de possibles confusions entre une lettre désignant la phase et un nom d'élément (le "l" de Cl - chlore - par exemple)

• absence de chaînage des noms avec la liste complète des ancêtres, rendue possible par l'utilisation de noms plus explicites pour les traceurs (dont la hiérarchie est connue par ailleurs).
• possibilité de tagger à toute génération sans que le tagging ne concerne nécessairement une famille complète ou une génération complète.

En effet (remarque de Frédéric), sommer des traceurs géographiques de différentes régions ne donne pas nécessairement la même chose que le traceur de la somme des régions, car le transport n'est pas nécessairement linéaire.

• le tagging concerne par contre toutes les phases d'une espèce donnée.
• le mot-clef spécial "all" utilisé comme nom de parent d'un traceur de type "tag" permet de tagger tous les traceurs.

Exemple de liste (volontairement en désordre pour illustrer que le parseur s'en sort bien) au nouveau format:

&version=1.0
&default
# Note: currently, the 2 recognized types are "tracer" and "tag"
type_trac=lmdz parent=air hadv=10 vadv=10 phases=g type=tracer
&lmdz
blue,red                     parent=H[2]HO,H2O type=tag   # tagging tracer of gen 1&2 tracers
H2O                          phases=g   hadv=14 vadv=14   # water vapour
water,H2[18]O,H[2]HO,H[3]HO  parent=H2O                   # H2O childs
yellow                       parent=H[3]HO     type=tag   # tagging tracer for single isotope
H2O                          phases=ls                    # H2O in liquid and solid phases

Le parseur en donne la version décompactée qui suit (sorties textes effectives telles qu'elles apparaîtront dans LMDZ):

infotrac_init: Information stored in infotrac :
infotrac_init:   iq  |  tname            | ttext               |  iadv  |  niadv  |  ipar
infotrac_init: ---------------------------------------------------------------------------
infotrac_init:   1   |  H2O-g            | H2O-gVLH            |  14    |  1      |  0
infotrac_init:   2   |  H2O-l            | H2O-lVL1            |  10    |  2      |  0
infotrac_init:   3   |  H2O-s            | H2O-sVL1            |  10    |  3      |  0
infotrac_init:   4   |  H2O-g_blue       | H2O-g_blueVL1       |  10    |  4      |  1
infotrac_init:   5   |  H2O-l_blue       | H2O-l_blueVL1       |  10    |  5      |  2
infotrac_init:   6   |  H2O-s_blue       | H2O-s_blueVL1       |  10    |  6      |  3
infotrac_init:   7   |  H2O-g_red        | H2O-g_redVL1        |  10    |  7      |  1
infotrac_init:   8   |  H2O-l_red        | H2O-l_redVL1        |  10    |  8      |  2
infotrac_init:   9   |  H2O-s_red        | H2O-s_redVL1        |  10    |  9      |  3
infotrac_init:   10  |  water-g          | water-gVL1          |  10    |  10     |  1
infotrac_init:   11  |  water-l          | water-lVL1          |  10    |  11     |  2
infotrac_init:   12  |  water-s          | water-sVL1          |  10    |  12     |  3
infotrac_init:   13  |  H2[18]O-g        | H2[18]O-gVL1        |  10    |  13     |  1
infotrac_init:   14  |  H2[18]O-l        | H2[18]O-lVL1        |  10    |  14     |  2
infotrac_init:   15  |  H2[18]O-s        | H2[18]O-sVL1        |  10    |  15     |  3
infotrac_init:   16  |  H[2]HO-g         | H[2]HO-gVL1         |  10    |  16     |  1
infotrac_init:   17  |  H[2]HO-l         | H[2]HO-lVL1         |  10    |  17     |  2
infotrac_init:   18  |  H[2]HO-s         | H[2]HO-sVL1         |  10    |  18     |  3
infotrac_init:   19  |  H[3]HO-g         | H[3]HO-gVL1         |  10    |  19     |  1
infotrac_init:   20  |  H[3]HO-l         | H[3]HO-lVL1         |  10    |  20     |  2
infotrac_init:   21  |  H[3]HO-s         | H[3]HO-sVL1         |  10    |  21     |  3
infotrac_init:   22  |  H[2]HO-g_blue    | H[2]HO-g_blueVL1    |  10    |  22     |  16
infotrac_init:   23  |  H[2]HO-l_blue    | H[2]HO-l_blueVL1    |  10    |  23     |  17
infotrac_init:   24  |  H[2]HO-s_blue    | H[2]HO-s_blueVL1    |  10    |  24     |  18
infotrac_init:   25  |  H[2]HO-g_red     | H[2]HO-g_redVL1     |  10    |  25     |  16
infotrac_init:   26  |  H[2]HO-l_red     | H[2]HO-l_redVL1     |  10    |  26     |  17
infotrac_init:   27  |  H[2]HO-s_red     | H[2]HO-s_redVL1     |  10    |  27     |  18
infotrac_init:   28  |  H[3]HO-g_yellow  | H[3]HO-g_yellowVL1  |  10    |  28     |  19
infotrac_init:   29  |  H[3]HO-l_yellow  | H[3]HO-l_yellowVL1  |  10    |  29     |  20
infotrac_init:   30  |  H[3]HO-s_yellow  | H[3]HO-s_yellowVL1  |  10    |  30     |  21
infotrac_init: fin

On peut ajouter d'autres clefs, notamment les ratios de fractionnement.

A DISCUTER ENCORE: Savoir si changer les noms de l'eau dans ses trois phases: H2Ov H2Ol H2Oi -> H2O-g, H2O-l H2O-s n'implique pas trop de contraintes du côté des chaînes de post-traitement.

A AJOUTER DANS LE PARSEUR:

• Gestion de base de donnée, afin de pouvoir, indépendamment du module infotrac, accéder à n'importe quelle clef, à la manière de la routine "getin" d'IOIPSL.
• Gestion des listes de traceurs non fusionnées, mais cumulées (cf. ci-dessus).

A NE PAS OUBLIER: Pour mémoire, il y a aussi le ticket #32 (sur la conservation des traceurs)

16/12/2019: MISE À JOUR

Les deux points à ajouter l'ont été:

• Possibilité de cumuler plutôt que fusionner des sections de traceurs. Le nom de section est alors ajouté en suffixe (avant l'éventuel suffixe de phase) pour permettre de distinguer les différents traceurs homonymes. Activation avec tracs_merge=.FALSE. (.TRUE. par défaut), paramètre "en dur" de readTracFiles_Mod.f90, qui peut être transformé si nécessaire en clef de fichier de configuration *.def.
• Gestion de base de données:
  • Le parseur peut gérer plusieurs sections de traceurs par fichier, mais par mesure de simplicité (question tranchée avec Laurent Fairhead), on n'en lit qu'une, en fonction de la clef "type_trac".
    Exemple: pour type_trac=lmdz,inca: on lit les sections "&lmdz" et "&inca" respectivement dans "tracer_lmdz.def" et "tracer_inca.def", puis on les fusionne ou les cumule.
  • L'ancienne gestion de traceurs (un seul fichier nommé "traceur.def") n'est a priori plus utile que pour INCA et pourra peut-être être supprimée, car le nouveau format s'appliquera indifféremment à INCA: Anne Cozic est d'accord pour passer à un fichier de traceurs standard, sans nécessité d'une initialisation spécifique à INCA.
  • L'information lue dans chaque fichier est stockée dans une composante de dBase(:) (la base de données privée), vecteur de type dérivé "db" (pour database) :

      TYPE db                                                  !--- Type for tracers sections
        CHARACTER(LEN=128)    :: name
        TYPE(tr), ALLOCATABLE :: trac(:)
      END TYPE db
      TYPE(db), ALLOCATABLE, TARGET, SAVE :: dBase(:)          !--- Private sections database
    

    La section "default", en première position, est stockée sous la forme d'un "traceur virtuel" du même nom. Les autres traceurs sont stockés à la suite, décompactés (parents, enfants et phases) et vérifiés. On procède ensuite à la fusion ou au cumul en fonction de la valeur de "tracs_merge".
    /!\ La fusion n'est pas effectuée sur les sections "default", utiles uniquement pour déterminer les valeurs par défaut de la liste de traceurs de leur fichier tracer_*.def. Le résultat final (sans aucune section "default") est stocké dans la variable publique "tracers":

      TYPE(tr), ALLOCATABLE, TARGET, SAVE :: tracers(:)        !--- Public tracers list
    

Chaque composante est de type "tr":

  TYPE tr
    CHARACTER(LEN=128) :: name = ''              !--- Name
    CHARACTER(LEN=128) :: prnt = ''              !--- Parent name
    CHARACTER(LEN=128) :: lnam = ''              !--- Long name (with adv. scheme)
    CHARACTER(LEN=16)  :: type = 'tracer'        !--- Type (so far: 'tracer'/'tag')
    CHARACTER(LEN=16)  :: phas = 'g'             !--- Phase ('g'as/'l'iquid/'s'olid)
    INTEGER            :: hadv = 10              !--- Horizontal advection scheme used
    INTEGER            :: vadv = 10              !--- Vertical   advection scheme used
    INTEGER            :: iadv = 10              !--- Advection scheme used
    INTEGER            :: igen = 1               !--- Generation number (<=1)
    INTEGER            :: iparnt = 0             !--- Parent index
    INTEGER,            ALLOCATABLE :: ichild(:) !--- Childs index
    CHARACTER(LEN=128), ALLOCATABLE :: key(:)    !--- Keys string list
    CHARACTER(LEN=128), ALLOCATABLE :: val(:)    !--- Corresponding values string list
  END TYPE tr

Après fusion ou cumul, la base dBase(:) n'est plus utile ; elle n'est donc pas accessible en dehors du module de lecture ("PRIVATE"). Par contre, la base après fusion/cumul et vérification tracers(:) l'est et peut être l'interrogée grâce à quelques routines visibles dans readTracFiles. La principal est getKey(tra, keyn, val[, def_val, t]), qui permet de récupérer la valeur d'une clef associée à un traceur:

• "tra" indique le traceur, soit son indice dans la liste "tracers(:)", soit son nom.
• "keyn" indique le nom de la clef voulue.
• "val" est le résultat (chaîne, entier ou réel ; routine générique).

Les deux derniers arguments sont optionnels:

• "def_val" est une valeur par défaut, au cas où la clef n'apparaîtrait pas dans le fichier tracer_*.def, ni dans la section de traceurs, ni dans la section "default".
• "t" est la base de données (vecteur de type "tr") dans laquelle chercher l'information (par défaut "tracers(:)"). Cela ne sert en principe qu'en interne pour manipuler "dBase(:)".

Parmi les autres outils, on trouve aliasTracer pour créer un pointeur de traceur en fonction de son nom et idxTracer pour obtenir le(s) indice(s) d'un ou plusieurs traceurs.

• À noter que le module "strings_mod.f90" regroupe des outils couramment utiles pour les chaînes et les affichages, en particulier un équivalent du "find" de matlab (indices d'un ou plusieurs éléments dans un vecteur) et une routine d'affichage "propre" de tableaux (chaînes, entiers ou réels).

SUITE PROBABLE:

• L'inclusion d'un pointeur de tableau réel en tant que nouvelle composante du type dérivé "tr" permet d'obtenir des raccourcis documentés vers les traceurs (utile notamment pour l'eau) tout en les laissant rangés comme avant (pas de pénalité numérique). A discuter.
• Ces objets "tr" incluent, de manière plus ordonnée, donc pratique il me semble, les différents indices gérant les différentes générations. À rediscuter avec Camille, notamment pour savoir comment ranger la partie "initialisation" (les valeurs par défaut - coefficients de fractionnement par exemple - utiles pour les isotopes et leur initialisation, seraient assez à leur place dans les fichiers tracer_*.def sous forme de clefs).