Custom Query (324 matches)

Under some condition one can lose the run.card because two process try to access it at the same time

Il y a 3 autres "problèmes", que le TSC pourrait régler:

A) un certain nombre de fichiers parcellaires demeurent dans Analyse

• exemple année 1850-->1919 alors que l'on veut 1850-->1849 (ce dernier étant présent)
• du coup à la cmorization je prends 1850-->1919 inutilement.
• je ne veux pas compliquer plus que cela la cmorization et donc faire faire le travail à libIGCM

B) Le problème de COSP qui fait faire de lourde manips de card pour avoir les TS.

• introduire deux options optionnelles TimeSeriesBegin, TimeSeriesEnd dans les section Post des comp.card
• soumettre un job spécifique pour chaque fichier brute pour lequel on rencontre cette option.

C) on ne peut pas refaire les TS_DA pour une simulation comme historical en une fois (CPU timelimit exceeded)

a) pour ensembles j'avais partager le TimeSeriesVar en paquet (!TimeSeriesVar1, !TimeSeriesVar2 ...), chacun émettant un job

• problème on va ramener tout les histday autant de fois qu'il y a de TimeSeriesVar(N) en l'état actuel du code
• avantage on n'a pas à gérer un seul TMPDIR pour tout les jobs initiés par les TimeSeriesVar(N)
• gérer un seul TMPDIR n'est pas chose facile dans le cas général (IDRIS, CCRT)

b) alternative, on pourrait aussi positionner la chunck size de façon à ce que le fichier soit de taille raisonnable ET que l'on puisse refaire le paquet de TS en une soumission.

Le fait de coder 1) et 2) dans TSC (mettre de la nouvelle intelligence dans create_TS aussi) va engendrer une petite adaptation dans l'algo que tu proposes:

Cadre général --- dat1= date début (global ou au sein d'une chunck) dat2= date fin (global ou au sein d'une chunck) dat1 et dat2 sont ici variables et pilotés par la boucle chunck ou global

dat1 et dat2 peuvent avoir été déterminer par les deux options optionnelles TimeSeriesBegin, TimeSeriesEnd dans les section Post des comp.card pour résoudre le problème B) du à COSP.

--- 1) Pas de job create_TS à lancer: (dat1_dat2 existe)

a) rien a faire si ( dat1_dat2 existe et qu'il n'y a pas de * tel que dat1_* existe avec * < dat2 ) b) effacer dat1_* si ( dat1_dat2 existe et qu'il y a des * tel que dat1_* existe avec * < dat2 )

2) Job(s) create_ts à lancer sans CompletedFlag (dat1_dat2 n'existe pas)

a) tout à faire si ( il n'y a pas de * tel que dat1_* existe avec * < dat2 )

3) Job(s) create_ts à lancer avec un CompletedFlag (dat1_dat2 n'existe pas)

a) faire avec CompletedFlag=* si ( date1_* existe avec * < dat2 ) mais: b) si plusieurs * vérifient cela

b') ( si il existe au moins un * commun à toutes les variable ) prendre le plus proche de dat2 et effacer les autres b) ( si il n'existe aucun * commun à toutes les variables )

• ou bien grouper les variables ayant le même * et OverRuler le contenu de TimeSeriesVar* pour refléter cela
• ou bien effacer tout et recommencer...

Le 3)b) est le pire des cas ; même si l'on regroupe les variables et que l'on OverRule la liste TimeSeriesVar*, on va retomber sur le problème du C)c) précédent et la charge dmnfs peut être importante. ----> gérer un TMPDIR commun c'est pas facile.

On doit pouvoir tout faire jusqu'à 3)b') le 3)b) étant plus casse tête.

Si l'on code 1), 2) et 3) dans le cadre général donné ci dessus alors on aura un TSC béton, et même plus que cela encore.

L'option CompletedFlag du run.card si 1) et 2) et 3) sont codés deviendrait inutile.

​http://wiki.ipsl.jussieu.fr/IGCMG/ENSEMBLES

This ticket will be split in 4 "sub tickets"