Impossible de compiler le Script ?
Bonjour, Je tente de lancer une AS, avec un grand nombre de paramètres à tester et beaucoup d'exports (les habituels + des exports par zone) mais peu de simus pour le moment car c'est un test. Les simus s'arrêtent en Janvier 0 et dans le log de simu j'ai ça : ERROR|09:33:53,618|InProcessSimulatorLauncher.java|484|localSimulateSameThread|Error during simulation fr.ifremer.isisfish.simulator.SimulationException: Can't evaluate simulation prescript at fr.ifremer.isisfish.simulator.SimulationPreScriptListener.beforeSimulation(SimulationPreScriptListener.java:90) at fr.ifremer.isisfish.simulator.SimulationContext.fireBeforeSimulation(SimulationContext.java:272) at fr.ifremer.isisfish.simulator.launcher.InProcessSimulatorLauncher.localSimulateSameThread(InProcessSimulatorLauncher.java:435) at fr.ifremer.isisfish.simulator.launcher.InProcessSimulatorLauncher$SimThread.run(InProcessSimulatorLauncher.java:271) Caused by: fr.ifremer.isisfish.IsisFishRuntimeException: Impossible de compiler le script : /export/home1/isis-data/loic/isis-build/as_7DV11_ISIS4311_ttesPop_ttesRegles_exportsZone_2015-01-22-09-33_5/fr.ifremer.isisfish.simulator/SimulationPreScriptGeneratedPreScript.java at fr.ifremer.isisfish.util.EvaluatorHelper.compile(EvaluatorHelper.java:265) at fr.ifremer.isisfish.util.EvaluatorHelper.evaluate(EvaluatorHelper.java:227) at fr.ifremer.isisfish.simulator.SimulationPreScriptListener.beforeSimulation(SimulationPreScriptListener.java:78) ... 3 more Caused by: fr.ifremer.isisfish.IsisFishRuntimeException: Impossible de compiler le script : -1 at fr.ifremer.isisfish.util.EvaluatorHelper.compile(EvaluatorHelper.java:262) ... 5 more Cette AS est basée sur une simu qui tournait sans problème, et cela tournait également quand l'AS était plus simple (moins d'exports et de paramètres à tester). Une idée de la cause du problème ? Loïc
Le 22/01/2015 10:03, Loic GASCHE a écrit :
Bonjour,
Je tente de lancer une AS, avec un grand nombre de paramètres à tester et beaucoup d'exports (les habituels + des exports par zone) mais peu de simus pour le moment car c'est un test. Bonjour,
Tu peux m'envoyer cette simulation, en particulier le fichier 'parameters.properties' pour que je vérifie le script ? Merci. -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
Voilà Le 22/01/2015 10:13, Eric Chatellier a écrit :
Le 22/01/2015 10:03, Loic GASCHE a écrit :
Bonjour,
Je tente de lancer une AS, avec un grand nombre de paramètres à tester et beaucoup d'exports (les habituels + des exports par zone) mais peu de simus pour le moment car c'est un test. Bonjour,
Tu peux m'envoyer cette simulation, en particulier le fichier 'parameters.properties' pour que je vérifie le script ?
Merci.
Le 22/01/2015 10:18, Loic GASCHE a écrit :
Voilà Il y a deux erreur : context.setComputeValue("Plaice_7D_growth.T0_P7D",NaN); context.setComputeValue("Sole_7D_growth.T0_S7D",NaN);
Tu peux vérifier ce que ces deux facteurs ont de special ? À première vue, distribution uniforme pourcentage (reference = -0.83, coefficient : 0.5) -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
Ben à priori ils n'ont rien de spécial. Ca fait partie des 3 paramètres de l'équation de croissance qui sont utilisés pour la sole et la plie (T0, K et Linf). L'AS sur les trois est définie de la même manière et ils sont nommés selon la même convention. La seule différence que j'observe est que pour Linf et K (qui ne posent pas de PB on dirait) on a context.getValueAndCompute("", valeur); alors que pour T0 jai T0 = valeur; Le 22/01/2015 10:35, Eric Chatellier a écrit :
Le 22/01/2015 10:18, Loic GASCHE a écrit :
Voilà Il y a deux erreur : context.setComputeValue("Plaice_7D_growth.T0_P7D",NaN); context.setComputeValue("Sole_7D_growth.T0_S7D",NaN);
Tu peux vérifier ce que ces deux facteurs ont de special ?
À première vue, distribution uniforme pourcentage (reference = -0.83, coefficient : 0.5)
Et l'équation n'a pas changé depuis que je bosse sur cette base, donc on a déjà fait de grosses AS incluant T0 et cela n'avait pas posé de PB. Le 22/01/2015 11:54, Loic GASCHE a écrit :
Ben à priori ils n'ont rien de spécial.
Ca fait partie des 3 paramètres de l'équation de croissance qui sont utilisés pour la sole et la plie (T0, K et Linf). L'AS sur les trois est définie de la même manière et ils sont nommés selon la même convention.
La seule différence que j'observe est que pour Linf et K (qui ne posent pas de PB on dirait) on a context.getValueAndCompute("", valeur); alors que pour T0 jai T0 = valeur;
Le 22/01/2015 10:35, Eric Chatellier a écrit :
Le 22/01/2015 10:18, Loic GASCHE a écrit :
Voilà Il y a deux erreur : context.setComputeValue("Plaice_7D_growth.T0_P7D",NaN); context.setComputeValue("Sole_7D_growth.T0_S7D",NaN);
Tu peux vérifier ce que ces deux facteurs ont de special ?
À première vue, distribution uniforme pourcentage (reference = -0.83, coefficient : 0.5)
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
Le 22/01/2015 11:59, Loic GASCHE a écrit :
Et l'équation n'a pas changé depuis que je bosse sur cette base, donc on a déjà fait de grosses AS incluant T0 et cela n'avait pas posé de PB. C'est un bug dans Isis.
Pour les facteurs uniforme pourcentage, l'appel de la distribution uniforme se fait avec: reference - coefficient reference + coefficient Mais dans ton cas, la référence est négative (-0.83 et coeff = 0.5), ton l'appel se fait avec -0.415 -1.245 mais comme min est supérieur à max, bah R renvoi NaN :( Que dois-je faire dans le cas où une valeur de référence est négative ? Inverser l'appel pour que min soit bien toujours inférieur à max ? Ou dois-je calculer les bornes d'une autre façon ? PS: ticket créé ici : http://forge.codelutin.com/issues/6525 -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
Ca peut poser des problèmes d'inverser l'appel ? Moi tant que ça marche ça me va, mais il faut voir si ça peut poser d'autres soucis... Tu penses à quoi quand tu parles d'une autre façon de calculer les bornes ? Le 22/01/2015 12:28, Eric Chatellier a écrit :
Le 22/01/2015 11:59, Loic GASCHE a écrit :
Et l'équation n'a pas changé depuis que je bosse sur cette base, donc on a déjà fait de grosses AS incluant T0 et cela n'avait pas posé de PB. C'est un bug dans Isis.
Pour les facteurs uniforme pourcentage, l'appel de la distribution uniforme se fait avec: reference - coefficient reference + coefficient
Mais dans ton cas, la référence est négative (-0.83 et coeff = 0.5), ton l'appel se fait avec -0.415 -1.245 mais comme min est supérieur à max, bah R renvoi NaN :(
Que dois-je faire dans le cas où une valeur de référence est négative ? Inverser l'appel pour que min soit bien toujours inférieur à max ? Ou dois-je calculer les bornes d'une autre façon ?
PS: ticket créé ici : http://forge.codelutin.com/issues/6525
En fait après discussion avec Steph il n'y a pas besoin d'inverser l'appel. Il faut travailler sur la valeur absolue de la valeur de référence et pas sur la valeur de référence elle-même. par exemple si T0 = -0.84 avec des bornes de 50% je fais -0.84 -0.5 * |-0.84| et -0.84 +0.5 * |-0.84|, et comme ça mes bornes sont toujours dans le bon sens ! C'est corrigeable rapidement ? Le 22/01/2015 14:38, Loic GASCHE a écrit :
Ca peut poser des problèmes d'inverser l'appel ?
Moi tant que ça marche ça me va, mais il faut voir si ça peut poser d'autres soucis...
Tu penses à quoi quand tu parles d'une autre façon de calculer les bornes ?
Le 22/01/2015 12:28, Eric Chatellier a écrit :
Le 22/01/2015 11:59, Loic GASCHE a écrit :
Et l'équation n'a pas changé depuis que je bosse sur cette base, donc on a déjà fait de grosses AS incluant T0 et cela n'avait pas posé de PB. C'est un bug dans Isis.
Pour les facteurs uniforme pourcentage, l'appel de la distribution uniforme se fait avec: reference - coefficient reference + coefficient
Mais dans ton cas, la référence est négative (-0.83 et coeff = 0.5), ton l'appel se fait avec -0.415 -1.245 mais comme min est supérieur à max, bah R renvoi NaN :(
Que dois-je faire dans le cas où une valeur de référence est négative ? Inverser l'appel pour que min soit bien toujours inférieur à max ? Ou dois-je calculer les bornes d'une autre façon ?
PS: ticket créé ici : http://forge.codelutin.com/issues/6525
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
Le 22/01/2015 15:27, Loic GASCHE a écrit :
En fait après discussion avec Steph il n'y a pas besoin d'inverser l'appel.
Il faut travailler sur la valeur absolue de la valeur de référence et pas sur la valeur de référence elle-même.
par exemple si T0 = -0.84 avec des bornes de 50% je fais -0.84 -0.5 * |-0.84| et -0.84 +0.5 * |-0.84|, et comme ça mes bornes sont toujours dans le bon sens ! Ok.
C'est à ça que je pensais quand je voulais dire "une autre façon de calculer les bornes" . Je préfère une manière de calculer qui fonctionne tous le temps plutot que gérer deux cas.
C'est corrigeable rapidement ?
La seule différence que j'observe est que pour Linf et K (qui ne posent pas de PB on dirait) on a context.getValueAndCompute("", valeur); alors que pour T0 jai T0 = valeur; Si l'equation ne contient pas context.getValueAndCompute(), le facteur ne sera
En fait, on est en attente de réponse pour pouvoir release la branche 4.4. pas utilisé. Si c'est volontaire, le facteur ne sert à rien, sinon il faut valider le facteur pour qu'il rajoute le "context.getValueAndCompute". Si c'est bloquant, je peux corriger ça sur la branche 4.3. -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
Pour le moment ce n'est pas un gros problème car c'est contournable en changeant l'équation de croissance pour que T0 prenne une valeur positive au lieu de négative. Le 22/01/2015 15:36, Eric Chatellier a écrit :
Le 22/01/2015 15:27, Loic GASCHE a écrit :
En fait après discussion avec Steph il n'y a pas besoin d'inverser l'appel.
Il faut travailler sur la valeur absolue de la valeur de référence et pas sur la valeur de référence elle-même.
par exemple si T0 = -0.84 avec des bornes de 50% je fais -0.84 -0.5 * |-0.84| et -0.84 +0.5 * |-0.84|, et comme ça mes bornes sont toujours dans le bon sens ! Ok.
C'est à ça que je pensais quand je voulais dire "une autre façon de calculer les bornes" . Je préfère une manière de calculer qui fonctionne tous le temps plutot que gérer deux cas.
C'est corrigeable rapidement ?
En fait, on est en attente de réponse pour pouvoir release la branche 4.4.
La seule différence que j'observe est que pour Linf et K (qui ne posent pas de PB on dirait) on a context.getValueAndCompute("", valeur); alors que pour T0 jai T0 = valeur; Si l'equation ne contient pas context.getValueAndCompute(), le facteur ne sera pas utilisé. Si c'est volontaire, le facteur ne sert à rien, sinon il faut valider le facteur pour qu'il rajoute le "context.getValueAndCompute".
Si c'est bloquant, je peux corriger ça sur la branche 4.3.
J'ai modifié mon équation et le parameter.properties contient bien une valeur pour T0 au lieu de NaN. Malheureusement mes simus plantent toujours en Janvier 0, et toujours pour un problème d'initialisation. Le 22/01/2015 15:49, Loic GASCHE a écrit :
Pour le moment ce n'est pas un gros problème car c'est contournable en changeant l'équation de croissance pour que T0 prenne une valeur positive au lieu de négative.
Le 22/01/2015 15:36, Eric Chatellier a écrit :
Le 22/01/2015 15:27, Loic GASCHE a écrit :
En fait après discussion avec Steph il n'y a pas besoin d'inverser l'appel.
Il faut travailler sur la valeur absolue de la valeur de référence et pas sur la valeur de référence elle-même.
par exemple si T0 = -0.84 avec des bornes de 50% je fais -0.84 -0.5 * |-0.84| et -0.84 +0.5 * |-0.84|, et comme ça mes bornes sont toujours dans le bon sens ! Ok.
C'est à ça que je pensais quand je voulais dire "une autre façon de calculer les bornes" . Je préfère une manière de calculer qui fonctionne tous le temps plutot que gérer deux cas.
C'est corrigeable rapidement ?
En fait, on est en attente de réponse pour pouvoir release la branche 4.4.
La seule différence que j'observe est que pour Linf et K (qui ne posent pas de PB on dirait) on a context.getValueAndCompute("", valeur); alors que pour T0 jai T0 = valeur; Si l'equation ne contient pas context.getValueAndCompute(), le facteur ne sera pas utilisé. Si c'est volontaire, le facteur ne sert à rien, sinon il faut valider le facteur pour qu'il rajoute le "context.getValueAndCompute".
Si c'est bloquant, je peux corriger ça sur la branche 4.3.
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
-- Loïc Gasche Doctorant Unité Ecologie et Modèles pour l'Halieutique (EMH) IFREMER - Centre de Nantes
Une idée ? Le 22/01/2015 17:31, Loic GASCHE a écrit :
J'ai modifié mon équation et le parameter.properties contient bien une valeur pour T0 au lieu de NaN.
Malheureusement mes simus plantent toujours en Janvier 0, et toujours pour un problème d'initialisation.
Le 22/01/2015 15:49, Loic GASCHE a écrit :
Pour le moment ce n'est pas un gros problème car c'est contournable en changeant l'équation de croissance pour que T0 prenne une valeur positive au lieu de négative.
Le 22/01/2015 15:36, Eric Chatellier a écrit :
Le 22/01/2015 15:27, Loic GASCHE a écrit :
En fait après discussion avec Steph il n'y a pas besoin d'inverser l'appel.
Il faut travailler sur la valeur absolue de la valeur de référence et pas sur la valeur de référence elle-même.
par exemple si T0 = -0.84 avec des bornes de 50% je fais -0.84 -0.5 * |-0.84| et -0.84 +0.5 * |-0.84|, et comme ça mes bornes sont toujours dans le bon sens ! Ok.
C'est à ça que je pensais quand je voulais dire "une autre façon de calculer les bornes" . Je préfère une manière de calculer qui fonctionne tous le temps plutot que gérer deux cas.
C'est corrigeable rapidement ?
En fait, on est en attente de réponse pour pouvoir release la branche 4.4.
La seule différence que j'observe est que pour Linf et K (qui ne posent pas de PB on dirait) on a context.getValueAndCompute("", valeur); alors que pour T0 jai T0 = valeur; Si l'equation ne contient pas context.getValueAndCompute(), le facteur ne sera pas utilisé. Si c'est volontaire, le facteur ne sert à rien, sinon il faut valider le facteur pour qu'il rajoute le "context.getValueAndCompute".
Si c'est bloquant, je peux corriger ça sur la branche 4.3.
_______________________________________________ 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
Le 23/01/2015 10:36, Eric Chatellier a écrit :
Je cherches encore la cause (Elle est beaucoup plus compliquée à corriger). Je l'ai corrigé mais il faut que je release une nouvelle version du coup. Et que je l'installe sur caparmor. Je vais manquer de temps aujourd'hui, mais d'ici lundi, ca devrait être bon.
-- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
Le 23/01/2015 15:30, Eric Chatellier a écrit :
Je l'ai corrigé mais il faut que je release une nouvelle version du coup. Et que je l'installe sur caparmor. Je vais manquer de temps aujourd'hui, mais d'ici lundi, ca devrait être bon. J'ai releasé la version: http://forge.codelutin.com/attachments/download/2791/isis-fish-4.3.1.1-bin.z...
Attention, j'ai corrigé le bug concernant les facteurs avec des valeurs de références négatives, donc si tu avais quelque choses pour contourner cela, il faudra l'annuler. -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
participants (2)
-
Eric Chatellier -
Loic GASCHE