Opened 12 years ago
Closed 12 years ago
#80 closed enhancement (fixed)
Distinguish environment for calcul and post-processing wrt .atlas_env
Reported by: | sdipsl | Owned by: | aclsce |
---|---|---|---|
Priority: | minor | Milestone: | libIGCM_v2.0 |
Component: | system | Version: | |
Keywords: | Cc: |
Description
Change History (3)
comment:1 follow-up: ↓ 2 Changed 12 years ago by sdipsl
comment:2 in reply to: ↑ 1 Changed 12 years ago by sdipsl
voila ce que l'on fait sur curie pour détecter que l'on fait du post-traitement.
Ce même test devrait suffire pour sourcer le bon fichier.
#====================================================
#- RUN_DIR_PATH : Temporary working directory (=> TMP)
if [ ! X${BRIDGE_MSUB_NPROC} = X1 ] ; then
typeset -r RUN_DIR_PATH=${RUN_DIR_PATH:=${SCRATCHDIR}/RUN_DIR/${BRIDGE_MSUB_JOBID}}
else
typeset -r RUN_DIR_PATH=${RUN_DIR_PATH:=${SCRATCHDIR}/TMPDIR_IGCM/${BRIDGE_MSUB_JOBID}}
fi
Replying to sdipsl:
Salut Sébastien,
je voulais modifier les atlas_env et les dissocier suivant calcul-post.
Par exemple, pour curie : j'avais dans l'idée de créer un atlas_env_calcul_curie_ksh et un atlas_env_post_curie_ksh, avec un atlas_env_curie_ksh qui
pointerait vers le atlas_env_calcul_curie_ksh pour ne pas tout casser.
Et donc, faire sourcer à libIGCM ou bien le calcul ou bien le post suivant le Job appelant.
Mais je crois me souvenir que tu m'avais confirmé qu'il n'y a pas moyen de savoir si on est dans un job de calcul ou de post.
D'ou la bidouille pour titane :
if ( [ X${LSB_QUEUE} = Xmono ] [ X${LSB_QUEUE} = Xmonoext ] ) ; then module switch nco/3.9.4 nco/3.9.4_netcdf4
fi
Sur Curie, on pourrait faire la même chose (en testant si on est sur noeuds larges ou fins par exemple) mais il me semble que c'est pas terrible.
Il y aurait donc 2 possibilités me semble-t-il :
1) faire sourcer une lib_sys.ksh differente suivant si on est dans un job de post ou de calcul.
Par exemple :
. ${libIGCM}/libIGCM_sys/libIGCM_sys_post.ksh dans un job de TS.
Mais il me semble que ca augmenterait le nombre de fichier *sys* à maintenir,....et donc pas top.
2) ou bien tester sur le nom du Job appelant au sens "nom du fichier" : Job_blabla pour un job de calcul vs create_ts.job pour un job de post
( ou tester sur le nom de la requête #MSUB -r TS par exemple sur Curie)
Du coup on se retrouverait à avoir une sorte de "if" dans la lib_sys_curie.ksh en remplacement de l'actuel :
. /ccc/cont003/home/dsm/p86ipsl/.atlas_env_curie_ksh
Ca donnerait un truc du genre :
if (nom du job appelant = *.job) alors
. /ccc/cont003/home/dsm/p86ipsl/.atlas_env_post_curie_ksh
else
. /ccc/cont003/home/dsm/p86ipsl/.atlas_env_calcul_curie_ksh
fi
ou
if (nom de la requête != TS && nom de la requête != SE........) alors
. /ccc/cont003/home/dsm/p86ipsl/.atlas_env_calcul_curie_ksh
else
. /ccc/cont003/home/dsm/p86ipsl/.atlas_env_post_curie_ksh
fi
Que penses tu de tout ça ?
comment:3 Changed 12 years ago by aclsce
- Resolution set to fixed
- Status changed from new to closed
The best way is to add TaskType variable in jobs to specify the type of the job (computing or post-processing). That could be very useful : for example to distinguish environment for computing and post-processing. That is the case on Curie machine.
More information : [712]
Salut Sébastien,
je voulais modifier les atlas_env et les dissocier suivant calcul-post.
Par exemple, pour curie : j'avais dans l'idée de créer un atlas_env_calcul_curie_ksh et un atlas_env_post_curie_ksh, avec un atlas_env_curie_ksh qui
pointerait vers le atlas_env_calcul_curie_ksh pour ne pas tout casser.
Et donc, faire sourcer à libIGCM ou bien le calcul ou bien le post suivant le Job appelant.
Mais je crois me souvenir que tu m'avais confirmé qu'il n'y a pas moyen de savoir si on est dans un job de calcul ou de post.
D'ou la bidouille pour titane :
Sur Curie, on pourrait faire la même chose (en testant si on est sur noeuds larges ou fins par exemple) mais il me semble que c'est pas terrible.
Il y aurait donc 2 possibilités me semble-t-il :
1) faire sourcer une lib_sys.ksh differente suivant si on est dans un job de post ou de calcul.
Par exemple :
. ${libIGCM}/libIGCM_sys/libIGCM_sys_post.ksh dans un job de TS.
Mais il me semble que ca augmenterait le nombre de fichier *sys* à maintenir,....et donc pas top.
2) ou bien tester sur le nom du Job appelant au sens "nom du fichier" : Job_blabla pour un job de calcul vs create_ts.job pour un job de post
( ou tester sur le nom de la requête #MSUB -r TS par exemple sur Curie)
Du coup on se retrouverait à avoir une sorte de "if" dans la lib_sys_curie.ksh en remplacement de l'actuel :
Ca donnerait un truc du genre :
if (nom du job appelant = *.job) alors
else
fi
ou
if (nom de la requête != TS && nom de la requête != SE........) alors
else
fi
Que penses tu de tout ça ?