Erreur en cours de simulation avec TAC.
Bonjour, Lorsque je fais ma simulation en utilisant la rule TACpoids, j'ai une erreur durant la 4eme année. Je n'arrive pas à l'interpréter, si quelqu'un a déjà rencontré cela :) Merci, Benoit Fin du Debug, le fichier complet fait 11 Mo, donc dispo sur demande.. : INFO [Thread-66] (SubProcessSimulationLauncher.java:267) run - dans un sous processus> INFO [SimThread sim_TEST_WITH_TACS_2010-07-26-14-35] (TACpoids.java:224) aw$original$_AW_$preAction$_AW_$rules_TACpoids - [TAC] Use case 2 INFO [Thread-66] (SubProcessSimulationLauncher.java:267) run - dans un sous processus> INFO [SimThread sim_TEST_WITH_TACS_2010-07-26-14-35] (TACpoids.java:248) aw$original$_AW_$preAction$_AW_$rules_TACpoids - [TAC] il y a des metiers possibles INFO [Thread-66] (SubProcessSimulationLauncher.java:267) run - dans un sous processus> INFO [SimThread sim_TEST_WITH_TACS_2010-07-26-14-35] (TACpoids.java:224) aw$original$_AW_$preAction$_AW_$rules_TACpoids - [TAC] Use case 2 INFO [Thread-66] (SubProcessSimulationLauncher.java:267) run - dans un sous processus> INFO [SimThread sim_TEST_WITH_TACS_2010-07-26-14-35] (TACpoids.java:248) aw$original$_AW_$preAction$_AW_$rules_TACpoids - [TAC] il y a des metiers possibles INFO [Thread-66] (SubProcessSimulationLauncher.java:267) run - dans un sous processus> INFO [SimThread sim_TEST_WITH_TACS_2010-07-26-14-35] (TACpoids.java:224) aw$original$_AW_$preAction$_AW_$rules_TACpoids - [TAC] Use case 2 INFO [Thread-66] (SubProcessSimulationLauncher.java:267) run - dans un sous processus> INFO [SimThread sim_TEST_WITH_TACS_2010-07-26-14-35] (TACpoids.java:248) aw$original$_AW_$preAction$_AW_$rules_TACpoids - [TAC] il y a des metiers possibles INFO [Thread-66] (SubProcessSimulationLauncher.java:267) run - dans un sous processus> INFO [SimThread sim_TEST_WITH_TACS_2010-07-26-14-35] (TACpoids.java:224) aw$original$_AW_$preAction$_AW_$rules_TACpoids - [TAC] Use case 2 INFO [Thread-66] (SubProcessSimulationLauncher.java:267) run - dans un sous processus>ERROR [SimThread sim_TEST_WITH_TACS_2010-07-26-14-35] (InProcessSimulatorLauncher.java:428) localSimulateSameThread - Error during simulation INFO [Thread-66] (SubProcessSimulationLauncher.java:267) run - dans un sous processus>java.util.NoSuchElementException: L'objet passé en argument n'a pas été retrouvé ou la dimension donnée ne convient pas:Gillnet_unspecified_spring in [bottom_otter_trawl_stern_mixed, Danish_Seine_mixed, Gillnet_fixed_demersal, Longline_autres, Longline_cod, Mixed_Traps_crab, Pot_crab]
Bonjour,
INFO [Thread-66] (SubProcessSimulationLauncher.java:267) run - dans un sous processus>java.util.NoSuchElementException: L'objet passé en argument n'a pas été retrouvé ou la dimension donnée ne convient pas:Gillnet_unspecified_spring in [bottom_otter_trawl_stern_mixed, Danish_Seine_mixed, Gillnet_fixed_demersal, Longline_autres, Longline_cod, Mixed_Traps_crab, Pot_crab]
En gros, tu demandes une information ou une opération sur une matrice en utilisant un objet qui n'est pas présent dans la sémantique de la matrice. Dans ton cas il dit que "Gillnet_unspecified_spring" n'est pas dans la liste [bottom_otter_trawl_stern_mixed, Danish_Seine_mixed, Gillnet_fixed_demersal, Longline_autres, Longline_cod, Mixed_Traps_crab, Pot_crab] -- Éric Chatellier
Merci pour la réponse. J'ai pas forcement su cibler le problème mais un de mes modelés de population était pas top (la population "explosait"), en le corrigeant je n'ai plus l'erreur. Par contre avec la règle TACpoids, la première année la règle ne s'applique pas puis elle s'applique mais de façon pas super stricte . Exemple avec un TAC fixé a 300 t pour toute la simu : Annee 1 : 1900 t (idem captures sans TAC) Annee 2 : 400 et qq Annee 3 : 350 et qq Annee 4 : 400 et qq etc Si quelqu'un a une idée du pourquoi.. :) J'ai vu dans les archives que Sigrid disait avoir d'autres scripts pour les TAC ? Merci, Benoit 2010/7/26 Eric Chatellier <chatellier@codelutin.com>
Bonjour,
INFO [Thread-66] (SubProcessSimulationLauncher.java:267) run - dans un sous processus>java.util.NoSuchElementException: L'objet passé en argument n'a pas été retrouvé ou la dimension donnée ne convient pas:Gillnet_unspecified_spring in [bottom_otter_trawl_stern_mixed, Danish_Seine_mixed, Gillnet_fixed_demersal, Longline_autres, Longline_cod, Mixed_Traps_crab, Pot_crab]
En gros, tu demandes une information ou une opération sur une matrice en utilisant un objet qui n'est pas présent dans la sémantique de la matrice.
Dans ton cas il dit que "Gillnet_unspecified_spring" n'est pas dans la liste [bottom_otter_trawl_stern_mixed, Danish_Seine_mixed, Gillnet_fixed_demersal, Longline_autres, Longline_cod, Mixed_Traps_crab, Pot_crab]
-- Éric Chatellier
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
Salut benoit, pas d inquietude c est normal ou presque ! en fait comme le pas de temps est mensuel, si fin mars le tac n est pas atteint mais presque, disons qu il en reste 2kg, ils vont aller pecher en avril, ils font 500kg et c est seulement fin avril qu on va s apercevoir que le tac est dépassé de 498kg ! c est d ailleurs assez proche de la realité en fait, car on ne fait pas revenir les bateaux qui sont en mer parce qu un copain a debarqué le dernier poisson légal ! ;-) pour etre sur que ca s applique il fait regarder l effort des metiers concernés par le tac. si il devient nul en cours d année c est que ca a marché. pour la premiere année c est plus louche, a part si le TAC est atteint au cours du mois de decembre... t as mis quoi comme beginDate ? A+ Benoit Archambault <benarcha@gmail.com> a écrit :
Merci pour la réponse. J'ai pas forcement su cibler le problème mais un de mes modelés de population était pas top (la population "explosait"), en le corrigeant je n'ai plus l'erreur.
Par contre avec la règle TACpoids, la première année la règle ne s'applique pas puis elle s'applique mais de façon pas super stricte . Exemple avec un TAC fixé a 300 t pour toute la simu :
Annee 1 : 1900 t (idem captures sans TAC) Annee 2 : 400 et qq Annee 3 : 350 et qq Annee 4 : 400 et qq etc
Si quelqu'un a une idée du pourquoi.. :)
J'ai vu dans les archives que Sigrid disait avoir d'autres scripts pour les TAC ?
Merci, Benoit
2010/7/26 Eric Chatellier <chatellier@codelutin.com>
Bonjour,
INFO [Thread-66] (SubProcessSimulationLauncher.java:267) run - dans un sous processus>java.util.NoSuchElementException: L'objet passé en argument n'a pas été retrouvé ou la dimension donnée ne convient pas:Gillnet_unspecified_spring in [bottom_otter_trawl_stern_mixed, Danish_Seine_mixed, Gillnet_fixed_demersal, Longline_autres, Longline_cod, Mixed_Traps_crab, Pot_crab]
En gros, tu demandes une information ou une opération sur une matrice en utilisant un objet qui n'est pas présent dans la sémantique de la matrice.
Dans ton cas il dit que "Gillnet_unspecified_spring" n'est pas dans la liste [bottom_otter_trawl_stern_mixed, Danish_Seine_mixed, Gillnet_fixed_demersal, Longline_autres, Longline_cod, Mixed_Traps_crab, Pot_crab]
-- Éric Chatellier
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
Hello Sigrid, Ah ok j'y vois un peu plus clair maintenant. Le souci c'est que une grosse partie de l'effort de pêche est concentré dans un mois sur un engin. Du coup ils vont vraiment exploser le quota et effectivement arreter derriere, "oops, nous avons pêché 1500 % du quota.." Pour les autres années, le quota est atteint avant ou quelque chose du genre. En gros j'ai plusieurs solutions 1) Je peux peut être trafiquer manuellement pour que l'effort ne soit pas aussi fort avec cet engin qui de toute facon ne cible que cette espece ou presque. J'ai calibré le modèle sur une période avec des quotas plus élevés et de toute manière non atteints. Mais pour ma période a simuler le TAC est fixé beaucoup plus bas. 2)J'essaye d'adapter la regle pour qu'elle agisse en "temps reel" mais c'est impossible non ? (pas de temps mensuel) Merci, Benoit 2010/7/28 <Sigrid.Lehuta@ifremer.fr>
Salut benoit, pas d inquietude c est normal ou presque ! en fait comme le pas de temps est mensuel, si fin mars le tac n est pas atteint mais presque, disons qu il en reste 2kg, ils vont aller pecher en avril, ils font 500kg et c est seulement fin avril qu on va s apercevoir que le tac est dépassé de 498kg ! c est d ailleurs assez proche de la realité en fait, car on ne fait pas revenir les bateaux qui sont en mer parce qu un copain a debarqué le dernier poisson légal ! ;-)
pour etre sur que ca s applique il fait regarder l effort des metiers concernés par le tac. si il devient nul en cours d année c est que ca a marché. pour la premiere année c est plus louche, a part si le TAC est atteint au cours du mois de decembre... t as mis quoi comme beginDate ?
A+
Benoit Archambault <benarcha@gmail.com> a écrit :
Merci pour la réponse. J'ai pas forcement su cibler le problème mais un de
mes modelés de population était pas top (la population "explosait"), en le corrigeant je n'ai plus l'erreur.
Par contre avec la règle TACpoids, la première année la règle ne s'applique pas puis elle s'applique mais de façon pas super stricte . Exemple avec un TAC fixé a 300 t pour toute la simu :
Annee 1 : 1900 t (idem captures sans TAC) Annee 2 : 400 et qq Annee 3 : 350 et qq Annee 4 : 400 et qq etc
Si quelqu'un a une idée du pourquoi.. :)
J'ai vu dans les archives que Sigrid disait avoir d'autres scripts pour les TAC ?
Merci, Benoit
2010/7/26 Eric Chatellier <chatellier@codelutin.com>
Bonjour,
INFO [Thread-66] (SubProcessSimulationLauncher.java:267) run - dans un sous processus>java.util.NoSuchElementException: L'objet passé en argument n'a pas été retrouvé ou la dimension donnée ne convient pas:Gillnet_unspecified_spring in [bottom_otter_trawl_stern_mixed, Danish_Seine_mixed, Gillnet_fixed_demersal, Longline_autres, Longline_cod, Mixed_Traps_crab, Pot_crab]
En gros, tu demandes une information ou une opération sur une matrice en utilisant un objet qui n'est pas présent dans la sémantique de la matrice.
Dans ton cas il dit que "Gillnet_unspecified_spring" n'est pas dans la liste [bottom_otter_trawl_stern_mixed, Danish_Seine_mixed, Gillnet_fixed_demersal, Longline_autres, Longline_cod, Mixed_Traps_crab, Pot_crab]
-- Éric Chatellier
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
On Wed, 28 Jul 2010 14:16:14 -0400 Benoit Archambault <benarcha@gmail.com> wrote:
Hello Sigrid,
Ah ok j'y vois un peu plus clair maintenant. Le souci c'est que une grosse partie de l'effort de pêche est concentré dans un mois sur un engin. Du coup ils vont vraiment exploser le quota et effectivement arreter derriere, "oops, nous avons pêché 1500 % du quota.."
Salut, Vu de ma fenêtre d'informaticien (donc vous pouvez rigoler si c'est complètement idiot :D). Je mettrais un delta au quota qui dépendrait de la quantité de poisson peché sur le mois courant. Par exemple: cota 500T peche total 498T Donc pas d'application du TAC. Si on ajoute un delta en fonction de la pêche du mois. Si la pêche est de 300T alors on applique le TAC. Si la pêche n'était que 1T, on applique pas le TAC et on verra au pas de temps suivant. Ce n'est que l'idée, il faut maintenant chercher comment définir le delta :) (j'ai déjà beaucoup trop travaillé, je le laisse en exercice ;)) -- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii
Je suis d'accord avec "l'informaticien" (il te pousse des écailles Benjamin ? ;-) ) un delta ca serait pas mal mais surement insuffisant si l effort est vraiment concentré sur un mois... il semble que le pas de temps n'est pas adapté a cette peche... trafiquer l'effort,c est délicat, demande toi comment tu vas justifier ça dans l'article... éventuellement on peux considérer un règle de comportement de pêche, tu calcule le niveau de biomasse au dessus duquel pour ce mois le tac sera dépassé si on garde l'effort initial et tu fais une regle qui dit si le niveau de biomasse en debut de mois est > a ce seuil alors une partie de l effort est déplacé sur un autre métier. Ca suppose que les pêcheurs ont une bonne vision de ce qu il y a dans l eau... bon courage Benjamin POUSSIN <poussin@codelutin.com> a écrit :
On Wed, 28 Jul 2010 14:16:14 -0400 Benoit Archambault <benarcha@gmail.com> wrote:
Hello Sigrid,
Ah ok j'y vois un peu plus clair maintenant. Le souci c'est que une grosse partie de l'effort de pêche est concentré dans un mois sur un engin. Du coup ils vont vraiment exploser le quota et effectivement arreter derriere, "oops, nous avons pêché 1500 % du quota.."
Salut,
Vu de ma fenêtre d'informaticien (donc vous pouvez rigoler si c'est complètement idiot :D). Je mettrais un delta au quota qui dépendrait de la quantité de poisson peché sur le mois courant.
Par exemple: cota 500T peche total 498T
Donc pas d'application du TAC.
Si on ajoute un delta en fonction de la pêche du mois. Si la pêche est de 300T alors on applique le TAC. Si la pêche n'était que 1T, on applique pas le TAC et on verra au pas de temps suivant.
Ce n'est que l'idée, il faut maintenant chercher comment définir le delta :) (j'ai déjà beaucoup trop travaillé, je le laisse en exercice ;))
-- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii _______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
Salut, Une autre bidouille possible: dans ta règle TAC, tu modifies ce qui s'appelait avant Action après (ça a changé?) te retire tes poissons trop pêchés de tes captures et les remettes dans l'eau plutôt que dans les rejets? C'est pas tout à fait nickel d'un point de vue bio mais ça doit pas changer grand chose non? surtout que les résultats sont sauvegardés après l'action après? Sur ce bonnes vacances!!!!! Le 29/07/2010 09:02, Sigrid.Lehuta@ifremer.fr a écrit :
Je suis d'accord avec "l'informaticien" (il te pousse des écailles Benjamin ? ;-) ) un delta ca serait pas mal mais surement insuffisant si l effort est vraiment concentré sur un mois... il semble que le pas de temps n'est pas adapté a cette peche...
trafiquer l'effort,c est délicat, demande toi comment tu vas justifier ça dans l'article... éventuellement on peux considérer un règle de comportement de pêche, tu calcule le niveau de biomasse au dessus duquel pour ce mois le tac sera dépassé si on garde l'effort initial et tu fais une regle qui dit si le niveau de biomasse en debut de mois est > a ce seuil alors une partie de l effort est déplacé sur un autre métier. Ca suppose que les pêcheurs ont une bonne vision de ce qu il y a dans l eau...
bon courage
Benjamin POUSSIN <poussin@codelutin.com> a écrit :
On Wed, 28 Jul 2010 14:16:14 -0400 Benoit Archambault <benarcha@gmail.com> wrote:
Hello Sigrid,
Ah ok j'y vois un peu plus clair maintenant. Le souci c'est que une grosse partie de l'effort de pêche est concentré dans un mois sur un engin. Du coup ils vont vraiment exploser le quota et effectivement arreter derriere, "oops, nous avons pêché 1500 % du quota.."
Salut,
Vu de ma fenêtre d'informaticien (donc vous pouvez rigoler si c'est complètement idiot :D). Je mettrais un delta au quota qui dépendrait de la quantité de poisson peché sur le mois courant.
Par exemple: cota 500T peche total 498T
Donc pas d'application du TAC.
Si on ajoute un delta en fonction de la pêche du mois. Si la pêche est de 300T alors on applique le TAC. Si la pêche n'était que 1T, on applique pas le TAC et on verra au pas de temps suivant.
Ce n'est que l'idée, il faut maintenant chercher comment définir le delta :) (j'ai déjà beaucoup trop travaillé, je le laisse en exercice ;))
-- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii _______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
Ca me semble pas mal cette idée hilaire, je vais essayer. L'idée du delta est bien aussi, mais je ne suis pas sûr non plus que ceci marcherait ici... C'est vrai que mes pêcheries ont une grosse saisonnalité et du coup un pas de temps mensuel n'est pas assez "réactif". Le crabe par exemple est pêché en grosse quantité en l'espace de deux mois. Je vais me renseigner pour savoir comment les TAC sont suivis dans la réalité. Merci pour vos éclaircissement halieutiques, informatiques, et haliomatique donc... Benoit 2010/7/29 Hilaire <hilaire.drouineau@gmail.com>
Salut, Une autre bidouille possible: dans ta règle TAC, tu modifies ce qui s'appelait avant Action après (ça a changé?) te retire tes poissons trop pêchés de tes captures et les remettes dans l'eau plutôt que dans les rejets? C'est pas tout à fait nickel d'un point de vue bio mais ça doit pas changer grand chose non? surtout que les résultats sont sauvegardés après l'action après? Sur ce bonnes vacances!!!!!
Le 29/07/2010 09:02, Sigrid.Lehuta@ifremer.fr a écrit :
Je suis d'accord avec "l'informaticien" (il te pousse des écailles Benjamin ? ;-) ) un delta ca serait pas mal mais surement insuffisant si l effort est vraiment concentré sur un mois... il semble que le pas de temps n'est pas adapté a cette peche...
trafiquer l'effort,c est délicat, demande toi comment tu vas justifier ça dans l'article... éventuellement on peux considérer un règle de comportement de pêche, tu calcule le niveau de biomasse au dessus duquel pour ce mois le tac sera dépassé si on garde l'effort initial et tu fais une regle qui dit si le niveau de biomasse en debut de mois est > a ce seuil alors une partie de l effort est déplacé sur un autre métier. Ca suppose que les pêcheurs ont une bonne vision de ce qu il y a dans l eau...
bon courage
Benjamin POUSSIN <poussin@codelutin.com> a écrit :
On Wed, 28 Jul 2010 14:16:14 -0400
Benoit Archambault <benarcha@gmail.com> wrote:
Hello Sigrid,
Ah ok j'y vois un peu plus clair maintenant. Le souci c'est que une grosse partie de l'effort de pêche est concentré dans un mois sur un engin. Du coup ils vont vraiment exploser le quota et effectivement arreter derriere, "oops, nous avons pêché 1500 % du quota.."
Salut,
Vu de ma fenêtre d'informaticien (donc vous pouvez rigoler si c'est complètement idiot :D). Je mettrais un delta au quota qui dépendrait de la quantité de poisson peché sur le mois courant.
Par exemple: cota 500T peche total 498T
Donc pas d'application du TAC.
Si on ajoute un delta en fonction de la pêche du mois. Si la pêche est de 300T alors on applique le TAC. Si la pêche n'était que 1T, on applique pas le TAC et on verra au pas de temps suivant.
Ce n'est que l'idée, il faut maintenant chercher comment définir le delta :) (j'ai déjà beaucoup trop travaillé, je le laisse en exercice ;))
-- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii _______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
Comment réinjecter dans la population une partie du TAC péché ? Est-ce une solution possible de : - calculer la proportion de quota dépassé, exemple si on a pris 120% du TAC, prop=0.2 - récupérer la matrice CatchPerStrategyMetPerZonePop - la modifier (sommes) pour avoir juste des valeurs par groupe par zone - multiplier la proportion dépassée par cette nouvelle matrice - rajouter ces abondances aux abondances existante, dans ce cas quel est l'objet auquel il faut ajouter pour que ce soit effectivement pris en compte par la suite ? Si vous avez des idées, ou une solution plus simple, ca peut me faire gagner pas mal de temps je pense :) Merci Benoit 2010/7/29 Hilaire <hilaire.drouineau@gmail.com>
voilà ce que c'est de partir dans des coins où c'est qu'il y a de la glace l'hiver! Youen il a pas ça à Boulogne?
Le 29/07/2010 14:03, Benoit Archambault a écrit :
Ca me semble pas mal cette idée hilaire, je vais essayer. L'idée du delta est bien aussi, mais je ne suis pas sûr non plus que ceci marcherait ici... C'est vrai que mes pêcheries ont une grosse saisonnalité et du coup un pas de temps mensuel n'est pas assez "réactif". Le crabe par exemple est pêché en grosse quantité en l'espace de deux mois. Je vais me renseigner pour savoir comment les TAC sont suivis dans la réalité.
Merci pour vos éclaircissement halieutiques, informatiques, et haliomatique donc...
Benoit
2010/7/29 Hilaire <hilaire.drouineau@gmail.com>
Salut, Une autre bidouille possible: dans ta règle TAC, tu modifies ce qui s'appelait avant Action après (ça a changé?) te retire tes poissons trop pêchés de tes captures et les remettes dans l'eau plutôt que dans les rejets? C'est pas tout à fait nickel d'un point de vue bio mais ça doit pas changer grand chose non? surtout que les résultats sont sauvegardés après l'action après? Sur ce bonnes vacances!!!!!
Le 29/07/2010 09:02, Sigrid.Lehuta@ifremer.fr a écrit :
Je suis d'accord avec "l'informaticien" (il te pousse des écailles Benjamin ? ;-) ) un delta ca serait pas mal mais surement insuffisant si l effort est vraiment concentré sur un mois... il semble que le pas de temps n'est pas adapté a cette peche...
trafiquer l'effort,c est délicat, demande toi comment tu vas justifier ça dans l'article... éventuellement on peux considérer un règle de comportement de pêche, tu calcule le niveau de biomasse au dessus duquel pour ce mois le tac sera dépassé si on garde l'effort initial et tu fais une regle qui dit si le niveau de biomasse en debut de mois est > a ce seuil alors une partie de l effort est déplacé sur un autre métier. Ca suppose que les pêcheurs ont une bonne vision de ce qu il y a dans l eau...
bon courage
Benjamin POUSSIN <poussin@codelutin.com> a écrit :
On Wed, 28 Jul 2010 14:16:14 -0400
Benoit Archambault <benarcha@gmail.com> wrote:
Hello Sigrid,
Ah ok j'y vois un peu plus clair maintenant. Le souci c'est que une grosse partie de l'effort de pêche est concentré dans un mois sur un engin. Du coup ils vont vraiment exploser le quota et effectivement arreter derriere, "oops, nous avons pêché 1500 % du quota.."
Salut,
Vu de ma fenêtre d'informaticien (donc vous pouvez rigoler si c'est complètement idiot :D). Je mettrais un delta au quota qui dépendrait de la quantité de poisson peché sur le mois courant.
Par exemple: cota 500T peche total 498T
Donc pas d'application du TAC.
Si on ajoute un delta en fonction de la pêche du mois. Si la pêche est de 300T alors on applique le TAC. Si la pêche n'était que 1T, on applique pas le TAC et on verra au pas de temps suivant.
Ce n'est que l'idée, il faut maintenant chercher comment définir le delta :) (j'ai déjà beaucoup trop travaillé, je le laisse en exercice ;))
-- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii _______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
_______________________________________________ Isis-fish-users mailing listIsis-fish-users@list.isis-fish.orghttp://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
Petite quesiton, dans une rule, si je veux pouvoir utiliser une variable crée en preAction ou en condition en postAction, il faut faire comment déjà par rapport aux private/public/void etc merci Benoit 2010/7/29 Benoit Archambault <benarcha@gmail.com>
Comment réinjecter dans la population une partie du TAC péché ?
Est-ce une solution possible de :
- calculer la proportion de quota dépassé, exemple si on a pris 120% du TAC, prop=0.2 - récupérer la matrice CatchPerStrategyMetPerZonePop - la modifier (sommes) pour avoir juste des valeurs par groupe par zone - multiplier la proportion dépassée par cette nouvelle matrice - rajouter ces abondances aux abondances existante, dans ce cas quel est l'objet auquel il faut ajouter pour que ce soit effectivement pris en compte par la suite ?
Si vous avez des idées, ou une solution plus simple, ca peut me faire gagner pas mal de temps je pense :)
Merci
Benoit
2010/7/29 Hilaire <hilaire.drouineau@gmail.com>
voilà ce que c'est de partir dans des coins où c'est qu'il y a de la glace l'hiver! Youen il a pas ça à Boulogne?
Le 29/07/2010 14:03, Benoit Archambault a écrit :
Ca me semble pas mal cette idée hilaire, je vais essayer. L'idée du delta est bien aussi, mais je ne suis pas sûr non plus que ceci marcherait ici... C'est vrai que mes pêcheries ont une grosse saisonnalité et du coup un pas de temps mensuel n'est pas assez "réactif". Le crabe par exemple est pêché en grosse quantité en l'espace de deux mois. Je vais me renseigner pour savoir comment les TAC sont suivis dans la réalité.
Merci pour vos éclaircissement halieutiques, informatiques, et haliomatique donc...
Benoit
2010/7/29 Hilaire <hilaire.drouineau@gmail.com>
Salut, Une autre bidouille possible: dans ta règle TAC, tu modifies ce qui s'appelait avant Action après (ça a changé?) te retire tes poissons trop pêchés de tes captures et les remettes dans l'eau plutôt que dans les rejets? C'est pas tout à fait nickel d'un point de vue bio mais ça doit pas changer grand chose non? surtout que les résultats sont sauvegardés après l'action après? Sur ce bonnes vacances!!!!!
Le 29/07/2010 09:02, Sigrid.Lehuta@ifremer.fr a écrit :
Je suis d'accord avec "l'informaticien" (il te pousse des écailles Benjamin ? ;-) ) un delta ca serait pas mal mais surement insuffisant si l effort est vraiment concentré sur un mois... il semble que le pas de temps n'est pas adapté a cette peche...
trafiquer l'effort,c est délicat, demande toi comment tu vas justifier ça dans l'article... éventuellement on peux considérer un règle de comportement de pêche, tu calcule le niveau de biomasse au dessus duquel pour ce mois le tac sera dépassé si on garde l'effort initial et tu fais une regle qui dit si le niveau de biomasse en debut de mois est > a ce seuil alors une partie de l effort est déplacé sur un autre métier. Ca suppose que les pêcheurs ont une bonne vision de ce qu il y a dans l eau...
bon courage
Benjamin POUSSIN <poussin@codelutin.com> a écrit :
On Wed, 28 Jul 2010 14:16:14 -0400
Benoit Archambault <benarcha@gmail.com> wrote:
Hello Sigrid,
Ah ok j'y vois un peu plus clair maintenant. Le souci c'est que une grosse partie de l'effort de pêche est concentré dans un mois sur un engin. Du coup ils vont vraiment exploser le quota et effectivement arreter derriere, "oops, nous avons pêché 1500 % du quota.."
Salut,
Vu de ma fenêtre d'informaticien (donc vous pouvez rigoler si c'est complètement idiot :D). Je mettrais un delta au quota qui dépendrait de la quantité de poisson peché sur le mois courant.
Par exemple: cota 500T peche total 498T
Donc pas d'application du TAC.
Si on ajoute un delta en fonction de la pêche du mois. Si la pêche est de 300T alors on applique le TAC. Si la pêche n'était que 1T, on applique pas le TAC et on verra au pas de temps suivant.
Ce n'est que l'idée, il faut maintenant chercher comment définir le delta :) (j'ai déjà beaucoup trop travaillé, je le laisse en exercice ;))
-- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii _______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
_______________________________________________ Isis-fish-users mailing listIsis-fish-users@list.isis-fish.orghttp://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
Si j'ai bien compris tu déclare la variable en protected... (c est bien ca les "informaticiens"?) pour reinjecté la pop, je pense qu'avec la regle tacPoids, c est deja écrit pour les rejets en post action. Il y a propSurvie, la proportion des rejets qui survie t as qu a mettre 100% ! A+ Benoit Archambault <benarcha@gmail.com> a écrit :
Petite quesiton, dans une rule, si je veux pouvoir utiliser une variable crée en preAction ou en condition en postAction, il faut faire comment déjà par rapport aux private/public/void etc
merci Benoit
2010/7/29 Benoit Archambault <benarcha@gmail.com>
Comment réinjecter dans la population une partie du TAC péché ?
Est-ce une solution possible de :
- calculer la proportion de quota dépassé, exemple si on a pris 120% du TAC, prop=0.2 - récupérer la matrice CatchPerStrategyMetPerZonePop - la modifier (sommes) pour avoir juste des valeurs par groupe par zone - multiplier la proportion dépassée par cette nouvelle matrice - rajouter ces abondances aux abondances existante, dans ce cas quel est l'objet auquel il faut ajouter pour que ce soit effectivement pris en compte par la suite ?
Si vous avez des idées, ou une solution plus simple, ca peut me faire gagner pas mal de temps je pense :)
Merci
Benoit
2010/7/29 Hilaire <hilaire.drouineau@gmail.com>
voilà ce que c'est de partir dans des coins où c'est qu'il y a de la glace l'hiver! Youen il a pas ça à Boulogne?
Le 29/07/2010 14:03, Benoit Archambault a écrit :
Ca me semble pas mal cette idée hilaire, je vais essayer. L'idée du delta est bien aussi, mais je ne suis pas sûr non plus que ceci marcherait ici... C'est vrai que mes pêcheries ont une grosse saisonnalité et du coup un pas de temps mensuel n'est pas assez "réactif". Le crabe par exemple est pêché en grosse quantité en l'espace de deux mois. Je vais me renseigner pour savoir comment les TAC sont suivis dans la réalité.
Merci pour vos éclaircissement halieutiques, informatiques, et haliomatique donc...
Benoit
2010/7/29 Hilaire <hilaire.drouineau@gmail.com>
Salut, Une autre bidouille possible: dans ta règle TAC, tu modifies ce qui s'appelait avant Action après (ça a changé?) te retire tes poissons trop pêchés de tes captures et les remettes dans l'eau plutôt que dans les rejets? C'est pas tout à fait nickel d'un point de vue bio mais ça doit pas changer grand chose non? surtout que les résultats sont sauvegardés après l'action après? Sur ce bonnes vacances!!!!!
Le 29/07/2010 09:02, Sigrid.Lehuta@ifremer.fr a écrit :
Je suis d'accord avec "l'informaticien" (il te pousse des écailles Benjamin ? ;-) ) un delta ca serait pas mal mais surement insuffisant si l effort est vraiment concentré sur un mois... il semble que le pas de temps n'est pas adapté a cette peche...
trafiquer l'effort,c est délicat, demande toi comment tu vas justifier ça dans l'article... éventuellement on peux considérer un règle de comportement de pêche, tu calcule le niveau de biomasse au dessus duquel pour ce mois le tac sera dépassé si on garde l'effort initial et tu fais une regle qui dit si le niveau de biomasse en debut de mois est > a ce seuil alors une partie de l effort est déplacé sur un autre métier. Ca suppose que les pêcheurs ont une bonne vision de ce qu il y a dans l eau...
bon courage
Benjamin POUSSIN <poussin@codelutin.com> a écrit :
On Wed, 28 Jul 2010 14:16:14 -0400
Benoit Archambault <benarcha@gmail.com> wrote:
Hello Sigrid, > > Ah ok j'y vois un peu plus clair maintenant. > Le souci c'est que une grosse partie de l'effort de pêche est > concentré dans > un mois sur un engin. Du coup ils vont vraiment exploser le quota et > effectivement arreter derriere, "oops, nous avons pêché 1500 % du > quota.." >
Salut,
Vu de ma fenêtre d'informaticien (donc vous pouvez rigoler si c'est complètement idiot :D). Je mettrais un delta au quota qui dépendrait de la quantité de poisson peché sur le mois courant.
Par exemple: cota 500T peche total 498T
Donc pas d'application du TAC.
Si on ajoute un delta en fonction de la pêche du mois. Si la pêche est de 300T alors on applique le TAC. Si la pêche n'était que 1T, on applique pas le TAC et on verra au pas de temps suivant.
Ce n'est que l'idée, il faut maintenant chercher comment définir le delta :) (j'ai déjà beaucoup trop travaillé, je le laisse en exercice ;))
-- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii _______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
_______________________________________________ Isis-fish-users mailing listIsis-fish-users@list.isis-fish.orghttp://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
*Coucou* 2010/7/29 <Sigrid.Lehuta@ifremer.fr>
Si j'ai bien compris tu déclare la variable en protected... (c est bien ca les "informaticiens"?)
*Ca n'a pas l'air de fonctionner ? J'ai toujours un "illegal start of expression", ca m'enerve car j'avais deja eu le probleme et trouvé la solution mais je bloque là !*
pour reinjecté la pop, je pense qu'avec la regle tacPoids, c est deja écrit pour les rejets en post action. Il y a propSurvie, la proportion des rejets qui survie t as qu a mettre 100% !
*Merci pour l'info, ca va bien m'aider*
A+
Re-bonjour, j'ai reussi à contourner le souci des variables en en creant des nouvelles, pas super propre mais bon ca marche. Par contre j'ai un nouveau problème: Voila ce que je fais jusqu'a present. L'objectif est de remettre dans la population les captures excédentes par rapport au TAC. 1)Je recupère la matrice des captures, que j'appelle capt, en sommant sur les metiers et les strategies.J'utilise la fonction suivante : * public static MatrixND getTotalCatchinN(SimulationContext context, Species species, Date date) { MatrixND result2=null; for (Population pop : species.getPopulation()) { MatrixND mat = context.getPopulationMonitor().getCatch(pop); mat = mat.sumOverDim(0); // sum over Strategies mat = mat.sumOverDim(1); // sum over metiers result2= mat; } return result2; } }* J'ai verifié avec le log, ca marche et me ressort bien la matrice désirée. A partir de cette matrice, je calcule une nouvelle matrice qui contiendra les captures à transférer dans la population,propATransferer est la proportion de captures non désirées : * MatrixND transfertCapt=capt.mults(propATransferer);* Vérifié aussi, ca me ressort bien les valeurs voulues. Maintenant je veux additionner les effectifs actuels de la population avec cette matrice de transfert : On récupère les effectifs actuels : * PopulationMonitor popMon = context.getPopulationMonitor(); MatrixND eff = popMon.getN(param_pop);* On additionne : *MatrixND effCorriges=eff.add(transfertCapt) ;* Ca fonctionne, mais apres verification les valeurs obtenues sont incohérentes. En fait il semble que si on se refere aux matrices telles qu'on peut les visualiser dans l'interface d'isis. La fonction *getN* retourne les valeurs lues dans le sens vertical. *(zone par zone)* La fonction *getCatch* retourne les valeurs lues dans le sens horizontal *(groupe par groupe)*. L'opération fonctionne car les dimensions restent les mêmes mais évidemment les résultats ne sont pas attendus. Il faudrait reformater une des matrices (la matrice des captures probablement) pour que l'ordre des valeurs collent à ceux des effectifs. Mais je ne sais pas comment faire, surement la parcourir avec iterator etc mais je bloque la dessus et mon planning est assez serré :( Sinon, une fois ce problème dépassé, il faut que je remplace les effectifs dans isis par mes nouveaux effectifs calculés, fonction *setN()* ? Par contre, pour remplacer les captures, je n'ai pas trouvé de fonction, est-ce possible ? Merci,j'espère avoir été clair Benoit 2010/7/31 Benoit Archambault <benarcha@gmail.com>
*Coucou*
2010/7/29 <Sigrid.Lehuta@ifremer.fr>
Si j'ai bien compris tu déclare la variable en protected...
(c est bien ca les "informaticiens"?)
*Ca n'a pas l'air de fonctionner ? J'ai toujours un "illegal start of expression", ca m'enerve car j'avais deja eu le probleme et trouvé la solution mais je bloque là !*
pour reinjecté la pop, je pense qu'avec la regle tacPoids, c est deja écrit pour les rejets en post action. Il y a propSurvie, la proportion des rejets qui survie t as qu a mettre 100% !
*Merci pour l'info, ca va bien m'aider*
A+
Re-re bonjour tout d'abord désolé pour le spam Finalement réussi à calculer la matrice des nouveaux effectifs ainsi que les captures, je n'arrive juste pas à les mettre à jour dans isis. J'ai essayé ceci, eff et capdetailupdate étant respectivement les matrices des nouveux effectifs et des nouvelles captures. Pour la population: popMon.setN(param_pop,eff); Pour les captures : resultmanager.addResult(date,ResultName.MATRIX_CATCH_PER_STRATEGY_MET_PER_ZONE_POP,captdetailupdate); Ca compile mais aucune différence de résultats avec ou sans ces lignes :( Bon ce sera mon dernier message pour aujourd'hui encore désolé ! benoit
Bonjour, Voila le pre-action en PJ, j'ai essayé en l'incluant dans la regle TACpoids. Merci, benoit
Salut Benoit, quel est le probleme ? pour moi tu n as rien a recoder : tu appliques la regle TAC poids avec une survie de 100% et tu t interesses a la matrice de landings = catch - discards pour connaitre les captures. A+ Benoit Archambault <benarcha@gmail.com> a écrit :
Bonjour,
Voila le pre-action en PJ, j'ai essayé en l'incluant dans la regle TACpoids.
Merci, benoit
Salut, Mais pour le premier mois où le TAC est dépassé ca ne change rien non ? Les individus sont quand même capturés et le TAC explosé. J'ai fais le test avec une simulation sur 20 ans, tac à 300 t, survie à 1. Dépassé certaines années à cause de ces captures concentrées sur un mois. En calculant le poids total des débarquements sur la période, j'obtiens la même valeur que le poids total des captures. Après peut être que je me plante quelque part mais je ne vois pas où A+ benoit 2010/8/2 <Sigrid.Lehuta@ifremer.fr>
Salut Benoit, quel est le probleme ? pour moi tu n as rien a recoder : tu appliques la regle TAC poids avec une survie de 100% et tu t interesses a la matrice de landings = catch - discards pour connaitre les captures.
A+
Benoit Archambault <benarcha@gmail.com> a écrit :
Bonjour,
Voila le pre-action en PJ, j'ai essayé en l'incluant dans la regle TACpoids.
Merci, benoit
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
En fait j'ai testé d'autres scénarios et la valeur de propSurvie ne change rien, je n'ai jamais de rejets.. 2010/8/2 Benoit Archambault <benarcha@gmail.com>
Salut,
Mais pour le premier mois où le TAC est dépassé ca ne change rien non ? Les individus sont quand même capturés et le TAC explosé.
J'ai fais le test avec une simulation sur 20 ans, tac à 300 t, survie à 1. Dépassé certaines années à cause de ces captures concentrées sur un mois.
En calculant le poids total des débarquements sur la période, j'obtiens la même valeur que le poids total des captures.
Après peut être que je me plante quelque part mais je ne vois pas où
A+ benoit
2010/8/2 <Sigrid.Lehuta@ifremer.fr>
Salut Benoit,
quel est le probleme ? pour moi tu n as rien a recoder : tu appliques la regle TAC poids avec une survie de 100% et tu t interesses a la matrice de landings = catch - discards pour connaitre les captures.
A+
Benoit Archambault <benarcha@gmail.com> a écrit :
Bonjour,
Voila le pre-action en PJ, j'ai essayé en l'incluant dans la regle TACpoids.
Merci, benoit
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
Désolé de revenir à la charge sur ce sujet mais j'arrive toujours pas à générer des débarquements égaux aux TACS. Toujours ce fameux problème de TACs largement dépassés en l'espace d'un mois. J'aimerais implanter la solution d'Hilaire : remettre les poissons excédant le TAC dans l'eau à la fin du mois et corriger les captures. La solution du delta ne marcherait pas vraiment dans mon cas. J'ai essayé en fixant une survie à 1 dans la règle TACpoids mais ca ne change rien : débarquements = captures. Je commence à désespérer car les dépassement de TACs sont assez énormes et au final conditionnent vraiment mes sorties, plus que les mesures que je veux tester à coté :(. Merci, Benoit 2010/8/2 Benoit Archambault <benarcha@gmail.com>
En fait j'ai testé d'autres scénarios et la valeur de propSurvie ne change rien, je n'ai jamais de rejets..
2010/8/2 Benoit Archambault <benarcha@gmail.com>
Salut,
Mais pour le premier mois où le TAC est dépassé ca ne change rien non ? Les individus sont quand même capturés et le TAC explosé.
J'ai fais le test avec une simulation sur 20 ans, tac à 300 t, survie à 1. Dépassé certaines années à cause de ces captures concentrées sur un mois.
En calculant le poids total des débarquements sur la période, j'obtiens la même valeur que le poids total des captures.
Après peut être que je me plante quelque part mais je ne vois pas où
A+ benoit
2010/8/2 <Sigrid.Lehuta@ifremer.fr>
Salut Benoit,
quel est le probleme ? pour moi tu n as rien a recoder : tu appliques la regle TAC poids avec une survie de 100% et tu t interesses a la matrice de landings = catch - discards pour connaitre les captures.
A+
Benoit Archambault <benarcha@gmail.com> a écrit :
Bonjour,
Voila le pre-action en PJ, j'ai essayé en l'incluant dans la regle TACpoids.
Merci, benoit
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
C'est que la partie discards de la regle TACpoids ne doit pas marcher... faudrait remettre le nez dedans ! il y a en effet des commentaires dans cette regle qui laissent penser qu'elle n est pas opérationnelle... faudrait la corriger... perso j ai vraiment pas le temps... Benoit Archambault <benarcha@gmail.com> a écrit :
Désolé de revenir à la charge sur ce sujet mais j'arrive toujours pas à générer des débarquements égaux aux TACS. Toujours ce fameux problème de TACs largement dépassés en l'espace d'un mois. J'aimerais implanter la solution d'Hilaire : remettre les poissons excédant le TAC dans l'eau à la fin du mois et corriger les captures. La solution du delta ne marcherait pas vraiment dans mon cas.
J'ai essayé en fixant une survie à 1 dans la règle TACpoids mais ca ne change rien : débarquements = captures. Je commence à désespérer car les dépassement de TACs sont assez énormes et au final conditionnent vraiment mes sorties, plus que les mesures que je veux tester à coté :(.
Merci,
Benoit
2010/8/2 Benoit Archambault <benarcha@gmail.com>
En fait j'ai testé d'autres scénarios et la valeur de propSurvie ne change rien, je n'ai jamais de rejets..
2010/8/2 Benoit Archambault <benarcha@gmail.com>
Salut,
Mais pour le premier mois où le TAC est dépassé ca ne change rien non ? Les individus sont quand même capturés et le TAC explosé.
J'ai fais le test avec une simulation sur 20 ans, tac à 300 t, survie à 1. Dépassé certaines années à cause de ces captures concentrées sur un mois.
En calculant le poids total des débarquements sur la période, j'obtiens la même valeur que le poids total des captures.
Après peut être que je me plante quelque part mais je ne vois pas où
A+ benoit
2010/8/2 <Sigrid.Lehuta@ifremer.fr>
Salut Benoit,
quel est le probleme ? pour moi tu n as rien a recoder : tu appliques la regle TAC poids avec une survie de 100% et tu t interesses a la matrice de landings = catch - discards pour connaitre les captures.
A+
Benoit Archambault <benarcha@gmail.com> a écrit :
Bonjour,
Voila le pre-action en PJ, j'ai essayé en l'incluant dans la regle TACpoids.
Merci, benoit
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
Bonjour, Petite question sur le calcul des distances géographiques dans ISIS: Pour calculer les temps de trajets on utilise la vitesse des navires et la distance entre le port et la zone de pêche. Mais comment est calculée cette distance? Est-ce la distance entre la maille du port et la maille la plus proche de la zone de pêche, ou la distance moyenne entre la maille du port et l'ensemble des mailles du port, ou autre? Merci. Bastien
c'est une bonne idee mais je pense qu'il faut faire attention aux inconsistances que cela peut generer avec les hypotheses du modele. si tu realloues de la capture dans la mer, les pecheurs n'ont plus grand chose dans leur panier... est-ce plus realiste? Je penche plus pour un changement de la regle TAC, en utilisant par exemple l'idee du delta comme le proposait Benjamin. Cependant comme le TAC n'est pas atteint (delta!=0), je ne m'en servirais pas dans la condition de la regle mais plutot dans Action Avant pour limiter l'effort sur le metier capturant cette espece ce nouveau mois. L'effort peut etre calculer comme une proportion de l'effort habituel à partir du delta et des captures que tu aurais si tu ne limitais l'effort (cette valeur tu l'as dans les simus qui t'ont mis la puce à l'oreille). steph Benoit Archambault <benarcha@gmail.com> a écrit :
Comment réinjecter dans la population une partie du TAC péché ?
Est-ce une solution possible de :
- calculer la proportion de quota dépassé, exemple si on a pris 120% du TAC, prop=0.2 - récupérer la matrice CatchPerStrategyMetPerZonePop - la modifier (sommes) pour avoir juste des valeurs par groupe par zone - multiplier la proportion dépassée par cette nouvelle matrice - rajouter ces abondances aux abondances existante, dans ce cas quel est l'objet auquel il faut ajouter pour que ce soit effectivement pris en compte par la suite ?
Si vous avez des idées, ou une solution plus simple, ca peut me faire gagner pas mal de temps je pense :)
Merci Benoit
2010/7/29 Hilaire <hilaire.drouineau@gmail.com>
voilà ce que c'est de partir dans des coins où c'est qu'il y a de la glace l'hiver! Youen il a pas ça à Boulogne?
Le 29/07/2010 14:03, Benoit Archambault a écrit :
Ca me semble pas mal cette idée hilaire, je vais essayer. L'idée du delta est bien aussi, mais je ne suis pas sûr non plus que ceci marcherait ici... C'est vrai que mes pêcheries ont une grosse saisonnalité et du coup un pas de temps mensuel n'est pas assez "réactif". Le crabe par exemple est pêché en grosse quantité en l'espace de deux mois. Je vais me renseigner pour savoir comment les TAC sont suivis dans la réalité.
Merci pour vos éclaircissement halieutiques, informatiques, et haliomatique donc...
Benoit
2010/7/29 Hilaire <hilaire.drouineau@gmail.com>
Salut, Une autre bidouille possible: dans ta règle TAC, tu modifies ce qui s'appelait avant Action après (ça a changé?) te retire tes poissons trop pêchés de tes captures et les remettes dans l'eau plutôt que dans les rejets? C'est pas tout à fait nickel d'un point de vue bio mais ça doit pas changer grand chose non? surtout que les résultats sont sauvegardés après l'action après? Sur ce bonnes vacances!!!!!
Le 29/07/2010 09:02, Sigrid.Lehuta@ifremer.fr a écrit :
Je suis d'accord avec "l'informaticien" (il te pousse des écailles Benjamin ? ;-) ) un delta ca serait pas mal mais surement insuffisant si l effort est vraiment concentré sur un mois... il semble que le pas de temps n'est pas adapté a cette peche...
trafiquer l'effort,c est délicat, demande toi comment tu vas justifier ça dans l'article... éventuellement on peux considérer un règle de comportement de pêche, tu calcule le niveau de biomasse au dessus duquel pour ce mois le tac sera dépassé si on garde l'effort initial et tu fais une regle qui dit si le niveau de biomasse en debut de mois est > a ce seuil alors une partie de l effort est déplacé sur un autre métier. Ca suppose que les pêcheurs ont une bonne vision de ce qu il y a dans l eau...
bon courage
Benjamin POUSSIN <poussin@codelutin.com> a écrit :
On Wed, 28 Jul 2010 14:16:14 -0400
Benoit Archambault <benarcha@gmail.com> wrote:
Hello Sigrid,
Ah ok j'y vois un peu plus clair maintenant. Le souci c'est que une grosse partie de l'effort de pêche est concentré dans un mois sur un engin. Du coup ils vont vraiment exploser le quota et effectivement arreter derriere, "oops, nous avons pêché 1500 % du quota.."
Salut,
Vu de ma fenêtre d'informaticien (donc vous pouvez rigoler si c'est complètement idiot :D). Je mettrais un delta au quota qui dépendrait de la quantité de poisson peché sur le mois courant.
Par exemple: cota 500T peche total 498T
Donc pas d'application du TAC.
Si on ajoute un delta en fonction de la pêche du mois. Si la pêche est de 300T alors on applique le TAC. Si la pêche n'était que 1T, on applique pas le TAC et on verra au pas de temps suivant.
Ce n'est que l'idée, il faut maintenant chercher comment définir le delta :) (j'ai déjà beaucoup trop travaillé, je le laisse en exercice ;))
-- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii _______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
_______________________________________________ Isis-fish-users mailing listIsis-fish-users@list.isis-fish.orghttp://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
participants (7)
-
Bastien PREUSS -
Benjamin POUSSIN -
Benoit Archambault -
Eric Chatellier -
Hilaire -
Sigrid.Lehuta＠ifremer.fr -
Stephanie.Mahevas＠ifremer.fr