Bonjour Eric, Pour le moment je confirme qu'il nous est obligatoire de préciser la classe du job. Dans la modif de ISIS qui sera faite, est-il possible de rendre la classe du job modifiable par l'utilisateur et non pas en dur? Afin de pouvoir la renseigner en fonction des besoins? Concernant la glibc, effectivement il y avait un petit soucis, elle était normalement installée, mais après vérification seule la machine principale en disposait. On installe puis on retest. A bientôt. Bastien -----Message d'origine----- De : isis-fish-users-bounces@list.isis-fish.org [mailto:isis-fish-users-bounces@list.isis-fish.org] De la part de Eric Chatellier Envoyé : mercredi 21 avril 2010 01:52 À : isis-fish-users@list.isis-fish.org Objet : Re: [Isis-fish-users] Simulation sur Cluster Le 20/04/2010 07:34, Bastien Preuss a écrit :
Bonjour Eric,
Bonjour,
Donc pour que la simulation tourne bien, nous lançons à la main le script "toto.pbs" suivant:
Comme tu peux le voir il y a la commande "qsub -q qLong toto.pbs" Qui est peut être le soucis, car le pbs du cluster est paramétré de telle façon qu'il faut obligatoirement spécifier la classe du job; ce que ne fait peut être pas ISIS...?
Ce n'est pas fait actuellement, mais si vous me confirmer que c'est obligatoire, je vais faire une évolution dans Isis. Pouvez vous vérifier également que la queue (-q) peut être configurée dans le script toto.pbs Par exemple, une option de la forme: #PBS -q xyz
Autre point il y a peut être un soucis avec Java... Est-il nécessaire d'installer Java sur tous les nœuds du cluster? En fait, le JRE est installé sur home/bpreuss qui est partagé par nfs par l'ensemble des machines du cluster, qui elle n'ont pas Java.
Non, isis utilisera le Java dans /home/bpreuss (un seul donc)
A l'exécution de Java à travers pbs (grâce au toto.pbs envoyé à la main), le job apparait dans qstat, mais s'arrête tout de suite avec une erreur: " /var/spool/pbs/mom_priv/jobs/42244.editr.SC: /home/bpreuss/jre1.6.0_19/bin/java: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory" Qui se trouve dans le fichier: simulation-sim_sim_test_1_2010-04-19-16-52_2010-04-20-15-25-output.txt Donc Java ne semble pas reconnu par le cluster...
En fait, le probleme vient d'un Java 32bits tournant sur un système 64bits. Je vois donc 2 options pour résoudre ce problème. Il faudrait que l'administrateur installe les packages manquants 32bits sur les noeuds du cluster. (à ce que j'en connais, c'est une couche de compatibilité pour exécuter des applications 32bits) A priori, le fichier ld-linux.so.2 est fournit pas le packages glibc (nommé libc6-i386 ou différent suivant la distribution utilisée) http://packages.debian.org/search?searchon=contents&keywords=ld-linux.so.2&m ode=exactfilename&suite=stable&arch=any Sinon, l'autre solution est d'utiliser une version 64bits de Java. Ça marchera directement, par contre, les simulations dureront plus longtemps en 64bits (fois deux quasiment). Bon courage. -- Éric <chatellier@codelutin.com> Tel: 02 40 50 29 28 http://www.codelutin.com _______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users