ins_job scope

[sdipsl]

on a actuellement un souci pour qq'un qui met a jour libIGCM sans mettre a jour le config. Dans ce cas, la personne va modifier le config.card dans le répertoire où il va travailler mais probablement il ne va pas s'occuper des autres config.card dans les expériences autour. C'est donc fort probable que ca va planter.

Pour simplifier jusqu'au prochain tag, je propose d'ajouter ${configCardPath} dans le commentaire en cas de plantage, pour avoir le suivant dans libIGCM_config.ksh dans le tag v2.7 :
IGCM_debug_Exit "You are using a deprecated ressources specification mechanism in ${configCardPath}"

Pour la suite, je relance la question dont on avait parlé il y a longtemps maintenant : pourquoi ins_job fait tout les config.card qu'il trouve ? Il suffit que ins_job traite le config.card dans le repertoire où on le lance. Mais je ne sais pas comment les ensemble fonctionne et si ca a un impacte. Je propose le petit modification suivant dans ins_job sur le trunk:

Changer lignes 170-171 :
for i in $(find ${d_n}/../config -name ${F_CFG} -print)
do

en :

i=`pwd!`/config.card

Puis enlever "done" correspondant sur la ligne 302.

Qu'en pense tu ?

Josefine

[sdipsl]

Le fait que ins_job travail avec tout les config.card qu'il trouve nous vient des v5. On voulait pouvoir créer plusieurs job d'un coup.

Les ensemble ont eux aussi besoin de cela.

On pourrait conditionner la boucle à l'activation ou non des ensembles.

[jgipsl]

Ajoute ${configCardPath} dans le message d'errur fait sur le tag [1269] et trunk [1270].

Comme dit a la réunion 3nov, je prends cette ticket. Nicolas Lebas pense que c'est bon pour les ensmebles en traitant qu'une seule config.card mais il va faire des tests.

[jgipsl]

• Fait dans le trunk rev [1271]
• Adpated doc ici ​http://forge.ipsl.jussieu.fr/igcmg_doc/wiki/DocEsetup#Thescriptins_job