Simulations qui s'arrêtent quand ça leur chante...
Bonjour, J'ai lancé des AS sur caparmor, une sans règles de gestion, et l'autre avec une gestion par les TACS et la taille min. La première AS semble marcher sans soucis, mais il apparait que dans la seconde la plupart des simulations s'arrêtent au cours de la première année, mais pas forcément toujours au même moment. Ce qui est étrange est que certaines simulations arrivent bien à leur terme, et que dans ce cas là j'ai bien tous les résultats de la simulation, et ils semblent cohérents... Loïc
Hello, apparement ca vient des rejets, les simulations qui marchent sont surement (?) celles ou le TAC n est pas atteint. MatrixND discard = popMon.getDiscard(step, pop); (rule TAC ligne 328) Je ne suis pas familiere de la gestion de cette matrice mais je suppose qu'il manque une ligne qui la cree pour la simulation si elle n a pas ete cree par une autre regle, comme dans TailleMin. Eric, Jean ? if (popMon.getDiscard(step, pop) == null) { MatrixND discard = popMon.getCatch(pop).copy(); Loic peux tu faire des tests de la regle TAC avec des TAC tres petits pour voir si la matrice discard est cree? Le 30 avril 2012 03:41, Loic GASCHE <Loic.Gasche@ifremer.fr> a écrit :
Bonjour,
J'ai lancé des AS sur caparmor, une sans règles de gestion, et l'autre avec une gestion par les TACS et la taille min. La première AS semble marcher sans soucis, mais il apparait que dans la seconde la plupart des simulations s'arrêtent au cours de la première année, mais pas forcément toujours au même moment. Ce qui est étrange est que certaines simulations arrivent bien à leur terme, et que dans ce cas là j'ai bien tous les résultats de la simulation, et ils semblent cohérents...
Loïc
_______________________________________________ Isis-fish-devel mailing list Isis-fish-devel@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-devel
Le 30/04/2012 09:41, Loic GASCHE a écrit :
Bonjour,
J'ai lancé des AS sur caparmor, une sans règles de gestion, et l'autre avec une gestion par les TACS et la taille min. La première AS semble marcher sans soucis, mais il apparait que dans la seconde la plupart des simulations s'arrêtent au cours de la première année, mais pas forcément toujours au même moment. Ce qui est étrange est que certaines simulations arrivent bien à leur terme, et que dans ce cas là j'ai bien tous les résultats de la simulation, et ils semblent cohérents... Tu a du perdre du code dans DefaultSimulator_F quand tu as fait la mise à jour (PopulationMonitor n'est plus initialisé).
Tu peux verifier ? -- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
Le 02/05/2012 09:44, Eric Chatellier a écrit :
Le 30/04/2012 09:41, Loic GASCHE a écrit :
Bonjour,
J'ai lancé des AS sur caparmor, une sans règles de gestion, et l'autre avec une gestion par les TACS et la taille min. La première AS semble marcher sans soucis, mais il apparait que dans la seconde la plupart des simulations s'arrêtent au cours de la première année, mais pas forcément toujours au même moment. Ce qui est étrange est que certaines simulations arrivent bien à leur terme, et que dans ce cas là j'ai bien tous les résultats de la simulation, et ils semblent cohérents... Tu a du perdre du code dans DefaultSimulator_F quand tu as fait la mise à jour (PopulationMonitor n'est plus initialisé).
Tu peux verifier ?
Il ne semble pas y avoir eu de perte de code, la seule différence entre les deux simulateurs étant l'ajout de TotalFishingMortality et de quelques commentaires à DefaultSimulator_F (10 lignes de code en plus et rien en moins). Je vais tester la méthode de Sigrid, pour voir s'il n'y a pas un soucis avec les rejets.
Le 02/05/2012 10:23, Loic GASCHE a écrit :
Il ne semble pas y avoir eu de perte de code, la seule différence entre les deux simulateurs étant l'ajout de TotalFishingMortality et de quelques commentaires à DefaultSimulator_F (10 lignes de code en plus et rien en moins).
Je vais tester la méthode de Sigrid, pour voir s'il n'y a pas un soucis avec les rejets.
Envoie le moi pour voir stp. -- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
Le 02/05/2012 10:27, Eric Chatellier a écrit :
Le 02/05/2012 10:23, Loic GASCHE a écrit :
Il ne semble pas y avoir eu de perte de code, la seule différence entre les deux simulateurs étant l'ajout de TotalFishingMortality et de quelques commentaires à DefaultSimulator_F (10 lignes de code en plus et rien en moins).
Je vais tester la méthode de Sigrid, pour voir s'il n'y a pas un soucis avec les rejets.
Envoie le moi pour voir stp.
Le 02/05/2012 10:23, Loic GASCHE a écrit :
Il ne semble pas y avoir eu de perte de code, la seule différence entre les deux simulateurs étant l'ajout de TotalFishingMortality et de quelques commentaires à DefaultSimulator_F (10 lignes de code en plus et rien en moins).
Je vais tester la méthode de Sigrid, pour voir s'il n'y a pas un soucis avec les rejets.
En effet, pas de pb avec le simulateur. TACpoids est ta seule regle ? C'est comme si tu essayais de recuperer le discard d'une population qui n'existe pas au départ de la simulation. -- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
Le 02/05/2012 10:36, Eric Chatellier a écrit :
Le 02/05/2012 10:23, Loic GASCHE a écrit :
Il ne semble pas y avoir eu de perte de code, la seule différence entre les deux simulateurs étant l'ajout de TotalFishingMortality et de quelques commentaires à DefaultSimulator_F (10 lignes de code en plus et rien en moins).
Je vais tester la méthode de Sigrid, pour voir s'il n'y a pas un soucis avec les rejets.
En effet, pas de pb avec le simulateur.
TACpoids est ta seule regle ?
C'est comme si tu essayais de recuperer le discard d'une population qui n'existe pas au départ de la simulation.
J'ai un TACpoids et une TailleMin pour chaque population
Le 02/05/2012 10:40, Loic GASCHE a écrit :
J'ai un TACpoids et une TailleMin pour chaque population
J'ai trouvé en fait. Tu dois lancer ta simulation avec 2 pops (Pop1 et Pop2) Les discards sont initialisés pour ces 2 populations. Mais la régle TACPoids utilise toutes les populations d'une espèce, même si elles ne sont pas sélectionnées au départ (l 321) : for (Population pop : param_species.getPopulation()) { d'où l'erreur. Par contre, je ne sais pas si l'erreur est dans la règle ou dans isis. Quel est la meilleur façon de résoudre cela ? -- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
Le 02/05/2012 10:54, Eric Chatellier a écrit :
Le 02/05/2012 10:40, Loic GASCHE a écrit :
J'ai un TACpoids et une TailleMin pour chaque population
J'ai trouvé en fait.
Tu dois lancer ta simulation avec 2 pops (Pop1 et Pop2) Les discards sont initialisés pour ces 2 populations.
Mais la régle TACPoids utilise toutes les populations d'une espèce, même si elles ne sont pas sélectionnées au départ (l 321) :
for (Population pop : param_species.getPopulation()) {
d'où l'erreur.
Par contre, je ne sais pas si l'erreur est dans la règle ou dans isis. Quel est la meilleur façon de résoudre cela ?
Heu je ne comprends pas trop la dernière phrase... A priori je trouve ça bizarre que la règle TAC prenne toutes les populations d'une espèce. Les TACs sont définis par zone CIEM ou par groupe de zones CIEM. Par exemple, il y a un TAC pour la sole en 7D et un TAC pour la sole en 7E; mais le TAC de plie est défini pour les zones 7D et 7E à la fois. Comme ça je dirais donc que quand on veut mettre un TAC, il faudrait en même temps qu'on nous demande à quelles populations il va s'appliquer. Comme ça un TAC s'applique à un groupe de populations, et c'est à l'utilisateur de faire correspondre ce groupe de populations à une ou plusieurs zones CIEM. Comme ça on peut avoir un modèle ISIS qui représente plusieurs zones CIEM avec chacune leurs populations et avec un TAC par zone. Après ce n'est que la vision que j'en ai avec mon petit modèle que je n'utilise pas en entier. D'ailleurs le soucis ne se pose peut-être que dans mon cas particulier: mon modèle représente 2 zones mais je n'en utilise qu'une dans les simulations car l'autre est appelée à sauter à terme. Mais on peut supposer qu'un "vrai" modèle ISIS ne contient que les zones auxquelles on s'intéresse, et donc on travaillerait sur toutes les zones et toutes les pops (avec toujours la question de comment séparer les pops des différentes zones si le TAC prend automatiquement toutes les pops). Donc peut-être que Steph ou Sigrid seraient plus utiles pour répondre à cette question.
-- Éric Chatellier<chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
_______________________________________________ Isis-fish-devel mailing list Isis-fish-devel@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-devel
Le 02/05/2012 13:40, Loic GASCHE a écrit :
Heu je ne comprends pas trop la dernière phrase...
A priori je trouve ça bizarre que la règle TAC prenne toutes les populations d'une espèce.
Les TACs sont définis par zone CIEM ou par groupe de zones CIEM. Par exemple, il y a un TAC pour la sole en 7D et un TAC pour la sole en 7E; mais le TAC de plie est défini pour les zones 7D et 7E à la fois.
Comme ça je dirais donc que quand on veut mettre un TAC, il faudrait en même temps qu'on nous demande à quelles populations il va s'appliquer. Comme ça un TAC s'applique à un groupe de populations, et c'est à l'utilisateur de faire correspondre ce groupe de populations à une ou plusieurs zones CIEM.
Comme ça on peut avoir un modèle ISIS qui représente plusieurs zones CIEM avec chacune leurs populations et avec un TAC par zone.
Après ce n'est que la vision que j'en ai avec mon petit modèle que je n'utilise pas en entier. D'ailleurs le soucis ne se pose peut-être que dans mon cas particulier: mon modèle représente 2 zones mais je n'en utilise qu'une dans les simulations car l'autre est appelée à sauter à terme. Mais on peut supposer qu'un "vrai" modèle ISIS ne contient que les zones auxquelles on s'intéresse, et donc on travaillerait sur toutes les zones et toutes les pops (avec toujours la question de comment séparer les pops des différentes zones si le TAC prend automatiquement toutes les pops). Donc peut-être que Steph ou Sigrid seraient plus utiles pour répondre à cette question.
Je comprend. C'est juste que dans le postAction, Sigrid a utilisé les populations de l'espece au lieu des populations de la simulation. Il y a peut etre une raison, ou alors c'est une erreur. -- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
hello, je decline toutes responsabilite dans l ecriture de cette regle ;-) je pense que l esprit etait que, dans la vraie vie, les TAC ciblent une espece (et toutes ses pops) a l echelle d une region et non une pop. Et le cas de Loic est particulier. mais je ne vois pas pourquoi on s interesserait a des pop non simulees, donc il faudrait garder le species (for (Population pop : param_species.getPopulation()) {) mais ajouter un test qui verifie que la pop est simulee. ca vous parait bien? Le 2 mai 2012 08:04, Eric Chatellier <chatellier@codelutin.com> a écrit :
Le 02/05/2012 13:40, Loic GASCHE a écrit :
Heu je ne comprends pas trop la dernière phrase...
A priori je trouve ça bizarre que la règle TAC prenne toutes les
d'une espèce.
Les TACs sont définis par zone CIEM ou par groupe de zones CIEM. Par exemple, il y a un TAC pour la sole en 7D et un TAC pour la sole en 7E; mais le TAC de plie est défini pour les zones 7D et 7E à la fois.
Comme ça je dirais donc que quand on veut mettre un TAC, il faudrait en même temps qu'on nous demande à quelles populations il va s'appliquer. Comme ça un TAC s'applique à un groupe de populations, et c'est à l'utilisateur de faire correspondre ce groupe de populations à une ou plusieurs zones CIEM.
Comme ça on peut avoir un modèle ISIS qui représente plusieurs zones CIEM avec chacune leurs populations et avec un TAC par zone.
Après ce n'est que la vision que j'en ai avec mon petit modèle que je n'utilise pas en entier. D'ailleurs le soucis ne se pose peut-être que dans mon cas particulier: mon modèle représente 2 zones mais je n'en utilise qu'une dans les simulations car l'autre est appelée à sauter à terme. Mais on
supposer qu'un "vrai" modèle ISIS ne contient que les zones auxquelles on s'intéresse, et donc on travaillerait sur toutes les zones et toutes les
populations peut pops
(avec toujours la question de comment séparer les pops des différentes zones si le TAC prend automatiquement toutes les pops). Donc peut-être que Steph ou Sigrid seraient plus utiles pour répondre à cette question.
Je comprend.
C'est juste que dans le postAction, Sigrid a utilisé les populations de l'espece au lieu des populations de la simulation. Il y a peut etre une raison, ou alors c'est une erreur.
-- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
_______________________________________________ Isis-fish-devel mailing list Isis-fish-devel@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-devel
Le 02/05/2012 16:01, Sigrid Lehuta a écrit :
hello, je decline toutes responsabilite dans l ecriture de cette regle ;-)
je pense que l esprit etait que, dans la vraie vie, les TAC ciblent une espece (et toutes ses pops) a l echelle d une region et non une pop. Et le cas de Loic est particulier. mais je ne vois pas pourquoi on s interesserait a des pop non simulees, donc il faudrait garder le species (for (Population pop : param_species.getPopulation()) {) mais ajouter un test qui verifie que la pop est simulee.
ca vous parait bien?
Je suis d'accord avec toi sur le fait que c'est bizarre de s'intéresser à des pops non simulées. Je reviens quand même sur mon autre question: qu'est-ce qui se passe si on simule une grande région qui correspond à plusieurs zones CIEM adjacentes (c'est bien ce qu'on a en Golfe de Gascogne non) ? Il faut faire un seul gros TAC qui s'applique à toutes les pops d'une espèce sans considération de localisation dans une zone CIEM donnée ? Ce serait bizarre...
Le 2 mai 2012 08:04, Eric Chatellier <chatellier@codelutin.com <mailto:chatellier@codelutin.com>> a écrit :
Le 02/05/2012 13:40, Loic GASCHE a écrit : > > Heu je ne comprends pas trop la dernière phrase... > > A priori je trouve ça bizarre que la règle TAC prenne toutes les populations > d'une espèce. > > Les TACs sont définis par zone CIEM ou par groupe de zones CIEM. Par exemple, > il y a un TAC pour la sole en 7D et un TAC pour la sole en 7E; mais le TAC de > plie est défini pour les zones 7D et 7E à la fois. > > Comme ça je dirais donc que quand on veut mettre un TAC, il faudrait en même > temps qu'on nous demande à quelles populations il va s'appliquer. Comme ça un > TAC s'applique à un groupe de populations, et c'est à l'utilisateur de faire > correspondre ce groupe de populations à une ou plusieurs zones CIEM. > > Comme ça on peut avoir un modèle ISIS qui représente plusieurs zones CIEM avec > chacune leurs populations et avec un TAC par zone. > > Après ce n'est que la vision que j'en ai avec mon petit modèle que je > n'utilise pas en entier. D'ailleurs le soucis ne se pose peut-être que dans > mon cas particulier: mon modèle représente 2 zones mais je n'en utilise qu'une > dans les simulations car l'autre est appelée à sauter à terme. Mais on peut > supposer qu'un "vrai" modèle ISIS ne contient que les zones auxquelles on > s'intéresse, et donc on travaillerait sur toutes les zones et toutes les pops > (avec toujours la question de comment séparer les pops des différentes zones > si le TAC prend automatiquement toutes les pops). Donc peut-être que Steph ou > Sigrid seraient plus utiles pour répondre à cette question. > Je comprend.
C'est juste que dans le postAction, Sigrid a utilisé les populations de l'espece au lieu des populations de la simulation. Il y a peut etre une raison, ou alors c'est une erreur.
-- Éric Chatellier <chatellier@codelutin.com <mailto:chatellier@codelutin.com>> Tel: 02.40.50.29.28 http://www.codelutin.com
_______________________________________________ Isis-fish-devel mailing list Isis-fish-devel@list.isis-fish.org <mailto:Isis-fish-devel@list.isis-fish.org> http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-devel
_______________________________________________ Isis-fish-devel mailing list Isis-fish-devel@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-devel
-- Loïc Gasche Doctorant Unité Ecologie et Modèles pour l'Halieutique (EMH) IFREMER - Centre de Nantes
C'est vraiment une question pertinente, surtout dans un contexte de redefinition des structures demographiques des pop (cf le Bar en Manche, le Hareng en Mer du Nord). De maniere pragmatique, L'objectif du modele est de tester de la gestion donc on se met a l echelle de la gestion. Les especes isis ont un sens pour les metiers et les TAC. Donc si chaque pop a sa zone, son metier et son TAC, je serais d avis de creer 2 especes differentes (comme pour les evaluations de stocks). meme si le sens biologique est perdu. Surtout que je ne crois pas que dans isis, les populations d une meme espece aient des liens privilegies qui ne puissent pas etre crees entre especes (?). Il faudrait chequer ca avec Steph qu'on ne neglige pas un aspect important en faisant ca. Autre option, creer une autre regle de TAC qui cible la pop au lieu de l espece. mais tu vas devoir interdire un metier qui cible une pop donc le TAC est atteint alors qu il pourrait encore pecher sur le reste de l'espece... et on ne distingue generalement pas les pop dans les debarquements... Bisarre! Le 2 mai 2012 10:11, Loic GASCHE <Loic.Gasche@ifremer.fr> a écrit :
Le 02/05/2012 16:01, Sigrid Lehuta a écrit :
hello,
je decline toutes responsabilite dans l ecriture de cette regle ;-)
je pense que l esprit etait que, dans la vraie vie, les TAC ciblent une espece (et toutes ses pops) a l echelle d une region et non une pop. Et le cas de Loic est particulier. mais je ne vois pas pourquoi on s interesserait a des pop non simulees, donc il faudrait garder le species (for (Population pop : param_species.getPopulation()) {) mais ajouter un test qui verifie que la pop est simulee.
ca vous parait bien?
Je suis d'accord avec toi sur le fait que c'est bizarre de s'intéresser à des pops non simulées.
Je reviens quand même sur mon autre question: qu'est-ce qui se passe si on simule une grande région qui correspond à plusieurs zones CIEM adjacentes (c'est bien ce qu'on a en Golfe de Gascogne non) ? Il faut faire un seul gros TAC qui s'applique à toutes les pops d'une espèce sans considération de localisation dans une zone CIEM donnée ? Ce serait bizarre...
Le 2 mai 2012 08:04, Eric Chatellier <chatellier@codelutin.com <mailto:chatellier@codelutin.**com <chatellier@codelutin.com>>> a écrit :
Le 02/05/2012 13:40, Loic GASCHE a écrit : > > Heu je ne comprends pas trop la dernière phrase... > > A priori je trouve ça bizarre que la règle TAC prenne toutes les populations > d'une espèce. > > Les TACs sont définis par zone CIEM ou par groupe de zones CIEM. Par exemple, > il y a un TAC pour la sole en 7D et un TAC pour la sole en 7E; mais le TAC de > plie est défini pour les zones 7D et 7E à la fois. > > Comme ça je dirais donc que quand on veut mettre un TAC, il faudrait en même > temps qu'on nous demande à quelles populations il va s'appliquer. Comme ça un > TAC s'applique à un groupe de populations, et c'est à l'utilisateur de faire > correspondre ce groupe de populations à une ou plusieurs zones CIEM. > > Comme ça on peut avoir un modèle ISIS qui représente plusieurs zones CIEM avec > chacune leurs populations et avec un TAC par zone. > > Après ce n'est que la vision que j'en ai avec mon petit modèle que je > n'utilise pas en entier. D'ailleurs le soucis ne se pose peut-être que dans > mon cas particulier: mon modèle représente 2 zones mais je n'en utilise qu'une > dans les simulations car l'autre est appelée à sauter à terme. Mais on peut > supposer qu'un "vrai" modèle ISIS ne contient que les zones auxquelles on > s'intéresse, et donc on travaillerait sur toutes les zones et toutes les pops > (avec toujours la question de comment séparer les pops des différentes zones > si le TAC prend automatiquement toutes les pops). Donc peut-être que Steph ou > Sigrid seraient plus utiles pour répondre à cette question. > Je comprend.
C'est juste que dans le postAction, Sigrid a utilisé les populations de l'espece au lieu des populations de la simulation. Il y a peut etre une raison, ou alors c'est une erreur.
-- Éric Chatellier <chatellier@codelutin.com <mailto:chatellier@codelutin.**com <chatellier@codelutin.com>>>
Tel: 02.40.50.29.28 http://www.codelutin.com
______________________________**_________________ Isis-fish-devel mailing list Isis-fish-devel@list.isis-**fish.org<Isis-fish-devel@list.isis-fish.org> <mailto:Isis-fish-devel@list.**isis-fish.org<Isis-fish-devel@list.isis-fish.org>
______________________________**_________________ Isis-fish-devel mailing list Isis-fish-devel@list.isis-**fish.org <Isis-fish-devel@list.isis-fish.org> http://list.isis-fish.org/cgi-**bin/mailman/listinfo/isis-**fish-devel<http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-devel>
-- Loïc Gasche Doctorant Unité Ecologie et Modèles pour l'Halieutique (EMH) IFREMER - Centre de Nantes
______________________________**_________________ Isis-fish-devel mailing list Isis-fish-devel@list.isis-**fish.org <Isis-fish-devel@list.isis-fish.org> http://list.isis-fish.org/cgi-**bin/mailman/listinfo/isis-**fish-devel<http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-devel>
Bonjour, hier j'ai refait un essai d'AS avec un TAC et une taille min, mais cette fois en faisant tourner sur toutes les pops et zones (et donc avec un TAC par espèce qui correspond à 7D+7E). Cette fois-ci toutes les simus se sont arrêtées à Décembre 0. Et je m'inquiète un peu car le .log semble indiquer des erreurs dans SiMatrix et DefaultSimulator_F qui correspondent à nos ajouts pour calculer une mortalité par pêche totale... Le 02/05/2012 16:33, Sigrid Lehuta a écrit :
C'est vraiment une question pertinente, surtout dans un contexte de redefinition des structures demographiques des pop (cf le Bar en Manche, le Hareng en Mer du Nord).
De maniere pragmatique, L'objectif du modele est de tester de la gestion donc on se met a l echelle de la gestion. Les especes isis ont un sens pour les metiers et les TAC. Donc si chaque pop a sa zone, son metier et son TAC, je serais d avis de creer 2 especes differentes (comme pour les evaluations de stocks). meme si le sens biologique est perdu. Surtout que je ne crois pas que dans isis, les populations d une meme espece aient des liens privilegies qui ne puissent pas etre crees entre especes (?). Il faudrait chequer ca avec Steph qu'on ne neglige pas un aspect important en faisant ca.
Autre option, creer une autre regle de TAC qui cible la pop au lieu de l espece. mais tu vas devoir interdire un metier qui cible une pop donc le TAC est atteint alors qu il pourrait encore pecher sur le reste de l'espece... et on ne distingue generalement pas les pop dans les debarquements... Bisarre!
Le 2 mai 2012 10:11, Loic GASCHE <Loic.Gasche@ifremer.fr <mailto:Loic.Gasche@ifremer.fr>> a écrit :
Le 02/05/2012 16:01, Sigrid Lehuta a écrit :
hello, je decline toutes responsabilite dans l ecriture de cette regle ;-)
je pense que l esprit etait que, dans la vraie vie, les TAC ciblent une espece (et toutes ses pops) a l echelle d une region et non une pop. Et le cas de Loic est particulier. mais je ne vois pas pourquoi on s interesserait a des pop non simulees, donc il faudrait garder le species (for (Population pop : param_species.getPopulation()) {) mais ajouter un test qui verifie que la pop est simulee.
ca vous parait bien?
Je suis d'accord avec toi sur le fait que c'est bizarre de s'intéresser à des pops non simulées.
Je reviens quand même sur mon autre question: qu'est-ce qui se passe si on simule une grande région qui correspond à plusieurs zones CIEM adjacentes (c'est bien ce qu'on a en Golfe de Gascogne non) ? Il faut faire un seul gros TAC qui s'applique à toutes les pops d'une espèce sans considération de localisation dans une zone CIEM donnée ? Ce serait bizarre...
Le 2 mai 2012 08:04, Eric Chatellier <chatellier@codelutin.com <mailto:chatellier@codelutin.com> <mailto:chatellier@codelutin.__com <mailto:chatellier@codelutin.com>>> a écrit :
Le 02/05/2012 13:40, Loic GASCHE a écrit : > > Heu je ne comprends pas trop la dernière phrase... > > A priori je trouve ça bizarre que la règle TAC prenne toutes les populations > d'une espèce. > > Les TACs sont définis par zone CIEM ou par groupe de zones CIEM. Par exemple, > il y a un TAC pour la sole en 7D et un TAC pour la sole en 7E; mais le TAC de > plie est défini pour les zones 7D et 7E à la fois. > > Comme ça je dirais donc que quand on veut mettre un TAC, il faudrait en même > temps qu'on nous demande à quelles populations il va s'appliquer. Comme ça un > TAC s'applique à un groupe de populations, et c'est à l'utilisateur de faire > correspondre ce groupe de populations à une ou plusieurs zones CIEM. > > Comme ça on peut avoir un modèle ISIS qui représente plusieurs zones CIEM avec > chacune leurs populations et avec un TAC par zone. > > Après ce n'est que la vision que j'en ai avec mon petit modèle que je > n'utilise pas en entier. D'ailleurs le soucis ne se pose peut-être que dans > mon cas particulier: mon modèle représente 2 zones mais je n'en utilise qu'une > dans les simulations car l'autre est appelée à sauter à terme. Mais on peut > supposer qu'un "vrai" modèle ISIS ne contient que les zones auxquelles on > s'intéresse, et donc on travaillerait sur toutes les zones et toutes les pops > (avec toujours la question de comment séparer les pops des différentes zones > si le TAC prend automatiquement toutes les pops). Donc peut-être que Steph ou > Sigrid seraient plus utiles pour répondre à cette question. > Je comprend.
C'est juste que dans le postAction, Sigrid a utilisé les populations de l'espece au lieu des populations de la simulation. Il y a peut etre une raison, ou alors c'est une erreur.
-- Éric Chatellier <chatellier@codelutin.com <mailto:chatellier@codelutin.com> <mailto:chatellier@codelutin.__com <mailto:chatellier@codelutin.com>>>
Tel: 02.40.50.29.28 http://www.codelutin.com
_________________________________________________ Isis-fish-devel mailing list Isis-fish-devel@list.isis-__fish.org <mailto:Isis-fish-devel@list.isis-fish.org> <mailto:Isis-fish-devel@list.__isis-fish.org <mailto:Isis-fish-devel@list.isis-fish.org>> http://list.isis-fish.org/cgi-__bin/mailman/listinfo/isis-__fish-devel <http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-devel>
_________________________________________________ Isis-fish-devel mailing list Isis-fish-devel@list.isis-__fish.org <mailto:Isis-fish-devel@list.isis-fish.org> http://list.isis-fish.org/cgi-__bin/mailman/listinfo/isis-__fish-devel <http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-devel>
-- Loïc Gasche Doctorant Unité Ecologie et Modèles pour l'Halieutique (EMH) IFREMER - Centre de Nantes
_________________________________________________ Isis-fish-devel mailing list Isis-fish-devel@list.isis-__fish.org <mailto:Isis-fish-devel@list.isis-fish.org> http://list.isis-fish.org/cgi-__bin/mailman/listinfo/isis-__fish-devel <http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-devel>
_______________________________________________ Isis-fish-devel mailing list Isis-fish-devel@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-devel
Le 03/05/2012 10:41, Loic GASCHE a écrit :
Bonjour,
hier j'ai refait un essai d'AS avec un TAC et une taille min, mais cette fois en faisant tourner sur toutes les pops et zones (et donc avec un TAC par espèce qui correspond à 7D+7E).
Cette fois-ci toutes les simus se sont arrêtées à Décembre 0.
Et je m'inquiète un peu car le .log semble indiquer des erreurs dans SiMatrix et DefaultSimulator_F qui correspondent à nos ajouts pour calculer une mortalité par pêche totale... SiMatrix.java ligne 1641, tu appelles une méthode sur un objet null.
C'est pas encore une matrice non disponible car résultat non calculé ? -- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
Le 03/05/2012 10:51, Eric Chatellier a écrit :
Le 03/05/2012 10:41, Loic GASCHE a écrit :
Bonjour,
hier j'ai refait un essai d'AS avec un TAC et une taille min, mais cette fois en faisant tourner sur toutes les pops et zones (et donc avec un TAC par espèce qui correspond à 7D+7E).
Cette fois-ci toutes les simus se sont arrêtées à Décembre 0.
Et je m'inquiète un peu car le .log semble indiquer des erreurs dans SiMatrix et DefaultSimulator_F qui correspondent à nos ajouts pour calculer une mortalité par pêche totale... SiMatrix.java ligne 1641, tu appelles une méthode sur un objet null.
C'est pas encore une matrice non disponible car résultat non calculé ?
Il y a ça à la ligne 1641: for (PopulationGroup group : groupesRepresentatifs) { // On ne fait l'analyse que sur les groupes representatifs En fait c'est normal que ça ne marche pas, j'avais rajouté les groupes représentatifs dans SiMatrix pour coller aux méthodes du CIEM, mais uniquement pour la zone 7D... Donc comme il n'y a pas de groupes représentatifs pour al zone 7E on n'est pas près de boucler dessus... J'avais oublié ce détail, c'est vrai que c'est embêtant ces groupes représentatifs dans SiMatrix, mais je ne vois pas comment faire autrement.
participants (3)
-
Eric Chatellier -
Loic GASCHE -
Sigrid Lehuta