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

Gestion de la distribution dans les méthodes d'AS
by Eric Chatellier 22 Nov '13

22 Nov '13

Bonjour, J'ai un peu progressé dans la compréhension de l'utilisation de la distribution dans les méthodes d'AS. Il y a plusieurs cas: * soit la méthode prend en paramètres la distribution directement (Fast99) * soit des paramètres de la distribution peuvent être calculé avant par une distribution (Sobol) * soit la méthode gère elle même la distribution, non modifiable (LHS) * soit la distribution ne peut pas être gérée Voici en détail les problèmes rencontrés suivant les méthodes de calcul: Morris ------ Morris prend en paramètres deux vecteurs correspondant aux valeurs min et max de chaque facteur. Si les facteurs n'ont pas été défini en distribution uniforme avec des valeurs min et max, cela pose problème. Sobol ----- Sobol prend en paramètres 2 dataframe qui peuvent être défini manuellement suivant une méthode de distribution. C'est donc théoriquement possible. RandomLHS et OptimumLHS ----------------------- RandomLHS gère elle même une distribution uniforme entre 0 et 1. help(randmonLHS) : An ‘n’ by ‘k’ Latin Hypercube Sample matrix with values uniformly distributed on [0,1] Donc en faisant un produit en croix entre min et max, il est possible d'obtenir la valeur réelle du facteur. Mais dans le cas d'une distribution non uniforme, comment peut-on exploiter la valeur entre 0 et 1 ? ExpandGrid ---------- Pas de gestion de la distribution. RDOpimal -------- Pas de gestion de la distribution. Apparemment Sigrid avait bien aidé Jean sur ce script. RegularFraction --------------- Pas de gestion de la distribution. JavaExpandGrid et FrF2 ---------------------- JavaExpandGrid calcule manuellement les valeurs des facteurs. Donc a moins de refaire le calcul pour toutes les distributions possibles, autant supprimer cette méthode. FrF2 est la même méthode que RegularFraction. Stéphanie, tu aurais un moment pour rediscuter de ca ? -- Éric Chatellier <chatellier(a)codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com

2 6

Gestion de la mémoire du fichier des résultats mappé
by Eric Chatellier 26 Nov '12

26 Nov '12

Bonjour, Suite aux problèmes de mémoires actuels avec le nouveau fichier de stockage des résultats, j'ai rechercher comment était gérée la mémoire pour ce genre de fichier. J'ai trouvé cet article qui en parle: http://blog.ippon.fr/2011/11/03/java-acces-directs-a-la-memoire-off-heap/ Les fichiers mappé semble être stocké hors de la mémoire heap (celle qu'on augmente avec -Xmx), cela explique pourquoi si cette mémoire est trop grande, celle ci se réduit. Il parle également d'autres options pour controler la taille de cette zone: -XX:MaxDirectMemorySize À voir. Pour l'instant, je vais faire quelques tests sans mapper les résultats en mémoire (ca sera surrement plus lent)... -- Éric Chatellier <chatellier(a)codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com

2 3

Petit probleme dans TACPoids
by Benjamin POUSSIN 22 Nov '12

22 Nov '12

Salut, Il me semble qu'il y a un probleme dans tacPoids car on y trouve: """ discard = popMon.getCatch(pop).copy(); // ca ne doit pas pouvoir marcher car MATRIX_DISCARDS_PER_STR_MET est de dimension pop groupe str met - et discard n'a plus la dimension pop discard.setName(ResultName.MATRIX_DISCARDS_PER_STR_MET_PER_ZONE_POP); popMon.addDiscard(step, pop, discard); log.info("[TAC] add discard for " + pop + ": " + discard); // ne manquerait-il pas resultmanager.addResult(step, pop, discard); """ Le problème sont les 2 dernieres lignes. Car pour moi il ne faut pas le faire car on l'a deja dans DefaultSimulator """ MatrixND discard = populationMonitor.getDiscard(step, pop); if (discard != null || step.getStep() == 0) { // force discard for the first month to have discard in result if (discard == null) { discard = MatrixFactory.getInstance().create( ResultName.MATRIX_DISCARDS_PER_STR_MET_PER_ZONE_POP, new List[] { siMatrix.getStrategies(step), siMatrix.getMetiers(step), pop.getPopulationGroup(), pop.getPopulationZone() }, new String[] { n_("Strategies"), n_("Metiers"), n_("Groups"), n_("Zones") }); } resManager.addResult(step, pop, discard); """ Pourquoi avions nous fait ca ? Parce que s'il y a plusieurs regles de gestion qui font du rejet de la meme espece au meme pas de temps on se retrouve avec plus de poisson rejeté que peché :(. Donc en stockant dans populationMonitor, on ne permet l'ajout qu'une seul fois, et lorsqu'on sauve dans DefaultSimulator, on est sur qu'il n'y a pas plus de poisson que prevu. Je pense qu'il faudrait remodifier ce petit probleme, a moins que je ne me trompe ? -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin(a)codelutin.com http://www.codelutin.com

3 2