| Version 5 (modified by , 4 years ago) (diff) |
|---|
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).
- "version", donnant le numéro de version du fichier présent
- "default", donnant les paramètres par défaut sous la forme <clef>=<valeur>
- -... 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):
- nom du(des) parent(s) (séparateur: "," si plusieurs parents, ce qui n'est possible que pour des traceurs de tagging)
- hadv et vadv (schéma d'advection horizontal et vertical)
- phases: "g"as, "l"iquid, "s"olid
- 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[[br]]
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é:
- Possibilté 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 en valorisant la clef booléenne tracs_merge à FALSE plutôt qu'à TRUE. Cette clef est un paramètre "en dur" de readTracFiles_Mod.f90 pour l'instant. À reporter sans les fichiers de configuration *.def éventuellement.
- Gestion de base de données OK:
- En l'état, par mesure de simplicité (discuté avec Laurent Fairhead), on ne lit qu'une section de type "traceur" par fichier (on pourra en lire plusieurs si nécessaire), du nom de la clef "type_trac". Exemple: type_trac=lmdz,inca: on lit les sections "&lmdz" et "&inca" respectivement dans "tracer_lmdz.def" et "tracer_inca.def", puis on les fusionne.
- L'ancienne gestion de traceurs n'existe plus que pour INCA (un seul fichier nommé "traceur.def").
- Chaque fichier est lu sous la forme d'une composante de type dérivé "db" (pour database) stockée dans dBase (la base de données privée):
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" est stockée comme un "traceur virtuel" du même nom.
Les autres traceurs sont stockés à la suite, décompactés (phases, parents, enfants) 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": chaque section ne sert qu'à déterminer les valeurs par défaut de la liste de traceurs du même fichier tracer_*.def.
Le résultat finale 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 externe. Par contre, tracers(:) l'est. On peut l'interroger via quelques outils visibles dans readTracFiles. Le principal est la commande 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).
- on peut indiquer dans def_val une valeur par défaut, au cas oùm rien ne soit trouvé (donc aucune valeur spécifiéer dans le fichier *.def, ni aucune valeur dans la section "default" pour cette clef).
- par défaut, on va chercher l'information dans "traceurs", mais "t" permet d'aller la chercher dans un autre vecteur de type "tr" (surtout utile en interne quand on manipule dBase).
On peut aussi créer un alias (pointeur) vers un traceur particulier (aliasTracer) ou obtenir les indices d'un ou plusieurs traceurs (idxTracer).
- À noter que le module "strings_mod.f90" contient des outils couramment utiles pour les chaînes et les affichages, en particulier un équivalent de "find" dans matlab (indices d'un ou plusieurs éléments dans un vecteur), ou 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).
