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: Changed 12 years ago by 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: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]

Note: See TracTickets for help on using tickets.