Review doc
doc/Structure.svg
Quelle est la convention ? il y a le langage "UML" qui a normalisé ce genre de diagramme (avec différentes formes de diagramme en fonction de ce que tu veux représenter). https://fr.wikipedia.org/wiki/UML_(informatique)
computed states analysed states forecast__ed__ states
@huderl: le participe passé de forecast est forecast (verbe irrégulier)
Fichier setup.py :
- il n'y a pas de dépendance vis à vis de fortran. Normal ? embarquée avec numpy ?
- pas de ref à f2py (alors que ref à Forecast.f90 et Init.f90)
@huderl: f2py (ainsi que gfortran ?) est embarqué avec numpy qui doit être installé avant le setup.py
Fichier env.sh :
toujours nécessaire ? je n'en ai pas l'impression si on passe par du virtual env.
@huderl: C'est un reliquat, je vais le retirer
Fichier readme.md
pour le test, quid de mettre : python3 -c "import GeDACCMU; print(GeDACCMU.version)"
plutôt que python3 import GeDACCMU GeDACCMU.version
@huderl: Validé
See example.conf for an example ...
est il possible de faire un lien ?
@huderl: Je vais essayer
Section usage :
peut être mentionner l'option -h de run_algo.py Peut être ajouter dans run_algo.py un #!/bin/env python3 de façon à pouvoir directement lancer run_algo.py -h sans avoir à préfixer la commande par python3 (nécessite de donner les droits en exécution du coup)
Section sur mpi :
On ne l'a pas trop testé (en tout cas moi), mais normalement avec mpi on peut faire du multinoeud. Il peut y avoir quelques subtilités sur l'appel avec mpi lorsque l'on a plusieurs noeuds. Il faudrait qu'on trouve un moment pour faire un test sur un autre cluster pour
- vérifier que ça marche en multinoeuds
- pour culture, voir l'impact sur les perfs
- donner des infos sur comment on lance le truc en multinoeuds
IST-OAR :
peut être remplacer par "run on a cluster" car ist-oar est très "isterre spécifique" et on veut documenter plus l'usage sur un cluster.
virtualenv : j'ai entendu parlé d'un successeur à virtualenv. As tu vu passer des choses ?
Si numpy est dans la dépendance, est bien nécessaire de faire un pip3 install numpy.
Launch the job in a virtual env on the cluster : example with the OAR scheduler
Dans le script.sh, le nombre de coeurs peut être calculé à la volée. oar nous "set" une variable d'env "OAR_NODE_FILE" qui contient le nom d'un fichier contenant les ressources allouées :
ex sur luke : oarsub --project nsbas -n NSBAS -l /nodes=2/core=4,walltime=01:00:00 -I env | grep OAR_NODE_FILE OAR_NODE_FILE=/var/lib/oar/9447591
cat $OAR_NODE_FILE luke28 luke28 luke28 luke28 luke32 luke32 luke32 luke32
donc cat $OAR_NODE_FILE| sort -u| wc -l 2 donne le nombre de noeuds
cat $OAR_NODE_FILE| wc -l donne le nombre global de coeurs.
A rediscuter car il y a d'autres subtilités (genre, si on est avec OAR, il faut spécifier l'outil qui permet de faire les connections entre les noeuds, outil qui n'est pas ssh mais oarsh ou un truc du genre).
Question subsidiaire sur la partie hdf5 :
comment se passe la partie "reprise sur erreur" ? Si le code est tué en cours de traitement et qu'on le relance, repart-il de l'état stocké dans les fichiers hdf5 ou pas. Si on veut repartir from scratch, que faut il faire ?
Peut être préciser.
@huderl: On peut maintenant reprendre le calcul depuis un fichier hdf5 (#60 (closed)). Je vais préciser ça dans la doc.
If you wish to use your own data, have more information on the implementation or to use low-level features, please refer to the In-depth guide in the doc folder.
il y a peut être un to en trop, ou en "pas assez".
@huderl: Fait