- Isis-fish-devel - mailman.cloud.codelutin.com

boucles métiers dans les regles de gestion
by Sigrid Lehuta Sept. 3, 2014

Sept. 3, 2014

Petite question existentielle concernant les regles de gestion : 1) Chaque methode (condition, preaction,postaction) boucle t'elle sur TOUS les metiers ? ou 2) Condition boucle sur TOUS les metiers et pre action et post action bouclent sur les metiers pour lesquels la condition est TRUE? (Je crois que c'est 2, la preuve on re-evalue les conditions liées aux engins et target species en preaction... ) Dans le cas 2, est ce bien utile de boucler sur les métiers dans la condition? Dans tous les cas, serait il possible de modifier le shéma ici présent http://www.isis-fish.org/v4/devel/architecture.html qui montre la boucle que font les regles, car il est inexact. En effet la boucle sur metiers est réalisée a chaque etape or le schéma laisse penser qu on fait toutes les etapes pour un metier puis on recommence pour le deuxieme etc. Merci !

2 2

Re: [Isis-fish-devel] Différentes versions de R pour IsisFish
by Eric Chatellier Aug. 28, 2014

Aug. 28, 2014

Le 02/06/2014 18:04, Eric Chatellier a écrit : > Bonjour, > > La version 4.3.0.0 d'IsisFish fonctionne avec R 3.0.x. > > Dans une future version, IsisFish ne sera plus fournit avec JRI (ce qui nous > sert à appeler R), et nécessitera une action de l'utilisateur pour fonctionner. > > L'utilisateur devra manuellement installer, dans R, le package rJava pour sa > version de R pour que IsisFish puissent continuer d'utiliser R. > Cela résoudra les problèmes de versions. C'est fait. La prochaine version majeure fonctionnera avec n'importe quelle version de R si le package R rJava est installé. -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28

1 0

bug en priorité...
by Sigrid Lehuta Aug. 20, 2014

Aug. 20, 2014

Tu demandais hier quels bugs etaient a traiter en priorité, jai eu a nouveau ce matin un bug a la sauvegarde de la region, apres la sauvegarde j ai des erreurs chaque fois que je clique sur un objet. Ca fait peur ! ;-) il faut fermer/ouvrir isis pour que ca cesse. celui ci est penible,Merci de regarder.

1 0

Utiliser des règles sous la V 4.3.0.0
by Audric Vigier May 23, 2014

May 23, 2014

Bonjour, J'ai un souci pour utiliser des règles sous ISIS 4.3. J'ai essayé avec 3 règles différentes pour voir si la problème venait des règles, mais je ne peux pas les utiliser (et certaines sont dans le VCS officiel). J'essaye de lancer une simulation avec une règle. Lorsqu'elle se lance (interface des simus), la simu passe rapidement dans le bas de l'interface (ou desfois reste en haut), avec comme message "Rules initialisation:[rules.NomDeLaRegle@NumeroDeBit]" (e.g. [rules.TACpoids@cbdb96]) Dans le debug, il n'y a rien si la simu reste en haut, et je trouve une ERROR et un WARN si la simu passe en bas (voir le debug pour la simu sim_RealiteReelleVraie10param10ans_2014-04-23-17-01, avec la règle GraviteVPUE1LangEtGrossValueOtherSpeciesECOMOD). Il n'y a pas de souci avec ces règles sous la V 4.2 Je joins script de règle + inputs spécifiques à la règle + debug. Pour la region, j'ai pris GolfeDeGascogne. Bonne soirée, Audric

5 19

Nom d'exports d'optimizations
by Audric VIGIER May 21, 2014

May 21, 2014

Bonjour, J'ai remarqué qu'en utilisant les plans d'optimizations, le nom de l'export créé était toujours celui indiqué par défaut dans le script, ce qui devient vite gênant qui on fait tourner en parallèle plusieurs fois ce plan sur la même machine. Pourtant, le parameter.properties indique bien un nom de plan différent du nom par défaut. Je suis sous ISIS V4.3, la version 3977. J'ai mis en PJ un plan avec son inputs et un dossier de simulation générée avec ce plan. Il fonctionne avec la base golfe de Gascogne. Une idée d'où peut venir l'erreur? Audric

2 1

Amélioration des lancements des simulations sur CapArmor
by Benjamin POUSSIN May 19, 2014

May 19, 2014

Salut, Je viens de commit des modifications par rapport aux problèmes qui arrivent lorsque CapArmor n'est pas joignable. En fait, on réessayait, mais tout de suite, donc sa replantait tout de suite, jusqu'à faire planter Isis :(. Maintenant on réessaye durant un peu plus de 4h (50 fois en 4h) en prenant de plus en plus de temps entre chaque essai (10min au plus). Si au bout de c'est 50 essais on arrive toujours pas à soumettre le jobs a CapArmor la queue de simulation se met en pause pour les simulations CapArmor. Il est possible de relancer en appuyant sur le bouton 'pause/reprendre'. Donc au cas, ou CapArmor est indisponible 24h, on ne perd pas tout. Il me reste a tester avant de faire un release. -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin(a)codelutin.com http://www.codelutin.com

2 1

Proposition couplage Marxan-ISIS
by Yves Reecht May 15, 2014

May 15, 2014

Bonjour à tous, Afin de la dynamiser un peu, je relance sur la liste cette discussion qui avait été commencée en /off/ (j'y synthétise les réponses à quelques questions que cette proposition avait déjà soulevées). Un petit mot de contexte pour ceux qui ne sont pas au courant : dans le cadre de mon postdoc, j'ai pour mission de faire un couplage entre une approche de planification spatiale de conservation (utilisant Marxan with Zones, qui permet d'optimiser le /design/ d'aires marines protégées) avec un modèle ISIS-Fish en Manche Est. La première étape est d'utiliser dans ISIS des zones de réduction d'effort définies par engin à l'aide de Marxan. Après discussion avec Stéphanie et Sigrid, il apparait que l'utilisation du simulateur par cellule est /(//i//)/ plus simple (inutile de redéfinir autant de métiers et zones métiers que de pourcentage de réduction d'effort par engin, comme ce serait le cas avec le simulateur par défaut) et /(ii)/ bien plus à même de retranscrire les effets d'une gestion spatialisée à une échelle fine. Il a donc été choisi de s'inspirer de l'actuel simulateur par cellule et de modifier les scripts afin d'introduire dans l'équation de mortalité par pêche un terme de limitation d'effort (dans SiMatrix) estimé, le cas échéant, à l'échelle de la cellule par évaluation d'intersection avec des zones de réduction d'effort pour l'engin courant. La limitation d'effort serait bien entendu fixée à zéro en l'absence de zones de limitation d'effort. J'ai donc codé, en m'inspirant d'un premier travail de préparation fait avec Éric, quelques modifications qui devraient permettre de réaliser ce couplage. Et je souhaiterais les soumettre à vos critiques et éventuelle approbation. Le code que vous trouverez ci-joint, adapté de la *version 4.2.1.2*, aspire à être le plus générique possible et se caractérise par : * un nouveau simulateur, SimulatorEffortByCellMarxanWithZones.java qui, comme le script du simulateur par cellule, ne fait que définir un tag dans le context : "effortByCellMarxanWithZones" = "true". * une modification de la fonction isEffortByCell() (lignes 342+ de DefaultSimulator.java) afin d'entrer en mode simulation par cellule également lorsque ce nouveau tag est défini. À noter que pour éviter cette modification il devrait être possible - et sûrement souhaitable - de définir deux tags effortMarxanWithZones et effortByCell distincts à l'aide du nouveau simulateur. Je vous l'envoie toutefois en l'état, en attendant d'avoir pu tester cette solution. * une nouvelle règle de gestion (ReductionEffortMwZPreSimu.java) qui définit en présimulation les zones de réduction d'effort et le paramètre (proportion) de réduction associé pour chaque engin, à partir d'un fichier de sorties Marxan (fichier joint effortRedISIS_3.csv, une ligne par zone : <engin>;<proportion réduction>;<Cell1>,<Cell2>,...). De plus, si la proportion de réduction d'effort est 1.0 sur une zone, celle-ci est ajoutée à la table NoActivity de l'engin. * une modification de SiMatrix.java qui se décline en deux parties : 1. ajout d'une fonction locale qui permet de tester si on est dans une simu Marxan (lignes 82+ ; teste le tag définit par le nouveau simulateur). 2. modification (lignes 885-912) de la fonction qui calcule la mortalité par pêche au niveau de la cellule (matrixFishingMortalityPerCell) : * ajout d'un facteur de réduction d'effort, à 0.0 par défaut, utilisé dans l'équation de mortalité. * modulation de ce facteur en fonction de l'intersection avec les zones de réduction d'effort de l'engin, uniquement si on est dans une simu Marxan (reste 0.0 sinon). Du coup le script reste parfaitement utilisable avec les autres simulateurs : * simulateur par défaut : cette fonction modifiée n'est simplement pas utilisée. * simulateur par cellule simple : l'effort est multiplié par (1.0 - 0.0) dans tous les cas. Les modifications apportées au code des fonctions fondamentales d'ISIS (hors règle) sont donc relativement légère et - à mon avis - faciles à maintenir : toute amélioration/correction de bug apporté(e) au simulateur par cellule bénéficierait systématiquement au simulateur "Marxan". Ces scripts ont été testés et donnent des sorties qui paraissent cohérentes avec la base Manche Est, datée du 21/10/2013, de Sigrid. Toutes vos remarques et suggestions seront les bienvenues. N'hésitez pas a demander des précisions si quelque chose ne semble pas clair. Yves -- ------------------------------------------------------------ Yves REECHT Laboratoire Ressources Halieutiques IFREMER - Centre Manche Mer du Nord 150, Quai Gambetta 62200 Boulogne-sur-Mer FRANCE tel. +33 (0)3 21 99 56 09 --------------------------------------------------)><))))°>

1 1

Conflit local/Caparmor sur la V 4.3
by Audric Vigier May 14, 2014

May 14, 2014

Bonjour, Ce matin, je faisais tourner sur une même machine des plans de simulations en local et des plans d'optimisation sur Caparmor. Comme Caparmor est très chargé aujourd'hui, je ne faisais pas beaucoup de simulations dessus, jusque là c'est normal. Cependant, j'ai eu l'impression que ça ralentissant mes simus locales aussi. Je me suis rendu compte que quand j'avais des simus en local et sur Caparmor, elles sont traitées dans un certain ordre. Ainsi si ISIS doit lancer une simu Caparmor puis une simu locale, il doit attendre d'avoir récupéré les résultats de la simu Caparmor avant d'exporter les résultats de la simu locale (j'ai l'impression que dans ce cas, la simu locale a tourné (j'aurais dû regarder le debug, mais j'ai encore oublié et relancé ISIS), mais les résultats ne sont pas exportés immédiatement). Du coup, mes simus locales avançaient au même rythme que les simus sur Caparmor : quand j'avais des jobs sur Caparmor, mes simus locales se faisaient et je voyais leurs résultats exportés, que je n'avais pas de job, je ne voyait aucune évolution dans l'interface pour les simus locales. Est-ce que c'est un comportement normal? Audric

2 1

Plan de simulations indépendantes + V4.3 + Caparmor
by Audric Vigier May 13, 2014

May 13, 2014

Bonsoir, Gros souci avec Caparmor avec un plan de simulation (en PJ). Lorsque j'ai lancé ce plan sur Caparmor, les simulations se sont lancées de manière indépendante mais sans limite : une à une, des simulations se sont lancées sur Caparmor, sans attendre que l'autre soit terminée, jusqu'à ce que plus de 200 simus aient été lancées, ce qui est bien plus que le nombre de coeurs auquel nous avons droit. Là, j'ai eu des centaines de messages d'erreur, plantage, et j'ai dû redémarrer(j'espère vraiment qu'aucun autre utilisateur n'avait de choses importantes en cours sur la machine)(je n'ai pas le debug comme j'ai relancé ISIS après redémarrage). Lorsque je fais la même chose en local, une à une, autant de simus que de coeurs dispos se lancent, se réalisent en même temps, se terminent, puis le même nombre de simus va se lancer, etc. C'est exactement ce qu'on veut. Donc le problème ne vient pas de mes scripts... Je suis contraint, pour utiliser ces plans sur caparmor, de le faire en dépendant (lorque je déclare ma classe : "[....] extends SimulationPlan"), ce qui nous fait perdre tout l'intérêt de la parallélisation puisqu'il faut attendre qu'une simu soit terminée pour lancer l'autre. Une solution pour utiliser ce plan de simus sur Caparmor avec des simus indépendantes? Bonne soirée, Audric

5 7

Lancement d'un job qsub depuis un job qsub
by Eric Chatellier May 12, 2014

May 12, 2014

Bonjour, Est-il possible depuis un job qsub de démarrer des nouveaux jobs qsub ? L'idée serait d'avoir le fonctionnement suivant : - lancement d'un job très long qui ne fait rien d'autre que lancer des sous simulations - chaque sous job est une simulation indépendante Il me semble que j'avais essayé, mais cela ne fonctionnait pas. Merci. -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28

2 1