commit 39d7daf5288ee2c4f18dd6f8c62ab53db58d780c Author: Martin Potier Date: Sat Jul 8 17:42:46 2017 +0200 Initial commit diff --git a/README b/README new file mode 100644 index 0000000..05033a8 --- /dev/null +++ b/README @@ -0,0 +1,20 @@ +Dépot git de mon mémoire de thèse. + +La manière la plus simple de compiler le manuscrit passe par `nix-env` (il +faut avoir le gestionnaire de paquet `nix` installé [0]). Cet outil se charge de +récupérer ou construire toutes les dépendances nécessaires à la compilation, +puis de les mettre à disposition dans l'environnement de l'utilisateur. + +Dans le répertoire racine du dépot, entrez: + + $ nix-shell + +puis (à cause du fonctionnement de tex): + + $ buildthesis && buildthesis + +LACL - Université Paris Est Créteil +Financé par le projet ANR SYNBIOTIC +Martin POTIER + +[0] http://nixos.org/nix/ diff --git a/biblio/my.bib b/biblio/my.bib new file mode 100644 index 0000000..c0f79bf --- /dev/null +++ b/biblio/my.bib @@ -0,0 +1,23 @@ +@inproceedings{potier_topological_2013, + title = {Topological computation of activity regions}, + url = {http://doi.acm.org/10.1145/2486092.2486136}, + doi = {10.1145/2486092.2486136}, + booktitle = {{SIGSIM} {Principles} of {Advanced} {Discrete} {Simulation}, {SIGSIM}-{PADS} '13, {Montreal}, {QC}, {Canada}, {May} 19-22, 2013}, + author = {Potier, Martin and Spicher, Antoine and Michel, Olivier}, + year = {2013}, + pages = {337--342} +} + +@inproceedings{potier_computing_2013, + title = {Computing activity in space}, + booktitle = {{AAMAS} Spatial Computing Workshop, {AAMAS}-{SCW} '13, {St Paul}, {Minnesota}, {USA}, {May} 6-10, 2013}, + author = {Potier, Martin and Spicher, Antoine and Michel, Olivier}, + year = {2013}, +} + +@article{pascalie_morphogenetic_2016, + title = {Morphogenetic {Engineering} in {Synthetic} {Biology}}, + journal = {ACS Synthetic Biology}, + author = {Pascalie, Jonathan and Potier, Martin and Kowaliw, Taras and Giavitto, Jean-Louis and Michel, Olivier and Spicher, Antoine and Doursat, René}, + year = {2016} +} diff --git a/biblio/standards.bib b/biblio/standards.bib new file mode 100644 index 0000000..135f723 --- /dev/null +++ b/biblio/standards.bib @@ -0,0 +1,9 @@ +@standard{UML, + author = {OMG}, + institution = {Object Management Group}, + organization = {Object Management Group}, + year = 2015, + title = {{OMG Unified Modeling Language (OMG UML), Version 2.5}}, + url = {http://www.omg.org/spec/UML/2.5} +} + diff --git a/biblio/these2015.bib b/biblio/these2015.bib new file mode 100644 index 0000000..1bc0832 --- /dev/null +++ b/biblio/these2015.bib @@ -0,0 +1,764 @@ + +@article{muzy_refounding_2013, + title = {Refounding of the activity concept? {Towards} a federative paradigm for modeling and simulation}, + volume = {89}, + number = {2}, + journal = {Simulation}, + author = {Muzy, Alexandre and Varenne, Franck and Zeigler, Bernard P and Caux, Jonathan and Coquillard, Patrick and Touraille, Luc and Prunetti, Dominique and Caillou, Philippe and Michel, Olivier and Hill, David RC}, + year = {2013}, + pages = {156--177} +} + +@phdthesis{axen_topological_1998, + address = {Champaign, IL, USA}, + title = {Topological {Analysis} {Using} {Morse} {Theory} and {Auditory} {Display}}, + school = {University of Illinois at Urbana-Champaign}, + author = {Axen, U.}, + year = {1998} +} + +@article{hu_devs-fire:_2011, + title = {{DEVS}-{FIRE}: design and application of formal discrete event wildfire spread and suppression models}, + volume = {88}, + issn = {0037-5497, 1741-3133}, + shorttitle = {{DEVS}-{FIRE}}, + url = {http://sim.sagepub.com/cgi/doi/10.1177/0037549711414592}, + doi = {10.1177/0037549711414592}, + number = {3}, + urldate = {2013-01-29}, + journal = {SIMULATION}, + author = {Hu, X. and Sun, Y. and Ntaimo, L.}, + month = oct, + year = {2011}, + pages = {259--279} +} + +@article{karafyllidis_model_1997, + title = {A model for predicting forest fire spreading using cellular automata}, + volume = {99}, + number = {1}, + journal = {Ecological Modelling}, + author = {Karafyllidis, Ioannis and Thanailakis, Adonios}, + year = {1997}, + pages = {87--97} +} + +@article{filippi_discrete_2010, + title = {Discrete event front-tracking simulation of a physical fire-spread model}, + volume = {86}, + number = {10}, + journal = {Simulation}, + author = {Filippi, Jean-Baptiste and Morandini, Frédéric and Balbi, Jacques Henri and Hill, David RC}, + year = {2010}, + pages = {629--646} +} + +@book{toffoli_cellular_1987, + address = {Cambridge}, + title = {Cellular automata machines: a new environment for modeling}, + publisher = {MIT press}, + author = {Toffoli, Tommaso and Margolus, Norman}, + year = {1987} +} + +@inproceedings{kubera_interaction-oriented_2008, + title = {Interaction-{Oriented} {Agent} {Simulations}: {From} {Theory} to {Implementation}.}, + booktitle = {{ECAI}}, + author = {Kubera, Yoann and Mathieu, Philippe and Picault, Sébastien and {others}}, + year = {2008}, + pages = {383--387} +} + +@book{mamei_field-based_2006, + title = {Field-based coordination for pervasive multiagent systems}, + publisher = {Springer Science \& Business Media}, + author = {Mamei, Marco and Zambonelli, Franco}, + year = {2006} +} + +@incollection{mamei_co-fields:_2003, + title = {Co-fields: {Towards} a unifying approach to the engineering of swarm intelligent systems}, + booktitle = {Engineering {Societies} in the {Agents} {World} {III}}, + publisher = {Springer}, + author = {Mamei, Marco and Zambonelli, Franco and Leonardi, Letizia}, + year = {2003}, + pages = {68--81} +} + +@article{chopard_cellular_1998, + title = {Cellular automata modeling of physical systems}, + journal = {Cellular automata modeling of physical systems}, + author = {Chopard, Bastien and Droz, Michel}, + year = {1998} +} + +@incollection{giavitto_computations_2005, + title = {Computations in space and space in computations}, + booktitle = {Unconventional {Programming} {Paradigms}}, + publisher = {Springer}, + author = {Giavitto, Jean-Louis and Michel, Olivier and Cohen, Julien and Spicher, Antoine}, + year = {2005}, + pages = {137--152} +} + +@inproceedings{muzy_activity_2010, + title = {Activity regions for the specification of discrete event systems}, + booktitle = {Proceedings of the 2010 {Spring} {Simulation} {Multiconference}}, + publisher = {Society for Computer Simulation International}, + author = {Muzy, Alexandre and Touraille, Luc and Vangheluwe, Hans and Michel, Olivier and Traoré, Mamadou Kaba and Hill, David RC}, + year = {2010}, + pages = {136} +} + +@article{shi_activity-based_1999, + title = {Activity-based construction ({ABC}) modeling and simulation method}, + volume = {125}, + number = {5}, + journal = {Journal of construction engineering and management}, + author = {Shi, Jonathan Jingsheng}, + year = {1999}, + pages = {354--360} +} + +@inproceedings{potier_topological_2013, + title = {Topological computation of activity regions}, + url = {http://doi.acm.org/10.1145/2486092.2486136}, + doi = {10.1145/2486092.2486136}, + booktitle = {{SIGSIM} {Principles} of {Advanced} {Discrete} {Simulation}, {SIGSIM}-{PADS} '13, {Montreal}, {QC}, {Canada}, {May} 19-22, 2013}, + author = {Potier, Martin and Spicher, Antoine and Michel, Olivier}, + year = {2013}, + pages = {337--342} +} + +@book{tocher_art_1967, + title = {The {Art} of {Simulation}}, + isbn = {B0007ITI4E}, + publisher = {English Universities Press}, + author = {Tocher, K. D}, + year = {1967} +} + +@phdthesis{louail_comparer_2010, + title = {Comparer les morphogénèses urbaines en {Europe} et aux États-{Unis} par la simulation à base d'agents–{Approches} multi-niveaux et environnements de simulation spatiale}, + school = {Université d'Evry-Val d'Essonne}, + author = {Louail, Thomas}, + year = {2010} +} + +@article{bretagnolle_theory_2006, + title = {From theory to modelling: urban systems as complex systems}, + journal = {Cybergeo: European Journal of Geography}, + author = {Bretagnolle, Anne and Daudé, Eric and Pumain, Denise}, + year = {2006} +} + +@article{karr_whole-cell_2012, + title = {A whole-cell computational model predicts phenotype from genotype}, + volume = {150}, + number = {2}, + journal = {Cell}, + author = {Karr, Jonathan R and Sanghvi, Jayodita C and Macklin, Derek N and Gutschow, Miriam V and Jacobs, Jared M and Bolival, Benjamin and Assad-Garcia, Nacyra and Glass, John I and Covert, Markus W}, + year = {2012}, + pages = {389--401} +} + +@article{lighthill_kinematic_1955, + title = {On kinematic waves. {II}. {A} theory of traffic flow on long crowded roads}, + volume = {229}, + number = {1178}, + journal = {Proceedings of the Royal Society of London. Series A. Mathematical and Physical Sciences}, + author = {Lighthill, Michael J and Whitham, Gerald Beresford}, + year = {1955}, + pages = {317--345} +} + +@article{nagel_cellular_1992, + title = {A cellular automaton model for freeway traffic}, + volume = {2}, + number = {12}, + journal = {Journal de physique I}, + author = {Nagel, Kai and Schreckenberg, Michael}, + year = {1992}, + pages = {2221--2229} +} + +@article{banos_simuler_2008, + title = {Simuler les interactions piétons-automobilistes dans un environnement urbain : une approche à base d’agents}, + copyright = {© Tous droits réservés}, + issn = {1954-4863}, + shorttitle = {Simuler les interactions piétons-automobilistes dans un environnement urbain}, + url = {http://tem.revues.org/1048}, + abstract = {Afin d’explorer le rôle des interactions piétons-automobilistes dans l’avènement des accidents de la circulation en milieu urbain, un modèle à base d’agents - SAMU - a été développé. SAMU permet d’explorer des dynamiques complexes à partir de règles comportementales simples. Les principaux éléments de ce modèle sont exposés et discutés., An agent-based model - SAMU - has been designed, which allows exploring pedestrians-drivers interaction in a virtual urban environment. Complex dynamics are obtained from simple behaviours. The key elements of SAMU are presented and discussed.}, + language = {fr}, + number = {1}, + urldate = {2015-01-05}, + journal = {Territoire en mouvement Revue de géographie et aménagement. Territory in movement Journal of geography and planning}, + author = {Banos, Arnaud and Lassarre, Sylvain}, + month = dec, + year = {2008}, + note = {Afin d’explorer le rôle des interactions piétons-automobilistes dans l’avènement des accidents de la circulation en milieu urbain, un modèle à base d’agents - SAMU - a été développé. SAMU permet d’explorer des dynamiques complexes à partir de règles comportementales simples. Les principaux éléments de ce modèle sont exposés et discutés.}, + keywords = {accidentologie, agent-based simulation, environnement urbain, multi-agents, risque routier, road safety, simulation, urban environment}, + pages = {58--66} +} + +@article{willems_paradigms_1991, + title = {Paradigms and puzzles in the theory of dynamical systems}, + volume = {36}, + number = {3}, + journal = {Automatic Control, IEEE Transactions on}, + author = {Willems, Jan C}, + year = {1991}, + pages = {259--294} +} + +@article{kurtz_relationship_1972, + title = {The relationship between stochastic and deterministic models for chemical reactions}, + volume = {57}, + number = {7}, + journal = {The Journal of Chemical Physics}, + author = {Kurtz, Thomas G}, + year = {1972}, + pages = {2976--2978} +} + +@article{gillespie_exact_1977, + title = {Exact stochastic simulation of coupled chemical reactions}, + volume = {81}, + number = {25}, + journal = {The journal of physical chemistry}, + author = {Gillespie, Daniel T}, + year = {1977}, + pages = {2340--2361} +} + +@book{mainzer_local_2013, + title = {Local {Activity} {Principle}: {The} {Cause} of {Complexity} and {Symmetry} {Breaking}}, + isbn = {978-1-908977-09-0}, + publisher = {Imperial College Press}, + author = {Mainzer, Klaus and Chua, Leon O.}, + year = {2013}, + lccn = {2013427768} +} + +@incollection{abbott_model_1990, + title = {Model {Neurons}: from {Hodgkin}-{Huxley} to {Hopfield}}, + booktitle = {Statistical mechanics of neural networks}, + publisher = {Springer}, + author = {Abbott, LF and Kepler, Thomas B}, + year = {1990}, + pages = {5--18} +} + +@article{burkitt_review_2006, + title = {A review of the integrate-and-fire neuron model: {I}. {Homogeneous} synaptic input}, + volume = {95}, + number = {1}, + journal = {Biological cybernetics}, + author = {Burkitt, Anthony N}, + year = {2006}, + pages = {1--19} +} + +@article{hindmarsh_model_1984, + title = {A model of neuronal bursting using three coupled first order differential equations}, + volume = {221}, + number = {1222}, + journal = {Proceedings of the Royal society of London. Series B. Biological sciences}, + author = {Hindmarsh, JL and Rose, RM}, + year = {1984}, + pages = {87--102} +} + +@article{fitzhugh_impulses_1961, + title = {Impulses and physiological states in theoretical models of nerve membrane}, + volume = {1}, + number = {6}, + journal = {Biophysical journal}, + author = {FitzHugh, Richard}, + year = {1961}, + pages = {445} +} + +@article{stein_improved_1974, + title = {Improved neuronal models for studying neural networks}, + volume = {15}, + number = {1}, + journal = {Kybernetik}, + author = {Stein, RB and Leung, KV and Mangeron, D and Oğuztöreli, MN}, + year = {1974}, + pages = {1--9} +} + +@article{abarbanel_synchronisation_1996, + title = {Synchronisation in neural networks}, + volume = {39}, + number = {4}, + journal = {Physics-Uspekhi}, + author = {Abarbanel, HDI and Rabinovich, Mikhail Izrailevich and Selverston, A and Bazhenov, MV and Huerta, R and Sushchik, MM and Rubchinskii, LL}, + year = {1996}, + pages = {337--362} +} + +@article{golomb_reduction_1993, + title = {Reduction of a channel-based model for a stomatogastric ganglion {LP} neuron}, + volume = {69}, + number = {2}, + journal = {Biological cybernetics}, + author = {Golomb, David and Guckenheimer, John and Gueron, Shay}, + year = {1993}, + pages = {129--137} +} + +@article{morris_voltage_1981, + title = {Voltage oscillations in the barnacle giant muscle fiber.}, + volume = {35}, + number = {1}, + journal = {Biophysical journal}, + author = {Morris, Catherine and Lecar, Harold}, + year = {1981}, + pages = {193} +} + +@article{prusinkiewicz_introduction_2003, + title = {Introduction to {Modeling} with {L}-systems}, + journal = {L-systems and Beyond-SIGGRAPH 2003 Course Notes}, + author = {Prusinkiewicz, Przemyslaw}, + year = {2003}, + pages = {1--26} +} + +@inproceedings{kovalevsky_algorithms_2001, + title = {Algorithms and data structures for computer topology}, + booktitle = {Digital and image geometry}, + publisher = {Springer}, + author = {Kovalevsky, Vladimir}, + year = {2001}, + pages = {38--58} +} + +@incollection{polack_architecture_2005, + title = {An architecture for modelling emergence in {CA}-like systems}, + booktitle = {Advances in {Artificial} {Life}}, + publisher = {Springer}, + author = {Polack, Fiona and Stepney, Susan and Turner, Heather and Welch, Peter and Barnes, Fred}, + year = {2005}, + pages = {433--442} +} + +@phdthesis{louail_comparer_2010-1, + type = {Theses}, + title = {Comparer les morphogénèses urbaines en {Europe} et aux États-{Unis} par la simulation à base d'agents – {Approches} multi-niveaux et environnements de simulation spatiale}, + url = {https://tel.archives-ouvertes.fr/tel-00584495}, + school = {Université d'Evry-Val d'Essonne}, + author = {Louail, Thomas}, + month = dec, + year = {2010}, + keywords = {agent based simulation, city, environnements de simulation, modélisation multi-niveaux, morphogenèses urbaines, multilevel modeling, simulation à base d'agents, simulation environements, urban morphogenesis, ville} +} + +@article{codd_relational_1970, + title = {A relational model of data for large shared data banks}, + volume = {13}, + number = {6}, + journal = {Communications of the ACM}, + author = {Codd, Edgar F}, + year = {1970}, + pages = {377--387} +} + +@techreport{gratie_quantitative_2013, + title = {Quantitative model refinement in four different frameworks, with applications to the heat shock response}, + institution = {Technical Report 1067, TUCS}, + author = {Gratie, Diana-Elena and Iancu, Bogdan and Azimi, Sepinoud and Petre, Ion}, + year = {2013} +} + +@article{grace_integrative_2016, + title = {Integrative modelling reveals mechanisms linking productivity and plant species richness}, + volume = {529}, + number = {7586}, + journal = {Nature}, + author = {Grace, James B and Anderson, T Michael and Seabloom, Eric W and Borer, Elizabeth T and Adler, Peter B and Harpole, W Stanley and Hautier, Yann and Hillebrand, Helmut and Lind, Eric M and Pärtel, Meelis and {others}}, + year = {2016}, + pages = {390--393} +} + +@article{karr_whole-cell_2012-1, + title = {A whole-cell computational model predicts phenotype from genotype}, + volume = {150}, + number = {2}, + journal = {Cell}, + author = {Karr, Jonathan R and Sanghvi, Jayodita C and Macklin, Derek N and Gutschow, Miriam V and Jacobs, Jared M and Bolival, Benjamin and Assad-Garcia, Nacyra and Glass, John I and Covert, Markus W}, + year = {2012}, + pages = {389--401} +} + +@article{mens_taxonomy_2006, + title = {A taxonomy of model transformation}, + volume = {152}, + journal = {Electronic Notes in Theoretical Computer Science}, + author = {Mens, Tom and Van Gorp, Pieter}, + year = {2006}, + pages = {125--142} +} + +@article{adamek_abstract_2004, + title = {Abstract and concrete categories. {The} joy of cats}, + author = {Adámek, Jiří and Herrlich, Horst and Strecker, George E}, + year = {2004} +} + +@incollection{ehresmann_mens:_2012, + address = {Berlin, Heidelberg}, + title = {{MENS}: {From} {Neurons} to {Higher} {Mental} {Processes} up to {Consciousness}}, + isbn = {978-3-642-28111-2}, + url = {http://dx.doi.org/10.1007/978-3-642-28111-2_3}, + booktitle = {Integral {Biomathics}: {Tracing} the {Road} to {Reality}}, + publisher = {Springer Berlin Heidelberg}, + author = {Ehresmann, Andrée C.}, + editor = {Simeonov, L. Plamen and Smith, S. Leslie and Ehresmann, C. Andrée}, + year = {2012}, + pages = {29--30} +} + +@article{jang_specification_2012, + title = {Specification and simulation of synthetic multicelled behaviors}, + volume = {1}, + number = {8}, + journal = {ACS synthetic biology}, + author = {Jang, Seunghee S and Oishi, Kevin T and Egbert, Robert G and Klavins, Eric}, + year = {2012}, + pages = {365--374} +} + +@article{hallatschek_genetic_2007, + title = {Genetic drift at expanding frontiers promotes gene segregation}, + volume = {104}, + number = {50}, + journal = {Proceedings of the National Academy of Sciences}, + author = {Hallatschek, Oskar and Hersen, Pascal and Ramanathan, Sharad and Nelson, David R}, + year = {2007}, + pages = {19926--19930} +} + +@article{mittal_motility_2003, + title = {Motility of {Escherichia} coli cells in clusters formed by chemotactic aggregation}, + volume = {100}, + number = {23}, + journal = {Proceedings of the National Academy of Sciences}, + author = {Mittal, Nikhil and Budrene, Elena O and Brenner, Michael P and van Oudenaarden, Alexander}, + year = {2003}, + pages = {13259--13263} +} + +@misc{thesoundofscience_motions_2010, + title = {Motions of {Swarming} {E} coli {Bacteria}}, + url = {https://www.youtube.com/watch?v=q27Jn3h4kpE&feature=youtube_gdata_player}, + abstract = {A dense group of E. coli swims in the roughly two dimensional space at an air water interface. Their collective motion is significantly different from their motion as single cells. Under these conditions they behave more like an active fluid, hence changing the way that nutrients are shared within the group. Notice the appearance of turbulence-like flow fields. Groups of cells form and swim together, other groups split and join, the average trajectory of a single cell can be quite erratic as shown by the cell labeled in red. + +Video courtesy Matthew Copeland, University of Wisconsin, Madison.}, + urldate = {2015-01-05}, + collaborator = {{thesoundofscience}}, + month = feb, + year = {2010} +} + +@book{toffoli_cellular_1987-1, + title = {Cellular automata machines: a new environment for modeling}, + publisher = {MIT press}, + author = {Toffoli, Tommaso and Margolus, Norman}, + year = {1987} +} + +@article{margolus_physics-like_1984, + title = {Physics-like models of computation}, + volume = {10}, + number = {1}, + journal = {Physica D: Nonlinear Phenomena}, + author = {Margolus, Norman}, + year = {1984}, + pages = {81--95} +} + +@article{morita_computation_1989, + title = {Computation universality of one-dimensional reversible (injective) cellular automata}, + volume = {72}, + number = {6}, + journal = {IEICE TRANSACTIONS (1976-1990)}, + author = {Morita, Kenichi and Harao, Masateru}, + year = {1989}, + pages = {758--762} +} + +@article{kari_reversibility_1994, + title = {Reversibility and surjectivity problems of cellular automata}, + volume = {48}, + number = {1}, + journal = {Journal of Computer and System Sciences}, + author = {Kari, Jarkko}, + year = {1994}, + pages = {149--182} +} + +@phdthesis{michel_representations_1996, + title = {Représentations dynamiques de l'espace dans un langage déclaratif de simulation}, + school = {Université de Paris-Sud, centre d'Orsay}, + author = {Michel, O.}, + month = dec, + year = {1996} +} + +@article{pascalie_morphogenetic_2016, + title = {Morphogenetic {Engineering} in {Synthetic} {Biology}}, + journal = {ACS Synthetic Biology}, + author = {Pascalie, Jonathan and Potier, Martin and Kowaliw, Taras and Giavitto, Jean-Louis and Michel, Olivier and Spicher, Antoine and Doursat, René}, + year = {2016} +} + +@article{blattner_complete_1997, + title = {The complete genome sequence of {Escherichia} coli {K}-12}, + volume = {277}, + number = {5331}, + journal = {Science}, + author = {Blattner, Frederick R and Plunkett, Guy and Bloch, Craig A and Perna, Nicole T and Burland, Valerie and Riley, Monica and Collado-Vides, Julio and Glasner, Jeremy D and Rode, Christopher K and Mayhew, George F and {others}}, + year = {1997}, + pages = {1453--1462} +} + +@article{bremer_modulation_1996, + title = {Modulation of chemical composition and other parameters of the cell by growth rate}, + author = {Bremer, Hans and Dennis, Patrick P.}, + year = {1996}, + file = {[PDF] à partir de researchgate.net:/home/eeva/work/thesis/biblio/zotero/storage/7SUBW2MM/Bremer et Dennis - 1996 - Modulation of chemical composition and other param.pdf:application/pdf} +} + +@article{kubitschek_cell_1990, + title = {Cell volume increase in {Escherichia} coli after shifts to richer media.}, + volume = {172}, + number = {1}, + journal = {Journal of bacteriology}, + author = {Kubitschek, HE}, + year = {1990}, + pages = {94--101} +} + +@article{zaritsky_growth_1982, + title = {Growth and form in bacteria}, + volume = {1}, + journal = {Comments Mol. Cell. Biophys}, + author = {Zaritsky, A and Grover, NB and Naaman, J and Woldringh, CL and Rosenberger, RF}, + year = {1982}, + pages = {237--260} +} + +@article{skarstad_cell_1983, + title = {Cell cycle parameters of slowly growing {Escherichia} coli {B}/r studied by flow cytometry.}, + volume = {154}, + number = {2}, + journal = {Journal of Bacteriology}, + author = {Skarstad, Kirsten and Steen, Harold B and Boye, Erik}, + year = {1983}, + pages = {656--662} +} + +@misc{britanica_online_encyclopedia_bacteria_2016, + title = {Bacteria article}, + url = {http://www.britannica.com/print/article/48203}, + urldate = {2016-01-30}, + author = {Britanica Online Encyclopedia}, + year = {2016} +} + +@article{trueba_changes_1980, + title = {Changes in cell diameter during the division cycle of {Escherichia} coli.}, + volume = {142}, + number = {3}, + journal = {Journal of bacteriology}, + author = {Trueba, Frank J and Woldringh, Conrad L}, + year = {1980}, + pages = {869--878} +} + +@article{diluzio_escherichia_2005, + title = {Escherichia coli swim on the right-hand side}, + volume = {435}, + issn = {0028-0836}, + url = {http://dx.doi.org/10.1038/nature03660}, + doi = {10.1038/nature03660}, + number = {7046}, + journal = {Nature}, + author = {DiLuzio, Willow R. and Turner, Linda and Mayer, Michael and Garstecki, Piotr and Weibel, Douglas B. and Berg, Howard C. and Whitesides, George M.}, + year = {2005}, + pages = {1271--1274} +} + +@article{berg_chemotaxis_1972, + title = {Chemotaxis in {Escherichia} coli analysed by three-dimensional tracking}, + volume = {239}, + number = {5374}, + journal = {Nature}, + author = {Berg, Howard C and Brown, Douglas A and {others}}, + year = {1972}, + pages = {500--504} +} + +@article{bourgoin_spoc:_2012, + title = {{SPOC}: {GPGPU} programming through stream processing with {OCaml}}, + volume = {22}, + number = {02}, + journal = {Parallel Processing Letters}, + author = {Bourgoin, Mathias and Chailloux, Emmanuel and Lamotte, Jean-Luc}, + year = {2012}, + pages = {1240007} +} + +@incollection{medvedev_multi-particle_2010, + title = {Multi-particle cellular-automata models for diffusion simulation}, + booktitle = {Methods and tools of parallel programming multicomputers}, + publisher = {Springer}, + author = {Medvedev, Yu}, + year = {2010}, + pages = {204--211} +} + +@article{bray_chemotactic_2007, + title = {The chemotactic behavior of computer-based surrogate bacteria}, + volume = {17}, + number = {1}, + journal = {Current biology}, + author = {Bray, Dennis and Levin, Matthew D and Lipkow, Karen}, + year = {2007}, + pages = {12--19} +} + +@article{goeddel_expression_1979, + title = {Expression in {Escherichia} coli of chemically synthesized genes for human insulin}, + volume = {76}, + number = {1}, + journal = {Proceedings of the National Academy of Sciences}, + author = {Goeddel, David V and Kleid, Dennis G and Bolivar, Francisco and Heyneker, Herbert L and Yansura, Daniel G and Crea, Roberto and Hirose, Tadaaki and Kraszewski, Adam and Itakura, Keiichi and Riggs, Arthur D}, + year = {1979}, + pages = {106--110} +} + +@article{darnton_torque_2007, + title = {On torque and tumbling in swimming {Escherichia} coli}, + volume = {189}, + url = {http://jb.asm.org/content/189/5/1756.short}, + number = {5}, + urldate = {2016-02-05}, + journal = {Journal of bacteriology}, + author = {Darnton, Nicholas C. and Turner, Linda and Rojevsky, Svetlana and Berg, Howard C.}, + year = {2007}, + pages = {1756--1764}, + file = {[HTML] à partir de asm.org:/home/eeva/work/thesis/biblio/zotero/storage/CGEI8NH7/1756.html:text/html;Snapshot:/home/eeva/work/thesis/biblio/zotero/storage/JK49X6HH/1756.html:text/html} +} + +@article{turner_real-time_2000, + title = {Real-{Time} {Imaging} of {Fluorescent} {Flagellar} {Filaments}}, + volume = {182}, + issn = {0021-9193, 1098-5530}, + url = {http://jb.asm.org/content/182/10/2793}, + doi = {10.1128/JB.182.10.2793-2801.2000}, + abstract = {Bacteria swim by rotating flagellar filaments that are several micrometers long, but only about 20 nm in diameter. The filaments can exist in different polymorphic forms, having distinct values of curvature and twist. Rotation rates are on the order of 100 Hz. In the past, the motion of individual filaments has been visualized by dark-field or differential-interference-contrast microscopy, methods hampered by intense scattering from the cell body or shallow depth of field, respectively. We have found a simple procedure for fluorescently labeling cells and filaments that allows recording their motion in real time with an inexpensive video camera and an ordinary fluorescence microscope with mercury-arc or strobed laser illumination. We report our initial findings with cells of Escherichia coli. Tumbles (events that enable swimming cells to alter course) are remarkably varied. Not every filament on a cell needs to change its direction of rotation: different filaments can change directions at different times, and a tumble can result from the change in direction of only one. Polymorphic transformations tend to occur in the sequence normal, semicoiled, curly 1, with changes in the direction of movement of the cell body correlated with transformations to the semicoiled form.}, + language = {en}, + number = {10}, + urldate = {2016-02-05}, + journal = {Journal of Bacteriology}, + author = {Turner, Linda and Ryu, William S. and Berg, Howard C.}, + month = may, + year = {2000}, + pmid = {10781548}, + pages = {2793--2801}, + file = {Full Text PDF:/home/eeva/work/thesis/biblio/zotero/storage/MQ5R6TIB/Turner et al. - 2000 - Real-Time Imaging of Fluorescent Flagellar Filamen.pdf:application/pdf;Snapshot:/home/eeva/work/thesis/biblio/zotero/storage/NA5FUS4J/2793.html:text/html} +} + +@article{sourjik_receptor_2004, + title = {Receptor clustering and signal processing in {E}. coli chemotaxis}, + volume = {12}, + url = {http://www.sciencedirect.com/science/article/pii/S0966842X04002343}, + number = {12}, + urldate = {2016-02-06}, + journal = {Trends in microbiology}, + author = {Sourjik, Victor}, + year = {2004}, + pages = {569--576}, + file = {[PDF] à partir de psu.edu:/home/eeva/work/thesis/biblio/zotero/storage/PEM88DQE/Sourjik - 2004 - Receptor clustering and signal processing in E. co.pdf:application/pdf;Snapshot:/home/eeva/work/thesis/biblio/zotero/storage/K65JZAUM/S0966-842X(04)00234-3.html:text/html} +} + +@article{shimizu_spatially_2003, + title = {A {Spatially} {Extended} {Stochastic} {Model} of the {Bacterial} {Chemotaxis} {Signalling} {Pathway}}, + volume = {329}, + issn = {00222836}, + url = {http://linkinghub.elsevier.com/retrieve/pii/S0022283603004376}, + doi = {10.1016/S0022-2836(03)00437-6}, + language = {en}, + number = {2}, + urldate = {2016-02-06}, + journal = {Journal of Molecular Biology}, + author = {Shimizu, Thomas S. and Aksenov, Sergej V. and Bray, Dennis}, + month = may, + year = {2003}, + pages = {291--309} +} + +@article{mello_quantitative_2003, + title = {Quantitative modeling of sensitivity in bacterial chemotaxis: {The} role of coupling among different chemoreceptor species}, + volume = {100}, + issn = {0027-8424, 1091-6490}, + shorttitle = {Quantitative modeling of sensitivity in bacterial chemotaxis}, + url = {http://www.pnas.org/content/100/14/8223}, + doi = {10.1073/pnas.1330839100}, + abstract = {We propose a general theoretical framework for modeling receptor sensitivity in bacterial chemotaxis, taking into account receptor interactions, including those among different receptor species. We show that our model can quantitatively explain the recent in vivo measurements of receptor sensitivity at different ligand concentrations for both mutant and wild-type strains. For mutant strains, our model can fit the experimental data exactly. For the wild-type cell, our model is capable of achieving high gain while having modest values of Hill coefficient for the response curves. Furthermore, the high sensitivity of the wild-type cell in our model is maintained for a wide range of ambient ligand concentrations, facilitated by near-perfect adaptation and dependence of ligand binding on receptor activity. Our study reveals the importance of coupling among different chemoreceptor species, in particular strong interactions between the aspartate (Tar) and serine (Tsr) receptors, which is crucial in explaining both the mutant and wild-type data. Predictions for the sensitivity of other mutant strains and possible improvements of our model for the wild-type cell are also discussed.}, + language = {en}, + number = {14}, + urldate = {2016-02-06}, + journal = {Proceedings of the National Academy of Sciences}, + author = {Mello, Bernardo A. and Tu, Yuhai}, + month = jul, + year = {2003}, + pmid = {12826616}, + pages = {8223--8228}, + file = {Full Text PDF:/home/eeva/work/thesis/biblio/zotero/storage/SNG3NCZX/Mello et Tu - 2003 - Quantitative modeling of sensitivity in bacterial .pdf:application/pdf;Snapshot:/home/eeva/work/thesis/biblio/zotero/storage/PIGH9TS7/8223.html:text/html} +} + +@article{stewart_aging_2005, + title = {Aging and {Death} in an {Organism} {That} {Reproduces} by {Morphologically} {Symmetric} {Division}}, + volume = {3}, + url = {http://dx.doi.org/10.1371/journal.pbio.0030045}, + doi = {10.1371/journal.pbio.0030045}, + abstract = {Detailed time lapse photography reveals that organisms that divide symmetrically, such as the bacterium E. coli, can indeed age and consequently that no organism is immune to mortality.}, + number = {2}, + urldate = {2016-02-07}, + journal = {PLoS Biol}, + author = {Stewart, Eric J and Madden, Richard and Paul, Gregory and Taddei, François}, + month = feb, + year = {2005}, + pages = {e45}, + file = {PLoS Full Text PDF:/home/eeva/work/thesis/biblio/zotero/storage/IP932H39/Stewart et al. - 2005 - Aging and Death in an Organism That Reproduces by .pdf:application/pdf} +} + +@incollection{hoekstra_complex_2010, + title = {Complex automata: multi-scale modeling with coupled cellular automata}, + booktitle = {Simulating complex systems by cellular automata}, + publisher = {Springer}, + author = {Hoekstra, Alfons G and Caiazzo, Alfonso and Lorenz, Eric and Falcone, Jean-Luc and Chopard, Bastien}, + year = {2010}, + pages = {29--57} +} + +@article{bray_javascript_2014, + title = {The javascript object notation (json) data interchange format}, + author = {Bray, Tim}, + year = {2014} +} + +@article{dilao_validation_1998, + title = {Validation and calibration of models for reaction–diffusion systems}, + volume = {8}, + number = {06}, + journal = {International Journal of Bifurcation and Chaos}, + author = {Dilão, Rui and Sainhas, Joaquim}, + year = {1998}, + pages = {1163--1182} +} \ No newline at end of file diff --git a/biblio/these2016.bib b/biblio/these2016.bib new file mode 100644 index 0000000..4edb2db --- /dev/null +++ b/biblio/these2016.bib @@ -0,0 +1,1379 @@ + +@article{muzy_refounding_2013, + title = {Refounding of the activity concept? {Towards} a federative paradigm for modeling and simulation}, + volume = {89}, + number = {2}, + journal = {Simulation}, + author = {Muzy, Alexandre and Varenne, Franck and Zeigler, Bernard P and Caux, Jonathan and Coquillard, Patrick and Touraille, Luc and Prunetti, Dominique and Caillou, Philippe and Michel, Olivier and Hill, David RC}, + year = {2013}, + pages = {156--177} +} + +@phdthesis{axen_topological_1998, + address = {Champaign, IL, USA}, + title = {Topological {Analysis} {Using} {Morse} {Theory} and {Auditory} {Display}}, + school = {University of Illinois at Urbana-Champaign}, + author = {Axen, Ulrike}, + year = {1998} +} + +@article{hu_devs-fire:_2011, + title = {{DEVS}-{FIRE}: design and application of formal discrete event wildfire spread and suppression models}, + volume = {88}, + issn = {0037-5497, 1741-3133}, + shorttitle = {{DEVS}-{FIRE}}, + url = {http://sim.sagepub.com/cgi/doi/10.1177/0037549711414592}, + doi = {10.1177/0037549711414592}, + number = {3}, + urldate = {2013-01-29}, + journal = {SIMULATION}, + author = {Hu, X. and Sun, Y. and Ntaimo, L.}, + month = oct, + year = {2011}, + pages = {259--279} +} + +@article{karafyllidis_model_1997, + title = {A model for predicting forest fire spreading using cellular automata}, + volume = {99}, + number = {1}, + journal = {Ecological Modelling}, + author = {Karafyllidis, Ioannis and Thanailakis, Adonios}, + year = {1997}, + pages = {87--97} +} + +@article{filippi_discrete_2010, + title = {Discrete event front-tracking simulation of a physical fire-spread model}, + volume = {86}, + number = {10}, + journal = {Simulation}, + author = {Filippi, Jean-Baptiste and Morandini, Frédéric and Balbi, Jacques Henri and Hill, David RC}, + year = {2010}, + pages = {629--646} +} + +@book{toffoli_cellular_1987, + address = {Cambridge}, + title = {Cellular automata machines: a new environment for modeling}, + publisher = {MIT press}, + author = {Toffoli, Tommaso and Margolus, Norman}, + year = {1987} +} + +@inproceedings{kubera_interaction-oriented_2008, + title = {Interaction-{Oriented} {Agent} {Simulations}: {From} {Theory} to {Implementation}.}, + booktitle = {{ECAI}}, + author = {Kubera, Yoann and Mathieu, Philippe and Picault, Sébastien and {others}}, + year = {2008}, + pages = {383--387} +} + +@book{mamei_field-based_2006, + title = {Field-based coordination for pervasive multiagent systems}, + publisher = {Springer Science \& Business Media}, + author = {Mamei, Marco and Zambonelli, Franco}, + year = {2006} +} + +@incollection{mamei_co-fields:_2003, + title = {Co-fields: {Towards} a unifying approach to the engineering of swarm intelligent systems}, + booktitle = {Engineering {Societies} in the {Agents} {World} {III}}, + publisher = {Springer}, + author = {Mamei, Marco and Zambonelli, Franco and Leonardi, Letizia}, + year = {2003}, + pages = {68--81} +} + +@article{chopard_cellular_1998, + title = {Cellular automata modeling of physical systems}, + journal = {Cellular automata modeling of physical systems}, + author = {Chopard, Bastien and Droz, Michel}, + year = {1998} +} + +@incollection{giavitto_computations_2005, + title = {Computations in space and space in computations}, + booktitle = {Unconventional {Programming} {Paradigms}}, + publisher = {Springer}, + author = {Giavitto, Jean-Louis and Michel, Olivier and Cohen, Julien and Spicher, Antoine}, + year = {2005}, + pages = {137--152} +} + +@inproceedings{muzy_activity_2010, + title = {Activity regions for the specification of discrete event systems}, + booktitle = {Proceedings of the 2010 {Spring} {Simulation} {Multiconference}}, + publisher = {Society for Computer Simulation International}, + author = {Muzy, Alexandre and Touraille, Luc and Vangheluwe, Hans and Michel, Olivier and Traoré, Mamadou Kaba and Hill, David RC}, + year = {2010}, + pages = {136} +} + +@article{shi_activity-based_1999, + title = {Activity-based construction ({ABC}) modeling and simulation method}, + volume = {125}, + number = {5}, + journal = {Journal of construction engineering and management}, + author = {Shi, Jonathan Jingsheng}, + year = {1999}, + pages = {354--360} +} + +@inproceedings{potier_topological_2013, + address = {Montreal, Québec, Canada}, + title = {Topological computation of activity regions}, + url = {http://doi.acm.org/10.1145/2486092.2486136}, + doi = {10.1145/2486092.2486136}, + booktitle = {{SIGSIM} {Principles} of {Advanced} {Discrete} {Simulation}}, + author = {Potier, Martin and Spicher, Antoine and Michel, Olivier}, + month = may, + year = {2013}, + pages = {337--342} +} + +@book{tocher_art_1967, + title = {The {Art} of {Simulation}}, + isbn = {B0007ITI4E}, + publisher = {English Universities Press}, + author = {Tocher, K. D}, + year = {1967} +} + +@phdthesis{spicher_transformation_2006, + title = {Transformation de collections topologiques de dimension arbitraire: application à la modélisation de systèmes dynamiques}, + school = {Evry-Val d'Essonne}, + author = {Spicher, Antoine}, + year = {2006} +} + +@incollection{giavitto_group-based_1996, + title = {Group-based fields}, + booktitle = {Parallel {Symbolic} {Languages} and {Systems}}, + publisher = {Springer Berlin Heidelberg}, + author = {Giavitto, Jean-Louis and Michel, Olivier and Sansonnet, Jean-Paul}, + year = {1996}, + pages = {209--214} +} + +@inproceedings{spicher_topological_2004, + series = {{LNCS}}, + title = {A topological framework for the specification and the simulation of discrete dynamical systems}, + volume = {3305}, + booktitle = {Sixth {International} conference on {Cellular} {Automata} for {Research} and {Industry} ({ACRI}'04)}, + publisher = {Springer}, + author = {Spicher, Antoine and Michel, Olivier and Giavitto, Jean-Louis}, + year = {2004}, + pages = {238--247} +} + +@incollection{giavitto_data_2002, + address = {Berlin, Heidelberg}, + title = {Data {Structure} as {Topological} {Spaces}}, + isbn = {978-3-540-45833-3}, + url = {http://dx.doi.org/10.1007/3-540-45833-6_12}, + booktitle = {Unconventional {Models} of {Computation}: {Third} {International} {Conference}, {UMC} 2002 {Kobe}, {Japan}, {October} 15–19, 2002 {Proceedings}}, + publisher = {Springer Berlin Heidelberg}, + author = {Giavitto, Jean-Louis and Michel, Olivier}, + year = {2002}, + pages = {137--150} +} + +@article{spicher_reactive_2009, + title = {From {Reactive} {Multi}-{Agent} models to {Cellular} {Automata} - {Illustration} on a {Diffusion}-{Limited} {Aggregation} model}, + journal = {Proceedings of ICAART'09}, + author = {Spicher, Antoine and Fatès, Nazim A and Simonin, Olivier and {others}}, + year = {2009} +} + +@article{witten_diffusion-limited_1981, + title = {Diffusion-{Limited} {Aggregation}, a {Kinetic} {Critical} {Phenomenon}}, + volume = {47}, + doi = {10.1103/PhysRevLett.47.1400}, + number = {19}, + journal = {Phys. Rev. Lett.}, + author = {Witten, T. A. and Sander, L. M.}, + month = nov, + year = {1981}, + pages = {1400--1403} +} + +@article{hoekstra_towards_2007, + title = {Towards a {Complex} {Automata} formalism for multi-scale modeling}, + volume = {5}, + number = {6}, + journal = {Int. J. Mult. Comp. Eng}, + author = {Hoekstra, Alfons G and Lorenz, Eric and Falcone, Jean-Luc and Chopard, Bastien}, + year = {2007}, + pages = {491} +} + +@article{berger_adaptive_1984, + title = {Adaptive mesh refinement for hyperbolic partial differential equations}, + volume = {53}, + number = {3}, + journal = {Journal of computational Physics}, + author = {Berger, Marsha J and Oliger, Joseph}, + year = {1984}, + pages = {484--512} +} + +@inproceedings{bardley_difficulties_1993, + title = {Difficulties in the simulation of wildfires}, + booktitle = {Proceedings of the 1993 {Simulation} {Multiconference} on the {International} {Emergency} {Management} and {Engineering} {Conference}}, + author = {Bardley, J.H. and Clymer, A.B.}, + year = {1993}, + pages = {161--171} +} + +@article{delemont_application_2007, + title = {Application of computational fluid dynamics modelling in the process of forensic fire investigation: {Problems} and solutions}, + volume = {167}, + number = {2}, + journal = {Forensic science international}, + author = {Delémont, O and Martin, J-C}, + year = {2007}, + pages = {127--135} +} + +@article{tieszen_fluid_2001, + title = {On the {Fluid} {Mechanics} of {Fires}}, + volume = {33}, + doi = {10.1146/annurev.fluid.33.1.67}, + journal = {Annual Review of Fluid Mechanics}, + author = {Tieszen, S. R.}, + year = {2001}, + pages = {67--92} +} + +@inproceedings{beer_australian_1989, + address = {Canberra, Australia}, + title = {The {Australian} {National} bushfire model}, + booktitle = {Proceedings of 8th {Biennial} {Conference} and {Bushfire} {Dynamics} {Workshop}}, + author = {Beer, T.}, + year = {1989}, + pages = {568--572} +} + +@article{hirabayashi_fire-spread_1988, + title = {Fire-spread simulation using an extended dynamic percolation process model}, + volume = {89}, + journal = {NEC research and development}, + author = {Hirabayashi, F. and Kasahara, Y.}, + year = {1988}, + pages = {111--122} +} + +@article{wagner_single-pulse_2004, + title = {From single-pulse to full-waveform airborne laser scanners: potential and practical challenges}, + volume = {35}, + number = {B3}, + journal = {International Archives of Photogrammetry and Remote Sensing}, + author = {Wagner, W. and Ullrich, A. and Melzer, T. and Briese, C. and Kraus, K.}, + year = {2004}, + pages = {201--206} +} + +@article{ivanilova_set_1985, + title = {Set probability identification in forest fire simulation}, + volume = {12, Part 2}, + issn = {0066-4138}, + doi = {10.1016/0066-4138(85)90357-X}, + number = {0}, + journal = {Annual Review in Automatic Programming}, + author = {Ivanilova, T. N.}, + year = {1985}, + keywords = {model divergence}, + pages = {185 -- 188} +} + +@article{ntaimo_devs-fire:_2008, + title = {{DEVS}-{FIRE}: {Towards} an {Integrated} {Simulation} {Environment} for {Surface} {Wildfire} {Spread} and {Containment}}, + volume = {84}, + doi = {10.1177/0037549708094047}, + number = {4}, + journal = {SIMULATION}, + author = {Ntaimo, Lewis and Hu, Xiaolin and Sun, Yi}, + year = {2008}, + pages = {137--155} +} + +@inproceedings{good_challenges_1989, + address = {Canberra, Australia}, + title = {The challenges of modeling natural area ecosystems}, + booktitle = {Proceedings of 8th {Biennial} {Conference} and {Bushfire} {Dynamics} {Workshop}}, + author = {Good, RB and McRae, RHD}, + year = {1989}, + pages = {475--484} +} + +@inproceedings{potier_computing_2013, + address = {Saint-Paul, Minesotta, USA}, + title = {Computing {Activity} in {Space}}, + booktitle = {Spatial {Computing} {Workshop} 2013}, + author = {Potier, Martin and Spicher, Antoine and Michel, Olivier}, + year = {2013} +} + +@phdthesis{louail_comparer_2010, + title = {Comparer les morphogénèses urbaines en {Europe} et aux États-{Unis} par la simulation à base d'agents–{Approches} multi-niveaux et environnements de simulation spatiale}, + school = {Université d'Evry-Val d'Essonne}, + author = {Louail, Thomas}, + year = {2010} +} + +@article{bretagnolle_theory_2006, + title = {From theory to modelling: urban systems as complex systems}, + journal = {Cybergeo: European Journal of Geography}, + author = {Bretagnolle, Anne and Daudé, Eric and Pumain, Denise}, + year = {2006} +} + +@article{karr_whole-cell_2012, + title = {A whole-cell computational model predicts phenotype from genotype}, + volume = {150}, + number = {2}, + journal = {Cell}, + author = {Karr, Jonathan R and Sanghvi, Jayodita C and Macklin, Derek N and Gutschow, Miriam V and Jacobs, Jared M and Bolival, Benjamin and Assad-Garcia, Nacyra and Glass, John I and Covert, Markus W}, + year = {2012}, + pages = {389--401} +} + +@article{yip_spatial_1996, + title = {Spatial {Aggregation}: {Theory} and {Applications}}, + volume = {cs.AI/9608103}, + url = {http://arxiv.org/abs/cs.AI/9608103}, + journal = {CoRR}, + author = {Yip, Kenneth and Zhao, Feng}, + year = {1996} +} + +@article{wilensky_netlogo_1997, + title = {Netlogo ants model}, + journal = {Netlogo model library, Center for Connected Learning and Computer-Based Modeling, Northwestern University, Evanston, IL. URL http://ccl. northwestern. edu/netlogo/models/Ants}, + author = {Wilensky, Uri}, + year = {1997} +} + +@article{gardner_mathematical_1970, + title = {Mathematical games: {The} fantastic combinations of {John} {Conway}’s new solitaire game “life”}, + volume = {223}, + number = {4}, + journal = {Scientific American}, + author = {Gardner, Martin}, + year = {1970}, + pages = {120--123} +} + +@article{reynolds_flocks_1987, + title = {Flocks, herds and schools: {A} distributed behavioral model}, + volume = {21}, + number = {4}, + journal = {ACM SIGGRAPH computer graphics}, + author = {Reynolds, Craig W}, + year = {1987}, + pages = {25--34} +} + +@book{bishop_mechatronics_2002, + title = {The mechatronics handbook}, + volume = {1}, + publisher = {CRC press Boca Raton}, + author = {Bishop, Robert H and {others}}, + year = {2002} +} + +@article{lighthill_kinematic_1955, + title = {On kinematic waves. {II}. {A} theory of traffic flow on long crowded roads}, + volume = {229}, + number = {1178}, + journal = {Proceedings of the Royal Society of London. Series A. Mathematical and Physical Sciences}, + author = {Lighthill, Michael J and Whitham, Gerald Beresford}, + year = {1955}, + pages = {317--345} +} + +@article{nagel_cellular_1992, + title = {A cellular automaton model for freeway traffic}, + volume = {2}, + number = {12}, + journal = {Journal de physique I}, + author = {Nagel, Kai and Schreckenberg, Michael}, + year = {1992}, + pages = {2221--2229} +} + +@article{banos_simuler_2008, + title = {Simuler les interactions piétons-automobilistes dans un environnement urbain : une approche à base d’agents}, + copyright = {© Tous droits réservés}, + issn = {1954-4863}, + shorttitle = {Simuler les interactions piétons-automobilistes dans un environnement urbain}, + url = {http://tem.revues.org/1048}, + abstract = {Afin d’explorer le rôle des interactions piétons-automobilistes dans l’avènement des accidents de la circulation en milieu urbain, un modèle à base d’agents - SAMU - a été développé. SAMU permet d’explorer des dynamiques complexes à partir de règles comportementales simples. Les principaux éléments de ce modèle sont exposés et discutés., An agent-based model - SAMU - has been designed, which allows exploring pedestrians-drivers interaction in a virtual urban environment. Complex dynamics are obtained from simple behaviours. The key elements of SAMU are presented and discussed.}, + language = {fr}, + number = {1}, + urldate = {2015-01-05}, + journal = {Territoire en mouvement Revue de géographie et aménagement. Territory in movement Journal of geography and planning}, + author = {Banos, Arnaud and Lassarre, Sylvain}, + month = dec, + year = {2008}, + note = {Afin d’explorer le rôle des interactions piétons-automobilistes dans l’avènement des accidents de la circulation en milieu urbain, un modèle à base d’agents - SAMU - a été développé. SAMU permet d’explorer des dynamiques complexes à partir de règles comportementales simples. Les principaux éléments de ce modèle sont exposés et discutés.}, + keywords = {accidentologie, agent-based simulation, environnement urbain, multi-agents, risque routier, road safety, simulation, urban environment}, + pages = {58--66} +} + +@article{willems_paradigms_1991, + title = {Paradigms and puzzles in the theory of dynamical systems}, + volume = {36}, + number = {3}, + journal = {Automatic Control, IEEE Transactions on}, + author = {Willems, Jan C}, + year = {1991}, + pages = {259--294} +} + +@article{kurtz_relationship_1972, + title = {The relationship between stochastic and deterministic models for chemical reactions}, + volume = {57}, + number = {7}, + journal = {The Journal of Chemical Physics}, + author = {Kurtz, Thomas G}, + year = {1972}, + pages = {2976--2978} +} + +@article{gillespie_exact_1977, + title = {Exact stochastic simulation of coupled chemical reactions}, + volume = {81}, + number = {25}, + journal = {The journal of physical chemistry}, + author = {Gillespie, Daniel T}, + year = {1977}, + pages = {2340--2361} +} + +@book{mainzer_local_2013, + title = {Local {Activity} {Principle}: {The} {Cause} of {Complexity} and {Symmetry} {Breaking}}, + isbn = {978-1-908977-09-0}, + publisher = {Imperial College Press}, + author = {Mainzer, Klaus and Chua, Leon O.}, + year = {2013}, + lccn = {2013427768} +} + +@incollection{abbott_model_1990, + title = {Model {Neurons}: from {Hodgkin}-{Huxley} to {Hopfield}}, + booktitle = {Statistical mechanics of neural networks}, + publisher = {Springer}, + author = {Abbott, LF and Kepler, Thomas B}, + year = {1990}, + pages = {5--18} +} + +@article{burkitt_review_2006, + title = {A review of the integrate-and-fire neuron model: {I}. {Homogeneous} synaptic input}, + volume = {95}, + number = {1}, + journal = {Biological cybernetics}, + author = {Burkitt, Anthony N}, + year = {2006}, + pages = {1--19} +} + +@article{hindmarsh_model_1984, + title = {A model of neuronal bursting using three coupled first order differential equations}, + volume = {221}, + number = {1222}, + journal = {Proceedings of the Royal society of London. Series B. Biological sciences}, + author = {Hindmarsh, JL and Rose, RM}, + year = {1984}, + pages = {87--102} +} + +@article{fitzhugh_impulses_1961, + title = {Impulses and physiological states in theoretical models of nerve membrane}, + volume = {1}, + number = {6}, + journal = {Biophysical journal}, + author = {FitzHugh, Richard}, + year = {1961}, + pages = {445} +} + +@article{stein_improved_1974, + title = {Improved neuronal models for studying neural networks}, + volume = {15}, + number = {1}, + journal = {Kybernetik}, + author = {Stein, RB and Leung, KV and Mangeron, D and Oğuztöreli, MN}, + year = {1974}, + pages = {1--9} +} + +@article{abarbanel_synchronisation_1996, + title = {Synchronisation in neural networks}, + volume = {39}, + number = {4}, + journal = {Physics-Uspekhi}, + author = {Abarbanel, HDI and Rabinovich, Mikhail Izrailevich and Selverston, A and Bazhenov, MV and Huerta, R and Sushchik, MM and Rubchinskii, LL}, + year = {1996}, + pages = {337--362} +} + +@article{golomb_reduction_1993, + title = {Reduction of a channel-based model for a stomatogastric ganglion {LP} neuron}, + volume = {69}, + number = {2}, + journal = {Biological cybernetics}, + author = {Golomb, David and Guckenheimer, John and Gueron, Shay}, + year = {1993}, + pages = {129--137} +} + +@article{morris_voltage_1981, + title = {Voltage oscillations in the barnacle giant muscle fiber.}, + volume = {35}, + number = {1}, + journal = {Biophysical journal}, + author = {Morris, Catherine and Lecar, Harold}, + year = {1981}, + pages = {193} +} + +@article{prusinkiewicz_introduction_2003, + title = {Introduction to {Modeling} with {L}-systems}, + journal = {L-systems and Beyond-SIGGRAPH 2003 Course Notes}, + author = {Prusinkiewicz, Przemyslaw}, + year = {2003}, + pages = {1--26} +} + +@inproceedings{kovalevsky_algorithms_2001, + title = {Algorithms and data structures for computer topology}, + booktitle = {Digital and image geometry}, + publisher = {Springer}, + author = {Kovalevsky, Vladimir}, + year = {2001}, + pages = {38--58} +} + +@incollection{polack_architecture_2005, + title = {An architecture for modelling emergence in {CA}-like systems}, + booktitle = {Advances in {Artificial} {Life}}, + publisher = {Springer}, + author = {Polack, Fiona and Stepney, Susan and Turner, Heather and Welch, Peter and Barnes, Fred}, + year = {2005}, + pages = {433--442} +} + +@phdthesis{louail_comparer_2010-1, + type = {Theses}, + title = {Comparer les morphogénèses urbaines en {Europe} et aux États-{Unis} par la simulation à base d'agents – {Approches} multi-niveaux et environnements de simulation spatiale}, + url = {https://tel.archives-ouvertes.fr/tel-00584495}, + school = {Université d'Evry-Val d'Essonne}, + author = {Louail, Thomas}, + month = dec, + year = {2010}, + keywords = {agent based simulation, city, environnements de simulation, modélisation multi-niveaux, morphogenèses urbaines, multilevel modeling, simulation à base d'agents, simulation environements, urban morphogenesis, ville} +} + +@article{codd_relational_1970, + title = {A relational model of data for large shared data banks}, + volume = {13}, + number = {6}, + journal = {Communications of the ACM}, + author = {Codd, Edgar F}, + year = {1970}, + pages = {377--387} +} + +@techreport{gratie_quantitative_2013, + title = {Quantitative model refinement in four different frameworks, with applications to the heat shock response}, + institution = {Technical Report 1067, TUCS}, + author = {Gratie, Diana-Elena and Iancu, Bogdan and Azimi, Sepinoud and Petre, Ion}, + year = {2013} +} + +@article{grace_integrative_2016, + title = {Integrative modelling reveals mechanisms linking productivity and plant species richness}, + volume = {529}, + number = {7586}, + journal = {Nature}, + author = {Grace, James B and Anderson, T Michael and Seabloom, Eric W and Borer, Elizabeth T and Adler, Peter B and Harpole, W Stanley and Hautier, Yann and Hillebrand, Helmut and Lind, Eric M and Pärtel, Meelis and {others}}, + year = {2016}, + pages = {390--393} +} + +@article{karr_whole-cell_2012-1, + title = {A whole-cell computational model predicts phenotype from genotype}, + volume = {150}, + number = {2}, + journal = {Cell}, + author = {Karr, Jonathan R and Sanghvi, Jayodita C and Macklin, Derek N and Gutschow, Miriam V and Jacobs, Jared M and Bolival, Benjamin and Assad-Garcia, Nacyra and Glass, John I and Covert, Markus W}, + year = {2012}, + pages = {389--401} +} + +@article{mens_taxonomy_2006, + title = {A taxonomy of model transformation}, + volume = {152}, + journal = {Electronic Notes in Theoretical Computer Science}, + author = {Mens, Tom and Van Gorp, Pieter}, + year = {2006}, + pages = {125--142} +} + +@article{adamek_abstract_2004, + title = {Abstract and concrete categories. {The} joy of cats}, + author = {Adámek, Jiří and Herrlich, Horst and Strecker, George E}, + year = {2004} +} + +@incollection{ehresmann_mens:_2012, + address = {Berlin, Heidelberg}, + title = {{MENS}: {From} {Neurons} to {Higher} {Mental} {Processes} up to {Consciousness}}, + isbn = {978-3-642-28111-2}, + url = {http://dx.doi.org/10.1007/978-3-642-28111-2_3}, + booktitle = {Integral {Biomathics}: {Tracing} the {Road} to {Reality}}, + publisher = {Springer Berlin Heidelberg}, + author = {Ehresmann, Andrée C.}, + editor = {Simeonov, L. Plamen and Smith, S. Leslie and Ehresmann, C. Andrée}, + year = {2012}, + pages = {29--30} +} + +@article{chua_cnn:_1997, + title = {{CNN}: {A} {Vision} of {Complexity}}, + volume = {07}, + url = {http://www.worldscientific.com/doi/abs/10.1142/S0218127497001618}, + doi = {10.1142/S0218127497001618}, + number = {10}, + journal = {International Journal of Bifurcation and Chaos}, + author = {Chua, Leon O.}, + year = {1997}, + pages = {2219--2425} +} + +@article{polack_emergent_2005, + title = {Emergent properties do not refine}, + volume = {137}, + number = {2}, + journal = {Electronic Notes in Theoretical Computer Science}, + author = {Polack, Fiona and Stepney, Susan}, + year = {2005}, + pages = {163--181} +} + +@article{tomita_e-cell:_1999, + title = {E-{CELL}: software environment for whole-cell simulation.}, + volume = {15}, + url = {+ http://dx.doi.org/10.1093/bioinformatics/15.1.72}, + doi = {10.1093/bioinformatics/15.1.72}, + number = {1}, + journal = {Bioinformatics}, + author = {Tomita, M and Hashimoto, K and Takahashi, K and Shimizu, T S and Matsuzaki, Y and Miyoshi, F and Saito, K and Tanida, S and Yugi, K and Venter, J C and Hutchison, 3rd, C A}, + year = {1999}, + pages = {72} +} + +@article{macklin_future_2014, + title = {The {Future} of {Whole}-{Cell} {Modeling}}, + volume = {28}, + issn = {0958-1669}, + url = {http://www.ncbi.nlm.nih.gov/pmc/articles/PMC4111988/}, + doi = {10.1016/j.copbio.2014.01.012}, + abstract = {Integrated whole-cell modeling is poised to make a dramatic impact on molecular and systems biology, bioengineering, and medicine — once certain obstacles are overcome. From our group’s experience building a whole-cell model of Mycoplasma genitalium, we identified several significant challenges to building models of more complex cells. Here we review and discuss these challenges in seven areas: (1) experimental interrogation, (2) data curation, (3) model building and integration, (4) accelerated computation, (5) analysis and visualization, (6) model validation, and (7) collaboration and community development. Surmounting these challenges will require the cooperation of an interdisciplinary group of researchers to create increasingly sophisticated whole-cell models and make data, models, and simulations more accessible to the wider community.}, + journal = {Current opinion in biotechnology}, + author = {Macklin, Derek N and Ruggero, Nicholas A and Covert, Markus W}, + month = aug, + year = {2014}, + pages = {111--115} +} + +@article{pumain_simpop:_1995, + title = {{SIMPOP}: a multi-agents model for urban transition}, + journal = {Recent development in spatial information modelling and processing. Budapest, Geomarket}, + author = {Pumain, D and Sanders, L and Mathian, H and Guerin-Pace, F and Bura, S}, + year = {1995}, + pages = {71--85} +} + +@article{taentzer_model_2005, + title = {Model transformation by graph transformation: {A} comparative study}, + author = {Taentzer, Gabriele and Ehrig, Karsten and Guerra, Esther and Lara, Juan de and Lengyel, Laszlo and Levendovszky, Tihamer and Prange, Ulrike and Varró, Dániel and Varró-Gyapay, Szilvia}, + year = {2005} +} + +@book{kleppe_mda_2003, + title = {{MDA} explained: the model driven architecture: practice and promise}, + publisher = {Addison-Wesley Professional}, + author = {Kleppe, Anneke G and Warmer, Jos B and Bast, Wim}, + year = {2003} +} + +@article{ferret_bateau_1996, + title = {Le bateau de {Thésée}}, + journal = {Le problème de l’identité à travers le temps, Paris, Éditions de Minuit}, + author = {Ferret, Stéphane}, + year = {1996} +} + +@book{rozenberg_mathematical_1980, + title = {The mathematical theory of {L} systems}, + volume = {90}, + publisher = {Academic press}, + author = {Rozenberg, Grzegorz and Salomaa, Arto}, + year = {1980} +} + +@book{prusinkiewicz_algorithmic_2012, + title = {The algorithmic beauty of plants}, + publisher = {Springer Science \& Business Media}, + author = {Prusinkiewicz, Przemyslaw and Lindenmayer, Aristid}, + year = {2012} +} + +@inproceedings{stepney_more_1998, + title = {More {Powerful} {Z} {Data} {Refinement}: pushing the state of the art in industrial refinement}, + author = {Stepney, Susan and Cooper, David and Woodcock, Jim}, + year = {1998}, + pages = {284--307} +} + +@book{bowen_z_1998, + series = {{LNCS}}, + title = {The {Z} {Formal} {Specification} {Notation}, 11th {International} {Conference} of {Z} {Users}, {Berlin}, {Germany}, {September} 1998}, + volume = {1493}, + publisher = {Springer}, + editor = {Bowen, Jonathan P. and Fett, Andreas and Hinchey, Michael G.}, + year = {1998} +} + +@book{ricard_vie_1858, + address = {Paris}, + title = {La vie des hommes illustres}, + volume = {1}, + url = {https://books.google.fr/books?id=0JzreqURriYC&pg=PA48&hl=fr&source=gbs_toc_r&cad=4#v=onepage}, + language = {fr}, + publisher = {Firmin Didiot Frères}, + author = {Ricard, Dominique}, + year = {1858} +} + +@article{giunti_dynamical_2012, + title = {Dynamical systems on monoids: {Toward} a general theory of deterministic systems and motion}, + journal = {Methods, models, simulations and approaches towards a general theory of change}, + author = {Giunti, Marco and Mazzola, Claudio}, + year = {2012}, + pages = {173--185} +} + +@article{de_koster_discrete_1987, + title = {Discrete and continuous models for heterocyst differentiation in growing filaments of blue-green bacteria}, + volume = {36}, + number = {4}, + journal = {Acta Biotheoretica}, + author = {De Koster, Chris G and Lindenmayer, Aristid}, + year = {1987}, + pages = {249--273} +} + +@article{peterson_ecological_1997, + title = {Ecological studies of wolves on {Isle} {Royale}}, + volume = {98}, + journal = {Annual Report}, + author = {Peterson, Rolf O and Vucetich, John A}, + year = {1997} +} + +@book{odum_fundamentals_1959, + title = {Fundamentals of {Ecology}.[{By}] {EP} {Odum}... in {Collaboration} with {Howard} {T}. {Odum}...}, + publisher = {Philadelphia \& London}, + author = {Odum, Eugene Pleasants and Odum, Howard Thomas}, + year = {1959} +} + +@article{lotka_analytical_1920, + title = {Analytical note on certain rhythmic relations in organic systems}, + volume = {6}, + number = {7}, + journal = {Proceedings of the National Academy of Sciences}, + author = {Lotka, Alfred J}, + year = {1920}, + pages = {410--415} +} + +@article{volterra_fluctuations_1926, + title = {Fluctuations in the abundance of a species considered mathematically}, + volume = {118}, + number = {2972}, + journal = {Nature}, + author = {Volterra, Vito}, + year = {1926}, + pages = {558--560} +} + +@article{lotka_elements_1925, + title = {Elements of physical biology}, + author = {Lotka, Alfred J}, + year = {1925} +} + +@article{mckane_predator-prey_2005, + title = {Predator-prey cycles from resonant amplification of demographic stochasticity}, + volume = {94}, + number = {21}, + journal = {Physical review letters}, + author = {McKane, Alan J and Newman, Timothy J}, + year = {2005}, + pages = {218102} +} + +@article{lugo_quasicycles_2008, + title = {Quasicycles in a spatial predator-prey model}, + volume = {78}, + number = {5}, + journal = {Physical Review E}, + author = {Lugo, Carlos A and McKane, Alan J}, + year = {2008}, + pages = {051911} +} + +@inproceedings{banos_coupling_2015, + title = {Coupling micro and macro dynamics models on networks: {Application} to disease spread}, + booktitle = {International {Workshop} on {Multi}-{Agent} {Systems} and {Agent}-{Based} {Simulation}}, + publisher = {Springer}, + author = {Banos, Arnaud and Corson, Nathalie and Gaudou, Benoit and Laperrière, Vincent and Coyrehourcq, Sébastien Rey}, + year = {2015}, + pages = {19--33} +} + +@article{church_set_1932, + title = {A set of postulates for the foundation of logic}, + journal = {Annals of mathematics}, + author = {Church, Alonzo}, + year = {1932}, + pages = {346--366} +} + +@article{turing_computable_1937, + title = {On computable numbers, with an application to the {Entscheidungsproblem}}, + volume = {2}, + number = {1}, + journal = {Proceedings of the London mathematical society}, + author = {Turing, Alan Mathison}, + year = {1937}, + pages = {230--265} +} + +@article{chomsky_three_1956, + title = {Three models for the description of language}, + volume = {2}, + number = {3}, + journal = {IRE Transactions on information theory}, + author = {Chomsky, Noam}, + year = {1956}, + pages = {113--124} +} + +@article{travers_small_1967, + title = {The small world problem}, + volume = {1}, + journal = {Phychology Today}, + author = {Travers, Jeffrey and Milgram, Stanley}, + year = {1967}, + pages = {61--67} +} + +@article{jang_specification_2012, + title = {Specification and simulation of synthetic multicelled behaviors}, + volume = {1}, + number = {8}, + journal = {ACS synthetic biology}, + author = {Jang, Seunghee S and Oishi, Kevin T and Egbert, Robert G and Klavins, Eric}, + year = {2012}, + pages = {365--374} +} + +@article{hallatschek_genetic_2007, + title = {Genetic drift at expanding frontiers promotes gene segregation}, + volume = {104}, + number = {50}, + journal = {Proceedings of the National Academy of Sciences}, + author = {Hallatschek, Oskar and Hersen, Pascal and Ramanathan, Sharad and Nelson, David R}, + year = {2007}, + pages = {19926--19930} +} + +@article{mittal_motility_2003, + title = {Motility of {Escherichia} coli cells in clusters formed by chemotactic aggregation}, + volume = {100}, + number = {23}, + journal = {Proceedings of the National Academy of Sciences}, + author = {Mittal, Nikhil and Budrene, Elena O and Brenner, Michael P and van Oudenaarden, Alexander}, + year = {2003}, + pages = {13259--13263} +} + +@misc{thesoundofscience_motions_2010, + title = {Motions of {Swarming} {E} coli {Bacteria}}, + url = {https://www.youtube.com/watch?v=q27Jn3h4kpE&feature=youtube_gdata_player}, + abstract = {A dense group of E. coli swims in the roughly two dimensional space at an air water interface. Their collective motion is significantly different from their motion as single cells. Under these conditions they behave more like an active fluid, hence changing the way that nutrients are shared within the group. Notice the appearance of turbulence-like flow fields. Groups of cells form and swim together, other groups split and join, the average trajectory of a single cell can be quite erratic as shown by the cell labeled in red. + +Video courtesy Matthew Copeland, University of Wisconsin, Madison.}, + urldate = {2015-01-05}, + collaborator = {{thesoundofscience}}, + month = feb, + year = {2010} +} + +@book{toffoli_cellular_1987-1, + title = {Cellular automata machines: a new environment for modeling}, + publisher = {MIT press}, + author = {Toffoli, Tommaso and Margolus, Norman}, + year = {1987} +} + +@article{margolus_physics-like_1984, + title = {Physics-like models of computation}, + volume = {10}, + number = {1}, + journal = {Physica D: Nonlinear Phenomena}, + author = {Margolus, Norman}, + year = {1984}, + pages = {81--95} +} + +@article{morita_computation_1989, + title = {Computation universality of one-dimensional reversible (injective) cellular automata}, + volume = {72}, + number = {6}, + journal = {IEICE TRANSACTIONS (1976-1990)}, + author = {Morita, Kenichi and Harao, Masateru}, + year = {1989}, + pages = {758--762} +} + +@article{kari_reversibility_1994, + title = {Reversibility and surjectivity problems of cellular automata}, + volume = {48}, + number = {1}, + journal = {Journal of Computer and System Sciences}, + author = {Kari, Jarkko}, + year = {1994}, + pages = {149--182} +} + +@phdthesis{michel_representations_1996, + title = {Représentations dynamiques de l'espace dans un langage déclaratif de simulation}, + school = {Université de Paris-Sud, centre d'Orsay}, + author = {Michel, O.}, + month = dec, + year = {1996} +} + +@article{blattner_complete_1997, + title = {The complete genome sequence of {Escherichia} coli {K}-12}, + volume = {277}, + number = {5331}, + journal = {Science}, + author = {Blattner, Frederick R and Plunkett, Guy and Bloch, Craig A and Perna, Nicole T and Burland, Valerie and Riley, Monica and Collado-Vides, Julio and Glasner, Jeremy D and Rode, Christopher K and Mayhew, George F and {others}}, + year = {1997}, + pages = {1453--1462} +} + +@article{bremer_modulation_1996, + title = {Modulation of chemical composition and other parameters of the cell by growth rate}, + author = {Bremer, Hans and Dennis, Patrick P.}, + year = {1996}, + file = {[PDF] à partir de researchgate.net:/home/eeva/these/biblio/zotero/storage/7SUBW2MM/Bremer et Dennis - 1996 - Modulation of chemical composition and other param.pdf:application/pdf} +} + +@article{kubitschek_cell_1990, + title = {Cell volume increase in {Escherichia} coli after shifts to richer media.}, + volume = {172}, + number = {1}, + journal = {Journal of bacteriology}, + author = {Kubitschek, HE}, + year = {1990}, + pages = {94--101} +} + +@article{zaritsky_growth_1982, + title = {Growth and form in bacteria}, + volume = {1}, + journal = {Comments Mol. Cell. Biophys}, + author = {Zaritsky, A and Grover, NB and Naaman, J and Woldringh, CL and Rosenberger, RF}, + year = {1982}, + pages = {237--260} +} + +@article{skarstad_cell_1983, + title = {Cell cycle parameters of slowly growing {Escherichia} coli {B}/r studied by flow cytometry.}, + volume = {154}, + number = {2}, + journal = {Journal of Bacteriology}, + author = {Skarstad, Kirsten and Steen, Harold B and Boye, Erik}, + year = {1983}, + pages = {656--662} +} + +@misc{britanica_online_encyclopedia_bacteria_2016, + title = {Bacteria article}, + url = {http://www.britannica.com/print/article/48203}, + urldate = {2016-01-30}, + author = {Britanica Online Encyclopedia}, + year = {2016}, + file = {bacteria -- Britannica Online Encyclopedia:/home/eeva/these/biblio/zotero/storage/973NWH92/48203.html:text/html} +} + +@article{trueba_changes_1980, + title = {Changes in cell diameter during the division cycle of {Escherichia} coli.}, + volume = {142}, + number = {3}, + journal = {Journal of bacteriology}, + author = {Trueba, Frank J and Woldringh, Conrad L}, + year = {1980}, + pages = {869--878} +} + +@article{diluzio_escherichia_2005, + title = {Escherichia coli swim on the right-hand side}, + volume = {435}, + issn = {0028-0836}, + url = {http://dx.doi.org/10.1038/nature03660}, + doi = {10.1038/nature03660}, + number = {7046}, + journal = {Nature}, + author = {DiLuzio, Willow R. and Turner, Linda and Mayer, Michael and Garstecki, Piotr and Weibel, Douglas B. and Berg, Howard C. and Whitesides, George M.}, + year = {2005}, + pages = {1271--1274} +} + +@article{berg_chemotaxis_1972, + title = {Chemotaxis in {Escherichia} coli analysed by three-dimensional tracking}, + volume = {239}, + number = {5374}, + journal = {Nature}, + author = {Berg, Howard C and Brown, Douglas A and {others}}, + year = {1972}, + pages = {500--504} +} + +@article{bourgoin_spoc:_2012, + title = {{SPOC}: {GPGPU} programming through stream processing with {OCaml}}, + volume = {22}, + number = {02}, + journal = {Parallel Processing Letters}, + author = {Bourgoin, Mathias and Chailloux, Emmanuel and Lamotte, Jean-Luc}, + year = {2012}, + pages = {1240007} +} + +@incollection{medvedev_multi-particle_2010, + title = {Multi-particle cellular-automata models for diffusion simulation}, + booktitle = {Methods and tools of parallel programming multicomputers}, + publisher = {Springer}, + author = {Medvedev, Yu}, + year = {2010}, + pages = {204--211} +} + +@article{bray_chemotactic_2007, + title = {The chemotactic behavior of computer-based surrogate bacteria}, + volume = {17}, + number = {1}, + journal = {Current biology}, + author = {Bray, Dennis and Levin, Matthew D and Lipkow, Karen}, + year = {2007}, + pages = {12--19} +} + +@article{goeddel_expression_1979, + title = {Expression in {Escherichia} coli of chemically synthesized genes for human insulin}, + volume = {76}, + number = {1}, + journal = {Proceedings of the National Academy of Sciences}, + author = {Goeddel, David V and Kleid, Dennis G and Bolivar, Francisco and Heyneker, Herbert L and Yansura, Daniel G and Crea, Roberto and Hirose, Tadaaki and Kraszewski, Adam and Itakura, Keiichi and Riggs, Arthur D}, + year = {1979}, + pages = {106--110} +} + +@article{darnton_torque_2007, + title = {On torque and tumbling in swimming {Escherichia} coli}, + volume = {189}, + url = {http://jb.asm.org/content/189/5/1756.short}, + number = {5}, + urldate = {2016-02-05}, + journal = {Journal of bacteriology}, + author = {Darnton, Nicholas C. and Turner, Linda and Rojevsky, Svetlana and Berg, Howard C.}, + year = {2007}, + pages = {1756--1764}, + file = {[HTML] à partir de asm.org:/home/eeva/these/biblio/zotero/storage/CGEI8NH7/1756.html:text/html;Snapshot:/home/eeva/these/biblio/zotero/storage/JK49X6HH/1756.html:text/html} +} + +@article{turner_real-time_2000, + title = {Real-{Time} {Imaging} of {Fluorescent} {Flagellar} {Filaments}}, + volume = {182}, + issn = {0021-9193, 1098-5530}, + url = {http://jb.asm.org/content/182/10/2793}, + doi = {10.1128/JB.182.10.2793-2801.2000}, + abstract = {Bacteria swim by rotating flagellar filaments that are several micrometers long, but only about 20 nm in diameter. The filaments can exist in different polymorphic forms, having distinct values of curvature and twist. Rotation rates are on the order of 100 Hz. In the past, the motion of individual filaments has been visualized by dark-field or differential-interference-contrast microscopy, methods hampered by intense scattering from the cell body or shallow depth of field, respectively. We have found a simple procedure for fluorescently labeling cells and filaments that allows recording their motion in real time with an inexpensive video camera and an ordinary fluorescence microscope with mercury-arc or strobed laser illumination. We report our initial findings with cells of Escherichia coli. Tumbles (events that enable swimming cells to alter course) are remarkably varied. Not every filament on a cell needs to change its direction of rotation: different filaments can change directions at different times, and a tumble can result from the change in direction of only one. Polymorphic transformations tend to occur in the sequence normal, semicoiled, curly 1, with changes in the direction of movement of the cell body correlated with transformations to the semicoiled form.}, + language = {en}, + number = {10}, + urldate = {2016-02-05}, + journal = {Journal of Bacteriology}, + author = {Turner, Linda and Ryu, William S. and Berg, Howard C.}, + month = may, + year = {2000}, + pmid = {10781548}, + pages = {2793--2801}, + file = {Full Text PDF:/home/eeva/these/biblio/zotero/storage/MQ5R6TIB/Turner et al. - 2000 - Real-Time Imaging of Fluorescent Flagellar Filamen.pdf:application/pdf;Snapshot:/home/eeva/these/biblio/zotero/storage/NA5FUS4J/2793.html:text/html} +} + +@article{sourjik_receptor_2004, + title = {Receptor clustering and signal processing in {E}. coli chemotaxis}, + volume = {12}, + url = {http://www.sciencedirect.com/science/article/pii/S0966842X04002343}, + number = {12}, + urldate = {2016-02-06}, + journal = {Trends in microbiology}, + author = {Sourjik, Victor}, + year = {2004}, + pages = {569--576}, + file = {[PDF] à partir de psu.edu:/home/eeva/these/biblio/zotero/storage/PEM88DQE/Sourjik - 2004 - Receptor clustering and signal processing in E. co.pdf:application/pdf;Snapshot:/home/eeva/these/biblio/zotero/storage/K65JZAUM/S0966-842X(04)00234-3.html:text/html} +} + +@article{shimizu_spatially_2003, + title = {A {Spatially} {Extended} {Stochastic} {Model} of the {Bacterial} {Chemotaxis} {Signalling} {Pathway}}, + volume = {329}, + issn = {00222836}, + url = {http://linkinghub.elsevier.com/retrieve/pii/S0022283603004376}, + doi = {10.1016/S0022-2836(03)00437-6}, + language = {en}, + number = {2}, + urldate = {2016-02-06}, + journal = {Journal of Molecular Biology}, + author = {Shimizu, Thomas S. and Aksenov, Sergej V. and Bray, Dennis}, + month = may, + year = {2003}, + pages = {291--309} +} + +@article{mello_quantitative_2003, + title = {Quantitative modeling of sensitivity in bacterial chemotaxis: {The} role of coupling among different chemoreceptor species}, + volume = {100}, + issn = {0027-8424, 1091-6490}, + shorttitle = {Quantitative modeling of sensitivity in bacterial chemotaxis}, + url = {http://www.pnas.org/content/100/14/8223}, + doi = {10.1073/pnas.1330839100}, + abstract = {We propose a general theoretical framework for modeling receptor sensitivity in bacterial chemotaxis, taking into account receptor interactions, including those among different receptor species. We show that our model can quantitatively explain the recent in vivo measurements of receptor sensitivity at different ligand concentrations for both mutant and wild-type strains. For mutant strains, our model can fit the experimental data exactly. For the wild-type cell, our model is capable of achieving high gain while having modest values of Hill coefficient for the response curves. Furthermore, the high sensitivity of the wild-type cell in our model is maintained for a wide range of ambient ligand concentrations, facilitated by near-perfect adaptation and dependence of ligand binding on receptor activity. Our study reveals the importance of coupling among different chemoreceptor species, in particular strong interactions between the aspartate (Tar) and serine (Tsr) receptors, which is crucial in explaining both the mutant and wild-type data. Predictions for the sensitivity of other mutant strains and possible improvements of our model for the wild-type cell are also discussed.}, + language = {en}, + number = {14}, + urldate = {2016-02-06}, + journal = {Proceedings of the National Academy of Sciences}, + author = {Mello, Bernardo A. and Tu, Yuhai}, + month = jul, + year = {2003}, + pmid = {12826616}, + pages = {8223--8228}, + file = {Full Text PDF:/home/eeva/these/biblio/zotero/storage/SNG3NCZX/Mello et Tu - 2003 - Quantitative modeling of sensitivity in bacterial .pdf:application/pdf;Snapshot:/home/eeva/these/biblio/zotero/storage/PIGH9TS7/8223.html:text/html} +} + +@article{stewart_aging_2005, + title = {Aging and {Death} in an {Organism} {That} {Reproduces} by {Morphologically} {Symmetric} {Division}}, + volume = {3}, + url = {http://dx.doi.org/10.1371/journal.pbio.0030045}, + doi = {10.1371/journal.pbio.0030045}, + abstract = {Detailed time lapse photography reveals that organisms that divide symmetrically, such as the bacterium E. coli, can indeed age and consequently that no organism is immune to mortality.}, + number = {2}, + urldate = {2016-02-07}, + journal = {PLoS Biol}, + author = {Stewart, Eric J and Madden, Richard and Paul, Gregory and Taddei, François}, + month = feb, + year = {2005}, + pages = {e45}, + file = {PLoS Full Text PDF:/home/eeva/these/biblio/zotero/storage/IP932H39/Stewart et al. - 2005 - Aging and Death in an Organism That Reproduces by .pdf:application/pdf} +} + +@incollection{hoekstra_complex_2010, + title = {Complex automata: multi-scale modeling with coupled cellular automata}, + booktitle = {Simulating complex systems by cellular automata}, + publisher = {Springer}, + author = {Hoekstra, Alfons G and Caiazzo, Alfonso and Lorenz, Eric and Falcone, Jean-Luc and Chopard, Bastien}, + year = {2010}, + pages = {29--57} +} + +@article{bray_javascript_2014, + title = {The javascript object notation (json) data interchange format}, + author = {Bray, Tim}, + year = {2014} +} + +@article{dilao_validation_1998, + title = {Validation and calibration of models for reaction–diffusion systems}, + volume = {8}, + number = {06}, + journal = {International Journal of Bifurcation and Chaos}, + author = {Dilão, Rui and Sainhas, Joaquim}, + year = {1998}, + pages = {1163--1182} +} + +@inproceedings{dong_step_2014, + title = {A step towards energy efficient computing: {Redesigning} a hydrodynamic application on {CPU}-{GPU}}, + booktitle = {Parallel and {Distributed} {Processing} {Symposium}, 2014 {IEEE} 28th {International}}, + publisher = {IEEE}, + author = {Dong, Tingxing and Dobrev, Veselin and Kolev, Tzanio and Rieben, Robert and Tomov, Stanimire and Dongarra, Jack}, + year = {2014}, + pages = {972--981} +} + +@article{flynn_computer_1972, + title = {Some {Computer} {Organizations} and {Their} {Effectiveness}}, + volume = {C-21}, + issn = {0018-9340}, + doi = {10.1109/TC.1972.5009071}, + abstract = {A hierarchical model of computer organizations is developed, based on a tree model using request/service type resources as nodes. Two aspects of the model are distinguished: logical and physical. General parallel- or multiple-stream organizations are examined as to type and effectiveness¿especially regarding intrinsic logical difficulties. The overlapped simplex processor (SISD) is limited by data dependencies. Branching has a particularly degenerative effect. The parallel processors [single-instruction stream-multiple-data stream (SIMD)] are analyzed. In particular, a nesting type explanation is offered for Minsky's conjecture¿the performance of a parallel processor increases as log M instead of M (the number of data stream processors). Multiprocessors (MIMD) are subjected to a saturation syndrome based on general communications lockout. Simplified queuing models indicate that saturation develops when the fraction of task time spent locked out (L/E) approaches 1/n, where n is the number of processors. Resources sharing in multiprocessors can be used to avoid several other classic organizational problems.}, + number = {9}, + journal = {IEEE Transactions on Computers}, + author = {Flynn, M. J.}, + month = sep, + year = {1972}, + keywords = {Automata, Computer aided instruction, Computer organization, Concurrent computing, instruction stream, overlapped, Parallel processing, parallel processors, Performance evaluation, resource hierarchy, Time sharing computer systems, Transmission electron microscopy}, + pages = {948--960} +} + +@article{han_escherichia_2006, + title = {The {Escherichia} coli {Proteome}: {Past}, {Present}, and {Future} {Prospects}}, + volume = {70}, + issn = {1092-2172 1098-5557}, + doi = {10.1128/MMBR.00036-05}, + abstract = {Proteomics has emerged as an indispensable methodology for large-scale protein analysis in functional genomics. The Escherichia coli proteome has been extensively studied and is well defined in terms of biochemical, biological, and biotechnological data. Even before the entire E. coli proteome was fully elucidated, the largest available data set had been integrated to decipher regulatory circuits and metabolic pathways, providing valuable insights into global cellular physiology and the development of metabolic and cellular engineering strategies. With the recent advent of advanced proteomic technologies, the E. coli proteome has been used for the validation of new technologies and methodologies such as sample prefractionation, protein enrichment, two-dimensional gel electrophoresis, protein detection, mass spectrometry (MS), combinatorial assays with n-dimensional chromatographies and MS, and image analysis software. These important technologies will not only provide a great amount of additional information on the E. coli proteome but also synergistically contribute to other proteomic studies. Here, we review the past development and current status of E. coli proteome research in terms of its biological, biotechnological, and methodological significance and suggest future prospects.}, + language = {eng}, + number = {2}, + journal = {Microbiology and Molecular Biology Reviews}, + author = {Han, Mee-Jung and Lee, Sang Yup}, + month = jun, + year = {2006}, + pmid = {16760308}, + pages = {362--439} +} + +@book{neumann_theory_1966, + address = {Champaign, IL, USA}, + title = {Theory of {Self}-{Reproducing} {Automata}}, + publisher = {University of Illinois Press}, + author = {Neumann, John Von}, + editor = {Burks, Arthur W.}, + year = {1966} +} + +@article{hardy_time_1973, + title = {Time evolution of a two-dimensional classical lattice system}, + volume = {31}, + number = {5}, + journal = {Physical Review Letters}, + author = {Hardy, J and Pomeau, Yv and De Pazzis, O}, + year = {1973}, + pages = {276} +} + +@article{kukan_disposition_1991, + title = {Disposition of lypophilized (methylmethacrylate-14C, 2-hydroxyethylmethacrylate, butylacrylate) nanoparticles in rats and their effect on zoxazolamine paralysis time}, + volume = {46}, + issn = {0031-7144}, + abstract = {The fate of lyophilized (methylmethacrylate-14C, 2-hydroxyethylmethacrylate, butylacrylate) nanoparticles was studied in male Wistar rats after p.o. administration. It was found that at least 4\% of the dose of 14C was absorbed from the gastrointestinal tract after a single dose with these nanoparticles. Some radioactivity (less than 0.15\% of dose) was found 7 d after administration in lung, spleen and liver. As expected excretion of the label was predominated via the feces. Ten d of p.o. treatment of rats with lyophilized nanoparticles (1 g/kg of body weight) was shown to prolong significantly zoxazolamine paralysis time. This result suggests that lyophilized nanoparticles decreased elimination of zoxazolamine.}, + language = {eng}, + number = {1}, + journal = {Die Pharmazie}, + author = {Kukan, M. and Koprda, V. and Bezek, S. and Kálal, J. and Labský, J. and Trnovec, T.}, + month = jan, + year = {1991}, + pmid = {1857727}, + keywords = {Acrylates, Administration, Oral, Animals, Delayed-Action Preparations, Feces, Freeze Drying, Intestinal Absorption, Male, Methacrylates, Methylmethacrylate, Methylmethacrylates, Microspheres, Paralysis, Rats, Rats, Inbred Strains, Time Factors, Tissue Distribution, Zoxazolamine}, + pages = {37--39} +} + +@article{schmoldt_digitoxin_1975, + title = {Digitoxin metabolism by rat liver microsomes}, + volume = {24}, + issn = {1873-2968}, + language = {eng}, + number = {17}, + journal = {Biochemical Pharmacology}, + author = {Schmoldt, A. and Benthe, H. F. and Haberland, G.}, + month = sep, + year = {1975}, + pmid = {10}, + keywords = {Animals, Chromatography, Thin Layer, Digitoxigenin, Digitoxin, Hydroxylation, In Vitro Techniques, Male, Microsomes, Liver, NADP, Rats, Time Factors}, + pages = {1639--1641} +} + +@article{mills_studies_1975, + title = {Studies on variant glucose-6-phosphate dehydrogenases: {G}6PD {Fort} {Worth}}, + volume = {13}, + issn = {0006-2944}, + shorttitle = {Studies on variant glucose-6-phosphate dehydrogenases}, + language = {eng}, + number = {3}, + journal = {Biochemical Medicine}, + author = {Mills, G. C. and Alperin, J. B. and Trimmer, K. B.}, + month = jul, + year = {1975}, + pmid = {1007}, + keywords = {Adult, Drug Stability, Erythrocytes, Female, Genetic Variation, Glucosephosphate Dehydrogenase, Humans, Hydrogen-Ion Concentration, Kinetics, Male, Temperature, Texas}, + pages = {264--275} +} + +@article{fredkin_conservative_1982, + title = {Conservative logic}, + volume = {21}, + issn = {1572-9575}, + url = {http://dx.doi.org/10.1007/BF01857727}, + doi = {10.1007/BF01857727}, + abstract = {Conservative logic is a comprehensive model of computation which explicitly reflects a number of fundamental principles of physics, such as the reversibility of the dynamical laws and the conservation of certainadditive quantities (among which energy plays a distinguished role). Because it more closely mirrors physics than traditional models of computation, conservative logic is in a better position to provide indications concerning the realization of high-performance computing systems, i.e., of systems that make very efficient use of the “computing resources” actually offered by nature. In particular, conservative logic shows that it is ideally possible to build sequential circuits with zero internal power dissipation. After establishing a general framework, we discuss two specific models of computation. The first uses binary variables and is the conservative-logic counterpart of switching theory; this model proves that universal computing capabilities are compatible with the reversibility and conservation constraints. The second model, which is a refinement of the first, constitutes a substantial breakthrough in establishing a correspondence between computation and physics. In fact, this model is based on elastic collisions of identical “balls,” and thus is formally identical with the atomic model that underlies the (classical) kinetic theory of perfect gases. Quite literally, the functional behavior of a general-purpose digital computer can be reproduced by a perfect gas placed in a suitably shaped container and given appropriate initial conditions.}, + number = {3}, + journal = {International Journal of Theoretical Physics}, + author = {Fredkin, Edward and Toffoli, Tommaso}, + year = {1982}, + pages = {219--253} +} + +@article{kolmogorov_etude_1937, + title = {Etude de l’équation de la diffusion avec croissance de la quantité de matière et son application à un problème biologique}, + volume = {1}, + number = {1-25}, + journal = {Moscow Univ. Math. Bull}, + author = {Kolmogorov, Andrei N and Petrovsky, IG and Piskunov, NS}, + year = {1937}, + pages = {129} +} + +@article{turing_chemical_1952, + title = {The {Chemical} {Basis} of {Morphogenesis}}, + volume = {237}, + issn = {0080-4622}, + url = {http://rstb.royalsocietypublishing.org/content/237/641/37}, + doi = {10.1098/rstb.1952.0012}, + abstract = {It is suggested that a system of chemical substances, called morphogens, reacting together and diffusing through a tissue, is adequate to account for the main phenomena of morphogenesis. Such a system, although it may originally be quite homogeneous, may later develop a pattern or structure due to an instability of the homogeneous equilibrium, which is triggered off by random disturbances. Such reaction-diffusion systems are considered in some detail in the case of an isolated ring of cells, a mathematically convenient, though biologically unusual system. The investigation is chiefly concerned with the onset of instability. It is found that there are six essentially different forms which this may take. In the most interesting form stationary waves appear on the ring. It is suggested that this might account, for instance, for the tentacle patterns on Hydra and for whorled leaves. A system of reactions and diffusion on a sphere is also considered. Such a system appears to account for gastrulation. Another reaction system in two dimensions gives rise to patterns reminiscent of dappling. It is also suggested that stationary waves in two dimensions could account for the phenomena of phyllotaxis. The purpose of this paper is to discuss a possible mechanism by which the genes of a zygote may determine the anatomical structure of the resulting organism. The theory does not make any new hypotheses; it merely suggests that certain well-known physical laws are sufficient to account for many of the facts. The full understanding of the paper requires a good knowledge of mathematics, some biology, and some elementary chemistry. Since readers cannot be expected to be experts in all of these subjects, a number of elementary facts are explained, which can be found in text-books, but whose omission would make the paper difficult reading.}, + number = {641}, + journal = {Philosophical Transactions of the Royal Society of London B: Biological Sciences}, + author = {Turing, A. M.}, + year = {1952}, + pages = {37--72} +} + +@article{pascalie_developmental_2016, + title = {Developmental {Design} of {Synthetic} {Bacterial} {Architectures} by {Morphogenetic} {Engineering}}, + volume = {5}, + url = {http://dx.doi.org/10.1021/acssynbio.5b00246}, + doi = {10.1021/acssynbio.5b00246}, + number = {8}, + journal = {ACS Synthetic Biology}, + author = {Pascalie, Jonathan and Potier, Martin and Kowaliw, Taras and Giavitto, Jean-Louis and Michel, Olivier and Spicher, Antoine and Doursat, René}, + year = {2016}, + pmid = {27244532}, + pages = {842--861} +} \ No newline at end of file diff --git a/biblio/zotero/locate/CrossRef Lookup.gif b/biblio/zotero/locate/CrossRef Lookup.gif new file mode 100644 index 0000000..ca8fabd Binary files /dev/null and b/biblio/zotero/locate/CrossRef Lookup.gif differ diff --git a/biblio/zotero/locate/Google Scholar Search.ico b/biblio/zotero/locate/Google Scholar Search.ico new file mode 100644 index 0000000..f6c8326 Binary files /dev/null and b/biblio/zotero/locate/Google Scholar Search.ico differ diff --git a/biblio/zotero/locate/engines.json b/biblio/zotero/locate/engines.json new file mode 100644 index 0000000..a9a576d --- /dev/null +++ b/biblio/zotero/locate/engines.json @@ -0,0 +1,31 @@ +[ + { + "name": "CrossRef Lookup", + "alias": "CrossRef", + "icon": "file:///home/eeva/.mozilla/firefox/bmo4pesa.default/zotero/locate/CrossRef%20Lookup.gif", + "_urlTemplate": "http://crossref.org/openurl?{z:openURL}&pid=zter:zter321", + "description": "CrossRef Search Engine", + "hidden": false, + "_urlParams": [], + "_urlNamespaces": { + "z": "http://www.zotero.org/namespaces/openSearch#", + "": "http://a9.com/-/spec/opensearch/1.1/" + }, + "_iconSourceURI": "http://crossref.org/favicon.ico" + }, + { + "name": "Google Scholar Search", + "alias": "Google Scholar", + "icon": "file:///home/eeva/.mozilla/firefox/bmo4pesa.default/zotero/locate/Google%20Scholar%20Search.ico", + "_urlTemplate": "http://scholar.google.com/scholar?as_q=&as_epq={z:title}&as_occt=title&as_sauthors={rft:aufirst?}+{rft:aulast?}&as_ylo={z:year?}&as_yhi={z:year?}&as_sdt=1.&as_sdtp=on&as_sdtf=&as_sdts=22&", + "description": "Google Scholar Search", + "hidden": false, + "_urlParams": [], + "_urlNamespaces": { + "rft": "info:ofi/fmt:kev:mtx:journal", + "z": "http://www.zotero.org/namespaces/openSearch#", + "": "http://a9.com/-/spec/opensearch/1.1/" + }, + "_iconSourceURI": "http://scholar.google.com/favicon.ico" + } +] \ No newline at end of file diff --git a/biblio/zotero/zotero.sqlite b/biblio/zotero/zotero.sqlite new file mode 100644 index 0000000..f57893d Binary files /dev/null and b/biblio/zotero/zotero.sqlite differ diff --git a/biblio/zotero/zotero.sqlite.1.bak b/biblio/zotero/zotero.sqlite.1.bak new file mode 100644 index 0000000..4e9a090 Binary files /dev/null and b/biblio/zotero/zotero.sqlite.1.bak differ diff --git a/biblio/zotero/zotero.sqlite.bak b/biblio/zotero/zotero.sqlite.bak new file mode 100644 index 0000000..4f20900 Binary files /dev/null and b/biblio/zotero/zotero.sqlite.bak differ diff --git a/builderbot/Build.cabal b/builderbot/Build.cabal new file mode 100644 index 0000000..a06af47 --- /dev/null +++ b/builderbot/Build.cabal @@ -0,0 +1,28 @@ +-- Initial Build.cabal generated by cabal init. For further documentation, +-- see http://haskell.org/cabal/users-guide/ + +name: buildthesis +version: 0.1.0.0 +-- synopsis: +-- description: +-- license: +license-file: LICENSE +author: eeva +maintainer: eeva@canine +-- copyright: +-- category: +build-type: Simple +-- extra-source-files: +cabal-version: >=1.10 + +executable buildthesis + main-is: Build.hs + -- other-modules: + -- other-extensions: + build-depends: base >=4.8 + ,directory >=1.2 + ,shake + ,Glob + + -- hs-source-dirs: + default-language: Haskell2010 diff --git a/builderbot/Build.hs b/builderbot/Build.hs new file mode 100644 index 0000000..65f0486 --- /dev/null +++ b/builderbot/Build.hs @@ -0,0 +1,121 @@ +import System.IO +import Development.Shake +import Development.Shake.FilePath +import System.Directory (createDirectory) +import System.FilePath.Glob +import Data.List (isSuffixOf) + +target :: FilePath +target = "main" + +finalTarget :: FilePath +finalTarget = "potier.these.2015" <.> "pdf" + +buildDir :: FilePath +buildDir = "_build" + +fullTarget :: FilePath +fullTarget = buildDir target <.> "pdf" + +sanityFile :: FilePath +sanityFile = buildDir "sanity.check" + +texCmd :: String -> [String] +texCmd target = ["xelatex", "-halt-on-error", target] + +foldersource :: FilePath -> [FilePattern] -> Action [FilePath] +foldersource folder wildcards = do + files <- getDirectoryFiles folder wildcards + return $ map (folder ) files + +foldersourceIO :: FilePath -> [String] -> IO [FilePath] +foldersourceIO folder wildcards = do + let patterns = map compile wildcards + (results,_) <- globDir patterns folder + return $ concat results + +allfiles :: Action [FilePath] +allfiles = do + tex <- getDirectoryFiles "" ["*.tex"] + bib <- foldersource "biblio" ["*"] + dots <- foldersource "data" ["*"] + figures <- foldersource "figures" ["*"] + fonts <- foldersource "fonts" ["*"] + let files = tex ++ bib ++ dots ++ figures ++ fonts + return $ map (buildDir ) files + +-- Without link +compiledTikzFiguresIO :: IO [FilePath] +compiledTikzFiguresIO = do + tikz <- foldersourceIO "figures" ["*.tikz"] + let pdfs = map (-<.> "pdf") tikz + return $ map (buildDir ) $ filter (not . isSuffixOf "link.pdf") pdfs + +main :: IO () +main = do + -- preping + compiledTikzFigures <- compiledTikzFiguresIO + + shakeArgs shakeOptions { shakeFiles = buildDir + , shakeThreads = 0 + , shakeProgress = progressSimple } $ do + want [ finalTarget ] + + -- Populate when needed + (map (buildDir ) ["*.tex", "biblio/*", "data/*", "figures/*", "fonts/*"]) |%> \out -> do + copyFile' (dropDirectory1 out) out + + -- creating a sanity file (erk!) + sanityFile %> \out -> do + writeFile' sanityFile "building sanely" + + -- Turn *.tikz in *.pdf + compiledTikzFigures |%> \out -> do + let source = out -<.> "tikz" + need [source] + cmd (EchoStdout False) [ "xelatex", "-halt-on-error", + "-output-directory=" ++ (buildDir "figures"), source] + + -- Build link.pdf + buildDir "figures/link.pdf" %> \out -> do + let source = out -<.> "tikz" + need $ source : map (buildDir ) + [ "common-headers.tex", "sigles.tex", + "figures/operateursS.pdf", "figures/operateursStS.pdf", + "figures/operateursfS.pdf", "figures/operateursfStS.pdf", + "figures/operateursStfS.pdf", "figures/operateursLkS.pdf" ] + + cmd (Cwd buildDir) (EchoStdout False) + [ "xelatex", "-halt-on-error", + "-output-directory=figures", (dropDirectory1 source)] + + + fullTarget %> \out -> do + removeFilesAfter sanityFile ["*"] + allSrc <- allfiles + need $ sanityFile : (out -<.> "bbl") + : (buildDir "figures/link.pdf") + : compiledTikzFigures ++ allSrc + cmd (Cwd buildDir) (EchoStdout False) $ texCmd target + + -- generate "main.bbl" + fullTarget -<.> "bbl" %> \out -> do + allSrc <- allfiles + need $ (buildDir "figures/link.pdf") : compiledTikzFigures ++ allSrc + + existsAux <- doesFileExist $ fullTarget -<.> "aux" + existsSane <- doesFileExist $ sanityFile + if (not existsAux || existsSane) + then cmd (Cwd buildDir) (EchoStdout False) $ texCmd target + else return () + + cmd (EchoStdout False) ["biber", dropExtension out] + + finalTarget %> \out -> do + need [fullTarget] + + copyFileChanged fullTarget out + + phony "clean" $ do + removeFilesAfter "_build" ["//*"] + diff --git a/builderbot/LICENSE b/builderbot/LICENSE new file mode 100644 index 0000000..d291609 --- /dev/null +++ b/builderbot/LICENSE @@ -0,0 +1 @@ +dummy text diff --git a/builderbot/default.nix b/builderbot/default.nix new file mode 100644 index 0000000..78e7665 --- /dev/null +++ b/builderbot/default.nix @@ -0,0 +1,24 @@ +{ nixpkgs ? import {}, compiler ? "default" }: + +let + + inherit (nixpkgs) pkgs; + + f = { mkDerivation, base, directory, Glob, shake, stdenv }: + mkDerivation { + pname = "buildthesis"; + version = "0.1.0.0"; + src = ./.; + isLibrary = false; + isExecutable = true; + executableHaskellDepends = [ base directory Glob shake ]; + license = stdenv.lib.licenses.publicDomain; + }; + + haskellPackages = if compiler == "default" + then pkgs.haskellPackages + else pkgs.haskell.packages.${compiler}; + + in + haskellPackages.callPackage f {} + diff --git a/common-headers.tex b/common-headers.tex new file mode 100644 index 0000000..589b691 --- /dev/null +++ b/common-headers.tex @@ -0,0 +1,139 @@ +% All packages and parameters usefull +% for generating standalone figures. + +\usepackage{xspace} + +\usepackage{polyglossia} +\setmainlanguage{french} +\setotherlanguage{english} + +% Do this BEFORE unicode-math +\usepackage{amsfonts} +\usepackage{amsmath} +\usepackage{mathrsfs} +\usepackage{amssymb} + +% Do this AFTER any math font package (see fontspec doc) +\usepackage{fontspec} +\usepackage{unicode-math} +\defaultfontfeatures{Scale=MatchLowercase,Mapping=tex-text} +%\setromanfont{Linux Libertine O} +\setromanfont{LinLibertine}[ + Path = fonts/ , + Extension = .otf , + UprightFont = *-R , + BoldFont = *-RB , + ItalicFont = *-RI , + BoldItalicFont = *-RBI ] +%\setsansfont {Linux Biolinum O} +\setsansfont{LinBiolinum}[ + Path = fonts/ , + Extension = .otf , + UprightFont = *-R , + BoldFont = *-RB , + ItalicFont = *-RI ] + +%\setmonofont {Fantasque Sans Mono} +\setmonofont{FantasqueSansMono}[ + Path = fonts/ , + Extension = .ttf , + UprightFont = *-Regular , + BoldFont = *-Bold , + ItalicFont = *-Italic , + BoldItalicFont = *-BoldItalic ] + +%\setmathfont[mathbf=sym] {Asana Math} +\setmathfont[mathbf=sym] {Asana-Math}[ + Path = fonts/ , + Extension = .otf ] + +\usepackage{tikz} +\usetikzlibrary{arrows.meta} +\usetikzlibrary{backgrounds} +\usetikzlibrary{bending} +\usetikzlibrary{calc} +\usetikzlibrary{decorations.pathreplacing} +\usetikzlibrary{decorations.text} +\usetikzlibrary{positioning} +\usetikzlibrary{fit} +\usetikzlibrary{shapes.geometric} + +\usepackage{pgfplots} +\pgfplotsset{compat=1.13} + +\usepackage[ + locale = FR % Gives comma as decimal separator. +]{siunitx} + +% SOLARIZED HEX 16/8 TERMCOL XTERM/HEX L*A*B RGB HSB +% --------- ------- ---- ------- ----------- ---------- ----------- ----------- +% base03 #002b36 8/4 brblack 234 #1c1c1c 15 -12 -12 0 43 54 193 100 21 +% base02 #073642 0/4 black 235 #262626 20 -12 -12 7 54 66 192 90 26 +% base01 #586e75 10/7 brgreen 240 #585858 45 -07 -07 88 110 117 194 25 46 +% base00 #657b83 11/7 bryellow 241 #626262 50 -07 -07 101 123 131 195 23 51 +% base0 #839496 12/6 brblue 244 #808080 60 -06 -03 131 148 150 186 13 59 +% base1 #93a1a1 14/4 brcyan 245 #8a8a8a 65 -05 -02 147 161 161 180 9 63 +% base2 #eee8d5 7/7 white 254 #e4e4e4 92 -00 10 238 232 213 44 11 93 +% base3 #fdf6e3 15/7 brwhite 230 #ffffd7 97 00 10 253 246 227 44 10 99 +% yellow #b58900 3/3 yellow 136 #af8700 60 10 65 181 137 0 45 100 71 +% orange #cb4b16 9/3 brred 166 #d75f00 50 50 55 203 75 22 18 89 80 +% red #dc322f 1/1 red 160 #d70000 50 65 45 220 50 47 1 79 86 +% magenta #d33682 5/5 magenta 125 #af005f 50 65 -05 211 54 130 331 74 83 +% violet #6c71c4 13/5 brmagenta 61 #5f5faf 50 15 -45 108 113 196 237 45 77 +% blue #268bd2 4/4 blue 33 #0087ff 55 -10 -45 38 139 210 205 82 82 +% cyan #2aa198 6/6 cyan 37 #00afaf 60 -35 -05 42 161 152 175 74 63 +% green #859900 2/2 green 64 #5f8700 60 -20 65 133 153 0 68 100 60 +\definecolor{base03} {HTML}{002b36} \colorlet{unused1} {base03} +\definecolor{base02} {HTML}{073642} \colorlet{unused2} {base02} +\definecolor{base01} {HTML}{586e75} \colorlet{fghl} {base01} +\definecolor{base00} {HTML}{657b83} \colorlet{fg} {base00} +\definecolor{base0 } {HTML}{839496} \colorlet{unused3} {base0 } +\definecolor{base1 } {HTML}{93a1a1} \colorlet{bgcomment}{base1 } +\definecolor{base2 } {HTML}{eee8d5} \colorlet{bghl} {base2 } +\definecolor{base3 } {HTML}{fdf6e3} \colorlet{bg} {base3 } +\definecolor{yellow} {HTML}{b58900} +\definecolor{orange} {HTML}{cb4b16} +\definecolor{red} {HTML}{dc322f} +\definecolor{magenta}{HTML}{d33682} +\definecolor{violet} {HTML}{6c71c4} +\definecolor{blue} {HTML}{268bd2} +\definecolor{cyan} {HTML}{2aa198} +\definecolor{green} {HTML}{859900} + +%Theme SMYCK +% 0x00 (dark black ) #000000 +% 0x01 (dark red ) #C75646 +% 0x02 (dark green ) #8EB33B +% 0x03 (dark yellow ) #D0B03C +% 0x04 (dark blue ) #72B3CC +% 0x05 (dark magenta) #C8A0D1 +% 0x06 (dark cyan ) #218693 +% 0x07 (dark white ) #B0B0B0 +% 0x10 (light black ) #5D5D5D +% 0x11 (light red ) #E09690 +% 0x12 (light green ) #CDEE69 +% 0x13 (light yellow ) #FFE377 +% 0x14 (light blue ) #9CD9F0 +% 0x15 (light magenta) #FBB1F9 +% 0x16 (light cyan ) #77DFD8 +% 0x17 (light white ) #F7F7F7 +%\definecolor{ darkblack }{HTML}{#000000} +%\definecolor{ darkred }{HTML}{#C75646} +%\definecolor{ darkgreen }{HTML}{#8EB33B} +%\definecolor{ darkyellow }{HTML}{#D0B03C} +%\definecolor{ darkblue }{HTML}{#72B3CC} +%\definecolor{ darkmagenta}{HTML}{#C8A0D1} +%\definecolor{ darkcyan }{HTML}{#218693} +%\definecolor{ darkwhite }{HTML}{#B0B0B0} +%\definecolor{lightblack }{HTML}{#5D5D5D} +%\definecolor{lightred }{HTML}{#E09690} +%\definecolor{lightgreen }{HTML}{#CDEE69} +%\definecolor{lightyellow }{HTML}{#FFE377} +%\definecolor{lightblue }{HTML}{#9CD9F0} +%\definecolor{lightmagenta}{HTML}{#FBB1F9} +%\definecolor{lightcyan }{HTML}{#77DFD8} +%\definecolor{lightwhite }{HTML}{#F7F7F7} + +%NoUglyEmptySet +%\let\oldemptyset\emptyset +\let\emptyset\varnothing diff --git a/data/bench.tex b/data/bench.tex new file mode 100644 index 0000000..e34b0ae --- /dev/null +++ b/data/bench.tex @@ -0,0 +1,107 @@ +% GNUPLOT: LaTeX picture with Postscript +\begingroup + \makeatletter + \providecommand\color[2][]{% + \GenericError{(gnuplot) \space\space\space\@spaces}{% + Package color not loaded in conjunction with + terminal option `colourtext'% + }{See the gnuplot documentation for explanation.% + }{Either use 'blacktext' in gnuplot or load the package + color.sty in LaTeX.}% + \renewcommand\color[2][]{}% + }% + \providecommand\includegraphics[2][]{% + \GenericError{(gnuplot) \space\space\space\@spaces}{% + Package graphicx or graphics not loaded% + }{See the gnuplot documentation for explanation.% + }{The gnuplot epslatex terminal needs graphicx.sty or graphics.sty.}% + \renewcommand\includegraphics[2][]{}% + }% + \providecommand\rotatebox[2]{#2}% + \@ifundefined{ifGPcolor}{% + \newif\ifGPcolor + \GPcolorfalse + }{}% + \@ifundefined{ifGPblacktext}{% + \newif\ifGPblacktext + \GPblacktexttrue + }{}% + % define a \g@addto@macro without @ in the name: + \let\gplgaddtomacro\g@addto@macro + % define empty templates for all commands taking text: + \gdef\gplbacktext{}% + \gdef\gplfronttext{}% + \makeatother + \ifGPblacktext + % no textcolor at all + \def\colorrgb#1{}% + \def\colorgray#1{}% + \else + % gray or color? + \ifGPcolor + \def\colorrgb#1{\color[rgb]{#1}}% + \def\colorgray#1{\color[gray]{#1}}% + \expandafter\def\csname LTw\endcsname{\color{white}}% + \expandafter\def\csname LTb\endcsname{\color{black}}% + \expandafter\def\csname LTa\endcsname{\color{black}}% + \expandafter\def\csname LT0\endcsname{\color[rgb]{1,0,0}}% + \expandafter\def\csname LT1\endcsname{\color[rgb]{0,1,0}}% + \expandafter\def\csname LT2\endcsname{\color[rgb]{0,0,1}}% + \expandafter\def\csname LT3\endcsname{\color[rgb]{1,0,1}}% + \expandafter\def\csname LT4\endcsname{\color[rgb]{0,1,1}}% + \expandafter\def\csname LT5\endcsname{\color[rgb]{1,1,0}}% + \expandafter\def\csname LT6\endcsname{\color[rgb]{0,0,0}}% + \expandafter\def\csname LT7\endcsname{\color[rgb]{1,0.3,0}}% + \expandafter\def\csname LT8\endcsname{\color[rgb]{0.5,0.5,0.5}}% + \else + % gray + \def\colorrgb#1{\color{black}}% + \def\colorgray#1{\color[gray]{#1}}% + \expandafter\def\csname LTw\endcsname{\color{white}}% + \expandafter\def\csname LTb\endcsname{\color{black}}% + \expandafter\def\csname LTa\endcsname{\color{black}}% + \expandafter\def\csname LT0\endcsname{\color{black}}% + \expandafter\def\csname LT1\endcsname{\color{black}}% + \expandafter\def\csname LT2\endcsname{\color{black}}% + \expandafter\def\csname LT3\endcsname{\color{black}}% + \expandafter\def\csname LT4\endcsname{\color{black}}% + \expandafter\def\csname LT5\endcsname{\color{black}}% + \expandafter\def\csname LT6\endcsname{\color{black}}% + \expandafter\def\csname LT7\endcsname{\color{black}}% + \expandafter\def\csname LT8\endcsname{\color{black}}% + \fi + \fi + \setlength{\unitlength}{0.0500bp}% + \begin{picture}(6800.00,5100.00)% + \gplgaddtomacro\gplbacktext{% + \csname LTb\endcsname% + \put(561,595){\makebox(0,0)[r]{\strut{} 0}}% + \put(561,1455){\makebox(0,0)[r]{\strut{} 0.2}}% + \put(561,2315){\makebox(0,0)[r]{\strut{} 0.4}}% + \put(561,3175){\makebox(0,0)[r]{\strut{} 0.6}}% + \put(561,4035){\makebox(0,0)[r]{\strut{} 0.8}}% + \put(561,4895){\makebox(0,0)[r]{\strut{} 1}}% + \put(663,409){\makebox(0,0){\strut{} 0}}% + \put(1311,409){\makebox(0,0){\strut{} 100}}% + \put(1959,409){\makebox(0,0){\strut{} 200}}% + \put(2606,409){\makebox(0,0){\strut{} 300}}% + \put(3254,409){\makebox(0,0){\strut{} 400}}% + \put(3902,409){\makebox(0,0){\strut{} 500}}% + \put(4550,409){\makebox(0,0){\strut{} 600}}% + \put(5197,409){\makebox(0,0){\strut{} 700}}% + \put(5845,409){\makebox(0,0){\strut{} 800}}% + \put(6493,409){\makebox(0,0){\strut{} 900}}% + \put(144,2745){\rotatebox{-270}{\makebox(0,0)[c]{}}}% + \put(3578,130){\makebox(0,0)[c]{Iterations}}% + }% + \gplgaddtomacro\gplfronttext{% + \csname LTb\endcsname% + \put(5705,4728){\makebox(0,0)[r]{$T_{opt}/T_{norm}$}}% + \csname LTb\endcsname% + \put(5705,4542){\makebox(0,0)[r]{Active$/100^2$}}% + }% + \gplbacktext + \put(0,0){\includegraphics{bench}}% + \gplfronttext + \end{picture}% +\endgroup diff --git a/data/deviceQuery-GTX970strix.txt b/data/deviceQuery-GTX970strix.txt new file mode 100644 index 0000000..3e60abb --- /dev/null +++ b/data/deviceQuery-GTX970strix.txt @@ -0,0 +1,41 @@ +./deviceQuery Starting... + + CUDA Device Query (Runtime API) version (CUDART static linking) + +Detected 1 CUDA Capable device(s) + +Device 0: "GeForce GTX 970" + CUDA Driver Version / Runtime Version 8.0 / 7.5 + CUDA Capability Major/Minor version number: 5.2 + Total amount of global memory: 4093 MBytes (4291493888 bytes) + (13) Multiprocessors, (128) CUDA Cores/MP: 1664 CUDA Cores + GPU Max Clock rate: 1253 MHz (1.25 GHz) + Memory Clock rate: 3505 Mhz + Memory Bus Width: 256-bit + L2 Cache Size: 1835008 bytes + Maximum Texture Dimension Size (x,y,z) 1D=(65536), 2D=(65536, 65536), 3D=(4096, 4096, 4096) + Maximum Layered 1D Texture Size, (num) layers 1D=(16384), 2048 layers + Maximum Layered 2D Texture Size, (num) layers 2D=(16384, 16384), 2048 layers + Total amount of constant memory: 65536 bytes + Total amount of shared memory per block: 49152 bytes + Total number of registers available per block: 65536 + Warp size: 32 + Maximum number of threads per multiprocessor: 2048 + Maximum number of threads per block: 1024 + Max dimension size of a thread block (x,y,z): (1024, 1024, 64) + Max dimension size of a grid size (x,y,z): (2147483647, 65535, 65535) + Maximum memory pitch: 2147483647 bytes + Texture alignment: 512 bytes + Concurrent copy and kernel execution: Yes with 2 copy engine(s) + Run time limit on kernels: Yes + Integrated GPU sharing Host Memory: No + Support host page-locked memory mapping: Yes + Alignment requirement for Surfaces: Yes + Device has ECC support: Disabled + Device supports Unified Addressing (UVA): Yes + Device PCI Domain ID / Bus ID / location ID: 0 / 1 / 0 + Compute Mode: + < Default (multiple host threads can use ::cudaSetDevice() with device simultaneously) > + +deviceQuery, CUDA Driver = CUDART, CUDA Driver Version = 8.0, CUDA Runtime Version = 7.5, NumDevs = 1, Device0 = GeForce GTX 970 +Result = PASS diff --git a/data/deviceQuery-marvin-tesla.txt b/data/deviceQuery-marvin-tesla.txt new file mode 100644 index 0000000..da5650e --- /dev/null +++ b/data/deviceQuery-marvin-tesla.txt @@ -0,0 +1,41 @@ +./deviceQuery Starting... + + CUDA Device Query (Runtime API) version (CUDART static linking) + +Detected 1 CUDA Capable device(s) + +Device 0: "Tesla K20m" + CUDA Driver Version / Runtime Version 6.5 / 6.5 + CUDA Capability Major/Minor version number: 3.5 + Total amount of global memory: 4800 MBytes (5032706048 bytes) + (13) Multiprocessors, (192) CUDA Cores/MP: 2496 CUDA Cores + GPU Clock rate: 706 MHz (0.71 GHz) + Memory Clock rate: 2600 Mhz + Memory Bus Width: 320-bit + L2 Cache Size: 1310720 bytes + Maximum Texture Dimension Size (x,y,z) 1D=(65536), 2D=(65536, 65536), 3D=(4096, 4096, 4096) + Maximum Layered 1D Texture Size, (num) layers 1D=(16384), 2048 layers + Maximum Layered 2D Texture Size, (num) layers 2D=(16384, 16384), 2048 layers + Total amount of constant memory: 65536 bytes + Total amount of shared memory per block: 49152 bytes + Total number of registers available per block: 65536 + Warp size: 32 + Maximum number of threads per multiprocessor: 2048 + Maximum number of threads per block: 1024 + Max dimension size of a thread block (x,y,z): (1024, 1024, 64) + Max dimension size of a grid size (x,y,z): (2147483647, 65535, 65535) + Maximum memory pitch: 2147483647 bytes + Texture alignment: 512 bytes + Concurrent copy and kernel execution: Yes with 2 copy engine(s) + Run time limit on kernels: No + Integrated GPU sharing Host Memory: No + Support host page-locked memory mapping: Yes + Alignment requirement for Surfaces: Yes + Device has ECC support: Enabled + Device supports Unified Addressing (UVA): Yes + Device PCI Bus ID / PCI location ID: 5 / 0 + Compute Mode: + < Default (multiple host threads can use ::cudaSetDevice() with device simultaneously) > + +deviceQuery, CUDA Driver = CUDART, CUDA Driver Version = 6.5, CUDA Runtime Version = 6.5, NumDevs = 1, Device0 = Tesla K20m +Result = PASS diff --git a/data/fullStablePopulation.data.gz b/data/fullStablePopulation.data.gz new file mode 100644 index 0000000..1ce5ec9 Binary files /dev/null and b/data/fullStablePopulation.data.gz differ diff --git a/data/moduleTree.gv b/data/moduleTree.gv new file mode 100644 index 0000000..443e357 --- /dev/null +++ b/data/moduleTree.gv @@ -0,0 +1,33 @@ +digraph G { + size="10,7.5"; + ratio="fill"; + rotate=90; + fontsize="12pt"; + rankdir = TB ; +"Bacterium" [style=filled, color=darkturquoise]; +"Bacterium" -> "Viewer"; +"Bacterium" -> "Packfile"; +"Bacterium" -> "OpenCL"; +"Bacterium" -> "BoundingBox"; +"BoundingBox" [style=filled, color=darkturquoise]; +"Coupling" [style=filled, color=darkturquoise]; +"Coupling" -> "OpenCL"; +"Main" [style=filled, color=darkturquoise]; +"Main" -> "Zone"; +"Main" -> "Viewer"; +"Main" -> "Morphogen"; +"Main" -> "Coupling"; +"Main" -> "BoundingBox"; +"Main" -> "Bacterium"; +"Morphogen" [style=filled, color=darkturquoise]; +"Morphogen" -> "Viewer"; +"Morphogen" -> "Packfile"; +"Morphogen" -> "OpenCL"; +"Morphogen" -> "BoundingBox"; +"OpenCL" [style=filled, color=darkturquoise]; +"Packfile" [style=filled, color=darkturquoise]; +"Viewer" [style=filled, color=darkturquoise]; +"Zone" [style=filled, color=darkturquoise]; +"Zone" -> "OpenCL"; +"Zone" -> "BoundingBox"; +} diff --git a/data/speedup2.data b/data/speedup2.data new file mode 100644 index 0000000..43a0623 --- /dev/null +++ b/data/speedup2.data @@ -0,0 +1,987 @@ +ITER NON OPT ACTIVE NONITER OPTITER NONITERNORM OPTITERNORM ACTIVENORM +0 9.553332 10.039998 8 11.3473051258883 0 1 0 3.2E-05 +1 21.873331 10.043332 25 12.319999 0.003334 1.02 0.00029381425484 0.0001 +2 34.793329 10.043332 49 12.919998 0 1.02 0 0.000196 +3 49.443328 10.046665 81 14.649999 0.003333 1.02 0.00029372612819 0.000324 +4 63.409993 10.053332 121 13.966665 0.006667 1.02 0.00058754038303 0.000484 +5 75.409992 10.059998 169 11.999999 0.006666 1.02 0.00058745225638 0.000676 +6 87.969991 10.069998 225 12.559999 0.01 1.02 0.00088126651122 0.0009 +7 99.986656 10.079998 289 12.016665 0.01 1.02 0.00088126651122 0.001156 +8 112.086655 10.096665 361 12.099999 0.016667 1.02 0.00146880689424 0.001444 +9 123.80332 10.113332 441 11.716665 0.016667 1.03255044876417 0.00146880689424 0.001764 +10 135.426653 10.136665 525 11.623333 0.023333 1.02432541216169 0.00205625915062 0.0021 +11 147.013318 10.163332 613 11.586665 0.026667 1.02109398411836 0.00235007340546 0.002452 +12 158.623317 10.196665 707 11.609999 0.033333 1.02315033139563 0.00293752566184 0.002828 +13 170.376649 10.233332 808 11.753332 0.036667 1.03578178868085 0.00323133991668 0.003232 +14 182.199981 10.273332 915 11.823332 0.04 1.02 0.00352506604487 0.00366 +15 193.93998 10.319998 1024 11.739999 0.046666 1.03460679604144 0.00411251830124 0.004096 +16 205.553312 10.373332 1146 11.613332 0.053334 1.02344405752382 0.00470014681092 0.004584 +17 217.136644 10.429998 1268 11.583332 0.056666 1.02080025799017 0.00499378481246 0.005072 +18 228.819977 10.496665 1398 11.683333 0.066667 1.02961301122899 0.00587513945033 0.005592 +19 240.553309 10.566665 1538 11.733332 0.07 1.03401925565842 0.00616886557852 0.006152 +20 252.283308 10.646665 1681 11.729999 0.08 1.03372552953023 0.00705013208973 0.006724 +21 263.939973 10.729998 1831 11.656665 0.083333 1.02726284969688 0.00734385821792 0.007324 +22 275.533305 10.823332 1983 11.593332 0.093334 1.02168152450139 0.00822521285579 0.007932 +23 287.156637 10.929998 2153 11.623332 0.106666 1.02432532403504 0.00940011736854 0.008612 +24 298.926636 11.043332 2311 11.769999 0.113334 1.03725059557509 0.00998774587822 0.009244 +25 310.666635 11.166665 2491 11.739999 0.123333 1.03460679604145 0.01086892426279 0.009964 +26 322.389967 11.303332 2668 11.723332 0.136667 1.0331379891472 0.01204400502884 0.010672 +27 333.976633 11.443332 2853 11.586666 0.14 1.02109407224501 0.01233773115703 0.011412 +28 346.243298 11.596665 3049 12.266665 0.153333 1.02 0.01351272379643 0.012196 +29 357.923297 11.759998 3242 11.679999 0.163333 1.02931919697415 0.01439399030765 0.012968 +30 369.683296 11.933332 3446 11.759999 0.173334 1.03636932906388 0.01527534494552 0.013784 +31 381.433295 12.116665 3656 11.749999 0.183333 1.03548806255266 0.01615652333008 0.014624 +32 393.12996 12.316665 3873 11.696665 0.2 1.03078791574174 0.01762533022433 0.015492 +33 404.729959 12.519998 4097 11.599999 0.203333 1.02226906488442 0.01791905635252 0.016388 +34 416.336625 12.743332 4323 11.606666 0.223334 1.02285660526745 0.0196816775016 0.017292 +35 428.186623 12.976665 4561 11.849998 0.233333 1.02 0.02056285588617 0.018244 +36 440.949955 13.226665 4793 12.763332 0.25 1.02 0.02203166278041 0.019172 +37 452.653288 13.479998 5043 11.703333 0.253333 1.03137554425142 0.0223253889086 0.020172 +38 464.283286 13.743331 5297 11.629998 0.263333 1.02491277629141 0.02320665541982 0.021188 +39 475.866619 14.026665 5548 11.583333 0.283334 1.02080034611683 0.0249692765689 0.022192 +40 487.576617 14.326665 5819 11.709998 0.3 1.03196290838114 0.02643799533649 0.023276 +41 499.313283 14.633331 6081 11.736666 0.306666 1.03431306991326 0.02702544759287 0.024324 +42 511.039948 14.956665 6357 11.726665 0.323334 1.03343171527539 0.02849434261377 0.025428 +43 522.689947 15.286665 6639 11.649999 0.33 1.0266753974405 0.02908179487014 0.026556 +44 534.269946 15.643331 6931 11.579999 0.356666 1.02050653186199 0.03143178014895 0.027724 +45 545.909945 16.009998 7221 11.639999 0.366667 1.02579413092928 0.03231313478682 0.028884 +46 557.659944 16.396665 7516 11.749999 0.386667 1.03548806255266 0.03407566780925 0.030064 +47 569.419943 16.796664 7829 11.759999 0.399999 1.03636932906388 0.03525057232201 0.031316 +48 581.116608 17.226664 8131 11.6966650000001 0.43 1.03078791574175 0.03789445998231 0.032524 +49 592.686607 17.636664 8455 11.5699989999999 0.41 1.01962526535076 0.03613192695987 0.03382 +50 604.243272 18.063331 8771 11.5566650000001 0.426667 1.01845018458472 0.03760073385412 0.035084 +51 615.983271 18.503331 9106 11.7399989999999 0.44 1.03460679604144 0.03877572649352 0.036424 +52 627.719937 18.959998 9434 11.736666 0.456667 1.03431306991326 0.04024453338777 0.037736 +53 639.453269 19.433331 9774 11.733332 0.473333 1.03401925565842 0.04171325215536 0.039096 +54 651.066601 19.919998 10125 11.613332 0.486667 1.02344405752382 0.04288833292142 0.0405 +55 662.653267 20.426664 10471 11.586666 0.506666 1.02109407224501 0.0446507778172 0.041884 +56 674.356599 20.946664 10834 11.7033319999999 0.52 1.03137545612476 0.04582585858325 0.043336 +57 686.106598 21.486664 11194 11.749999 0.54 1.03548806255266 0.04758839160569 0.044776 +58 697.833263 22.039997 11558 11.726665 0.553333 1.03343171527539 0.04876338424509 0.046232 +59 709.426595 22.616664 11943 11.593332 0.576667 1.02168152450139 0.05081973152236 0.047772 +60 720.906594 23.226664 12323 11.479999 0.61 1.01169386674982 0.0537572571842 0.049292 +61 732.459926 23.859997 12711 11.553332 0.633333 1.01815645845652 0.05581351633482 0.050844 +62 744.096592 24.566664 13107 11.636666 0.706667 1.02550040480109 0.06227619616818 0.052428 +63 755.729924 25.28333 13499 11.633332 0.716666 1.02520659054625 0.06315737455274 0.053996 +64 767.323256 26.03333 13910 11.593332 0.75 1.02168152450139 0.06609498834123 0.05564 +65 778.773255 26.776663 14313 11.4499989999999 0.743333 1.00905006721616 0.0655074479582 0.057252 +66 790.213254 27.536663 14729 11.4399990000001 0.76 1.00816880070496 0.06697625485245 0.058916 +67 801.769919 28.259997 15158 11.556665 0.723334 1.01845018458471 0.06374500306242 0.060632 +68 813.346585 28.999997 15579 11.576666 0.74 1.0202128057338 0.06521372183002 0.062316 +69 824.90325 29.766663 16017 11.556665 0.766666 1.01845018458471 0.06756370710883 0.064068 +70 836.343249 30.54333 16450 11.4399990000001 0.776667 1.00816880070496 0.06844506174669 0.0658 +71 847.763248 31.339996 16906 11.419999 0.796666 1.00640626768252 0.07020750664248 0.067624 +72 859.25658 32.16333 17341 11.493332 0.823334 1.01286885938922 0.07255766817459 0.069364 +73 870.816579 33.006663 17808 11.5599990000001 0.843333 1.01874399883956 0.07432011307037 0.071232 +74 882.396578 33.893329 18267 11.5799989999999 0.886666 1.02050653186198 0.07813890524342 0.073068 +75 893.866577 34.799996 18725 11.469999 0.906667 1.01081260023861 0.07990152639251 0.0749 +76 905.216576 35.736663 19208 11.349999 0.936667 1.00023740210401 0.08254532592616 0.076832 +77 916.656575 36.743329 19692 11.4399989999999 1.006666 1.00816880070495 0.08871410337802 0.078768 +78 928.20324 37.826662 20174 11.5466650000001 1.083333 1.0175689180735 0.09547050933956 0.080696 +79 939.733239 38.809996 20675 11.529999 0.983334 1.0161001993059 0.08665793235405 0.0827 +80 951.223238 39.823329 21172 11.489999 1.013333 1.01257513326104 0.08930164376105 0.084688 +81 962.59657 40.856662 21660 11.373332 1.033333 1.00229366125463 0.09106417678348 0.08664 +82 973.963235 41.906662 22174 11.366665 1.05 1.0017061208716 0.09253298367773 0.088696 +83 985.483234 42.983329 22683 11.519999 1.076667 1.01521893279468 0.09488305708319 0.090732 +84 997.0299 44.106662 23210 11.546666 1.123333 1.01756900620014 0.09899557538443 0.09284 +85 1008.519899 45.266662 23734 11.489999 1.16 1.01257513326104 0.10222691530111 0.094936 +86 1019.873231 46.449995 24270 11.353332 1.183333 1.0005311282322 0.10428317445173 0.09708 +87 1031.226563 47.719995 24805 11.3533319999999 1.27 1.00053112823219 0.11192084692449 0.09922 +88 1042.643229 48.996661 25348 11.4166660000001 1.27666600000001 1.00611254155434 0.11250829918086 0.101392 +89 1054.119894 50.239994 25895 11.4766649999999 1.243333 1.01140005249497 0.10957077351903 0.10358 +90 1065.579893 51.499994 26448 11.4599990000002 1.26 1.0099313337274 0.11103958041327 0.105792 +91 1076.986558 52.783328 27021 11.406665 1.283334 1.00523118691646 0.11309592769054 0.108084 +92 1088.286557 54.103327 27573 11.2999989999998 1.319999 0.99583106954791 0.11632709135392 0.110292 +93 1099.613223 55.483327 28148 11.3266660000002 1.38 0.9981811429534 0.12161477854787 0.112592 +94 1111.086555 56.893327 28727 11.473332 1.41 1.01110632636679 0.12425857808152 0.114908 +95 1122.509887 58.379994 29306 11.4233319999998 1.486667 1.0066999938107 0.13101498404306 0.117224 +96 1133.936553 59.883327 29898 11.4266660000001 1.503333 1.00699380806555 0.13248370281065 0.119592 +97 1145.243218 61.343327 30488 11.3066650000001 1.46 0.99641852180431 0.1286649106376 0.121952 +98 1156.549884 62.833327 31099 11.306666 1.48999999999999 0.99641860993095 0.13130871017125 0.124396 +99 1167.963216 64.34666 31686 11.4133320000001 1.513333 1.0058187272995 0.13336496932187 0.126744 +100 1179.399882 65.919993 32304 11.4366659999998 1.57333300000001 1.00787507457675 0.13865256838917 0.129216 +101 1190.803214 67.539993 32922 11.4033320000001 1.61999999999999 1.00493746078828 0.14276517481706 0.131688 +102 1202.093213 69.263326 33546 11.2899990000001 1.72333300000001 0.99494980303671 0.15187156605742 0.134184 +103 1213.369878 70.939992 34170 11.2766649999999 1.676666 0.99377472227064 0.14775895962952 0.13668 +104 1224.696544 72.613326 34817 11.3266659999999 1.673334 0.99818114295338 0.14746532162798 0.139268 +105 1236.103209 74.313325 35450 11.4066650000002 1.69999900000001 1.00523118691648 0.14981521878014 0.1418 +106 1247.519875 76.053325 36091 11.4166659999999 1.73999999999999 1.00611254155432 0.15334037295166 0.144364 +107 1258.879874 77.863325 36749 11.359999 1.81 1.00111866861522 0.15950923853018 0.146996 +108 1270.136539 79.703325 37388 11.2566650000001 1.84 0.99201218924823 0.16215303806382 0.149552 +109 1281.446538 81.646658 38063 11.3099989999998 1.943333 0.99671233605912 0.17125942930418 0.152252 +110 1292.85987 83.506658 38743 11.4133320000001 1.86 1.0058187272995 0.16391557108626 0.154972 +111 1304.256536 85.399991 39399 11.3966660000001 1.893333 1.00435000853191 0.16685309674809 0.157596 +112 1315.639868 87.346657 40076 11.3833319999999 1.94666599999999 1.00317492776583 0.17155315543237 0.160304 +113 1326.936533 89.356657 40781 11.2966650000001 2.01000000000001 0.99553725529309 0.1771345687545 0.163124 +114 1338.199866 91.483324 41451 11.2633329999999 2.126667 0.99259981775789 0.18741604076091 0.165804 +115 1349.576531 93.533323 42156 11.376665 2.049999 1.00258738738282 0.18065954667272 0.168624 +116 1360.969863 95.593323 42856 11.3933320000001 2.06 1.00405619427707 0.18154090131059 0.171424 +117 1372.363196 97.686656 43565 11.393333 2.093333 1.00405628240371 0.18447842697242 0.17426 +118 1383.659861 99.876656 44263 11.2966650000001 2.19 0.99553725529309 0.1929973659564 0.177052 +119 1394.923193 102.143323 45004 11.263332 2.266667 0.99259972963124 0.19975377191794 0.180016 +120 1406.263192 104.419989 45713 11.3399989999998 2.27666600000001 0.99935613559277 0.20063495030251 0.182852 +121 1417.669858 106.656656 46445 11.4066660000001 2.236667 1.00523127504312 0.19710997238429 0.18578 +122 1429.069857 108.926655 47198 11.399999 2.269999 1.00464373466009 0.20004740991948 0.188792 +123 1440.446522 111.296655 47911 11.376665 2.37 1.00258738738282 0.2088601631583 0.191644 +124 1451.693188 113.826655 48663 11.246666 2.53 0.99113101086365 0.22296042733776 0.194652 +125 1462.95652 116.233321 49426 11.263332 2.406666 0.99259972963124 0.21209141494832 0.197704 +126 1474.383185 118.646654 50180 11.426665 2.41333299999999 1.00699371993889 0.21267895533135 0.20072 +127 1485.799851 121.129987 50930 11.4166660000001 2.483333 1.00611254155434 0.21884782090987 0.20372 +128 1497.18985 123.689987 51701 11.389999 2.56 1.00376246814887 0.22560422687141 0.206804 +129 1508.489849 126.35332 52486 11.2999990000001 2.66333299999999 0.99583106954793 0.23471061811176 0.209944 +130 1519.766514 128.926653 53246 11.2766649999999 2.57333299999999 0.99377472227064 0.22677921951081 0.212984 +131 1531.149846 131.52332 54030 11.3833320000001 2.59666700000002 1.00317492776585 0.22883556678809 0.21612 +132 1542.563179 134.246653 54806 11.413333 2.723333 1.00581881542614 0.23999821717906 0.219224 +133 1553.986511 137.076652 55602 11.4233320000001 2.82999899999999 1.00669999381072 0.2493983345476 0.222408 +134 1565.313176 139.813319 56390 11.326665 2.73666700000001 0.99818105482674 0.24117329794512 0.22556 +135 1576.579842 142.556652 57195 11.266666 2.74333300000001 0.99289354388608 0.24176075020149 0.22878 +136 1587.906507 145.433318 57991 11.3266649999998 2.876666 0.99818105482672 0.25351094097549 0.231964 +137 1599.29984 148.509985 58791 11.393333 3.07666699999999 1.00405628240371 0.27113635932647 0.235164 +138 1610.719838 151.393318 59616 11.4199980000001 2.88333299999999 1.00640617955588 0.25409848135852 0.238464 +139 1622.126504 154.309984 60419 11.4066660000001 2.91666599999999 1.00523127504312 0.25703600702036 0.241676 +140 1633.389836 157.35665 61246 11.263332 3.04666600000002 0.99259972963124 0.26849247166618 0.244984 +141 1644.669835 160.479983 62067 11.2799989999999 3.123333 0.99406853652548 0.27524887762772 0.248268 +142 1656.099834 163.529983 62904 11.4299990000002 3.04999999999998 1.00728753419375 0.26878628592101 0.251616 +143 1667.646499 166.619983 63734 11.5466649999998 3.09 1.01756891807348 0.27231135196588 0.254936 +144 1679.039832 169.833316 64576 11.393333 3.21333300000001 1.00405628240371 0.28318027622867 0.258304 +145 1690.333164 173.156649 65416 11.293332 3.32333299999999 0.99524352916489 0.29287420785204 0.261664 +146 1701.616496 176.373315 66271 11.2833320000002 3.216666 0.9943622626537 0.28347400235685 0.265084 +147 1713.006495 179.679982 67116 11.389999 3.306667 1.00376246814887 0.29140548908445 0.268464 +148 1724.419827 183.206648 67968 11.4133319999999 3.52666600000001 1.00581872729948 0.31079326420456 0.271872 +149 1735.796493 186.556648 68832 11.3766660000001 3.34999999999999 1.00258747550948 0.29522428125751 0.275328 +150 1747.123158 189.936647 69691 11.326665 3.379999 0.99818105482674 0.2978679926645 0.278764 +151 1758.393157 193.466647 70568 11.2699989999999 3.53 0.99318727001426 0.3110870784594 0.282272 +152 1769.716489 197.123313 71441 11.3233319999999 3.656666 0.99788732869854 0.32224972885038 0.285764 +153 1781.126488 200.633313 72336 11.4099990000002 3.50999999999999 1.00552500117132 0.30932454543697 0.289344 +154 1792.52982 204.269979 73200 11.4033319999999 3.63666600000002 1.00493746078826 0.32048719582795 0.2928 +155 1803.909819 208.079979 74091 11.379999 3.81 1.00288120163765 0.33576254077346 0.296364 +156 1815.166485 211.726645 74991 11.256666 3.64666599999998 0.99201227737487 0.32136846233916 0.299964 +157 1826.449817 215.463311 75876 11.283332 3.73666600000001 0.99436226265368 0.32929986094011 0.303504 +158 1837.863149 219.439978 76772 11.4133320000001 3.97666699999999 1.0058187272995 0.35045034533595 0.307088 +159 1849.246481 223.216644 77683 11.3833319999999 3.77666600000001 1.00317492776583 0.33282492698497 0.310732 +160 1860.64648 227.08331 78604 11.3999990000002 3.86666600000001 1.00464373466011 0.34075632558592 0.314416 +161 1871.953146 231.219976 79511 11.306666 4.13666599999999 0.99641860993095 0.36455052138876 0.318044 +162 1883.249811 235.143309 80447 11.2966649999998 3.92333299999999 0.99553725529307 0.34575019852503 0.321788 +163 1894.623143 239.146642 81349 11.3733320000001 4.00333300000003 1.00229366125464 0.35280033061477 0.325396 +164 1906.029809 243.379975 82292 11.4066659999999 4.23333299999999 1.0052312750431 0.37306946037274 0.329168 +165 1917.433141 247.433308 83222 11.4033320000001 4.05333300000001 1.00493746078828 0.35720666317085 0.332888 +166 1928.726473 251.569974 84162 11.293332 4.13666599999999 0.99524352916489 0.36455052138876 0.336648 +167 1939.996472 255.986641 85107 11.2699990000001 4.41666699999999 0.99318727001428 0.38922607182948 0.340428 +168 1951.329804 260.189973 86050 11.3333319999999 4.20333200000002 0.99876859520975 0.37042557271244 0.3442 +169 1962.769803 264.50664 87003 11.4399989999999 4.316667 1.00816880070495 0.38041340671731 0.348012 +170 1974.176469 269.059973 87943 11.4066660000001 4.55333300000001 1.00523127504312 0.40126998873167 0.351772 +171 1985.523134 273.403305 88939 11.346665 4.34333199999998 0.99994358784917 0.38276330386947 0.355756 +172 1996.783133 277.886638 89895 11.2599989999999 4.48333300000002 0.99230600350305 0.39510112315315 0.35958 +173 2008.096465 282.603305 90853 11.3133320000002 4.71666699999997 0.99700606218734 0.41566406716597 0.363412 +174 2019.503131 287.073304 91839 11.4066659999999 4.46999900000003 1.0052312750431 0.3939260423871 0.367356 +175 2030.906463 291.75997 92827 11.4033320000001 4.686666 1.00493746078828 0.41302017950567 0.371308 +176 2042.293129 296.563303 93798 11.3866659999999 4.80333300000001 1.00346874202067 0.42330165151208 0.375192 +177 2053.593127 301.229969 94805 11.2999980000002 4.66666599999996 0.99583098142129 0.41125764648323 0.37922 +178 2064.869793 306.236636 95787 11.2766659999998 5.00666699999999 0.99377481039728 0.44122079599125 0.383148 +179 2076.256459 310.966635 96815 11.3866660000003 4.72999900000002 1.00346874202071 0.41683897167873 0.38726 +180 2087.666457 315.856635 97834 11.4099979999996 4.88999999999999 1.00552491304462 0.43093932398484 0.391336 +181 2099.08979 320.959967 98846 11.4233330000002 5.10333200000002 1.00670008193738 0.44973955872192 0.395384 +182 2110.396455 325.866634 99883 11.3066650000001 4.90666699999997 0.99641852180431 0.43240813087908 0.399532 +183 2121.659787 331.149966 100918 11.263332 5.28333200000003 0.99259972963124 0.46560235592382 0.403672 +184 2133.016453 336.146633 101973 11.3566660000001 4.996667 1.00082494248705 0.44033952948003 0.407892 +185 2144.446452 341.296632 103007 11.429999 5.14999899999998 1.00728753419373 0.45385216514981 0.412028 +186 2155.879784 346.713298 104060 11.4333320000001 5.41666600000002 1.00758126032193 0.47735263482447 0.41624 +187 2167.203116 351.886631 105119 11.3233319999999 5.17333300000001 0.99788732869854 0.45590851242709 0.420476 +188 2178.463115 357.469964 106189 11.2599989999999 5.58333299999998 0.99230600350305 0.49204043938696 0.424756 +189 2189.793114 362.733297 107247 11.329999 5.26333299999999 0.99847486908158 0.46383991102803 0.428988 +190 2201.213113 368.196629 108327 11.4199989999997 5.46333199999998 1.0064062676825 0.48146515312571 0.433308 +191 2212.599778 373.809962 109414 11.386665 5.61333300000001 1.00346865389403 0.49468423892061 0.437656 +192 2223.989777 379.299962 110498 11.389999 5.49000000000001 1.00376246814887 0.48381531465782 0.441992 +193 2235.236443 385.143294 111616 11.246666 5.84333200000003 0.99113101086365 0.51495328055194 0.446464 +194 2246.526442 390.713294 112675 11.2899990000001 5.56999999999999 0.99494980303671 0.49086544674756 0.4507 +195 2257.913107 396.723293 113785 11.386665 6.00999899999999 1.00346865389403 0.52964108511443 0.45514 +196 2269.296439 402.369959 114898 11.3833320000003 5.64666599999998 1.00317492776587 0.49762176458245 0.459592 +197 2280.683105 408.259959 116010 11.3866659999999 5.88999999999999 1.00346874202067 0.51906597510648 0.46404 +198 2291.983104 414.296625 117130 11.2999989999998 6.03666600000003 0.99583106954791 0.53199115851989 0.46852 +199 2303.236436 420.246624 118268 11.2533320000002 5.94999899999999 0.99171846312005 0.52435348604713 0.473072 +200 2314.613101 426.48329 119425 11.3766649999998 6.23666600000001 1.0025873873828 0.54961648874422 0.4777 +201 2326.036434 432.506623 120555 11.4233330000002 6.02333299999998 1.00670008193738 0.53081616588048 0.48222 +202 2337.456432 438.856622 121726 11.4199979999999 6.34999900000003 1.00640617955586 0.55960414649579 0.486904 +203 2348.766431 444.956622 122884 11.3099990000001 6.09999999999997 0.99671233605914 0.53757257184202 0.491536 +204 2360.03643 451.469954 124050 11.2699990000001 6.51333199999999 0.99318727001428 0.57399813680344 0.4962 +205 2371.366429 457.669954 125257 11.329999 6.20000000000005 0.99847486908158 0.5463852369542 0.501028 +206 2382.789761 464.389953 126408 11.4233319999998 6.71999899999997 1.0066999938107 0.59221100741079 0.505632 +207 2394.23976 470.703286 127618 11.4499989999999 6.313333 1.00905006721616 0.55637289470576 0.510472 +208 2405.599759 477.593285 128805 11.3599990000002 6.88999899999999 1.00111866861524 0.60719253810147 0.51522 +209 2416.846424 484.013284 130024 11.2466649999997 6.41999900000002 0.99113092273697 0.5657730120743 0.520096 +210 2428.116423 491.20995 131203 11.2699990000001 7.19666599999999 0.99318727001428 0.63421807382099 0.524812 +211 2439.539756 497.74995 132436 11.4233330000002 6.54000000000002 1.00670008193738 0.57634829833555 0.529744 +212 2451.109754 504.606616 133668 11.5699979999999 6.85666599999996 1.01962517722411 0.60425501243963 0.534672 +213 2462.50642 511.263282 134866 11.3966660000001 6.65666600000003 1.00435000853191 0.58662968221531 0.539464 +214 2473.799752 518.416614 136109 11.2933319999997 7.15333199999998 0.99524352916487 0.63039919352129 0.544436 +215 2485.093084 525.20328 137345 11.2933320000002 6.78666599999997 0.99524352916491 0.59808614686112 0.54938 +216 2496.476417 532.659946 138587 11.3833329999998 7.45666600000004 1.00317501589247 0.65713100311263 0.554348 +217 2507.909749 539.579946 139823 11.4333320000001 6.91999999999996 1.00758126032193 0.60983642576177 0.559292 +218 2519.289748 547.129945 141085 11.3799990000002 7.54999900000007 1.00288120163767 0.66535612784177 0.56434 +219 2530.586413 554.216611 142334 11.2966649999998 7.08666599999992 0.99553725529307 0.62452414219761 0.569336 +220 2541.866412 561.853277 143598 11.2799989999999 7.6366660000001 0.99406853652548 0.67299380031453 0.574392 +221 2553.233078 569.089943 144874 11.3666660000004 7.2366659999999 1.00170620899828 0.63774313986585 0.579496 +222 2564.613076 576.823275 146130 11.3799979999999 7.73333200000002 1.00288111351099 0.68151265117185 0.58452 +223 2576.013075 584.229941 147400 11.3999989999998 7.40666600000009 1.00464373466007 0.65272467055655 0.5896 +224 2587.329741 592.11994 148699 11.3166660000002 7.88999899999999 0.99729987644218 0.69531918922312 0.594796 +225 2598.59974 599.713273 149981 11.2699990000001 7.59333299999992 0.99318727001428 0.66917500814146 0.599924 +226 2609.903072 607.623272 151280 11.303332 7.90999900000008 0.99612479567611 0.69708172224556 0.60512 +227 2621.329737 615.396605 152576 11.426665 7.77333299999998 1.00699371993889 0.68503780534336 0.610304 +228 2632.72307 623.406604 153885 11.393333 8.00999899999999 1.00405628240371 0.70589438735771 0.61554 +229 2644.106402 631.716603 155182 11.3833319999999 8.30999899999995 1.00317492776583 0.7323323826942 0.620728 +230 2655.406401 639.506602 156518 11.2999990000003 7.78999900000008 0.99583106954795 0.68650652411096 0.626072 +231 2666.683066 648.039935 157842 11.2766649999999 8.53333299999997 0.99377472227064 0.75201406019581 0.631368 +232 2678.099732 656.046601 159144 11.4166660000001 8.006666 1.00611254155434 0.70560066122953 0.636576 +233 2689.499731 664.8366 160493 11.3999989999998 8.78999899999997 1.00464373466007 0.77463317523259 0.641972 +234 2700.913063 673.073266 161812 11.4133320000001 8.23666600000001 1.0058187272995 0.72586979098751 0.647248 +235 2712.226395 681.269931 163160 11.3133320000002 8.19666500000005 0.99700606218734 0.72234463681599 0.65264 +236 2723.516394 690.03993 164516 11.2899990000001 8.76999899999998 0.99494980303671 0.77287064221016 0.658064 +237 2734.899726 698.30993 165848 11.3833319999999 8.26999999999998 1.00317492776583 0.72880740477599 0.663392 +238 2746.339725 707.373262 167229 11.4399989999997 9.06333199999995 1.00816880070493 0.79872109716362 0.668916 +239 2757.73639 715.899928 168566 11.3966650000002 8.52666600000009 1.00434992040527 0.75142651981279 0.674264 +240 2769.079723 724.849927 169960 11.3433329999998 8.94999899999993 0.99964994984761 0.78873343941205 0.67984 +241 2780.346388 733.693259 171289 11.2666650000001 8.84333200000003 0.99289345575944 0.77933323391687 0.685156 +242 2791.67972 742.536592 172704 11.3333320000002 8.84333300000003 0.99876859520977 0.77933332204352 0.690816 +243 2803.073053 751.976591 174068 11.393333 9.43999899999994 1.00405628240371 0.83191549846166 0.696272 +244 2814.469718 760.86659 175455 11.3966649999998 8.88999899999999 1.00434992040523 0.78344584034476 0.70182 +245 2825.816384 770.906589 176860 11.3466660000004 10.0399990000001 0.99994367597585 0.88479148913466 0.70744 +246 2837.059716 780.076588 178250 11.243332 9.16999899999996 0.99083719660881 0.80812130265882 0.713 +247 2848.376381 789.013254 179670 11.3166649999998 8.93666599999995 0.9972997883155 0.78755844677265 0.71868 +248 2859.78638 798.27992 181048 11.409999 9.26666599999999 1.0055250011713 0.8166402416428 0.724192 +249 2871.176379 807.506585 181839 11.389999 9.22666500000003 1.00376246814887 0.81311508747128 0.727356 +250 2882.569711 816.736584 181933 11.3933320000001 9.22999900000002 1.00405619427707 0.81340890172612 0.727732 +251 2893.84971 826.289917 182127 11.2799989999999 9.55333299999995 0.99406853652548 0.84190324433988 0.728508 +252 2905.113042 835.433249 182316 11.263332 9.1433320000001 0.99259972963124 0.80577122925337 0.729264 +253 2916.529708 844.869915 182439 11.4166660000001 9.43666599999995 1.00611254155434 0.83162177233347 0.729756 +254 2927.96304 854.256581 182561 11.4333320000001 9.38666599999999 1.00758126032193 0.82721543977739 0.730244 +255 2939.349706 863.349913 182647 11.3866659999999 9.09333200000003 1.00346874202067 0.80136489669728 0.730588 +256 2950.666371 872.859912 182705 11.3166649999998 9.50999899999999 0.9972997883155 0.83808436404018 0.73082 +257 2961.953037 882.106578 182739 11.2866660000004 9.246666 0.99465607690856 0.81487770862037 0.730956 +258 2973.339702 891.233244 182767 11.386665 9.126666 1.00346865389403 0.80430251048577 0.731068 +259 2984.729701 900.653243 182743 11.389999 9.41999899999996 1.00376246814887 0.83015296543923 0.730972 +260 2996.103033 909.806575 182696 11.3733319999997 9.15333199999998 1.0022936612546 0.80665249576458 0.730784 +261 3007.406365 919.253241 182653 11.303332 9.44666600000005 0.99612479567611 0.8325030388447 0.730612 +262 3018.683031 928.786573 182548 11.2766660000002 9.53333199999997 0.99377481039732 0.8401406231908 0.730192 +263 3030.036363 937.843239 182430 11.3533320000001 9.05666600000006 1.00053112823221 0.79813364490726 0.72972 +264 3041.426362 947.213238 182313 11.389999 9.36999900000001 1.00376246814887 0.82574663288315 0.729252 +265 3052.843028 956.389904 182130 11.4166659999996 9.17666599999995 1.0061125415543 0.80870884304185 0.72852 +266 3064.173026 965.46657 181937 11.3299980000002 9.07666600000005 0.99847478095494 0.79989617792969 0.727748 +267 3075.446359 974.813235 181741 11.2733330000001 9.34666499999992 0.99348108426912 0.82369028560587 0.726964 +268 3086.756357 983.863234 181496 11.3099980000002 9.04999900000007 0.9967122479325 0.79754610452423 0.725984 +269 3098.153023 992.973234 181249 11.3966659999996 9.11000000000001 1.00435000853187 0.80283379171818 0.724996 +270 3109.559689 1002.173233 180973 11.4066660000003 9.19999899999993 1.00523127504314 0.81076510219247 0.723892 +271 3120.956354 1011.093232 180680 11.3966649999998 8.91999899999996 1.00434992040523 0.78608963987841 0.72272 +272 3132.219686 1020.566564 180359 11.263332 9.47333200000003 0.99259972963124 0.83485302412351 0.721436 +273 3143.479685 1029.576563 180037 11.2599989999999 9.00999900000011 0.99230600350305 0.79402103847937 0.720148 +274 3154.879684 1039.473229 179689 11.3999990000002 9.89666599999987 1.00464373466011 0.87216003184942 0.718756 +275 3166.303016 1048.569895 179318 11.4233319999998 9.09666600000014 1.0066999938107 0.80165871095213 0.717272 +276 3177.709682 1057.42656 178951 11.4066660000003 8.85666500000002 1.00523127504314 0.78050822655627 0.715804 +277 3188.996347 1066.429893 178543 11.2866649999996 9.00333299999988 0.99465598878183 0.79343358622297 0.714172 +278 3200.273013 1075.326559 178139 11.2766660000002 8.8966660000001 0.99377481039732 0.7840333807278 0.712556 +279 3211.626345 1084.189891 177686 11.3533320000001 8.8633319999999 1.00053112823221 0.78109576693929 0.710744 +280 3223.026344 1093.146557 177244 11.3999989999998 8.95666600000004 1.00464373466007 0.78932097979509 0.708976 +281 3234.423009 1101.843223 176789 11.3966650000002 8.69666600000005 1.00434992040527 0.76640805050347 0.707156 +282 3245.713008 1110.749888 176315 11.2899990000001 8.90666499999998 0.99494980303671 0.78491455911235 0.70526 +283 3256.979674 1119.529888 175895 11.266666 8.77999999999997 0.99289354388608 0.77375199684803 0.70358 +284 3268.339673 1128.239887 175400 11.3599989999998 8.70999899999993 1.0011186686152 0.76758304314286 0.7016 +285 3279.749672 1137.083219 174965 11.409999 8.84333200000015 1.0055250011713 0.77933323391688 0.69986 +286 3291.15967 1145.659885 174494 11.4099980000001 8.57666599999993 1.00552491304466 0.75583285236886 0.697976 +287 3302.499669 1154.449884 174037 11.3399989999998 8.78999900000008 0.99935613559277 0.7746331752326 0.696148 +288 3313.773001 1163.073217 173560 11.2733320000002 8.623333 0.99348099614248 0.75994545879676 0.69424 +289 3325.113 1171.693216 173110 11.3399989999998 8.61999899999978 0.99935613559277 0.7596516445419 0.69244 +290 3336.516333 1180.379881 172640 11.4033330000002 8.68666500000018 1.00493754891494 0.76552669586561 0.69056 +291 3347.926331 1188.843214 172155 11.4099980000001 8.46333299999992 1.00552491304466 0.74584519461729 0.68862 +292 3359.319664 1197.516546 171699 11.393333 8.67333200000007 1.00405628240371 0.76435170322619 0.686796 +293 3370.586329 1205.946546 171218 11.2666650000001 8.42999999999984 0.99289345575944 0.74290766895544 0.684872 +294 3381.859661 1214.503211 170755 11.2733319999998 8.55666500000007 0.99348099614244 0.75407023121979 0.68302 +295 3393.286327 1222.996544 170274 11.4266659999998 8.49333300000012 1.00699380806553 0.74848899415095 0.681096 +296 3404.702992 1231.419876 169808 11.4166650000002 8.42333199999985 1.0061124534277 0.74232004044576 0.679232 +297 3416.092991 1239.976542 169325 11.389999 8.55666600000018 1.00376246814887 0.75407031934645 0.6773 +298 3427.40299 1248.229875 168847 11.3099990000001 8.25333299999988 0.99671233605914 0.72733859788174 0.675388 +299 3438.682989 1256.643207 168382 11.2799989999999 8.41333200000008 0.99406853652548 0.74143877393457 0.673528 +300 3450.066321 1264.84654 167884 11.3833319999999 8.20333299999993 1.00317492776583 0.72293226532566 0.671536 +301 3461.479653 1273.129872 167404 11.4133320000001 8.28333199999997 1.0058187272995 0.72998230928875 0.669616 +302 3472.866319 1281.379871 166928 11.3866660000003 8.24999900000012 1.00346874202071 0.72704478362692 0.667712 +303 3484.209651 1289.549871 166436 11.3433319999999 8.16999999999985 0.99964986172097 0.71999473966382 0.665744 +304 3495.47965 1297.843203 165965 11.2699990000001 8.29333199999996 0.99318727001428 0.73086357579996 0.66386 +305 3506.846315 1305.863202 165483 11.3666649999996 8.0199990000001 1.00170612087156 0.70677565386894 0.661932 +306 3518.252981 1314.126535 164984 11.4066660000003 8.2633330000001 1.00523127504314 0.72821986439297 0.659936 +307 3529.64298 1322.136534 164498 11.389999 8.00999899999988 1.00376246814887 0.7058943873577 0.657992 +308 3540.969645 1330.279866 164019 11.326665 8.1433320000001 0.99818105482674 0.71764457813173 0.656076 +309 3552.246311 1338.303199 163530 11.2766659999998 8.02333299999987 0.99377481039728 0.70706946812376 0.65412 +310 3563.58631 1346.369865 163027 11.3399990000003 8.06666599999994 0.99935613559281 0.71088826029682 0.652108 +311 3575.016309 1354.423197 162542 11.429999 8.05333200000018 1.00728753419373 0.70971317953079 0.650168 +312 3586.426308 1362.349863 162052 11.409999 7.92666599999984 1.0055250011713 0.69855052913978 0.648208 +313 3597.762973 1370.433196 161533 11.3366649999998 8.08333300000004 0.99906232133793 0.71235706719107 0.646132 +314 3609.029639 1378.256528 161069 11.266666 7.82333199999994 0.99289354388608 0.68944404977279 0.644276 +315 3620.306304 1386.293194 160547 11.2766650000003 8.0366660000002 0.99377472227068 0.70824446076319 0.642188 +316 3631.72297 1394.083193 160064 11.4166659999996 7.78999899999985 1.0061125415543 0.68650652411094 0.640256 +317 3643.116302 1402.059859 159547 11.3933320000001 7.97666600000002 1.00405619427707 0.70295686169588 0.638188 +318 3654.509634 1409.829859 159052 11.3933320000001 7.76999999999998 1.00405619427707 0.68474407921517 0.636208 +319 3665.7863 1417.693191 158538 11.2766660000002 7.86333200000013 0.99377481039732 0.69296911581767 0.634152 +320 3677.066298 1425.459857 158047 11.279998 7.76666599999999 0.99406844839884 0.68445026496033 0.632188 +321 3688.472964 1433.239856 157536 11.4066659999999 7.77999899999986 1.0052312750431 0.68562525759972 0.630144 +322 3699.886296 1440.993189 157027 11.4133320000001 7.75333300000011 1.0058187272995 0.68327527232094 0.628108 +323 3711.272962 1448.686521 156537 11.3866659999999 7.69333200000005 1.00346874202067 0.67798758512698 0.626148 +324 3722.586294 1456.433187 156018 11.3133320000002 7.746666 0.99700606218734 0.6826877319379 0.624072 +325 3733.856293 1464.029853 155513 11.2699989999996 7.59666599999991 0.99318727001424 0.66946873426965 0.622052 +326 3745.216292 1471.766519 154991 11.3599990000002 7.73666600000001 1.00111866861524 0.68180646542668 0.619964 +327 3756.616291 1479.303185 154488 11.3999989999998 7.53666599999997 1.00464373466007 0.66418113520235 0.617952 +328 3768.032956 1487.009851 153979 11.4166650000002 7.70666600000004 1.0061124534277 0.67916266589304 0.615916 +329 3779.339622 1494.46985 153446 11.306666 7.45999899999993 0.99641860993095 0.6574247292408 0.613784 +330 3790.626287 1502.126516 152963 11.2866650000001 7.65666600000009 0.99465598878187 0.67475633333696 0.611852 +331 3801.959619 1509.526515 152400 11.3333320000002 7.39999899999998 0.99876859520977 0.65213713017351 0.6096 +332 3813.369618 1517.156514 151909 11.409999 7.629999 1.0055250011713 0.67240625993149 0.607636 +333 3824.766284 1524.50318 151356 11.3966659999996 7.34666599999991 1.00435000853187 0.64743707148923 0.605424 +334 3836.096283 1532.079846 150852 11.329999 7.57666600000016 0.99847486908158 0.66770620124723 0.603408 +335 3847.369615 1539.406512 150308 11.2733320000002 7.32666599999993 0.99348099614248 0.6456745384668 0.601232 +336 3858.712947 1546.876511 149788 11.3433319999999 7.46999899999992 0.99964986172097 0.65830599575202 0.599152 +337 3870.126279 1554.143177 149255 11.4133320000001 7.26666599999999 1.0058187272995 0.64038693939951 0.59702 +338 3881.539611 1561.569843 148724 11.4133320000001 7.42666600000007 1.0058187272995 0.65448720357898 0.594896 +339 3892.902944 1568.789843 148194 11.3633329999998 7.22000000000003 1.00141248287004 0.63627442109827 0.592776 +340 3904.149609 1576.159842 147649 11.2466650000001 7.36999900000001 0.99113092273701 0.64949333063986 0.590596 +341 3915.439608 1583.336508 147126 11.2899990000001 7.17666600000007 0.99494980303671 0.63245554079857 0.588504 +342 3926.836273 1590.65984 146579 11.3966649999998 7.32333199999994 1.00434992040523 0.64538072421196 0.586316 +343 3938.239606 1597.78984 146053 11.4033330000002 7.12999999999988 1.00493754891494 0.62834302249731 0.584212 +344 3949.622938 1605.053172 145508 11.3833319999999 7.26333199999999 1.00317492776583 0.64009312514467 0.582032 +345 3960.929603 1612.133172 144963 11.3066650000001 7.08000000000015 0.99641852180431 0.62393668994125 0.579852 +346 3972.199602 1619.356504 144433 11.2699990000001 7.22333200000003 0.99318727001428 0.63656805909981 0.577732 +347 3983.572934 1626.369837 143874 11.3733319999997 7.01333299999988 1.0022936612546 0.6180615504909 0.575496 +348 3994.9896 1633.539836 143324 11.4166660000001 7.16999899999996 1.00611254155434 0.63186800041553 0.573296 +349 4006.366266 1640.486502 142791 11.3766660000001 6.94666600000005 1.00258747550948 0.61218641104059 0.571164 +350 4017.666264 1647.636501 142222 11.299998 7.14999899999998 0.99583098142127 0.6301054673931 0.568888 +351 4028.929597 1654.519834 141680 11.2633329999999 6.88333299999999 0.99259981775789 0.6066050858451 0.56672 +352 4040.292929 1661.623167 141134 11.3633320000004 7.10333300000002 1.00141239474344 0.62599294909186 0.564536 +353 4051.689594 1668.449833 140580 11.3966649999998 6.82666599999993 1.00434992040523 0.60161121290598 0.56232 +354 4063.08626 1675.469832 140003 11.3966660000001 7.0199990000001 1.00435000853191 0.6186490027473 0.560012 +355 4074.399592 1682.259831 139471 11.3133320000002 6.78999900000008 0.99700606218734 0.59837987298932 0.557884 +356 4085.666258 1689.239831 138886 11.266666 6.98000000000002 0.99289354388608 0.61512402482907 0.555544 +357 4096.982923 1695.97983 138339 11.3166649999994 6.7399989999999 0.99729978831546 0.59397354043322 0.553356 +358 4108.406255 1702.849829 137768 11.4233320000003 6.86999900000001 1.00669999381074 0.60543000507904 0.551072 +359 4119.832921 1709.593162 137194 11.4266660000003 6.74333299999989 1.00699380806557 0.59426735468806 0.548776 +360 4131.179586 1716.359828 136646 11.346665 6.76666600000021 0.99994358784917 0.59632361383871 0.546584 +361 4142.426252 1723.069827 136083 11.246666 6.70999899999993 0.99113101086365 0.59132974089957 0.544332 +362 4153.739584 1729.746493 135503 11.3133319999997 6.67666600000007 0.9970060621873 0.58839221523775 0.542012 +363 4165.169583 1736.426493 134956 11.429999 6.67999999999984 1.00728753419373 0.58868602949257 0.539824 +364 4176.612915 1742.993159 134358 11.4433319999998 6.56666600000017 1.00846252683313 0.57869828361437 0.537432 +365 4187.926247 1749.679825 133797 11.3133320000006 6.68666599999983 0.99700606218738 0.58927348174894 0.535188 +366 4199.12958 1756.156491 133225 11.2033329999995 6.47666600000002 0.98731221869055 0.57076688501341 0.5329 +367 4210.372912 1762.833157 132641 11.243332 6.67666600000007 0.99083719660881 0.58839221523775 0.530564 +368 4221.729577 1769.246489 132083 11.3566650000002 6.41333200000008 1.0008248543604 0.56518547169128 0.528332 +369 4233.066243 1775.853155 131474 11.3366660000002 6.6066659999999 0.99906240946461 0.58222334965922 0.525896 +370 4244.419575 1782.249821 130922 11.3533319999997 6.3966660000001 1.00053112823217 0.56371675292369 0.523688 +371 4255.652907 1788.716487 130308 11.2333319999998 6.4666659999998 0.98995593009758 0.56988561850218 0.521232 +372 4266.852906 1795.123153 129740 11.1999990000004 6.40666600000009 0.98701840443579 0.5645980194349 0.51896 +373 4278.186238 1801.469819 129139 11.3333320000002 6.34666599999991 0.99876859520977 0.55931042036759 0.516556 +374 4289.526237 1807.876485 128573 11.3399989999998 6.40666600000009 0.99935613559277 0.5645980194349 0.514292 +375 4300.852903 1814.109818 127984 11.3266659999999 6.2333329999999 0.99818114295338 0.54932276261602 0.511936 +376 4312.102902 1820.516484 127382 11.2499989999997 6.40666600000009 0.99142473699181 0.5645980194349 0.509528 +377 4323.319567 1826.69315 126809 11.2166649999999 6.17666600000007 0.98848712320335 0.54432888967692 0.507236 +378 4334.626233 1833.016483 126180 11.3066660000004 6.32333300000005 0.99641860993099 0.55725416121698 0.50472 +379 4345.966232 1839.189816 125613 11.3399989999998 6.17333299999996 0.99935613559277 0.54403516354873 0.502452 +380 4357.332897 1845.359815 125010 11.3666650000005 6.16999899999996 1.00170612087164 0.54374134929389 0.50004 +381 4368.576229 1851.556481 124400 11.243332 6.19666600000005 0.99083719660881 0.54609142269936 0.4976 +382 4379.776228 1857.593147 123815 11.1999989999995 6.03666599999997 0.98701840443571 0.53199115851989 0.49526 +383 4391.042894 1863.793146 123197 11.2666660000004 6.19999899999993 0.99289354388612 0.54638514882753 0.492788 +384 4402.396226 1869.756479 122609 11.3533319999997 5.96333299999992 1.00053112823217 0.52552856681318 0.490436 +385 4413.752891 1875.853145 121987 11.3566650000002 6.09666600000014 1.0008248543604 0.5372787575872 0.487948 +386 4425.03289 1881.846478 121391 11.2799990000003 5.99333299999989 0.99406853652552 0.52817236634682 0.485564 +387 4436.236223 1887.779811 120760 11.2033329999995 5.93333300000018 0.98731221869055 0.52288476727955 0.48304 +388 4447.516221 1893.793143 120158 11.279998 6.01333199999999 0.99406844839884 0.52993481124262 0.480632 +389 4458.882887 1899.613143 119537 11.3666659999999 5.81999999999994 1.00170620899824 0.51289710952796 0.478148 +390 4470.226219 1905.616476 118915 11.3433320000004 6.00333299999988 0.99964986172101 0.52905363285804 0.47566 +391 4481.556218 1911.409808 118311 11.3299989999996 5.79333200000019 0.99847486908154 0.51054694799587 0.473244 +392 4492.742884 1917.213141 117652 11.1866660000005 5.80333299999984 0.9858434117964 0.51142830263371 0.470608 +393 4503.962882 1923.066474 117050 11.2199979999996 5.85333300000002 0.9887808493315 0.51583463518981 0.4682 +394 4515.319548 1928.72314 116415 11.3566660000006 5.65666600000009 1.00082494248708 0.49850303109367 0.46566 +395 4526.66288 1934.576473 115796 11.3433319999995 5.85333300000002 0.99964986172093 0.51583463518981 0.463184 +396 4537.982879 1940.223139 115164 11.3199990000003 5.64666599999987 0.99759360257038 0.49762176458244 0.460656 +397 4549.202878 1945.859805 114541 11.2199989999999 5.6366660000001 0.98878093745818 0.49674049807124 0.458164 +398 4560.42621 1951.549804 113891 11.2233319999996 5.68999899999994 0.98907466358634 0.5014405567555 0.455564 +399 4571.802876 1957.073137 113263 11.3766660000001 5.52333300000009 1.00258747550948 0.48675284031967 0.453052 +400 4583.172875 1962.739803 112606 11.3699990000005 5.66666599999985 1.00199993512648 0.49938429760487 0.450424 +401 4594.512873 1968.253136 111977 11.3399979999995 5.5133330000001 0.99935604746609 0.48587157380845 0.447908 +402 4605.736206 1973.703135 111326 11.2233329999999 5.44999899999993 0.98907475171302 0.4802901604863 0.445304 +403 4616.956204 1979.283135 110693 11.2199980000005 5.57999999999993 0.98878084933158 0.49174671325877 0.442772 +404 4628.29287 1984.673134 110038 11.3366660000002 5.38999899999999 0.99906240946461 0.47500256141901 0.440152 +405 4639.646202 1990.113134 109371 11.3533319999997 5.44000000000005 1.00053112823217 0.47940898210175 0.437484 +406 4650.996201 1995.536467 108727 11.349999 5.42333299999996 1.00023740210401 0.47794017520749 0.434908 +407 4662.2462 2000.786466 108073 11.2499989999997 5.24999900000012 0.99142473699181 0.46266483026199 0.432292 +408 4673.469532 2006.223132 107429 11.2233320000005 5.43666600000006 0.98907466358642 0.47911516784691 0.429716 +409 4684.799531 2011.483132 106745 11.3299989999996 5.25999999999999 0.99847486908154 0.46354618489985 0.42698 +410 4696.156197 2016.679798 106112 11.3566660000006 5.19666599999982 1.00082494248708 0.45796477157769 0.424448 +411 4707.492862 2022.006464 105423 11.3366649999998 5.32666600000016 0.99906232133793 0.46942123622354 0.421692 +412 4718.759528 2027.136463 104770 11.2666659999995 5.129999 0.99289354388604 0.45208963212738 0.41908 +413 4729.96286 2032.276463 104104 11.203332 5.13999999999987 0.98731213056395 0.45297098676524 0.416416 +414 4741.242859 2037.469796 103419 11.2799990000003 5.19333300000017 0.99406853652552 0.45767104544953 0.413676 +415 4752.606191 2042.493129 102773 11.3633319999999 5.02333299999987 1.0014123947434 0.44268951475883 0.411092 +416 4763.942856 2047.586461 102076 11.3366649999998 5.09333200000015 0.99906232133793 0.44885829221072 0.408304 +417 4775.216189 2052.653128 101409 11.2733330000001 5.06666699999982 0.99348108426912 0.44650839505853 0.405636 +418 4786.416188 2057.56646 100721 11.1999990000004 4.91333200000008 0.98701840443579 0.43299549500882 0.402884 +419 4797.672853 2062.593127 100035 11.2566649999999 5.02666700000009 0.99201218924821 0.44298332901369 0.40014 +420 4809.052852 2067.539793 99350 11.3799989999998 4.94666599999982 1.00288120163763 0.43593310879728 0.3974 +421 4820.402851 2072.343126 98669 11.349999 4.80333300000029 1.00023740210401 0.4233016515121 0.394676 +422 4831.71285 2077.289792 97997 11.3099990000001 4.94666599999982 0.99671233605914 0.43593310879728 0.391988 +423 4842.902849 2082.133125 97270 11.1899990000002 4.8433329999998 0.98613713792456 0.42682671755693 0.38908 +424 4854.166181 2086.829791 96602 11.2633319999995 4.69666600000028 0.9925997296312 0.41390144601691 0.386408 +425 4865.549513 2091.686457 95899 11.3833320000003 4.85666599999968 1.00317492776587 0.42800171019632 0.383596 +426 4876.912845 2096.413123 95214 11.3633319999999 4.72666600000002 1.0014123947434 0.41654524555054 0.380856 +427 4888.249511 2101.019789 94501 11.3366660000002 4.60666600000013 0.99906240946461 0.40597004741595 0.378004 +428 4899.43951 2105.749789 93795 11.1899990000002 4.73000000000002 0.98613713792456 0.41683905980538 0.37518 +429 4910.659508 2110.416455 93105 11.2199979999996 4.66666600000008 0.9887808493315 0.41125764648324 0.37242 +430 4922.046174 2114.906455 92368 11.3866660000003 4.48999999999978 1.00346874202071 0.39568866353616 0.369472 +431 4933.392839 2119.486454 91695 11.346665 4.57999900000004 0.99994358784917 0.40361997401048 0.36678 +432 4944.732838 2124.036454 90953 11.3399989999998 4.55000000000018 0.99935613559277 0.4009762626035 0.363812 +433 4955.952837 2128.429787 90261 11.2199989999999 4.39333299999998 0.98878093745818 0.3871697245522 0.361044 +434 4967.192836 2132.869786 89521 11.2399990000004 4.43999900000017 0.99054347048066 0.39128224285346 0.358084 +435 4978.559502 2137.329786 88835 11.3666659999999 4.45999999999958 1.00170620899824 0.39304486400249 0.35534 +436 4989.906167 2141.633119 88094 11.346665 4.30333300000029 0.99994358784917 0.37923832595128 0.352376 +437 5001.246166 2145.913118 87370 11.3399989999998 4.27999899999986 0.99935613559277 0.37718197867397 0.34948 +438 5012.486165 2150.319784 86664 11.2399990000004 4.40666599999986 0.99054347048066 0.3883447171916 0.346656 +439 5023.729497 2154.529784 85915 11.243332 4.21000000000004 0.99083719660881 0.37101320122212 0.34366 +440 5035.079496 2158.66645 85200 11.349999 4.13666600000033 1.00023740210401 0.36455052138879 0.3408 +441 5046.449495 2162.94645 84468 11.3699989999996 4.27999999999975 1.0019999351264 0.37718206680061 0.337872 +442 5057.79616 2167.126449 83740 11.346665 4.17999899999995 0.99994358784917 0.36836931356182 0.33496 +443 5069.052826 2171.186449 83001 11.2566660000002 4.05999999999995 0.99201227737489 0.35779420355387 0.332004 +444 5080.292825 2175.263115 82266 11.2399990000004 4.07666600000039 0.99054347048066 0.3592629223215 0.329064 +445 5091.586157 2179.399782 81511 11.2933319999993 4.13666699999976 0.99524352916483 0.3645506095154 0.326044 +446 5102.946156 2183.366448 80781 11.3599990000002 3.96666600000026 1.00111866861524 0.34956899069811 0.323124 +447 5114.302821 2187.253114 80017 11.3566650000002 3.88666599999988 1.0008248543604 0.34251885860834 0.320068 +448 5125.53282 2191.283114 79277 11.2299990000001 4.02999999999975 0.98966220396942 0.3551504040202 0.317108 +449 5136.736152 2195.223113 78518 11.203332 3.93999900000017 0.98731213056395 0.34721891729264 0.314072 +450 5148.006151 2199.033113 77783 11.2699989999992 3.80999999999995 0.9931872700142 0.33576254077346 0.311132 +451 5159.352817 2202.819779 77020 11.3466660000004 3.78666599999997 0.99994367597585 0.33370619349619 0.30808 +452 5170.709482 2206.709779 76264 11.3566650000002 3.88999999999987 1.0008248543604 0.34281267286318 0.305056 +453 5181.986148 2210.446445 75521 11.2766659999998 3.73666600000024 0.99377481039728 0.32929986094013 0.302084 +454 5193.182814 2214.103111 74724 11.1966659999998 3.65666599999986 0.98672467830755 0.32224972885036 0.298896 +455 5204.459479 2217.783111 73973 11.2766650000003 3.68000000000029 0.99377472227068 0.32430607612767 0.295892 +456 5215.816145 2221.536444 73209 11.3566659999997 3.75333299999966 1.000824942487 0.33076866783432 0.292836 +457 5227.169477 2225.106444 72441 11.3533320000006 3.57000000000016 1.00053112823225 0.31461214450428 0.289764 +458 5238.479476 2228.606443 71669 11.3099990000001 3.49999900000012 0.99671233605914 0.30844319079911 0.286676 +459 5249.669475 2232.139776 70879 11.1899989999993 3.53333299999986 0.98613713792448 0.31138080458758 0.283516 +460 5260.919473 2235.733109 70117 11.2499980000002 3.5933329999998 0.99142464886521 0.31666840365487 0.280468 +461 5272.269472 2239.156442 69336 11.349999 3.42333300000018 1.00023740210401 0.30168687296423 0.277344 +462 5283.652804 2242.519775 68514 11.3833320000003 3.36333300000024 1.00317492776587 0.29639927389693 0.274056 +463 5294.952803 2245.879775 67732 11.2999989999998 3.35999999999967 0.99583106954791 0.29610554776869 0.270928 +464 5306.146136 2249.303108 66957 11.1933330000002 3.42333300000018 0.9864309521794 0.30168687296423 0.267828 +465 5317.376134 2252.603108 66217 11.2299979999998 3.29999999999973 0.98966211584274 0.2908179487014 0.264868 +466 5328.746133 2255.819774 65441 11.3699989999996 3.21666600000026 1.0019999351264 0.28347400235688 0.261764 +467 5340.126132 2258.97644 64695 11.3799990000007 3.15666599999986 1.00288120163771 0.27818640328954 0.25878 +468 5351.459464 2262.243107 63944 11.3333319999992 3.26666699999987 0.99876859520969 0.28788042303958 0.255776 +469 5362.702797 2265.449773 63214 11.2433330000003 3.20666600000004 0.99083728473549 0.28259273584564 0.252856 +470 5373.959462 2268.519773 62507 11.2566649999999 3.07000000000016 0.99201218924821 0.27054881894346 0.250028 +471 5385.312794 2271.533106 61830 11.3533320000006 3.01333299999988 1.00053112823225 0.26555494600433 0.24732 +472 5396.66946 2274.583105 61172 11.3566659999997 3.0499990000003 1.000824942487 0.26878619779439 0.244688 +473 5408.002792 2277.669772 60498 11.3333320000002 3.08666700000003 0.99876859520977 0.27201762583769 0.241992 +474 5419.222791 2280.649771 59892 11.2199989999999 2.97999899999968 0.98878093745818 0.26261733221582 0.239568 +475 5430.436123 2283.549771 59250 11.2133320000003 2.90000000000009 0.98819339707519 0.25556728825277 0.237 +476 5441.799455 2286.393104 58639 11.3633319999999 2.84333300000026 1.0014123947434 0.25057341531368 0.234556 +477 5453.162788 2289.309771 58035 11.3633329999993 2.91666699999996 1.00141248287 0.25703609514701 0.23214 +478 5464.51612 2292.243104 57432 11.3533320000006 2.93333299999995 1.00053112823225 0.2585048139146 0.229728 +479 5475.769452 2295.053103 56836 11.2533319999993 2.80999900000006 0.99171846311997 0.24763580152517 0.227344 +480 5486.986117 2297.806436 56255 11.2166650000008 2.75333299999966 0.98848712320343 0.24264201671268 0.22502 +481 5498.306116 2300.499769 55682 11.3199989999994 2.69333300000017 0.9975936025703 0.23735441764542 0.222728 +482 5509.666115 2303.259769 55113 11.3599990000002 2.75999999999976 1.00111866861524 0.24322955709572 0.220452 +483 5520.989447 2306.036436 54534 11.3233319999999 2.77666700000009 0.99788732869854 0.24469836398999 0.218136 +484 5532.239446 2308.726435 53993 11.2499989999997 2.68999900000017 0.99142473699181 0.23706060339059 0.215972 +485 5543.449445 2311.336435 53432 11.2099990000006 2.61000000000013 0.98789967094703 0.2300105594275 0.213728 +486 5554.752777 2313.899768 52878 11.3033319999995 2.56333300000006 0.99612479567607 0.2258979529996 0.211512 +487 5566.109443 2316.473101 52345 11.3566660000006 2.57333299999982 1.00082494248708 0.2267792195108 0.20938 +488 5577.439442 2319.106434 51811 11.3299989999996 2.63333299999977 0.99847486908154 0.23206681857809 0.207244 +489 5588.679441 2321.709767 51288 11.2399990000004 2.60333300000002 0.99054347048066 0.22942301904446 0.205152 +490 5599.86944 2324.1931 50755 11.1899990000002 2.48333300000013 0.98613713792456 0.21884782090988 0.20302 +491 5611.162772 2326.6431 50245 11.2933319999993 2.44999999999982 0.99524352916483 0.21591029524801 0.20098 +492 5622.522771 2329.046433 49727 11.3599990000002 2.4033330000002 1.00111866861524 0.21179768882015 0.198908 +493 5633.852769 2331.519766 49227 11.3299980000002 2.47333299999991 0.99847478095494 0.21796655439864 0.196908 +494 5645.082768 2333.999766 48741 11.2299990000001 2.48000000000002 0.98966220396942 0.21855409478168 0.194964 +495 5656.276101 2336.419766 48232 11.1933330000002 2.42000000000007 0.9864309521794 0.21326649571438 0.192928 +496 5667.572766 2338.753099 47742 11.2966649999998 2.33333300000004 0.99553725529307 0.20562882324162 0.190968 +497 5678.919432 2341.049765 47247 11.3466659999995 2.29666600000019 0.99994367597577 0.20239748332496 0.188988 +498 5690.246097 2343.303099 46772 11.3266650000005 2.253334 0.99818105482678 0.19857877927854 0.187088 +499 5701.489429 2345.626432 46276 11.243332 2.32333299999982 0.99083719660881 0.20474755673039 0.185104 +500 5712.679428 2347.959765 45805 11.1899990000002 2.33333300000004 0.98613713792456 0.20562882324162 0.18322 +501 5723.94276 2350.246431 45332 11.2633319999995 2.28666599999997 0.9925997296312 0.20151621681372 0.181328 +502 5735.269426 2352.439764 44842 11.3266659999999 2.19333300000017 0.99818114295338 0.1932910920846 0.179368 +503 5746.632758 2354.599764 44382 11.3633319999999 2.15999999999985 1.0014123947434 0.19035356642274 0.177528 +504 5757.94609 2356.72643 43899 11.3133320000006 2.12666600000011 0.99700606218738 0.18741595263427 0.175596 +505 5769.142756 2358.869764 43439 11.1966659999998 2.14333399999987 0.98672467830755 0.18888484765515 0.173756 +506 5780.382755 2361.05643 42977 11.2399989999994 2.18666600000006 0.99054347048058 0.19270355170157 0.171908 +507 5791.716087 2363.233097 42522 11.3333320000002 2.17666699999972 0.99876859520977 0.19182237331697 0.170088 +508 5803.062753 2365.303096 42067 11.3466660000004 2.06999900000028 0.99994367597585 0.18242207969518 0.168268 +509 5814.356085 2367.336429 41609 11.2933320000002 2.03333299999986 0.99524352916491 0.17919082790511 0.166436 +510 5825.536084 2369.336429 41162 11.179999 2 0.98525587141332 0.17625330224329 0.164648 +511 5836.772749 2371.296429 40704 11.2366649999994 1.96000000000004 0.99024965622574 0.17272823619842 0.162816 +512 5848.126081 2373.299762 40258 11.3533320000006 2.00333300000011 1.00053112823225 0.17654702837149 0.161032 +513 5859.449414 2375.323095 39820 11.3233329999994 2.02333300000009 0.99788741682514 0.17830956139392 0.15928 +514 5870.779412 2377.343095 39384 11.3299980000002 2.01999999999998 0.99847478095494 0.17801583526572 0.157536 +515 5881.956078 2379.263095 38938 11.1766660000003 1.91999999999962 0.98496214528516 0.16920317015352 0.155752 +516 5893.182744 2381.143095 38513 11.2266659999996 1.88000000000011 0.98936847784118 0.1656781041087 0.154052 +517 5904.536076 2382.996428 38074 11.3533320000006 1.85333300000002 1.00053112823225 0.16332803070323 0.152296 +518 5915.902741 2384.813094 37644 11.3666649999996 1.81666600000017 1.00170612087156 0.16009669078657 0.150576 +519 5927.236073 2386.629761 37218 11.3333320000002 1.81666700000005 0.99876859520977 0.16009677891321 0.148872 +520 5938.456072 2388.503094 36805 11.2199989999999 1.873333 0.98878093745818 0.16509056372566 0.14722 +521 5949.672738 2390.356427 36376 11.2166660000003 1.85333300000002 0.98848721133003 0.16332803070323 0.145504 +522 5961.019403 2392.183094 35950 11.346665 1.82666699999982 0.99994358784917 0.1609780454244 0.1438 +523 5972.369402 2393.916427 35536 11.349999 1.73333300000013 1.00023740210401 0.15275283256864 0.142144 +524 5983.689401 2395.62976 35121 11.3199989999994 1.71333299999969 0.9975936025703 0.15099029954617 0.140484 +525 5994.8994 2397.316426 34708 11.2099990000006 1.68666600000006 0.98789967094703 0.14864022614074 0.138832 +526 6006.122732 2398.973093 34288 11.2233319999996 1.6566670000002 0.98907466358634 0.14599651473376 0.137152 +527 6017.519398 2400.626426 33888 11.3966660000006 1.65333299999975 1.00435000853195 0.14570270047888 0.135552 +528 6028.876063 2402.323093 33467 11.3566649999993 1.69666700000016 1.00082485436032 0.14952158077862 0.133868 +529 6040.216062 2404.009759 33073 11.3399990000007 1.68666600000006 0.99935613559285 0.14864022614074 0.132292 +530 6051.459394 2405.689759 32669 11.243332 1.67999999999984 0.99083719660881 0.14805277388435 0.130676 +531 6062.669393 2407.276425 32261 11.2099989999997 1.58666600000015 0.98789967094695 0.13982756102859 0.129044 +532 6074.022725 2408.839759 31872 11.3533319999997 1.56333399999994 1.00053112823217 0.1377713900046 0.127488 +533 6085.366058 2410.369758 31475 11.3433329999998 1.52999899999986 0.99964994984761 0.13483368808945 0.1259 +534 6096.702723 2411.879758 31063 11.3366650000007 1.51000000000022 0.99906232133801 0.1330712431937 0.124252 +535 6107.902722 2413.363091 30695 11.1999989999995 1.48333300000013 0.98701840443571 0.13072116978823 0.12278 +536 6119.116054 2414.853091 30296 11.2133320000003 1.48999999999978 0.98819339707519 0.13130871017123 0.121184 +537 6130.44272 2416.376425 29899 11.3266659999999 1.52333399999998 0.99818114295338 0.13424632395974 0.119596 +538 6141.786052 2417.889758 29533 11.3433320000004 1.51333299999988 0.99964986172101 0.13336496932186 0.118132 +539 6153.102718 2419.383091 29136 11.3166659999997 1.49333300000035 0.99729987644214 0.13160243629947 0.116544 +540 6164.34605 2420.816424 28766 11.243332 1.43333299999995 0.99083719660881 0.12631483723213 0.115064 +541 6175.562715 2422.209757 28382 11.2166649999999 1.39333299999998 0.98848712320335 0.12278977118727 0.113528 +542 6186.879381 2423.579757 27998 11.3166659999997 1.36999999999989 0.99729987644214 0.12073351203664 0.111992 +543 6198.236046 2424.926424 27626 11.3566650000002 1.34666700000025 1.0008248543604 0.11867725288605 0.110504 +544 6209.596045 2426.249757 27255 11.3599990000002 1.32333299999982 1.00111866861524 0.11662090560874 0.10902 +545 6220.846044 2427.549757 26869 11.2499989999997 1.30000000000018 0.99142473699181 0.11456464645815 0.107476 +546 6232.05271 2428.856423 26508 11.206666 1.30666599999995 0.98760594481879 0.11515209871451 0.106032 +547 6243.359375 2430.189756 26132 11.3066650000001 1.33333300000004 0.99641852180431 0.11750217211998 0.104528 +548 6254.716041 2431.506423 25765 11.3566659999997 1.3166669999996 1.000824942487 0.11603345335235 0.10306 +549 6266.03604 2432.809756 25400 11.3199990000003 1.30333300000029 0.99759360257038 0.11485837258635 0.1016 +550 6277.292705 2434.106423 25031 11.2566649999999 1.29666700000007 0.99201218924821 0.11427092032995 0.100124 +551 6288.506037 2435.319756 24674 11.2133320000003 1.21333299999969 0.98819339707519 0.10692697398535 0.098696 +552 6299.806036 2436.516423 24318 11.2999989999998 1.19666700000016 0.99583106954791 0.1054582552178 0.097272 +553 6311.139368 2437.689756 23954 11.3333320000002 1.17333300000018 0.99876859520977 0.10340190794053 0.095816 +554 6322.476034 2438.843089 23595 11.3366660000002 1.15333299999975 0.99906240946461 0.10163937491806 0.09438 +555 6333.749366 2439.976422 23242 11.2733319999998 1.13333300000022 0.99348099614244 0.09987684189567 0.092968 +556 6344.952698 2441.089755 22888 11.203332 1.11333299999978 0.98731213056395 0.09811430887319 0.091552 +557 6356.249364 2442.186422 22537 11.2966660000002 1.09666700000025 0.99553734341975 0.09664559010564 0.090148 +558 6367.596029 2443.309755 22189 11.346665 1.123333 0.99994358784917 0.09899557538443 0.088756 +559 6378.929362 2444.433088 21836 11.3333329999996 1.123333 0.99876868333638 0.09899557538443 0.087344 +560 6390.202694 2445.539755 21502 11.2733319999998 1.10666699999956 0.99348099614244 0.0975268566168 0.086008 +561 6401.399359 2446.629755 21141 11.1966650000004 1.09000000000015 0.98672459018095 0.0960580497226 0.084564 +562 6412.672692 2447.706421 20796 11.2733330000001 1.07666599999993 0.99348108426912 0.09488296895653 0.083184 +563 6424.02269 2448.733088 20458 11.3499979999997 1.02666700000009 1.00023731397733 0.09047672452711 0.081832 +564 6435.352689 2449.733088 20115 11.3299990000005 1 0.99847486908162 0.08812665112164 0.08046 +565 6446.602688 2450.709754 19769 11.2499989999997 0.97666600000002 0.99142473699181 0.08607030384437 0.079076 +566 6457.81602 2451.666421 19440 11.2133320000003 0.95666699999992 0.98819339707519 0.08430785894858 0.07776 +567 6469.089353 2452.606421 19115 11.2733330000001 0.94000000000005 0.99348108426912 0.08283905205435 0.07646 +568 6480.442685 2453.529754 18774 11.3533319999997 0.92333300000018 1.00053112823217 0.08137024516012 0.075096 +569 6491.806017 2454.433087 18463 11.3633319999999 0.90333299999975 1.0014123947434 0.07960771213765 0.073852 +570 6503.099349 2455.319754 18135 11.2933320000002 0.88666700000022 0.99524352916491 0.07813899337009 0.07254 +571 6514.296015 2456.189754 17826 11.1966659999998 0.86999999999989 0.98672467830755 0.07667018647582 0.071304 +572 6525.556014 2457.073087 17506 11.2599989999999 0.88333300000022 0.99230600350305 0.07784517911525 0.070024 +573 6536.896012 2457.959754 17205 11.3399980000004 0.88666699999976 0.99935604746617 0.07813899337005 0.06882 +574 6548.249345 2458.829754 16891 11.353333 0.86999999999989 1.00053121635885 0.07667018647582 0.067564 +575 6559.53601 2459.689754 16595 11.2866649999996 0.86000000000013 0.99465598878183 0.07578891996462 0.06638 +576 6570.739342 2460.533087 16285 11.203332 0.8433329999998 0.98731213056395 0.07432011307035 0.06514 +577 6581.972675 2461.363087 15995 11.2333330000001 0.83000000000038 0.98995601822426 0.073145120431 0.06398 +578 6593.326007 2462.189753 15703 11.3533319999997 0.82666599999993 1.00053112823217 0.07285130617612 0.062812 +579 6604.676006 2462.953087 15410 11.349999 0.76333399999976 1.00023740210401 0.06727006910727 0.06164 +580 6615.996005 2463.709753 15115 11.3199990000003 0.75666600000022 0.99759360257038 0.06668244059763 0.06046 +581 6627.17267 2464.449753 14838 11.176665 0.73999999999978 0.98496205715848 0.06521372183 0.059352 +582 6638.396002 2465.173086 14550 11.2233320000005 0.72333299999991 0.98907466358642 0.06374491493576 0.0582 +583 6649.756001 2465.87642 14268 11.3599989999993 0.70333400000027 1.00111866861516 0.06198247004001 0.057072 +584 6661.106 2466.569753 13987 11.349999 0.69333300000017 1.00023740210401 0.06110111540214 0.055948 +585 6672.445999 2467.249753 13721 11.3399989999998 0.67999999999984 0.99935613559277 0.0599261227627 0.054884 +586 6683.635998 2467.919753 13431 11.1899990000002 0.67000000000007 0.98613713792456 0.05904485625151 0.053724 +587 6694.86933 2468.569753 13163 11.2333320000007 0.65000000000009 0.98995593009766 0.05728232322908 0.052652 +588 6706.192662 2469.203086 12895 11.3233319999999 0.63333299999977 0.99788732869854 0.0558135163348 0.05158 +589 6717.532661 2469.829753 12631 11.3399989999998 0.626667 0.99935613559277 0.05522606407845 0.050524 +590 6728.855993 2470.439752 12366 11.3233319999999 0.60999900000024 0.99788732869854 0.05375716905757 0.049464 +591 6740.035992 2471.059752 12104 11.179999 0.61999999999989 0.98525587141332 0.05463852369541 0.048416 +592 6751.242658 2471.676419 11850 11.206666 0.61666699999978 0.98760594481879 0.05434479756721 0.0474 +593 6762.592657 2472.283086 11593 11.349999 0.60666700000002 1.00023740210401 0.05346353105602 0.046372 +594 6773.935989 2472.876419 11340 11.3433319999995 0.59333300000026 0.99964986172093 0.05228845028998 0.04536 +595 6785.259321 2473.459752 11091 11.3233320000008 0.58333300000004 0.99788732869862 0.05140718377875 0.044364 +596 6796.442653 2474.029752 10833 11.1833319999996 0.56999999999971 0.98554959754148 0.05023219113931 0.043332 +597 6807.645985 2474.583085 10596 11.203332 0.55333300000029 0.98731213056395 0.04876338424512 0.042384 +598 6819.019318 2475.126419 10354 11.3733329999995 0.54333399999996 1.00229374938124 0.04788220586052 0.041416 +599 6830.39265 2475.659752 10124 11.3733320000001 0.53333299999986 1.00229366125464 0.04700085122265 0.040496 +600 6841.709315 2476.186419 9876 11.3166650000003 0.52666700000009 0.99729978831554 0.04641339896629 0.039504 +601 6852.922648 2476.679752 9653 11.2133329999997 0.49333299999989 0.98819348520179 0.04347578517778 0.038612 +602 6864.12598 2477.153085 9416 11.203332 0.47333299999991 0.98731213056395 0.04171325215535 0.037664 +603 6875.469312 2477.619752 9178 11.3433320000004 0.46666700000014 0.99964986172101 0.041125799899 0.036712 +604 6886.809311 2478.073085 8961 11.3399989999998 0.45333299999993 0.99935613559277 0.03995071913292 0.035844 +605 6898.142643 2478.519752 8730 11.3333320000002 0.44666700000016 0.99876859520977 0.03936326687657 0.03492 +606 6909.339309 2478.949752 8515 11.1966659999998 0.42999999999984 0.98672467830755 0.03789445998229 0.03406 +607 6920.552641 2479.369752 8288 11.2133320000003 0.42000000000007 0.98819339707519 0.0370131934711 0.033152 +608 6931.91264 2479.779752 8073 11.3599989999993 0.40999999999985 1.00111866861516 0.03613192695986 0.032292 +609 6943.272639 2480.176418 7852 11.3599990000002 0.3966660000001 1.00111866861524 0.03495684619383 0.031408 +610 6954.605971 2480.563085 7650 11.3333320000002 0.38666699999976 0.99876859520977 0.03407566780923 0.0306 +611 6965.79597 2480.939751 7441 11.1899990000002 0.37666600000011 0.98613713792456 0.0331943131714 0.029764 +612 6977.022635 2481.309751 7226 11.2266650000001 0.36999999999989 0.98936838971458 0.032606860915 0.028904 +613 6988.369301 2481.666418 7031 11.3466659999995 0.35666700000002 0.99994367597577 0.0314318682756 0.028124 +614 6999.7093 2482.016418 6821 11.3399990000007 0.35000000000036 0.99935613559285 0.03084432789261 0.027284 +615 7011.052632 2482.353085 6634 11.3433319999995 0.33666700000003 0.99964986172093 0.02966933525317 0.026536 +616 7022.259297 2482.679751 6425 11.2066649999997 0.32666599999993 0.98760585669211 0.0287879806153 0.0257 +617 7033.479296 2482.996418 6242 11.2199990000008 0.31666700000005 0.98878093745826 0.02790680223074 0.024968 +618 7044.829295 2483.303085 6043 11.3499989999991 0.30666699999983 1.00023740210393 0.02702553571951 0.024172 +619 7056.169294 2483.603084 5849 11.3399990000007 0.29999899999984 0.99935613559285 0.02643790720983 0.023396 +620 7067.505959 2483.893084 5673 11.3366649999998 0.28999999999996 0.99906232133793 0.02555672882527 0.022692 +621 7078.735958 2484.173084 5478 11.2299990000001 0.2800000000002 0.98966220396942 0.02467546231408 0.021912 +622 7089.955957 2484.443084 5287 11.2199989999999 0.26999999999998 0.98878093745818 0.02379419580284 0.021148 +623 7101.302623 2484.706418 5091 11.3466659999995 0.26333400000021 0.99994367597577 0.02320674354649 0.020364 +624 7112.645955 2484.969751 4946 11.3433320000004 0.26333299999988 0.99964986172101 0.0232066554198 0.019784 +625 7123.965954 2485.223084 4821 11.3199990000003 0.25333300000011 0.99759360257038 0.02232538890861 0.019284 +626 7135.175953 2485.473084 4693 11.2099989999997 0.25 0.98789967094695 0.02203166278041 0.018772 +627 7146.382618 2485.713084 4582 11.2066649999997 0.23999999999978 0.98760585669211 0.02115039626918 0.018328 +628 7157.712617 2485.949751 4475 11.3299990000005 0.23666700000012 0.99847486908162 0.02085667014102 0.0179 +629 7169.072616 2486.179751 4367 11.3599990000002 0.23000000000002 1.00111866861524 0.02026912975798 0.017468 +630 7180.425948 2486.403084 4265 11.3533319999997 0.22333299999991 1.00053112823217 0.01968158937494 0.01706 +631 7191.662614 2486.619751 4190 11.2366659999998 0.21666700000014 0.99024974435242 0.01909413711859 0.01676 +632 7202.869279 2486.829751 4131 11.2066649999997 0.21000000000004 0.98760585669211 0.01850659673555 0.016524 +633 7214.202611 2487.039751 4074 11.3333320000002 0.20999999999958 0.99876859520977 0.01850659673551 0.016296 +634 7225.559277 2487.246417 4031 11.3566660000006 0.20666600000004 1.00082494248708 0.01821278248071 0.016124 +635 7236.879276 2487.449751 3991 11.3199989999994 0.20333400000027 0.9975936025703 0.01791914447919 0.015964 +636 7248.139275 2487.649751 3949 11.2599990000008 0.19999999999982 0.99230600350313 0.01762533022431 0.015796 +637 7259.35594 2487.849751 3930 11.2166649999999 0.20000000000027 0.98848712320335 0.01762533022435 0.01572 +638 7270.649272 2488.046417 3905 11.2933319999993 0.19666599999982 0.99524352916483 0.01733151596947 0.01562 +639 7282.009271 2488.243084 3885 11.3599990000002 0.19666700000016 1.00111866861524 0.01733160409615 0.01554 +640 7293.355937 2488.439751 3862 11.3466660000004 0.19666699999971 0.99994367597585 0.01733160409611 0.015448 +641 7304.615936 2488.633084 3843 11.2599989999999 0.19333300000017 0.99230600350305 0.01703778984132 0.015372 +642 7315.822601 2488.826417 3821 11.2066649999997 0.19333300000017 0.98760585669211 0.01703778984132 0.015284 +643 7327.145933 2489.016417 3804 11.3233319999999 0.1899999999996 0.99788732869854 0.01674406371308 0.015216 +644 7338.475932 2489.209751 3781 11.3299990000005 0.19333400000005 0.99847486908162 0.01703787796796 0.015124 +645 7349.792598 2489.399751 3758 11.3166659999997 0.19000000000005 0.99729987644214 0.01674406371312 0.015032 +646 7361.07593 2489.589751 3743 11.283332 0.19000000000005 0.99436226265368 0.01674406371312 0.014972 +647 7372.282596 2489.779751 3718 11.206666 0.19000000000005 0.98760594481879 0.01674406371312 0.014872 +648 7383.559261 2489.969751 3703 11.2766650000003 0.19000000000005 0.99377472227068 0.01674406371312 0.014812 +649 7394.915927 2490.156417 3675 11.3566659999997 0.18666600000006 1.000824942487 0.01645024945828 0.0147 +650 7406.225926 2490.343084 3660 11.3099990000001 0.18666699999994 0.99671233605914 0.01645033758492 0.01464 +651 7417.499258 2490.526417 3636 11.2733319999998 0.18333299999995 0.99348099614244 0.01615652333008 0.014544 +652 7428.689257 2490.69975 3624 11.1899990000002 0.17333300000018 0.98613713792456 0.01527525681888 0.014496 +653 7439.985922 2490.873084 3601 11.2966649999998 0.17333399999961 0.99553725529307 0.01527534494548 0.014404 +654 7451.345921 2491.046417 3581 11.3599990000002 0.17333300000018 1.00111866861524 0.01527525681888 0.014324 +655 7462.672587 2491.216417 3559 11.3266659999999 0.17000000000007 0.99818114295338 0.01498153069069 0.014236 +656 7473.915919 2491.38975 3535 11.243332 0.17333299999973 0.99083719660881 0.01527525681884 0.01414 +657 7485.105918 2491.55975 3520 11.1899990000002 0.17000000000007 0.98613713792456 0.01498153069069 0.01408 +658 7496.38925 2491.72975 3494 11.283332 0.17000000000007 0.99436226265368 0.01498153069069 0.013976 +659 7507.762582 2491.896417 3482 11.3733320000001 0.16666699999996 1.00229366125464 0.01468780456249 0.013928 +660 7519.079248 2492.066417 3456 11.3166659999997 0.17000000000007 0.99729987644214 0.01498153069069 0.013824 +661 7530.325913 2492.233084 3441 11.2466649999997 0.16666699999996 0.99113092273697 0.01468780456249 0.013764 +662 7541.539245 2492.39975 3417 11.2133320000003 0.16666600000008 0.98819339707519 0.01468771643585 0.013668 +663 7552.792578 2492.566417 3402 11.2533329999997 0.16666699999996 0.99171855124665 0.01468780456249 0.013608 +664 7564.12591 2492.72975 3383 11.3333320000002 0.16333299999997 0.99876859520977 0.01439399030765 0.013532 +665 7575.469242 2492.893084 3364 11.3433320000004 0.16333399999985 0.99964986172101 0.01439407843429 0.013456 +666 7586.735907 2493.056417 3345 11.2666650000001 0.16333299999997 0.99289345575944 0.01439399030765 0.01338 +667 7597.942573 2493.216417 3320 11.206666 0.16000000000031 0.98760594481879 0.01410026417949 0.01328 +668 7609.205905 2493.373083 3306 11.2633319999995 0.15666599999986 0.9925997296312 0.01380644992461 0.013224 +669 7620.535904 2493.533083 3283 11.3299990000005 0.15999999999985 0.99847486908162 0.01410026417945 0.013132 +670 7631.899236 2493.68975 3264 11.3633319999999 0.1566670000002 1.0014123947434 0.01380653805129 0.013056 +671 7643.199235 2493.846417 3243 11.2999989999998 0.1566670000002 0.99583106954791 0.01380653805129 0.012972 +672 7654.395901 2494.003083 3227 11.1966659999998 0.15666599999986 0.98672467830755 0.01380644992461 0.012908 +673 7665.682566 2494.156417 3205 11.2866650000005 0.15333400000009 0.99465598878191 0.01351281192309 0.01282 +674 7677.029232 2494.30975 3192 11.3466659999995 0.15333299999975 0.99994367597577 0.01351272379641 0.012768 +675 7688.382564 2494.463083 3170 11.3533319999997 0.1533330000002 1.00053112823217 0.01351272379645 0.01268 +676 7699.665896 2494.616417 3145 11.2833320000009 0.15333400000009 0.99436226265376 0.01351281192309 0.01258 +677 7710.845895 2494.766417 3136 11.179999 0.14999999999964 0.98525587141332 0.01321899766821 0.012544 +678 7722.095894 2494.916417 3110 11.2499989999997 0.15000000000009 0.99142473699181 0.01321899766825 0.01244 +679 7733.425893 2495.066417 3096 11.3299989999996 0.15000000000009 0.99847486908154 0.01321899766825 0.012384 +680 7744.759225 2495.213083 3072 11.3333320000002 0.1466660000001 0.99876859520977 0.01292518341342 0.012288 +681 7756.072557 2495.35975 3059 11.3133320000006 0.14666699999998 0.99700606218738 0.01292527154006 0.012236 +682 7767.259223 2495.50975 3037 11.1866659999996 0.15000000000009 0.98584341179632 0.01321899766825 0.012148 +683 7778.519222 2495.653083 3024 11.2599989999999 0.14333299999998 0.99230600350305 0.01263145728522 0.012096 +684 7789.865887 2495.79975 3001 11.346665 0.14666699999998 0.99994358784917 0.01292527154006 0.012004 +685 7801.209219 2495.943083 2983 11.3433320000004 0.14333299999998 0.99964986172101 0.01263145728522 0.011932 +686 7812.535885 2496.086417 2966 11.3266659999999 0.14333399999987 0.99818114295338 0.01263154541186 0.011864 +687 7823.719217 2496.226417 2943 11.1833319999996 0.13999999999987 0.98554959754148 0.01233773115702 0.011772 +688 7834.922549 2496.36975 2930 11.203332 0.14333299999998 0.98731213056395 0.01263145728522 0.01172 +689 7846.295882 2496.50975 2905 11.3733330000005 0.14000000000033 1.00229374938132 0.01233773115706 0.01162 +690 7857.622547 2496.646417 2893 11.3266649999996 0.13666699999976 0.9981810548267 0.01204400502882 0.011572 +691 7868.922546 2496.786416 2871 11.2999989999998 0.13999899999999 0.99583106954791 0.01233764303038 0.011484 +692 7880.082545 2496.923083 2855 11.1599990000004 0.13666700000022 0.98349333839093 0.01204400502886 0.01142 +693 7891.292544 2497.05975 2836 11.2099989999997 0.13666699999976 0.98789967094695 0.01204400502882 0.011344 +694 7902.655876 2497.193083 2821 11.3633319999999 0.13333300000022 1.0014123947434 0.01175019077402 0.011284 +695 7914.015875 2497.32975 2803 11.3599990000002 0.13666699999976 1.00111866861524 0.01204400502882 0.011212 +696 7925.315874 2497.463083 2786 11.2999989999998 0.13333300000022 0.99583106954791 0.01175019077402 0.011144 +697 7936.502539 2497.593083 2768 11.1866650000002 0.13000000000011 0.98584332366972 0.01145646464582 0.011072 +698 7947.692538 2497.726416 2749 11.1899990000002 0.13333299999977 0.98613713792456 0.01175019077398 0.010996 +699 7959.012537 2497.856416 2737 11.3199989999994 0.13000000000011 0.9975936025703 0.01145646464582 0.010948 +700 7970.362536 2497.98975 2708 11.349999 0.1333340000001 1.00023740210401 0.01175027890066 0.010832 +701 7981.655868 2498.116416 2696 11.2933320000002 0.12666599999966 0.99524352916491 0.01116265039094 0.010784 +702 7992.835867 2498.246416 2674 11.179999 0.13000000000011 0.98525587141332 0.01145646464582 0.010696 +703 8004.025866 2498.373083 2659 11.1899990000002 0.126667 0.98613713792456 0.01116273851763 0.010636 +704 8015.362531 2498.49975 2643 11.3366649999998 0.126667 0.99906232133793 0.01116273851763 0.010572 +705 8026.675863 2498.626416 2626 11.3133320000006 0.12666600000011 0.99700606218738 0.01116265039098 0.010504 +706 8037.979196 2498.74975 2611 11.3033329999998 0.12333399999989 0.99612488380275 0.01086901238943 0.010444 +707 8049.159195 2498.883083 2589 11.179999 0.13333300000022 0.98525587141332 0.01175019077402 0.010356 +708 8060.359193 2499.013083 2578 11.1999980000001 0.12999999999965 0.98701831630911 0.01145646464578 0.010312 +709 8071.715859 2499.143083 2554 11.3566659999997 0.13000000000011 1.000824942487 0.01145646464582 0.010216 +710 8083.052525 2499.26975 2541 11.3366660000002 0.126667 0.99906240946461 0.01116273851763 0.010164 +711 8094.36919 2499.396416 2520 11.3166650000003 0.12666600000011 0.99729978831554 0.01116265039098 0.01008 +712 8105.549189 2499.523083 2507 11.179999 0.126667 0.98525587141332 0.01116273851763 0.010028 +713 8116.755854 2499.64975 2492 11.2066649999997 0.126667 0.98760585669211 0.01116273851763 0.009968 +714 8128.109187 2499.776416 2474 11.353333 0.12666600000011 1.00053121635885 0.01116265039098 0.009896 +715 8139.449186 2499.89975 2455 11.3399989999998 0.12333399999989 0.99935613559277 0.01086901238943 0.00982 +716 8150.792518 2500.026416 2436 11.3433320000004 0.12666600000011 0.99964986172101 0.01116265039098 0.009744 +717 8161.999183 2500.146416 2422 11.2066649999997 0.11999999999989 0.98760585669211 0.01057519813459 0.009688 +718 8173.219182 2500.269749 2403 11.2199989999999 0.123333 0.98878093745818 0.01086892426279 0.009612 +719 8184.569181 2500.393083 2388 11.349999 0.12333399999989 1.00023740210401 0.01086901238943 0.009552 +720 8195.882513 2500.513083 2368 11.3133320000006 0.11999999999989 0.99700606218738 0.01057519813459 0.009472 +721 8207.182512 2500.633083 2358 11.2999989999989 0.12000000000035 0.99583106954783 0.01057519813463 0.009432 +722 8218.392511 2500.753083 2337 11.2099990000006 0.11999999999989 0.98789967094703 0.01057519813459 0.009348 +723 8229.58251 2500.869749 2321 11.1899990000002 0.1166659999999 0.98613713792456 0.01028138387975 0.009284 +724 8240.912509 2500.989749 2306 11.3299989999996 0.11999999999989 0.99847486908154 0.01057519813459 0.009224 +725 8252.235841 2501.106416 2291 11.3233319999999 0.11666700000023 0.99788732869854 0.01028147200643 0.009164 +726 8263.552506 2501.223083 2276 11.3166650000003 0.11666699999978 0.99729978831554 0.01028147200639 0.009104 +727 8274.759172 2501.336416 2256 11.206666 0.11333300000024 0.98760594481879 0.00998765775159 0.009024 +728 8285.952504 2501.453083 2245 11.1933320000007 0.11666699999978 0.9864308640528 0.01028147200639 0.00898 +729 8297.302503 2501.566416 2225 11.349999 0.11333300000024 1.00023740210401 0.00998765775159 0.0089 +730 8308.642502 2501.679749 2212 11.3399989999998 0.11333299999978 0.99935613559277 0.00998765775155 0.008848 +731 8319.949168 2501.793083 2192 11.3066659999986 0.11333400000012 0.99641860993083 0.00998774587823 0.008768 +732 8331.169166 2501.903083 2176 11.2199980000005 0.11000000000013 0.98878084933158 0.00969393162339 0.008704 +733 8342.385832 2502.013083 2160 11.2166660000003 0.10999999999967 0.98848721133003 0.00969393162335 0.00864 +734 8353.705831 2502.123083 2144 11.3199989999994 0.11000000000013 0.9975936025703 0.00969393162339 0.008576 +735 8365.032496 2502.233083 2132 11.3266650000005 0.11000000000013 0.99818105482678 0.00969393162339 0.008528 +736 8376.389162 2502.339749 2115 11.3566659999997 0.10666600000013 1.000824942487 0.00940011736855 0.00846 +737 8387.625827 2502.446416 2102 11.2366650000004 0.10666700000002 0.99024965622582 0.00940020549519 0.008408 +738 8398.845826 2502.556416 2084 11.2199990000008 0.10999999999967 0.98878093745826 0.00969393162335 0.008336 +739 8410.175825 2502.659749 2066 11.3299989999996 0.10333300000002 0.99847486908154 0.00910639124035 0.008264 +740 8421.519157 2502.766416 2052 11.3433320000004 0.10666700000002 0.99964986172101 0.00940020549519 0.008208 +741 8432.829156 2502.869749 2038 11.3099989999992 0.10333300000002 0.99671233605906 0.00910639124035 0.008152 +742 8444.042488 2502.973083 2023 11.2133319999994 0.1033339999999 0.98819339707511 0.009106479367 0.008092 +743 8455.215821 2503.076416 2010 11.1733330000006 0.10333300000002 0.98466841915701 0.00910639124035 0.00804 +744 8466.482486 2503.176416 1992 11.266665000001 0.09999999999991 0.99289345575952 0.00881266511216 0.007968 +745 8477.795818 2503.279749 1976 11.3133319999997 0.10333300000002 0.9970060621873 0.00910639124035 0.007904 +746 8489.069151 2503.379749 1963 11.2733329999992 0.10000000000036 0.99348108426904 0.0088126651122 0.007852 +747 8500.312483 2503.479749 1943 11.243332 0.09999999999991 0.99083719660881 0.00881266511216 0.007772 +748 8511.492482 2503.576416 1929 11.179999 0.0966669999998 0.98525587141332 0.00851893898396 0.007716 +749 8522.795814 2503.673082 1915 11.3033319999995 0.09666599999991 0.99612479567607 0.00851885085732 0.00766 +750 8534.142479 2503.773082 1901 11.3466650000009 0.10000000000036 0.99994358784925 0.0088126651122 0.007604 +751 8545.472478 2503.873082 1889 11.3299989999996 0.09999999999991 0.99847486908154 0.00881266511216 0.007556 +752 8556.739144 2503.969749 1875 11.2666659999995 0.0966669999998 0.99289354388604 0.00851893898396 0.0075 +753 8567.955809 2504.066416 1859 11.2166649999999 0.09666700000025 0.98848712320335 0.008518938984 0.007436 +754 8579.279142 2504.163082 1841 11.3233330000003 0.09666599999991 0.99788741682522 0.00851885085732 0.007364 +755 8590.62914 2504.256416 1829 11.3499979999997 0.09333400000014 1.00023731397733 0.0082252128558 0.007316 +756 8601.995806 2504.353082 1812 11.3666660000017 0.09666599999991 1.0017062089984 0.00851885085732 0.007248 +757 8613.265805 2504.443082 1803 11.2699989999983 0.08999999999969 0.99318727001412 0.00793139860092 0.007212 +758 8624.475804 2504.533082 1784 11.2099990000006 0.09000000000015 0.98789967094703 0.00793139860096 0.007136 +759 8635.762469 2504.616416 1772 11.2866649999996 0.08333399999992 0.99465598878183 0.00734394634456 0.007088 +760 8647.092468 2504.703082 1758 11.3299990000014 0.08666600000015 0.9984748690817 0.00763758434612 0.007032 +761 8658.439134 2504.789749 1742 11.3466659999995 0.08666700000003 0.99994367597577 0.00763767247276 0.006968 +762 8669.699133 2504.873082 1728 11.2599989999999 0.08333300000004 0.99230600350305 0.00734385821792 0.006912 +763 8680.899131 2504.959749 1711 11.1999980000001 0.08666700000003 0.98701831630911 0.00763767247276 0.006844 +764 8692.20913 2505.043082 1698 11.3099989999992 0.08333300000004 0.99671233605906 0.00734385821792 0.006792 +765 8703.542462 2505.126416 1683 11.3333320000002 0.08333399999992 0.99876859520977 0.00734394634456 0.006732 +766 8714.872461 2505.209749 1673 11.3299990000014 0.08333300000004 0.9984748690817 0.00734385821792 0.006692 +767 8726.125794 2505.289749 1660 11.2533329999987 0.07999999999993 0.99171855124657 0.00705013208973 0.00664 +768 8737.312459 2505.373082 1643 11.1866650000011 0.08333300000004 0.9858433236698 0.00734385821792 0.006572 +769 8748.559125 2505.453082 1630 11.2466659999991 0.07999999999993 0.99113101086357 0.00705013208973 0.00652 +770 8759.912457 2505.533082 1615 11.3533320000006 0.07999999999993 1.00053112823225 0.00705013208973 0.00646 +771 8771.219122 2505.613082 1603 11.3066650000001 0.07999999999993 0.99641852180431 0.00705013208973 0.006412 +772 8782.479121 2505.689749 1591 11.2599989999999 0.07666700000027 0.99230600350305 0.00675640596157 0.006364 +773 8793.68912 2505.769749 1577 11.2099989999988 0.07999999999993 0.98789967094687 0.00705013208973 0.006308 +774 8804.952452 2505.846416 1563 11.2633320000004 0.07666699999982 0.99259972963129 0.00675640596153 0.006252 +775 8816.305785 2505.923082 1549 11.3533330000009 0.07666599999993 1.00053121635893 0.00675631783489 0.006196 +776 8827.63245 2505.999749 1535 11.3266649999987 0.07666700000027 0.99818105482662 0.00675640596157 0.00614 +777 8838.925782 2506.073082 1519 11.2933320000011 0.07333299999982 0.99524352916499 0.00646259170669 0.006076 +778 8850.119114 2506.149749 1507 11.1933319999989 0.07666700000027 0.98643086405264 0.00675640596157 0.006028 +779 8861.369113 2506.223082 1492 11.2499990000015 0.07333299999982 0.99142473699197 0.00646259170669 0.005968 +780 8872.715779 2506.296416 1480 11.3466659999995 0.07333400000016 0.99994367597577 0.00646267983337 0.00592 +781 8884.092444 2506.369749 1468 11.3766649999998 0.07333299999982 1.0025873873828 0.00646259170669 0.005872 +782 8895.385777 2506.443082 1460 11.2933329999996 0.07333299999982 0.99524361729151 0.00646259170669 0.00584 +783 8906.575776 2506.513082 1441 11.1899990000002 0.07000000000016 0.98613713792456 0.00616886557853 0.005764 +784 8917.819108 2506.586416 1432 11.243332 0.07333400000016 0.99083719660881 0.00646267983337 0.005728 +785 8929.18244 2506.656416 1414 11.3633320000008 0.06999999999971 1.00141239474348 0.00616886557849 0.005656 +786 8940.562439 2506.726415 1403 11.3799989999989 0.06999900000028 1.00288120163755 0.00616877745189 0.005612 +787 8951.862438 2506.793082 1393 11.2999990000008 0.06666700000005 0.99583106954799 0.00587513945033 0.005572 +788 8963.049103 2506.863082 1378 11.1866649999993 0.06999999999971 0.98584332366964 0.00616886557849 0.005512 +789 8974.285769 2506.929749 1368 11.2366660000007 0.06666700000005 0.9902497443525 0.00587513945033 0.005472 +790 8985.622434 2506.999749 1353 11.3366650000007 0.07000000000016 0.99906232133801 0.00616886557853 0.005412 +791 8996.982433 2507.066415 1343 11.3599989999984 0.06666599999971 1.00111866861508 0.00587505132365 0.005372 +792 9008.305765 2507.133082 1328 11.3233319999999 0.06666700000005 0.99788732869854 0.00587513945033 0.005312 +793 9019.485764 2507.196415 1317 11.179999 0.06333300000006 0.98525587141332 0.00558132519549 0.005268 +794 9030.699096 2507.263082 1302 11.2133320000012 0.06666700000005 0.98819339707527 0.00587513945033 0.005208 +795 9042.022429 2507.326415 1288 11.3233330000003 0.06333300000006 0.99788741682522 0.00558132519549 0.005152 +796 9053.369094 2507.389749 1280 11.3466649999991 0.06333399999994 0.99994358784909 0.00558141332213 0.00512 +797 9064.702426 2507.453082 1263 11.3333320000002 0.06333300000006 0.99876859520977 0.00558132519549 0.005052 +798 9075.882425 2507.513082 1256 11.179999 0.05999999999995 0.98525587141332 0.00528759906729 0.005024 +799 9087.082424 2507.576415 1241 11.1999990000004 0.06333300000006 0.98701840443579 0.00558132519549 0.004964 +800 9098.42909 2507.636415 1230 11.3466659999995 0.05999999999995 0.99994367597577 0.00528759906729 0.00492 +801 9109.789089 2507.696415 1220 11.3599990000002 0.05999999999995 1.00111866861524 0.00528759906729 0.00488 +802 9121.139087 2507.756415 1210 11.3499979999997 0.05999999999995 1.00023731397733 0.00528759906729 0.00484 +803 9132.31242 2507.816415 1198 11.1733330000006 0.05999999999995 0.98466841915701 0.00528759906729 0.004792 +804 9143.545752 2507.876415 1185 11.2333319999998 0.0600000000004 0.98995593009758 0.00528759906733 0.00474 +805 9154.895751 2507.933082 1171 11.349999 0.05666699999983 1.00023740210401 0.0049938729391 0.004684 +806 9166.292416 2507.993082 1159 11.3966650000002 0.05999999999995 1.00434992040527 0.00528759906729 0.004636 +807 9177.619082 2508.049749 1145 11.326665999999 0.05666699999983 0.9981811429533 0.0049938729391 0.00458 +808 9188.802414 2508.106415 1134 11.1833320000005 0.0566660000004 0.98554959754156 0.00499378481249 0.004536 +809 9200.019079 2508.159749 1124 11.2166649999999 0.05333399999972 0.98848712320335 0.0047001468109 0.004496 +810 9211.365745 2508.216415 1112 11.3466659999995 0.05666599999995 0.99994367597577 0.00499378481245 0.004448 +811 9222.709077 2508.269749 1104 11.3433320000004 0.05333400000018 0.99964986172101 0.00470014681094 0.004416 +812 9234.022409 2508.323082 1092 11.3133319999997 0.05333299999984 0.9970060621873 0.00470005868426 0.004368 +813 9245.219075 2508.379749 1080 11.1966660000016 0.05666700000029 0.98672467830771 0.00499387293914 0.00432 +814 9256.435741 2508.433082 1071 11.2166659999984 0.05333299999984 0.98848721132987 0.00470005868426 0.004284 +815 9267.809073 2508.486415 1053 11.373332000001 0.05333299999984 1.00229366125472 0.00470005868426 0.004212 +816 9279.142405 2508.536415 1044 11.3333320000002 0.05000000000018 0.99876859520977 0.0044063325561 0.004176 +817 9290.462404 2508.589749 1034 11.3199989999994 0.05333400000018 0.9975936025703 0.00470014681094 0.004136 +818 9301.649069 2508.639749 1025 11.1866649999993 0.04999999999973 0.98584332366964 0.00440633255606 0.0041 +819 9312.869068 2508.689749 1015 11.2199990000008 0.05000000000018 0.98878093745826 0.0044063325561 0.00406 +820 9324.2224 2508.739749 1002 11.3533320000006 0.04999999999973 1.00053112823225 0.00440633255606 0.004008 +821 9335.579066 2508.789749 992 11.3566659999997 0.05000000000018 1.000824942487 0.0044063325561 0.003968 +822 9346.902398 2508.836415 978 11.3233319999999 0.04666600000019 0.99788732869854 0.00411251830126 0.003912 +823 9358.102397 2508.886415 973 11.1999990000004 0.04999999999973 0.98701840443579 0.00440633255606 0.003892 +824 9369.312396 2508.933082 956 11.2099989999988 0.04666700000007 0.98789967094687 0.0041126064279 0.003824 +825 9380.695728 2508.983082 947 11.3833320000012 0.05000000000018 1.00317492776595 0.0044063325561 0.003788 +826 9392.032394 2509.029749 936 11.3366659999992 0.04666699999962 0.99906240946453 0.00411260642786 0.003744 +827 9403.369059 2509.076415 926 11.3366650000007 0.04666600000019 0.99906232133801 0.00411251830126 0.003704 +828 9414.565725 2509.119749 918 11.1966659999998 0.04333399999996 0.98672467830755 0.0038188802997 0.003672 +829 9425.779057 2509.166415 906 11.2133319999994 0.04666600000019 0.98819339707511 0.00411251830126 0.003624 +830 9437.149056 2509.209749 895 11.3699990000005 0.04333399999996 1.00199993512648 0.0038188802997 0.00358 +831 9448.499055 2509.256415 888 11.349999 0.04666599999973 1.00023740210401 0.00411251830122 0.003552 +832 9459.829054 2509.299749 879 11.3299989999996 0.04333399999996 0.99847486908154 0.0038188802997 0.003516 +833 9471.025719 2509.343082 868 11.1966649999995 0.04333300000008 0.98672459018087 0.00381879217306 0.003472 +834 9482.242385 2509.386415 859 11.2166660000003 0.04333300000008 0.98848721133003 0.00381879217306 0.003436 +835 9493.56905 2509.429749 846 11.3266650000005 0.04333399999996 0.99818105482678 0.0038188802997 0.003384 +836 9504.919049 2509.469749 835 11.349999 0.03999999999996 1.00023740210401 0.00352506604486 0.00334 +837 9516.245715 2509.513082 822 11.326665999999 0.04333300000008 0.9981811429533 0.00381879217306 0.003288 +838 9527.469047 2509.553082 814 11.2233320000014 0.03999999999996 0.9890746635865 0.00352506604486 0.003256 +839 9538.695712 2509.593082 805 11.2266650000001 0.03999999999996 0.98936838971458 0.00352506604486 0.00322 +840 9550.019044 2509.633082 795 11.3233319999999 0.03999999999996 0.99788732869854 0.00352506604486 0.00318 +841 9561.352377 2509.673082 791 11.3333329999987 0.03999999999996 0.9987686833363 0.00352506604486 0.003164 +842 9572.745709 2509.713082 776 11.3933320000015 0.04000000000042 1.00405619427719 0.0035250660449 0.003104 +843 9583.972374 2509.753082 770 11.2266650000001 0.03999999999996 0.98936838971458 0.00352506604486 0.00308 +844 9595.172373 2509.789749 760 11.1999989999986 0.03666699999985 0.98701840443563 0.00323133991666 0.00304 +845 9606.509039 2509.826415 746 11.3366660000011 0.03666599999997 0.99906240946469 0.00323125179002 0.002984 +846 9617.845704 2509.866415 739 11.3366649999989 0.03999999999996 0.99906232133785 0.00352506604486 0.002956 +847 9629.20237 2509.903082 727 11.3566660000015 0.03666699999985 1.00082494248717 0.00323133991666 0.002908 +848 9640.439035 2509.939749 724 11.2366649999985 0.03666700000031 0.99024965622566 0.0032313399167 0.002896 +849 9651.662368 2509.973082 713 11.2233329999999 0.03333299999986 0.98907475171302 0.00293752566183 0.002852 +850 9662.982367 2510.009748 706 11.3199990000012 0.03666599999997 0.99759360257046 0.00323125179002 0.002824 +851 9674.339032 2510.046415 694 11.3566649999993 0.03666699999985 1.00082485436032 0.00323133991666 0.002776 +852 9685.662364 2510.079748 684 11.3233319999999 0.03333300000031 0.99788732869854 0.00293752566187 0.002736 +853 9696.892363 2510.113082 675 11.229999000001 0.03333399999974 0.9896622039695 0.00293761378847 0.0027 +854 9708.095695 2510.146415 662 11.2033319999991 0.03333300000031 0.98731213056387 0.00293752566187 0.002648 +855 9719.422361 2510.179748 657 11.3266660000008 0.03333299999986 0.99818114295346 0.00293752566183 0.002628 +856 9730.77236 2510.213082 648 11.349999 0.0333340000002 1.00023740210401 0.00293761378851 0.002592 +857 9742.102359 2510.246415 640 11.3299989999996 0.03333299999986 0.99847486908154 0.00293752566183 0.00256 +858 9753.359024 2510.276415 630 11.256664999999 0.02999999999975 0.99201218924813 0.00264379953363 0.00252 +859 9764.56569 2510.309748 622 11.206666 0.03333300000031 0.98760594481879 0.00293752566187 0.002488 +860 9775.882355 2510.339748 614 11.3166650000003 0.02999999999975 0.99729978831554 0.00264379953363 0.002456 +861 9787.252354 2510.369748 607 11.3699990000005 0.0300000000002 1.00199993512648 0.00264379953367 0.002428 +862 9798.592353 2510.399748 597 11.3399989999998 0.02999999999975 0.99935613559277 0.00264379953363 0.002388 +863 9809.865685 2510.429748 591 11.2733320000007 0.0300000000002 0.99348099614252 0.00264379953367 0.002364 +864 9821.075684 2510.459748 582 11.2099989999988 0.0300000000002 0.98789967094687 0.00264379953367 0.002328 +865 9832.38235 2510.489748 573 11.3066660000004 0.02999999999975 0.99641860993099 0.00264379953363 0.002292 +866 9843.745682 2510.519748 566 11.3633320000008 0.0300000000002 1.00141239474348 0.00264379953367 0.002264 +867 9855.079014 2510.546415 555 11.3333320000002 0.02666699999963 0.99876859520977 0.00235007340543 0.00222 +868 9866.339013 2510.576415 548 11.2599989999999 0.0300000000002 0.99230600350305 0.00264379953367 0.002192 +869 9877.535678 2510.603082 537 11.1966649999995 0.02666700000009 0.98672459018087 0.00235007340547 0.002148 +870 9888.829011 2510.629748 531 11.2933329999996 0.02666599999975 0.99524361729151 0.00234998527879 0.002124 +871 9900.172343 2510.656415 524 11.3433320000004 0.02666700000009 0.99964986172101 0.00235007340547 0.002096 +872 9911.499008 2510.683082 515 11.3266650000005 0.02666700000009 0.99818105482678 0.00235007340547 0.00206 +873 9922.765674 2510.709748 510 11.2666659999995 0.0266660000002 0.99289354388604 0.00234998527883 0.00204 +874 9933.952339 2510.733082 498 11.1866649999993 0.02333399999998 0.98584332366964 0.00205634727727 0.001992 +875 9945.222338 2510.759748 494 11.2699990000001 0.02666599999975 0.99318727001428 0.00234998527879 0.001976 +876 9956.562337 2510.783082 484 11.3399989999998 0.02333399999998 0.99935613559277 0.00205634727727 0.001936 +877 9967.875669 2510.809748 476 11.3133319999997 0.0266660000002 0.9970060621873 0.00234998527883 0.001904 +878 9979.129002 2510.833082 471 11.2533330000006 0.02333399999998 0.99171855124673 0.00205634727727 0.001884 +879 9990.319 2510.856415 462 11.1899979999998 0.02333300000009 0.98613704979788 0.00205625915063 0.001848 +880 10001.578999 2510.879748 458 11.2599989999999 0.02333299999964 0.99230600350305 0.00205625915059 0.001832 +881 10012.922332 2510.903082 447 11.3433330000007 0.02333399999998 0.99964994984769 0.00205634727727 0.001788 +882 10024.228997 2510.926415 440 11.3066650000001 0.02333300000009 0.99641852180431 0.00205625915063 0.00176 +883 10035.462329 2510.946415 433 11.2333319999998 0.01999999999998 0.98995593009758 0.00176253302243 0.001732 +884 10046.632328 2510.969748 426 11.1699989999997 0.02333300000009 0.98437460490209 0.00205625915063 0.001704 +885 10057.872327 2510.989748 418 11.2399989999994 0.01999999999998 0.99054347048058 0.00176253302243 0.001672 +886 10069.198993 2511.013082 411 11.3266660000008 0.02333399999998 0.99818114295346 0.00205634727727 0.001644 +887 10080.512325 2511.033082 406 11.3133319999997 0.01999999999998 0.9970060621873 0.00176253302243 0.001624 +888 10091.755657 2511.053082 397 11.243332 0.01999999999998 0.99083719660881 0.00176253302243 0.001588 +889 10102.938989 2511.073082 391 11.1833320000005 0.01999999999998 0.98554959754156 0.00176253302243 0.001564 +890 10114.185655 2511.093082 383 11.2466659999991 0.01999999999998 0.99113101086357 0.00176253302243 0.001532 +891 10125.508987 2511.113082 379 11.3233319999999 0.01999999999998 0.99788732869854 0.00176253302243 0.001516 +892 10136.828986 2511.133082 371 11.3199990000012 0.01999999999998 0.99759360257046 0.00176253302243 0.001484 +893 10148.108985 2511.153082 366 11.2799990000003 0.01999999999998 0.99406853652552 0.00176253302243 0.001464 +894 10159.288984 2511.169748 359 11.179999 0.01666599999999 0.98525587141332 0.00146871876759 0.001436 +895 10170.598982 2511.189748 353 11.3099979999988 0.01999999999998 0.99671224793238 0.00176253302243 0.001412 +896 10181.938981 2511.206415 344 11.3399989999998 0.01666700000033 0.99935613559277 0.00146880689427 0.001376 +897 10193.312314 2511.223082 338 11.3733330000014 0.01666699999987 1.0022937493814 0.00146880689423 0.001352 +898 10204.632312 2511.243082 332 11.319997999999 0.01999999999998 0.99759351444362 0.00176253302243 0.001328 +899 10215.828978 2511.259748 323 11.1966659999998 0.01666599999999 0.98672467830755 0.00146871876759 0.001292 +900 10227.11231 2511.276415 317 11.2833320000009 0.01666699999987 0.99436226265376 0.00146880689423 0.001268 +901 10238.468976 2511.293082 312 11.3566659999997 0.01666700000033 1.000824942487 0.00146880689427 0.001248 +902 10249.788975 2511.306415 305 11.3199989999994 0.01333299999988 0.9975936025703 0.00117499263939 0.00122 +903 10261.088973 2511.323082 302 11.2999980000004 0.01666699999987 0.99583098142131 0.00146880689423 0.001208 +904 10272.265639 2511.339748 293 11.1766659999994 0.01666599999999 0.98496214528508 0.00146871876759 0.001172 +905 10283.485638 2511.353082 288 11.2199990000008 0.01333400000021 0.98878093745826 0.00117508076607 0.001152 +906 10294.825637 2511.369748 284 11.3399989999998 0.01666599999999 0.99935613559277 0.00146871876759 0.001136 +907 10306.175636 2511.383082 280 11.349999 0.01333399999976 1.00023740210401 0.00117508076603 0.00112 +908 10317.492301 2511.399748 273 11.3166650000003 0.01666599999999 0.99729978831554 0.00146871876759 0.001092 +909 10328.678967 2511.413082 268 11.1866659999996 0.01333400000021 0.98584341179632 0.00117508076607 0.001072 +910 10339.902299 2511.426415 260 11.2233319999996 0.01333299999988 0.98907466358634 0.00117499263939 0.00104 +911 10351.235631 2511.439748 252 11.3333320000002 0.01333299999988 0.99876859520977 0.00117499263939 0.001008 +912 10362.592297 2511.453082 247 11.3566659999997 0.01333400000021 1.000824942487 0.00117508076607 0.000988 +913 10373.912295 2511.466415 243 11.3199980000009 0.01333299999988 0.99759351444378 0.00117499263939 0.000972 +914 10385.098961 2511.479748 237 11.1866659999996 0.01333300000033 0.98584341179632 0.00117499263943 0.000948 +915 10396.312293 2511.493082 233 11.2133320000012 0.01333399999976 0.98819339707527 0.00117508076603 0.000932 +916 10407.645625 2511.503082 228 11.3333319999983 0.01000000000022 0.99876859520961 0.00088126651124 0.000912 +917 10418.978958 2511.516415 222 11.3333330000005 0.01333299999988 0.99876868333646 0.00117499263939 0.000888 +918 10430.33229 2511.526415 216 11.3533320000006 0.00999999999976 1.00053112823225 0.0008812665112 0.000864 +919 10441.512289 2511.539748 212 11.179999 0.01333300000033 0.98525587141332 0.00117499263943 0.000848 +920 10452.725621 2511.549748 204 11.2133319999994 0.00999999999976 0.98819339707511 0.0008812665112 0.000816 +921 10464.068953 2511.559748 201 11.3433320000004 0.01000000000022 0.99964986172101 0.00088126651124 0.000804 +922 10475.435619 2511.569748 195 11.3666659999999 0.00999999999976 1.00170620899824 0.0008812665112 0.00078 +923 10486.782284 2511.583082 195 11.3466650000009 0.01333400000021 0.99994358784925 0.00117508076607 0.00078 +924 10497.982283 2511.593082 189 11.1999989999986 0.00999999999976 0.98701840443563 0.0008812665112 0.000756 +925 10509.175615 2511.603082 184 11.1933320000007 0.01000000000022 0.9864308640528 0.00088126651124 0.000736 +926 10520.535614 2511.613082 178 11.3599990000002 0.00999999999976 1.00111866861524 0.0008812665112 0.000712 +927 10531.855613 2511.619748 173 11.3199989999994 0.00666600000022 0.9975936025703 0.0005874522564 0.000692 +928 10543.185612 2511.629748 168 11.3299989999996 0.00999999999976 0.99847486908154 0.0008812665112 0.000672 +929 10554.392277 2511.639748 161 11.2066650000015 0.01000000000022 0.98760585669227 0.00088126651124 0.000644 +930 10565.612276 2511.649748 157 11.219998999999 0.00999999999976 0.9887809374581 0.0008812665112 0.000628 +931 10576.982275 2511.656415 154 11.3699990000005 0.00666700000011 1.00199993512648 0.00058754038304 0.000616 +932 10588.312274 2511.666415 149 11.3299989999996 0.01000000000022 0.99847486908154 0.00088126651124 0.000596 +933 10599.662273 2511.673082 145 11.349999 0.00666699999965 1.00023740210401 0.000587540383 0.00058 +934 10610.878938 2511.679748 140 11.2166649999999 0.00666600000022 0.98848712320335 0.0005874522564 0.00056 +935 10622.095604 2511.689748 138 11.2166660000003 0.00999999999976 0.98848721133003 0.0008812665112 0.000552 +936 10633.465603 2511.696415 135 11.3699990000005 0.00666700000011 1.00199993512648 0.00058754038304 0.00054 +937 10644.805602 2511.703082 131 11.3399989999998 0.00666700000011 0.99935613559277 0.00058754038304 0.000524 +938 10656.152267 2511.709748 127 11.3466649999991 0.00666600000022 0.99994358784909 0.0005874522564 0.000508 +939 10667.392266 2511.716415 124 11.2399990000013 0.00666699999965 0.99054347048074 0.000587540383 0.000496 +940 10678.618932 2511.723082 117 11.2266659999987 0.00666700000011 0.9893684778411 0.00058754038304 0.000468 +941 10689.955597 2511.729748 113 11.3366650000007 0.00666600000022 0.99906232133801 0.0005874522564 0.000452 +942 10701.298929 2511.736415 109 11.3433320000004 0.00666699999965 0.99964986172101 0.000587540383 0.000436 +943 10712.632262 2511.743082 106 11.3333329999987 0.00666700000011 0.9987686833363 0.00058754038304 0.000424 +944 10723.83226 2511.749748 102 11.1999980000001 0.00666600000022 0.98701831630911 0.0005874522564 0.000408 +945 10735.052259 2511.753082 99 11.2199990000008 0.003334 0.98878093745826 0.00029381425484 0.000396 +946 10746.385592 2511.759748 97 11.3333330000005 0.00666599999977 0.99876868333646 0.00058745225636 0.000388 +947 10757.748924 2511.766415 92 11.363331999999 0.00666700000011 1.00141239474332 0.00058754038304 0.000368 +948 10769.118923 2511.769748 89 11.3699990000005 0.00333300000011 1.00199993512648 0.0002937261282 0.000356 +949 10780.338921 2511.776415 83 11.2199980000005 0.00666699999965 0.98878084933158 0.000587540383 0.000332 +950 10791.542254 2511.779748 78 11.2033329999995 0.00333300000011 0.98731221869055 0.0002937261282 0.000312 +951 10802.898919 2511.786415 78 11.3566649999993 0.00666700000011 1.00082485436032 0.00058754038304 0.000312 +952 10814.235585 2511.789748 75 11.3366660000011 0.00333300000011 0.99906240946469 0.0002937261282 0.0003 +953 10825.568917 2511.793082 74 11.3333320000002 0.003334 0.99876859520977 0.00029381425484 0.000296 +954 10836.818916 2511.796415 71 11.2499989999997 0.00333299999966 0.99142473699181 0.00029372612816 0.000284 +955 10848.042248 2511.803082 68 11.2233319999996 0.00666700000011 0.98907466358634 0.00058754038304 0.000272 +956 10859.368914 2511.806415 65 11.3266660000008 0.00333300000011 0.99818114295346 0.0002937261282 0.00026 +957 10870.715579 2511.809748 61 11.3466649999991 0.00333300000011 0.99994358784909 0.0002937261282 0.000244 +958 10882.035578 2511.813082 57 11.3199990000012 0.003334 0.99759360257046 0.00029381425484 0.000228 +959 10893.29891 2511.816415 52 11.2633319999986 0.00333299999966 0.99259972963112 0.00029372612816 0.000208 +960 10904.515576 2511.819748 49 11.2166660000003 0.00333300000011 0.98848721133003 0.0002937261282 0.000196 +961 10915.842241 2511.823082 49 11.3266650000005 0.003334 0.99818105482678 0.00029381425484 0.000196 +962 10927.188907 2511.826415 47 11.3466659999995 0.00333300000011 0.99994367597577 0.0002937261282 0.000188 +963 10938.505572 2511.829748 45 11.3166650000003 0.00333300000011 0.99729978831554 0.0002937261282 0.00018 +964 10949.772238 2511.833082 40 11.2666659999995 0.003334 0.99289354388604 0.00029381425484 0.00016 +965 10960.98557 2511.833082 40 11.2133320000012 0 0.98819339707527 0 0.00016 +966 10972.298902 2511.836415 38 11.3133319999997 0.00333300000011 0.9970060621873 0.0002937261282 0.000152 +967 10983.642234 2511.839748 36 11.3433320000004 0.00333299999966 0.99964986172101 0.00029372612816 0.000144 +968 10994.9589 2511.839748 32 11.3166659999988 0 0.99729987644206 0 0.000128 +969 11006.195566 2511.843082 30 11.2366660000007 0.003334 0.9902497443525 0.00029381425484 0.00012 +970 11017.398898 2511.846415 27 11.2033319999991 0.00333300000011 0.98731213056387 0.0002937261282 0.000108 +971 11028.68223 2511.846415 24 11.2833320000009 0 0.99436226265376 0 9.6E-05 +972 11040.025562 2511.849748 23 11.3433320000004 0.00333300000011 0.99964986172101 0.0002937261282 9.2E-05 +973 11051.368894 2511.849748 21 11.3433319999986 0 0.99964986172085 0 8.4E-05 +974 11062.622227 2511.853082 20 11.2533330000006 0.003334 0.99171855124673 0.00029381425484 8E-05 +975 11073.828892 2511.853082 19 11.2066649999997 0 0.98760585669211 0 7.6E-05 +976 11085.108891 2511.853082 18 11.2799990000003 0 0.99406853652552 0 7.2E-05 +977 11096.462223 2511.856415 13 11.3533320000006 0.00333300000011 1.00053112823225 0.0002937261282 5.2E-05 +978 11107.785555 2511.856415 10 11.3233319999999 0 0.99788732869854 0 4E-05 +979 11119.065554 2511.856415 9 11.2799990000003 0 0.99406853652552 0 3.6E-05 +980 11130.28222 2511.859748 8 11.2166659999984 0.00333299999966 0.98848721132987 0.00029372612816 3.2E-05 +981 11141.548885 2511.859748 7 11.266665000001 0 0.99289345575952 0 2.8E-05 +982 11152.898884 2511.859748 6 11.349999 0 1.00023740210401 0 2.4E-05 +983 11164.21555 2511.859748 4 11.3166660000006 0 0.99729987644222 0 1.6E-05 +984 11175.455549 2511.859748 2 11.2399989999994 0 0.99054347048058 0 8E-06 +985 11186.648881 2511.859748 0 11.1933319999989 0 0.98643086405264 0 0 diff --git a/data/stablePopulation.data b/data/stablePopulation.data new file mode 100644 index 0000000..1a1014b --- /dev/null +++ b/data/stablePopulation.data @@ -0,0 +1,1144 @@ + 1000 1 + 2000 1 + 3000 1 + 4000 1 + 5000 2 + 6000 2 + 7000 2 + 8000 2 + 9000 4 + 10000 4 + 11000 4 + 12000 4 + 13000 8 + 14000 8 + 15000 8 + 16000 8 + 17000 14 + 18000 16 + 19000 16 + 20000 16 + 21000 26 + 22000 27 + 23000 28 + 24000 28 + 25000 39 + 26000 46 + 27000 50 + 28000 53 + 29000 67 + 30000 69 + 31000 72 + 32000 75 + 33000 86 + 34000 110 + 35000 117 + 36000 125 + 37000 133 + 38000 151 + 39000 166 + 40000 177 + 41000 190 + 42000 215 + 43000 242 + 44000 263 + 45000 285 + 46000 314 + 47000 347 + 48000 374 + 49000 404 + 50000 430 + 51000 454 + 52000 490 + 53000 512 + 54000 527 + 55000 542 + 56000 556 + 57000 563 + 58000 581 + 59000 589 + 60000 617 + 61000 650 + 62000 656 + 63000 662 + 64000 675 + 65000 690 + 66000 694 + 67000 712 + 68000 725 + 69000 742 + 70000 769 + 71000 769 + 72000 774 + 73000 788 + 74000 796 + 75000 810 + 76000 822 + 77000 855 + 78000 856 + 79000 875 + 80000 903 + 81000 899 + 82000 893 + 83000 908 + 84000 910 + 85000 928 + 86000 951 + 87000 966 + 88000 988 + 89000 993 + 90000 1001 + 91000 1010 + 92000 1025 + 93000 1049 + 94000 1052 + 95000 1085 + 96000 1109 + 97000 1110 + 98000 1121 + 99000 1115 +100000 1125 +101000 1149 +102000 1181 +103000 1204 +104000 1226 +105000 1239 +106000 1267 +107000 1267 +108000 1278 +109000 1295 +110000 1318 +111000 1345 +112000 1367 +113000 1378 +114000 1415 +115000 1435 +116000 1449 +117000 1461 +118000 1480 +119000 1489 +120000 1510 +121000 1528 +122000 1553 +123000 1590 +124000 1611 +125000 1628 +126000 1624 +127000 1639 +128000 1663 +129000 1690 +130000 1715 +131000 1738 +132000 1774 +133000 1795 +134000 1823 +135000 1822 +136000 1827 +137000 1835 +138000 1863 +139000 1899 +140000 1914 +141000 1943 +142000 1966 +143000 1987 +144000 2003 +145000 2008 +146000 2039 +147000 2070 +148000 2105 +149000 2104 +150000 2132 +151000 2138 +152000 2165 +153000 2175 +154000 2211 +155000 2233 +156000 2251 +157000 2285 +158000 2296 +159000 2318 +160000 2359 +161000 2364 +162000 2366 +163000 2388 +164000 2428 +165000 2472 +166000 2476 +167000 2502 +168000 2520 +169000 2553 +170000 2550 +171000 2585 +172000 2634 +173000 2653 +174000 2674 +175000 2693 +176000 2697 +177000 2715 +178000 2731 +179000 2766 +180000 2810 +181000 2850 +182000 2858 +183000 2873 +184000 2897 +185000 2909 +186000 2926 +187000 2973 +188000 2986 +189000 3009 +190000 3053 +191000 3076 +192000 3122 +193000 3142 +194000 3129 +195000 3151 +196000 3166 +197000 3160 +198000 3229 +199000 3271 +200000 3291 +201000 3299 +202000 3309 +203000 3324 +204000 3348 +205000 3359 +206000 3419 +207000 3451 +208000 3476 +209000 3500 +210000 3505 +211000 3506 +212000 3520 +213000 3570 +214000 3592 +215000 3657 +216000 3648 +217000 3662 +218000 3686 +219000 3712 +220000 3715 +221000 3753 +222000 3782 +223000 3807 +224000 3808 +225000 3821 +226000 3845 +227000 3871 +228000 3880 +229000 3916 +230000 3899 +231000 3935 +232000 3947 +233000 3966 +234000 4011 +235000 4033 +236000 4041 +237000 4062 +238000 4104 +239000 4152 +240000 4142 +241000 4130 +242000 4185 +243000 4185 +244000 4199 +245000 4183 +246000 4227 +247000 4265 +248000 4322 +249000 4297 +250000 4325 +251000 4346 +252000 4353 +253000 4378 +254000 4428 +255000 4472 +256000 4472 +257000 4481 +258000 4485 +259000 4531 +260000 4522 +261000 4554 +262000 4543 +263000 4559 +264000 4586 +265000 4609 +266000 4689 +267000 4680 +268000 4702 +269000 4701 +270000 4711 +271000 4718 +272000 4720 +273000 4728 +274000 4787 +275000 4842 +276000 4853 +277000 4832 +278000 4856 +279000 4881 +280000 4872 +281000 4946 +282000 4921 +283000 4949 +284000 4974 +285000 4995 +286000 4999 +287000 5005 +288000 4981 +289000 5040 +290000 5071 +291000 5062 +292000 5116 +293000 5140 +294000 5130 +295000 5149 +296000 5152 +297000 5144 +298000 5143 +299000 5179 +300000 5232 +301000 5253 +302000 5270 +303000 5275 +304000 5297 +305000 5285 +306000 5276 +307000 5262 +308000 5328 +309000 5381 +310000 5403 +311000 5445 +312000 5406 +313000 5389 +314000 5403 +315000 5404 +316000 5456 +317000 5455 +318000 5524 +319000 5519 +320000 5498 +321000 5497 +322000 5527 +323000 5548 +324000 5574 +325000 5609 +326000 5632 +327000 5644 +328000 5636 +329000 5601 +330000 5602 +331000 5600 +332000 5668 +333000 5675 +334000 5748 +335000 5724 +336000 5735 +337000 5699 +338000 5688 +339000 5734 +340000 5765 +341000 5793 +342000 5799 +343000 5758 +344000 5822 +345000 5817 +346000 5823 +347000 5836 +348000 5835 +349000 5840 +350000 5863 +351000 5898 +352000 5896 +353000 5874 +354000 5900 +355000 5921 +356000 5891 +357000 5934 +358000 5956 +359000 5986 +360000 5971 +361000 5939 +362000 5952 +363000 5947 +364000 5944 +365000 5992 +366000 6011 +367000 6016 +368000 6035 +369000 5982 +370000 6008 +371000 5963 +372000 6007 +373000 6029 +374000 6043 +375000 6015 +376000 6050 +377000 6012 +378000 6028 +379000 6041 +380000 6068 +381000 6114 +382000 6072 +383000 6038 +384000 6048 +385000 6041 +386000 6078 +387000 6097 +388000 6088 +389000 6095 +390000 6102 +391000 6136 +392000 6085 +393000 6050 +394000 6059 +395000 6112 +396000 6134 +397000 6144 +398000 6138 +399000 6133 +400000 6086 +401000 6070 +402000 6092 +403000 6107 +404000 6146 +405000 6162 +406000 6148 +407000 6139 +408000 6159 +409000 6142 +410000 6128 +411000 6142 +412000 6138 +413000 6148 +414000 6144 +415000 6191 +416000 6175 +417000 6164 +418000 6128 +419000 6146 +420000 6161 +421000 6144 +422000 6178 +423000 6185 +424000 6203 +425000 6164 +426000 6187 +427000 6168 +428000 6183 +429000 6185 +430000 6169 +431000 6189 +432000 6214 +433000 6189 +434000 6178 +435000 6171 +436000 6145 +437000 6142 +438000 6183 +439000 6202 +440000 6155 +441000 6175 +442000 6129 +443000 6115 +444000 6146 +445000 6198 +446000 6196 +447000 6145 +448000 6130 +449000 6161 +450000 6152 +451000 6125 +452000 6161 +453000 6191 +454000 6177 +455000 6162 +456000 6154 +457000 6155 +458000 6140 +459000 6165 +460000 6177 +461000 6201 +462000 6167 +463000 6154 +464000 6184 +465000 6195 +466000 6111 +467000 6157 +468000 6188 +469000 6216 +470000 6202 +471000 6191 +472000 6212 +473000 6178 +474000 6141 +475000 6149 +476000 6173 +477000 6207 +478000 6221 +479000 6206 +480000 6202 +481000 6180 +482000 6144 +483000 6202 +484000 6241 +485000 6195 +486000 6220 +487000 6191 +488000 6194 +489000 6174 +490000 6197 +491000 6243 +492000 6242 +493000 6255 +494000 6235 +495000 6216 +496000 6217 +497000 6235 +498000 6289 +499000 6243 +500000 6254 +501000 6290 +502000 6250 +503000 6255 +504000 6276 +505000 6264 +506000 6276 +507000 6254 +508000 6287 +509000 6280 +510000 6237 +511000 6256 +512000 6261 +513000 6265 +514000 6306 +515000 6322 +516000 6331 +517000 6256 +518000 6261 +519000 6248 +520000 6267 +521000 6292 +522000 6348 +523000 6345 +524000 6329 +525000 6325 +526000 6297 +527000 6282 +528000 6275 +529000 6318 +530000 6311 +531000 6356 +532000 6343 +533000 6322 +534000 6300 +535000 6317 +536000 6293 +537000 6296 +538000 6339 +539000 6337 +540000 6336 +541000 6366 +542000 6354 +543000 6310 +544000 6304 +545000 6293 +546000 6317 +547000 6380 +548000 6373 +549000 6338 +550000 6309 +551000 6302 +552000 6298 +553000 6284 +554000 6316 +555000 6346 +556000 6346 +557000 6360 +558000 6368 +559000 6328 +560000 6305 +561000 6297 +562000 6293 +563000 6374 +564000 6343 +565000 6357 +566000 6341 +567000 6337 +568000 6318 +569000 6314 +570000 6300 +571000 6315 +572000 6345 +573000 6314 +574000 6354 +575000 6361 +576000 6308 +577000 6304 +578000 6319 +579000 6356 +580000 6342 +581000 6370 +582000 6347 +583000 6326 +584000 6314 +585000 6321 +586000 6314 +587000 6402 +588000 6355 +589000 6376 +590000 6315 +591000 6277 +592000 6312 +593000 6320 +594000 6361 +595000 6351 +596000 6341 +597000 6364 +598000 6333 +599000 6308 +600000 6272 +601000 6327 +602000 6328 +603000 6308 +604000 6332 +605000 6326 +606000 6309 +607000 6331 +608000 6329 +609000 6304 +610000 6283 +611000 6299 +612000 6341 +613000 6341 +614000 6325 +615000 6320 +616000 6321 +617000 6301 +618000 6305 +619000 6305 +620000 6277 +621000 6331 +622000 6328 +623000 6320 +624000 6305 +625000 6288 +626000 6325 +627000 6314 +628000 6312 +629000 6309 +630000 6328 +631000 6318 +632000 6271 +633000 6287 +634000 6294 +635000 6313 +636000 6316 +637000 6310 +638000 6305 +639000 6323 +640000 6320 +641000 6275 +642000 6275 +643000 6298 +644000 6321 +645000 6326 +646000 6318 +647000 6293 +648000 6314 +649000 6309 +650000 6251 +651000 6291 +652000 6267 +653000 6302 +654000 6322 +655000 6332 +656000 6312 +657000 6261 +658000 6299 +659000 6298 +660000 6257 +661000 6252 +662000 6277 +663000 6328 +664000 6293 +665000 6305 +666000 6305 +667000 6292 +668000 6289 +669000 6300 +670000 6301 +671000 6310 +672000 6293 +673000 6267 +674000 6292 +675000 6224 +676000 6270 +677000 6272 +678000 6298 +679000 6313 +680000 6289 +681000 6270 +682000 6263 +683000 6241 +684000 6216 +685000 6245 +686000 6238 +687000 6303 +688000 6290 +689000 6256 +690000 6227 +691000 6247 +692000 6242 +693000 6226 +694000 6221 +695000 6272 +696000 6259 +697000 6252 +698000 6223 +699000 6225 +700000 6215 +701000 6183 +702000 6183 +703000 6238 +704000 6206 +705000 6230 +706000 6202 +707000 6203 +708000 6186 +709000 6183 +710000 6166 +711000 6178 +712000 6218 +713000 6221 +714000 6208 +715000 6187 +716000 6177 +717000 6139 +718000 6146 +719000 6192 +720000 6224 +721000 6215 +722000 6224 +723000 6172 +724000 6165 +725000 6147 +726000 6138 +727000 6163 +728000 6166 +729000 6183 +730000 6173 +731000 6233 +732000 6180 +733000 6182 +734000 6163 +735000 6139 +736000 6140 +737000 6144 +738000 6169 +739000 6175 +740000 6185 +741000 6201 +742000 6171 +743000 6156 +744000 6146 +745000 6140 +746000 6143 +747000 6164 +748000 6176 +749000 6147 +750000 6123 +751000 6127 +752000 6098 +753000 6113 +754000 6137 +755000 6192 +756000 6162 +757000 6169 +758000 6143 +759000 6147 +760000 6065 +761000 6078 +762000 6095 +763000 6140 +764000 6130 +765000 6157 +766000 6160 +767000 6142 +768000 6088 +769000 6065 +770000 6093 +771000 6093 +772000 6142 +773000 6153 +774000 6182 +775000 6120 +776000 6097 +777000 6100 +778000 6103 +779000 6118 +780000 6141 +781000 6124 +782000 6135 +783000 6174 +784000 6155 +785000 6136 +786000 6128 +787000 6132 +788000 6178 +789000 6155 +790000 6190 +791000 6232 +792000 6187 +793000 6208 +794000 6210 +795000 6212 +796000 6253 +797000 6210 +798000 6161 +799000 6143 +800000 6178 +801000 6199 +802000 6235 +803000 6266 +804000 6275 +805000 6215 +806000 6206 +807000 6196 +808000 6158 +809000 6206 +810000 6237 +811000 6261 +812000 6272 +813000 6257 +814000 6213 +815000 6155 +816000 6164 +817000 6158 +818000 6242 +819000 6232 +820000 6237 +821000 6212 +822000 6217 +823000 6173 +824000 6165 +825000 6220 +826000 6231 +827000 6238 +828000 6243 +829000 6213 +830000 6197 +831000 6180 +832000 6208 +833000 6231 +834000 6228 +835000 6257 +836000 6253 +837000 6243 +838000 6209 +839000 6226 +840000 6240 +841000 6214 +842000 6190 +843000 6235 +844000 6238 +845000 6299 +846000 6281 +847000 6245 +848000 6246 +849000 6252 +850000 6215 +851000 6215 +852000 6223 +853000 6281 +854000 6317 +855000 6262 +856000 6243 +857000 6304 +858000 6212 +859000 6202 +860000 6245 +861000 6285 +862000 6318 +863000 6316 +864000 6313 +865000 6311 +866000 6253 +867000 6258 +868000 6285 +869000 6363 +870000 6338 +871000 6313 +872000 6302 +873000 6301 +874000 6289 +875000 6306 +876000 6335 +877000 6360 +878000 6301 +879000 6292 +880000 6295 +881000 6327 +882000 6348 +883000 6394 +884000 6408 +885000 6341 +886000 6340 +887000 6298 +888000 6300 +889000 6326 +890000 6376 +891000 6415 +892000 6394 +893000 6365 +894000 6320 +895000 6336 +896000 6336 +897000 6343 +898000 6392 +899000 6390 +900000 6373 +901000 6368 +902000 6387 +903000 6408 +904000 6397 +905000 6368 +906000 6377 +907000 6408 +908000 6388 +909000 6401 +910000 6401 +911000 6415 +912000 6432 +913000 6437 +914000 6430 +915000 6383 +916000 6392 +917000 6368 +918000 6354 +919000 6420 +920000 6440 +921000 6453 +922000 6412 +923000 6464 +924000 6421 +925000 6397 +926000 6422 +927000 6448 +928000 6425 +929000 6435 +930000 6460 +931000 6461 +932000 6433 +933000 6438 +934000 6421 +935000 6432 +936000 6468 +937000 6484 +938000 6517 +939000 6514 +940000 6444 +941000 6415 +942000 6420 +943000 6434 +944000 6458 +945000 6468 +946000 6462 +947000 6435 +948000 6415 +949000 6467 +950000 6442 +951000 6430 +952000 6458 +953000 6462 +954000 6424 +955000 6453 +956000 6447 +957000 6468 +958000 6482 +959000 6457 +960000 6462 +961000 6432 +962000 6441 +963000 6444 +964000 6429 +965000 6430 +966000 6402 +967000 6432 +968000 6471 +969000 6451 +970000 6439 +971000 6389 +972000 6384 +973000 6411 +974000 6434 +975000 6456 +976000 6420 +977000 6423 +978000 6387 +979000 6374 +980000 6343 +981000 6368 +982000 6395 +983000 6378 +984000 6424 +985000 6431 +986000 6368 +987000 6401 +988000 6346 +989000 6322 +990000 6330 +991000 6348 +992000 6352 +993000 6385 +994000 6393 +995000 6373 +996000 6332 +997000 6339 +998000 6322 +999000 6299 +1000000 6333 +1001000 6371 +1002000 6373 +1003000 6349 +1004000 6330 +1005000 6331 +1006000 6309 +1007000 6337 +1008000 6337 +1009000 6350 +1010000 6329 +1011000 6300 +1012000 6305 +1013000 6339 +1014000 6319 +1015000 6353 +1016000 6355 +1017000 6309 +1018000 6278 +1019000 6252 +1020000 6266 +1021000 6326 +1022000 6336 +1023000 6320 +1024000 6292 +1025000 6288 +1026000 6260 +1027000 6280 +1028000 6249 +1029000 6259 +1030000 6291 +1031000 6265 +1032000 6264 +1033000 6258 +1034000 6270 +1035000 6231 +1036000 6253 +1037000 6248 +1038000 6264 +1039000 6230 +1040000 6260 +1041000 6257 +1042000 6229 +1043000 6217 +1044000 6225 +1045000 6249 +1046000 6259 +1047000 6212 +1048000 6224 +1049000 6202 +1050000 6183 +1051000 6208 +1052000 6169 +1053000 6225 +1054000 6233 +1055000 6175 +1056000 6131 +1057000 6188 +1058000 6193 +1059000 6199 +1060000 6155 +1061000 6194 +1062000 6176 +1063000 6191 +1064000 6154 +1065000 6210 +1066000 6174 +1067000 6160 +1068000 6177 +1069000 6154 +1070000 6146 +1071000 6142 +1072000 6148 +1073000 6119 +1074000 6126 +1075000 6128 +1076000 6146 +1077000 6117 +1078000 6125 +1079000 6154 +1080000 6164 +1081000 6126 +1082000 6077 +1083000 6078 +1084000 6058 +1085000 6081 +1086000 6072 +1087000 6092 +1088000 6116 +1089000 6099 +1090000 6102 +1091000 6093 +1092000 6047 +1093000 6037 +1094000 6047 +1095000 6098 +1096000 6113 +1097000 6088 +1098000 6002 +1099000 5996 +1100000 6053 +1101000 6096 +1102000 6106 +1103000 6098 +1104000 6046 +1105000 6010 +1106000 5965 +1107000 5974 +1108000 5991 +1109000 6075 +1110000 6102 +1111000 6092 +1112000 6019 +1113000 5960 +1114000 5962 +1115000 5967 +1116000 6031 +1117000 6050 +1118000 6050 +1119000 6017 +1120000 5980 +1121000 5914 +1122000 5954 +1123000 5970 +1124000 5985 +1125000 6032 +1126000 6079 +1127000 6009 +1128000 5966 +1129000 5939 +1130000 5941 +1131000 5956 +1132000 5987 +1133000 5999 +1134000 6025 +1135000 6011 +1136000 5961 +1137000 5933 +1138000 5871 +1139000 5940 +1140000 6008 +1141000 6032 +1142000 6036 +1143000 6019 +1144000 5968 diff --git a/data/stablePopulation.sh b/data/stablePopulation.sh new file mode 100755 index 0000000..bcdb6bf --- /dev/null +++ b/data/stablePopulation.sh @@ -0,0 +1,6 @@ +#!/bin/sh + +zcat fullStablePopulation.data.gz \ + | nl \ + | awk 'NR == 0 || NR % 1000 == 0' \ + > stablePopulation.data diff --git a/default.nix b/default.nix new file mode 100644 index 0000000..023046a --- /dev/null +++ b/default.nix @@ -0,0 +1,50 @@ +with import {}; + +# My thesis-specific tools and utilities +stdenv.mkDerivation { + name = "thesis-bundle"; + buildInputs = [ + ( texlive.combine { + inherit (texlive) + scheme-basic + collection-langfrench + algorithm2e + biblatex + caption + enumitem + euenc + filehook + jknapltx + listings + logreq + metafont + minitoc + ms + multirow + pgf + pgfplots + placeins + polyglossia + relsize + rsfs + setspace + siunitx + standalone + ucharcat + unicode-math + xcolor + xetex + xetex-def + xkeyval + xstring + zapfding + ;} ) + biber + (import ./builderbot {}) + ]; + src=null; + shellHook = '' + mkdir -p /tmp/build-thesis + echo "Juste type 'buildthesis' to build the thesis" + ''; + } diff --git a/figures/BZ-reaction1.png b/figures/BZ-reaction1.png new file mode 100644 index 0000000..72d3c36 Binary files /dev/null and b/figures/BZ-reaction1.png differ diff --git a/figures/BZ-reaction2.png b/figures/BZ-reaction2.png new file mode 100644 index 0000000..d94ed7b Binary files /dev/null and b/figures/BZ-reaction2.png differ diff --git a/figures/BZ-reaction3.png b/figures/BZ-reaction3.png new file mode 100644 index 0000000..0be8104 Binary files /dev/null and b/figures/BZ-reaction3.png differ diff --git a/figures/BZ-reaction4.png b/figures/BZ-reaction4.png new file mode 100644 index 0000000..d494309 Binary files /dev/null and b/figures/BZ-reaction4.png differ diff --git a/figures/EscherichiaColi.jpg b/figures/EscherichiaColi.jpg new file mode 100644 index 0000000..6aeeae7 Binary files /dev/null and b/figures/EscherichiaColi.jpg differ diff --git a/figures/assembly01.png b/figures/assembly01.png new file mode 100755 index 0000000..e61a414 Binary files /dev/null and b/figures/assembly01.png differ diff --git a/figures/assembly02.png b/figures/assembly02.png new file mode 100755 index 0000000..8ae62c5 Binary files /dev/null and b/figures/assembly02.png differ diff --git a/figures/assembly03.png b/figures/assembly03.png new file mode 100755 index 0000000..56b3689 Binary files /dev/null and b/figures/assembly03.png differ diff --git a/figures/bacteria.tikz b/figures/bacteria.tikz new file mode 100644 index 0000000..d1eddc1 --- /dev/null +++ b/figures/bacteria.tikz @@ -0,0 +1,198 @@ +\documentclass[crop,tikz]{standalone} +\input{common-headers} + +\newcounter{bacteria} + +\begin{document} + +\tikzset{coord/.style={fill,inner sep=0.5mm, circle, black}} + +\def \mybact#1#2#3#4#5{ + \stepcounter{bacteria}; + \coordinate (p#5) at #1; % position vector + \coordinate (d#5) at #2; % direction vector + \coordinate (n#5) at ($ (0,0)!1! 90:(d#5) $); % orthogonal vector + \coordinate (ft#5) at ($ (p#5) + { #3+#4 }*(d#5) + #4*(n#5) $); + \coordinate (fb#5) at ($ (p#5) + { #3+#4 }*(d#5) - #4*(n#5) $); + \coordinate (bt#5) at ($ (p#5) + {-(#3+#4)}*(d#5) + #4*(n#5) $); + \coordinate (bb#5) at ($ (p#5) + {-(#3+#4)}*(d#5) - #4*(n#5) $); + \draw[black,rounded corners=#4cm] + (bt#5) -- (bb#5) -- (fb#5) -- (ft#5) -- cycle; +% + \coordinate (f#5) at ($ (p#5) + #3*(d#5) $); + \coordinate (b#5) at ($ (p#5) - #3*(d#5) $); +% \node[coord,label=$p_{#5}$] at (p#5) {}; + \node[coord,label=below:$f_{#5}$] at (f#5) {}; + \node[coord,label=$b_{#5}$] at (b#5) {}; +% + \coordinate (ff#5) at ($ (p#5) + {2*#3}*(d#5) $); + \coordinate (bb#5) at ($ (p#5) - {2*#3}*(d#5) $); + \draw[very thin] (ff#5) -- (bb#5); +} + +\begin{tikzpicture} + %\draw [help lines] (-4,-2) grid (4,2); + \coordinate (p) at (0,0); % position vector + \coordinate (d) at ($ (0,0)!1! 33:(1,0) $); % direction vector + \coordinate (n) at ($ (0,0)!1! 90:(d) $); % orthogonal vector + \coordinate (ft) at ($ (p) + { 2+1 }*(d) + 1*(n) $); + \coordinate (fb) at ($ (p) + { 2+1 }*(d) - 1*(n) $); + \coordinate (bt) at ($ (p) + {-(2+1)}*(d) + 1*(n) $); + \coordinate (bb) at ($ (p) + {-(2+1)}*(d) - 1*(n) $); + \draw[black,rounded corners=1cm] + (bt) -- (bb) -- (fb) -- (ft) -- cycle; + \coordinate (f) at ($ (p) + 2*(d) $); + \coordinate (b) at ($ (p) - 2*(d) $); + % + \node[coord,label=below:$f_{}$] at (f) {}; + \node[coord,label=$b_{}$] at (b) {}; + % + \draw[|<->|,shorten >=3pt,shorten <=3pt,dashed] (f) to node[below] {$2l$} (b); + \draw[|<->|,shorten >=1pt,shorten <=3pt,dashed] (b) to node[below] {$r$} +(180:1); + \draw[|<->|,shorten >=1pt,shorten <=1pt,dashed] ($(p) + 0.8*(d)$) to node[right] {$r$} +(n); + + \clip (-3,-2.5) rectangle (3,2.5); + %\draw[black!50,nearly transparent] (-3,-2.5) rectangle (3,2.5); +\end{tikzpicture} + +\begin{tikzpicture} + %\draw [help lines] (-4,-3) grid (4,5); + \mybact{(0 ,3)}{($ (0,0)!1! 61:(1,0) $)}{2}{1}{1}; + \mybact{(0.4,0)}{($ (0,0)!1! 33:(1,0) $)}{2}{1}{2}; + + \coordinate (po) at ($ (b1)!(f2)!(f1) $); + \draw[dashed] (f2) -- (po); + %\draw[rotate=-9] (po) rectangle ++(1mm,-1mm); + \node[coord,red,label=$\perp_{21}$] at (po) {}; + + \coordinate (pp) at ($ (b2)!(b1)!(f2) $); + \draw[dashed] (b1) -- (pp); + \node[coord,red,label=$\perp_{12}$] at (pp) {}; + + \coordinate (pq) at ($ (b2)!(f1)!(f2) $); + \draw[dashed] (f1) -- (pq); + \node[coord,red,label=$\perp_{12}$] at (pq) {}; + + \coordinate (pr) at ($ (b1)!(b2)!(f1) $); + \draw[dashed] (b2) -- (pr); + \node[coord,red,label=$\perp_{21}$] at (pr) {}; +\end{tikzpicture} + + +% scalar_t r1 = bact1->r; +% scalar_t r2 = bact2->r; +% scalar_t l1 = bact1->l; +% scalar_t l2 = bact2->l; + +% scalar_t r = r1 + r2; +% scalar_t rr = r * r; + +% vector_t b1 = p1 - l1 * d1; +% vector_t f1 = p1 + l1 * d1; +% vector_t b2 = p2 - l2 * d2; +% vector_t f2 = p2 + l2 * d2; + +% scalar_t mu2_f1 = clamp (dot2D_2_2 (d2, f1 - p2), -l2, l2); +% scalar_t mu2_b1 = clamp (dot2D_2_2 (d2, b1 - p2), -l2, l2); +% scalar_t mu1_f2 = clamp (dot2D_2_2 (d1, f2 - p1), -l1, l1); +% scalar_t mu1_b2 = clamp (dot2D_2_2 (d1, b2 - p1), -l1, l1); + +% vector_t h2_f1 = p2 + mu2_f1 * d2; +% vector_t h2_b1 = p2 + mu2_b1 * d2; +% vector_t h1_f2 = p1 + mu1_f2 * d1; +% vector_t h1_b2 = p1 + mu1_b2 * d1; + +% vector_t nf1_2 = (h2_f1 - f1); +% vector_t nb1_2 = (h2_b1 - b1); +% vector_t n1_f2 = - (h1_f2 - f2); +% vector_t n1_b2 = - (h1_b2 - b2); + +% scalar_t dist2_mu2_f1 = dot2D_2_2 (nf1_2, nf1_2); +% scalar_t dist2_mu2_b1 = dot2D_2_2 (nb1_2, nb1_2); +% scalar_t dist2_mu1_f2 = dot2D_2_2 (n1_f2, n1_f2); +% scalar_t dist2_mu1_b2 = dot2D_2_2 (n1_b2, n1_b2); + +\begin{tikzpicture} + \mybact{(0 ,3)}{($ (0,0)!1! 0:(1,0) $)}{2}{1}{1}; + \mybact{(1 ,0)}{($ (0,0)!1! 33:(1,0) $)}{2.2}{1.2}{2}; + \node[coord,label=$p_2$] at (p2) {}; + \draw[|->] (p2) -- ($ (b2)!(f1)!(f2) $); +\end{tikzpicture} + +\end{document} + +% \begin{document} +% +% \tikzset{cell color/.style={black!20}} +% +% \newcommand{\common}{% +% \coordinate (ll) at (0cm,-1cm); +% \coordinate (ur) at (5cm, 3cm); +% \draw (ll) rectangle (ur); +% \clip (ll)+(0.1cm,0.1cm) rectangle ([shift={(-0.1cm,-0.1cm)}]ur); +% } +% +% \begin{tikzpicture}[ +% every node/.style={draw, inner sep=0cm, +% minimum width=10pt, minimum height=10pt}, +% arrowed/.style={-Stealth, out=-90, in=90}] +% \common +% +% \node (h1) at (1,2) {}; +% \node (h2) at (2,2) {}; +% \node (h3) at (3,2) {}; +% \node (h4) at (4,2) {}; +% +% \node (m1) at (1,1) {}; +% \node (m2) at (2,1) {}; +% \node (m3) at (3,1) {}; +% \node (m4) at (4,1) {}; +% +% \node (b1) at (1,0) {}; +% \node (b2) at (2,0) {}; +% \node (b3) at (3,0) {}; +% \node (b4) at (4,0) {}; +% +% \draw[arrowed] (h1) to (m2.north) (h3) to (m2.north) (h2) to (m2.north); +% \draw[arrowed,dashed] (h2) to (m3.north) (h4) to (m3.north) (h3) to (m3.north); +% +% \draw[arrowed] (m1) to (b2.north) (m3) to (b2.north) (m2) to (b2.north); +% \draw[arrowed,dashed] (m2) to (b3.north) (m4) to (b3.north) (m3) to (b3.north); +% \end{tikzpicture} +% +% \begin{tikzpicture}[ +% c/.style={draw, inner sep=0cm, +% minimum width=10pt, minimum height=10pt}, +% arrowed/.style={-Stealth, out=-90, in=90}, +% mix/.style={draw, circle, inner sep=1pt}] +% \common +% +% \node[c] (h1) at (1,2) {}; +% \node[c] (h2) at (2,2) {}; +% \node[c] (h3) at (3,2) {}; +% \node[c] (h4) at (4,2) {}; +% +% \node[mix] (q1) at (1.5,1.5) {}; +% \node[mix] (q2) at (3.5,1.5) {}; +% +% \node[c] (m1) at (1,1) {}; +% \node[c] (m2) at (2,1) {}; +% \node[c] (m3) at (3,1) {}; +% \node[c] (m4) at (4,1) {}; +% +% \node[mix] (q3) at (2.5,0.5) {}; +% +% \node[c] (b1) at (1,0) {}; +% \node[c] (b2) at (2,0) {}; +% \node[c] (b3) at (3,0) {}; +% \node[c] (b4) at (4,0) {}; +% +% \draw[arrowed] (h1) to (q1) (q1) to (m1); +% \draw[arrowed] (h2) to (q1) (q1) to (m2); +% \draw[arrowed] (h3) to (q2) (q2) to (m3); +% \draw[arrowed] (h4) to (q2) (q2) to (m4); +% +% \draw[arrowed] (m2) to (q3) (q3) to (b2); +% \draw[arrowed] (m3) to (q3) (q3) to (b3); +% \end{tikzpicture} +% \end{document} diff --git a/figures/bb-activity.tikz b/figures/bb-activity.tikz new file mode 100644 index 0000000..f6b9f2e --- /dev/null +++ b/figures/bb-activity.tikz @@ -0,0 +1,51 @@ +\documentclass[crop,tikz]{standalone} +\input{common-headers} + +\begin{document} + +\begin{tikzpicture}[scale=0.4] + \foreach \n [count=\y] in {% + 0000000100000000,% + 0000001111110000,% + 0000001111110000,% + 0000001111100000,% + 0000001110000000,% + 0000011100000000,% + 0001111110000000,% + 0001111111110000,% + 0001111111100000,% + 0000011000000000,% + 0000000000000000 } + { + \pgfmathtodigitlist{\digitlist}{\n}; + \foreach \digit [count=\x, evaluate={\c=\digit*100}] in \digitlist { + \fill[fill=black!\c] (\x,-\y) rectangle ++(1,1); + } + } + \coordinate (ul) at (0,0); + \coordinate (lr) at (17,-11); + \coordinate (bbul) at ($(ul) + (-10pt,10pt)$); + \coordinate (bblr) at ($(lr) + (10pt,-10pt)$); + \draw[very thick] (bbul) rectangle (bblr); + \draw[black!50] (ul) grid ($(lr) + (0,-0.1pt)$); + + % width indicator + \pgfmathtodigitlist{\digitlist}{0001111111110000}; + \foreach \digit [count=\x, evaluate={\c=\digit*100}] in \digitlist { + \fill[fill=black!\c] (\x,1) rectangle ++(1,1); + } + \draw[black!50] (0,1) grid (17,2); + + % height indicator + \pgfmathtodigitlist{\digitlist}{11111111110}; + \foreach \digit [count=\x, evaluate={\c=\digit*100}] in \digitlist { + \fill[fill=black!\c] (18,-\x) rectangle ++(1,1); + } + \draw[black!50] (18,0) grid (19,-11); + + \node[circle, fill=black, label=below left:{$(x,y)$}] at ($(ul) - (0,11) + (-10pt,-10pt)$) {}; + \draw[|.<->.|] (0,-12) -- node[midway,fill=white]{$w$} (17,-12); + \draw[|.<->.|] (-1,-11) -- node[midway,fill=white]{$h$} (-1,0); +\end{tikzpicture} + +\end{document} diff --git a/figures/bench.pdf b/figures/bench.pdf new file mode 100644 index 0000000..06639b8 Binary files /dev/null and b/figures/bench.pdf differ diff --git a/figures/ca-glider.tikz b/figures/ca-glider.tikz new file mode 100644 index 0000000..be962e4 --- /dev/null +++ b/figures/ca-glider.tikz @@ -0,0 +1,75 @@ +\documentclass[crop,tikz]{standalone} +\input{common-headers} + +\begin{document} + +\newcommand{\common}{% + \coordinate (ll) at (-0.5cm,-0.5cm); + \coordinate (ur) at ( 3.5cm, 3.5cm); + \draw[thick] (ll) rectangle (ur); + \clip (ll)+(-0.1cm,-0.1cm) rectangle ([shift={(0.1cm,0.1cm)}]ur); +} + +\begin{tikzpicture}[ + cell/.style={fill=black!60, inner sep=0cm, + minimum width=1cm, minimum height=1cm}] + \common + \node[cell] at (0cm,1cm) {}; + \node[cell] at (1cm,1cm) {}; + \node[cell] at (1cm,3cm) {}; + \node[cell] at (2cm,1cm) {}; + \node[cell] at (2cm,2cm) {}; + \draw[xshift=0.5cm,yshift=0.5cm] (ll) grid (ur); +\end{tikzpicture} + +\begin{tikzpicture}[ + cell/.style={fill=black!60, inner sep=0cm, + minimum width=1cm, minimum height=1cm}] + \common + \node[cell] at (0cm,2cm) {}; + \node[cell] at (1cm,0cm) {}; + \node[cell] at (1cm,1cm) {}; + \node[cell] at (2cm,1cm) {}; + \node[cell] at (2cm,2cm) {}; + \draw[xshift=0.5cm,yshift=0.5cm] (ll) grid (ur); +\end{tikzpicture} + +\begin{tikzpicture}[ + cell/.style={fill=black!60, inner sep=0cm, + minimum width=1cm, minimum height=1cm}] + \common + \node[cell] at (0cm,1cm) {}; + \node[cell] at (1cm,0cm) {}; + \node[cell] at (2cm,0cm) {}; + \node[cell] at (2cm,1cm) {}; + \node[cell] at (2cm,2cm) {}; + \draw[xshift=0.5cm,yshift=0.5cm] (ll) grid (ur); +\end{tikzpicture} + +\begin{tikzpicture}[ + cell/.style={fill=black!60, inner sep=0cm, + minimum width=1cm, minimum height=1cm}] + \common + \node[cell] at (1cm,0cm) {}; + \node[cell] at (1cm,2cm) {}; + \node[cell] at (2cm,0cm) {}; + \node[cell] at (2cm,1cm) {}; + \node[cell] at (3cm,1cm) {}; + \draw[xshift=0.5cm,yshift=0.5cm] (ll) grid (ur); +\end{tikzpicture} + +\begin{tikzpicture}[ + cell/.style={fill=black!60, inner sep=0cm, + minimum width=1cm, minimum height=1cm}] + \common + \node[cell] at (1cm,0cm) {}; + \node[cell] at (2cm,0cm) {}; + \node[cell] at (2cm,2cm) {}; + \node[cell] at (3cm,0cm) {}; + \node[cell] at (3cm,1cm) {}; + \draw[xshift=0.5cm,yshift=0.5cm] (ll) grid (ur); +\end{tikzpicture} + + + +\end{document} diff --git a/figures/ca-neighborhood-2D.tikz b/figures/ca-neighborhood-2D.tikz new file mode 100644 index 0000000..82d767d --- /dev/null +++ b/figures/ca-neighborhood-2D.tikz @@ -0,0 +1,93 @@ +\documentclass[crop,tikz]{standalone} +\input{common-headers} + +\begin{document} + +\newcommand{\common}{% + \coordinate (ll) at (-1cm,-1cm); + \coordinate (ur) at (3cm, 3cm); + \draw (ll) rectangle (ur); + \clip (ll)+(0.1cm,0.1cm) rectangle ([shift={(-0.1cm,-0.1cm)}]ur); +} + +\begin{tikzpicture}[ + every node/.style={draw, black!30, inner sep=0cm, + minimum width=10pt, minimum height=10pt}, + cell/.style={black,fill=black}, + neig/.style={black}] + \common + + \node (h1) at (0,2) {}; + \node[neig] (h2) at (1,2) {}; + \node (h3) at (2,2) {}; + + \node[neig] (m1) at (0,1) {}; + \node[cell] (m2) at (1,1) {}; + \node[neig] (m3) at (2,1) {}; + + \node (b1) at (0,0) {}; + \node[neig] (b2) at (1,0) {}; + \node (b3) at (2,0) {}; + + \draw (m2) -- (h2); + \draw (m2) -- (m1); + \draw (m2) -- (m3); + \draw (m2) -- (b2); +\end{tikzpicture} + +\begin{tikzpicture}[ + every node/.style={draw, black!30, inner sep=0cm, + minimum width=10pt, minimum height=10pt}, + cell/.style={black,fill=black}, + neig/.style={black}] + \common + + \node (h1) at (0,2) {}; + \node[neig] (h2) at (1,2) {}; + \node[neig] (h3) at (2,2) {}; + + \node[neig] (m1) at (0,1) {}; + \node[cell] (m2) at (1,1) {}; + \node[neig] (m3) at (2,1) {}; + + \node[neig] (b1) at (0,0) {}; + \node[neig] (b2) at (1,0) {}; + \node (b3) at (2,0) {}; + + \draw (m2) -- (h2); + \draw (m2) -- (m1); + \draw (m2) -- (m3); + \draw (m2) -- (b2); + \draw (m2) -- (b1); + \draw (m2) -- (h3); +\end{tikzpicture} + +\begin{tikzpicture}[ + every node/.style={draw, black!30, inner sep=0cm, + minimum width=10pt, minimum height=10pt}, + cell/.style={black,fill=black}, + neig/.style={black}] + \common + + \node[neig] (h1) at (0,2) {}; + \node[neig] (h2) at (1,2) {}; + \node[neig] (h3) at (2,2) {}; + + \node[neig] (m1) at (0,1) {}; + \node[cell] (m2) at (1,1) {}; + \node[neig] (m3) at (2,1) {}; + + \node[neig] (b1) at (0,0) {}; + \node[neig] (b2) at (1,0) {}; + \node[neig] (b3) at (2,0) {}; + + \draw (m2) -- (m1); + \draw (m2) -- (m3); + \draw (m2) -- (b1); + \draw (m2) -- (b2); + \draw (m2) -- (b3); + \draw (m2) -- (h1); + \draw (m2) -- (h2); + \draw (m2) -- (h3); +\end{tikzpicture} +\end{document} diff --git a/figures/ca-neighborhood.tikz b/figures/ca-neighborhood.tikz new file mode 100644 index 0000000..9b467a0 --- /dev/null +++ b/figures/ca-neighborhood.tikz @@ -0,0 +1,78 @@ +\documentclass[crop,tikz]{standalone} +\input{common-headers} + +\begin{document} + +\tikzset{cell color/.style={black!20}} + +\newcommand{\common}{% + \coordinate (ll) at (0cm,-1cm); + \coordinate (ur) at (5cm, 3cm); + \draw (ll) rectangle (ur); + \clip (ll)+(0.1cm,0.1cm) rectangle ([shift={(-0.1cm,-0.1cm)}]ur); +} + +\begin{tikzpicture}[ + every node/.style={draw, inner sep=0cm, + minimum width=10pt, minimum height=10pt}, + arrowed/.style={-Stealth, out=-90, in=90}] + \common + + \node (h1) at (1,2) {}; + \node (h2) at (2,2) {}; + \node (h3) at (3,2) {}; + \node (h4) at (4,2) {}; + + \node (m1) at (1,1) {}; + \node (m2) at (2,1) {}; + \node (m3) at (3,1) {}; + \node (m4) at (4,1) {}; + + \node (b1) at (1,0) {}; + \node (b2) at (2,0) {}; + \node (b3) at (3,0) {}; + \node (b4) at (4,0) {}; + + \draw[arrowed] (h1) to (m2.north) (h3) to (m2.north) (h2) to (m2.north); + \draw[arrowed,dashed] (h2) to (m3.north) (h4) to (m3.north) (h3) to (m3.north); + + \draw[arrowed] (m1) to (b2.north) (m3) to (b2.north) (m2) to (b2.north); + \draw[arrowed,dashed] (m2) to (b3.north) (m4) to (b3.north) (m3) to (b3.north); +\end{tikzpicture} + +\begin{tikzpicture}[ + c/.style={draw, inner sep=0cm, + minimum width=10pt, minimum height=10pt}, + arrowed/.style={-Stealth, out=-90, in=90}, + mix/.style={draw, circle, inner sep=1pt}] + \common + + \node[c] (h1) at (1,2) {}; + \node[c] (h2) at (2,2) {}; + \node[c] (h3) at (3,2) {}; + \node[c] (h4) at (4,2) {}; + + \node[mix] (q1) at (1.5,1.5) {}; + \node[mix] (q2) at (3.5,1.5) {}; + + \node[c] (m1) at (1,1) {}; + \node[c] (m2) at (2,1) {}; + \node[c] (m3) at (3,1) {}; + \node[c] (m4) at (4,1) {}; + + \node[mix] (q3) at (2.5,0.5) {}; + + \node[c] (b1) at (1,0) {}; + \node[c] (b2) at (2,0) {}; + \node[c] (b3) at (3,0) {}; + \node[c] (b4) at (4,0) {}; + + \draw[arrowed] (h1) to (q1) (q1) to (m1); + \draw[arrowed] (h2) to (q1) (q1) to (m2); + \draw[arrowed] (h3) to (q2) (q2) to (m3); + \draw[arrowed] (h4) to (q2) (q2) to (m4); + + \draw[arrowed] (m2) to (q3) (q3) to (b2); + \draw[arrowed] (m3) to (q3) (q3) to (b3); +\end{tikzpicture} +\end{document} diff --git a/figures/cc.tikz b/figures/cc.tikz new file mode 100644 index 0000000..275e4e5 --- /dev/null +++ b/figures/cc.tikz @@ -0,0 +1,65 @@ +\documentclass{standalone} +\input{common-headers} +\input{sigles} +\begin{document} +\begin{tikzpicture}[scale=0.9, + shf/.style={isosceles triangle, shape border rotate=90, minimum height=0.5cm, + minimum width=.7cm, fill=red!30!white, isosceles triangle stretches}, + she/.style={fill=black, rectangle, inner xsep=0.3cm, inner ysep=0.06cm}, + shc/.style={fill=black, circle, inner sep=0.1cm}, + 2cell/.style={fill=red!30!white}, + 1cell/.style={draw=black, ultra thick}, + 0cell/.style={shape=circle, fill=black, draw=white, ultra thick, inner sep=0.1cm}] + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Figure on the left +\begin{scope}[xshift=-6cm, yshift=1.55cm,every node/.style={draw=white, ultra thick, inner sep=0}] +%nodes +\node[shf] (f) [label=above:$f$] {}; +\node[she] (e2) [label=right:$e_2$,below=of f] {}; +\node[she] (e1) [label=right:$e_1$,left=of e2] {}; +\node[she] (e3) [label=right:$e_3$,right=of e2] {}; +\node[shc] (c2) [label=below:$c_2$,below=of e1] {}; +\node[shc] (c1) [label=below:$c_1$,below=of e2] {}; +\node[shc] (c3) [label=below:$c_3$,below=of e3] {}; + +%incidence +\draw (f) -- (e1);\draw (f) -- (e2);\draw (f) -- (e3); +\draw (e1) -- (c1);\draw (e1) -- (c2); +\draw (e2) -- (c2);\draw (e2) -- (c3); +\draw (e3) -- (c1);\draw (e3) -- (c3); +\end{scope} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Figure on the center +\begin{scope}[scale=0.8] +\fill[2cell] (90:2cm) -- (210:2cm) -- (330:2cm); +\node at (0,0) {$f$}; +\end{scope} + +\draw[1cell] (90 :2cm) -- node[above left] {$e_1$} (210:2cm); +\draw[1cell] (210:2cm) -- node[below] {$e_2$} (330:2cm); +\draw[1cell] (330:2cm) -- node[above right] {$e_3$} ( 90:2cm); + +\node[0cell,label=above:$c_1$] at ( 90:2cm) {}; +\node[0cell,label=left:$c_2$] at (210:2cm) {}; +\node[0cell,label=right:$c_3$] at (330:2cm) {}; + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Figure on the right +\begin{scope}[xshift=6cm] +\begin{scope}[scale=0.8] +\fill[2cell] (90:2cm) -- (210:2cm) -- (330:2cm); +\node at (0,0) {$12$}; +\end{scope} + +\draw[1cell] (90 :2cm) -- node[above left] {$5$} (210:2cm); +\draw[1cell] (210:2cm) -- node[below] {$6$} (330:2cm); +\draw[1cell] (330:2cm) -- node[above right] {$5$} ( 90:2cm); + +\node[0cell,label=above:{$(0,4)$}] at ( 90:2cm) {}; +\node[0cell,label=below:{$(-3,0)$}] at (210:2cm) {}; +\node[0cell,label=below:{$(3,0)$}] at (330:2cm) {}; +\end{scope} +\end{tikzpicture} +\end{document} diff --git a/figures/cellcomplex2.pdf b/figures/cellcomplex2.pdf new file mode 100644 index 0000000..ca43b22 Binary files /dev/null and b/figures/cellcomplex2.pdf differ diff --git a/figures/cellcomplex2.pdf_t b/figures/cellcomplex2.pdf_t new file mode 100644 index 0000000..ba102fe --- /dev/null +++ b/figures/cellcomplex2.pdf_t @@ -0,0 +1,55 @@ +\begin{picture}(0,0)% +\includegraphics{cellcomplex2.pdf}% +\end{picture}% +\setlength{\unitlength}{4144sp}% +% +\begingroup\makeatletter\ifx\SetFigFont\undefined% +\gdef\SetFigFont#1#2#3#4#5{% + \reset@font\fontsize{#1}{#2pt}% + \fontfamily{#3}\fontseries{#4}\fontshape{#5}% + \selectfont}% +\fi\endgroup% +\begin{picture}(7181,1938)(-1708,-1030) +\put(2476,-961){\makebox(0,0)[lb]{\smash{{\SetFigFont{12}{14.4}{\familydefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}$c_2$}% +}}}} +\put(676,-961){\makebox(0,0)[rb]{\smash{{\SetFigFont{12}{14.4}{\familydefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}$c_3$}% +}}}} +\put(2521,614){\makebox(0,0)[lb]{\smash{{\SetFigFont{12}{14.4}{\familydefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}$f$}% +}}}} +\put(2071,-16){\makebox(0,0)[lb]{\smash{{\SetFigFont{12}{14.4}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}$e_1$}% +}}}} +\put(1576,749){\makebox(0,0)[b]{\smash{{\SetFigFont{12}{14.4}{\familydefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}$c_1$}% +}}}} +\put(1081,-16){\makebox(0,0)[rb]{\smash{{\SetFigFont{12}{14.4}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}$e_3$}% +}}}} +\put(1576,-961){\makebox(0,0)[b]{\smash{{\SetFigFont{12}{14.4}{\familydefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}$e_2$}% +}}}} +\put(3601,-961){\makebox(0,0)[rb]{\smash{{\SetFigFont{12}{14.4}{\familydefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}$(-3,0)$}% +}}}} +\put(4501,749){\makebox(0,0)[b]{\smash{{\SetFigFont{12}{14.4}{\familydefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}$(0,4)$}% +}}}} +\put(5446,614){\makebox(0,0)[lb]{\smash{{\SetFigFont{12}{14.4}{\familydefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}$12$}% +}}}} +\put(4501,-961){\makebox(0,0)[b]{\smash{{\SetFigFont{12}{14.4}{\familydefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}$6$}% +}}}} +\put(4996,-16){\makebox(0,0)[lb]{\smash{{\SetFigFont{12}{14.4}{\familydefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}$5$}% +}}}} +\put(4006,-16){\makebox(0,0)[rb]{\smash{{\SetFigFont{12}{14.4}{\familydefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}$5$}% +}}}} +\put(5401,-961){\makebox(0,0)[lb]{\smash{{\SetFigFont{12}{14.4}{\familydefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}$(3,0)$}% +}}}} +\put(-899,749){\makebox(0,0)[b]{\smash{{\SetFigFont{12}{14.4}{\familydefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}$f$}% +}}}} +\put(-224,-961){\makebox(0,0)[b]{\smash{{\SetFigFont{12}{14.4}{\familydefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}$c_3$}% +}}}} +\put(-899,-961){\makebox(0,0)[b]{\smash{{\SetFigFont{12}{14.4}{\familydefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}$c_1$}% +}}}} +\put(-1574,-961){\makebox(0,0)[b]{\smash{{\SetFigFont{12}{14.4}{\familydefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}$c_2$}% +}}}} +\put(-764,-106){\makebox(0,0)[lb]{\smash{{\SetFigFont{12}{14.4}{\familydefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}$e_2$}% +}}}} +\put(-89,-106){\makebox(0,0)[lb]{\smash{{\SetFigFont{12}{14.4}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}$e_3$}% +}}}} +\put(-1439,-106){\makebox(0,0)[lb]{\smash{{\SetFigFont{12}{14.4}{\rmdefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}$e_1$}% +}}}} +\end{picture}% diff --git a/figures/cnn-synapses.tikz b/figures/cnn-synapses.tikz new file mode 100644 index 0000000..164feab --- /dev/null +++ b/figures/cnn-synapses.tikz @@ -0,0 +1,100 @@ +\documentclass[crop,tikz]{standalone} +\input{common-headers} +\usetikzlibrary{circuits.logic.CDH} +\usetikzlibrary{decorations.markings} +\usepackage{ifthen} + +\newcommand{\gimmelegs}[1]{% + \draw[black!50,densely dash dot] (#1.east) -- +( 4mm,0cm); + \draw (#1.input 1) -- +(-4mm,0cm); + \draw[black!50,densely dash dot] (#1.input 2) -- +(-4mm,0cm); + \ifthenelse{\equal{\detokenize{#1}}{\detokenize{cell}}}{}{% + \node[xshift=-3mm,fill,circle,inner sep=1pt] (in#1) at (#1.input 1) {}; + } +} + +\begin{document} + +% Sum inputs +\begin{tikzpicture}[circuit logic CDH, node distance=20mm] + \node (cell) [and gate,fill=black!50] {}; \gimmelegs{cell} + \node (celle) [and gate,right=of cell] {}; \gimmelegs{celle} + \node (cellse) [and gate,below=of celle] {}; \gimmelegs{cellse} + \node (cells) [and gate,below=of cell] {}; \gimmelegs{cells} + \node (cellsw) [and gate,left=of cells] {}; \gimmelegs{cellsw} + \node (cellw) [and gate,left=of cell] {}; \gimmelegs{cellw} + \node (cellnw) [and gate,above=of cellw] {}; \gimmelegs{cellnw} + \node (celln) [and gate,above=of cell] {}; \gimmelegs{celln} + \node (cellne) [and gate,above=of celle] {}; \gimmelegs{cellne} + + \node[white,fill=black,circle,inner sep=1pt] + (hub) at (barycentric cs:cell=1,cellnw=1) {$\sum$}; + + \begin{scope}[decoration={markings,mark=at position 0.5 with {\arrow{Stealth}}}] + % Let's go to the hub + \draw[postaction={decorate},out=-90,in=130] (incellnw) to (hub); + \draw[postaction={decorate},out=-90,in=90] (incelln) to (hub); + \draw[postaction={decorate},out=-90,in=40] (incellne) to (hub); + \draw[postaction={decorate},out=90 ,in=10,looseness=0.5] (incelle) to (hub); + \draw[postaction={decorate},out=90 ,in=-20] (incellse) to (hub); + \draw[postaction={decorate},out=90 ,in=160] (incellw) to (hub); + \draw[postaction={decorate},out=90 ,in=200,looseness=1.5] (incellsw) to (hub); + \draw[postaction={decorate},out=90 ,in=-120] (incells) to (hub); + + % Then feedback my cell + \draw[postaction={decorate},thick,out=-70 ,in=90] (hub) to (cell.north); + \end{scope} + + \begin{scope}[on background layer] + \draw[thin] ($ (cell.center) + (-4cm,-3.5cm) $) + rectangle ($ (cell.center) + ( 4cm, 3.5cm) $); + \end{scope} +\end{tikzpicture} + + + +\renewcommand{\gimmelegs}[1]{% + \draw (#1.east) -- +(4mm,0cm); + \draw[black!50,densely dash dot] (#1.input 1) -- +(-4mm,0cm); + \draw[black!50,densely dash dot] (#1.input 2) -- +(-4mm,0cm); + \ifthenelse{\equal{\detokenize{#1}}{\detokenize{cell}}}{}{% + \node[xshift=2mm,fill,circle,inner sep=1pt] (out#1) at (#1.output) {}; + } +} + +% Sum outputs +\begin{tikzpicture}[circuit logic CDH, node distance=20mm] + \node (cell) [and gate,fill=black!50] {}; \gimmelegs{cell} + \node (celle) [and gate,right=of cell] {}; \gimmelegs{celle} + \node (cellse) [and gate,below=of celle] {}; \gimmelegs{cellse} + \node (cells) [and gate,below=of cell] {}; \gimmelegs{cells} + \node (cellsw) [and gate,left=of cells] {}; \gimmelegs{cellsw} + \node (cellw) [and gate,left=of cell] {}; \gimmelegs{cellw} + \node (cellnw) [and gate,above=of cellw] {}; \gimmelegs{cellnw} + \node (celln) [and gate,above=of cell] {}; \gimmelegs{celln} + \node (cellne) [and gate,above=of celle] {}; \gimmelegs{cellne} + + \node[white,fill=black,circle,inner sep=1pt] + (hub) at (barycentric cs:cell=1,cellne=1) {$\sum$}; + + \begin{scope}[decoration={markings,mark=at position 0.5 with {\arrow{Stealth}}}] + % Let's go to the hub + \draw[postaction={decorate},out=-90,in=130] (outcellnw) to (hub); + \draw[postaction={decorate},out=-90,in=90] (outcelln) to (hub); + \draw[postaction={decorate},out=-90,in=40] (outcellne) to (hub); + \draw[postaction={decorate},out=90 ,in=10] (outcelle) to (hub); + \draw[postaction={decorate},out=90 ,in=-80,looseness=1.5] (outcellse) to (hub); + \draw[postaction={decorate},out=90 ,in=160] (outcellw) to (hub); + \draw[postaction={decorate},out=90 ,in=200,looseness=1.2] (outcellsw) to (hub); + \draw[postaction={decorate},out=90 ,in=-100] (outcells) to (hub); + + % Then feedback my cell + \draw[postaction={decorate},thick,out=-120 ,in=90] (hub) to (cell.north); + \end{scope} + + \begin{scope}[on background layer] + \draw[thin] ($ (cell.center) + (-4cm,-3.5cm) $) + rectangle ($ (cell.center) + ( 4cm, 3.5cm) $); + \end{scope} +\end{tikzpicture} +\end{document} diff --git a/figures/collision.tikz b/figures/collision.tikz new file mode 100644 index 0000000..f450caa --- /dev/null +++ b/figures/collision.tikz @@ -0,0 +1,96 @@ +\documentclass[crop,tikz]{standalone} +\input{common-headers} +\input{sigles} + +\begin{document} +\newcounter{bacteria} + +\tikzset{coord/.style={fill,inner sep=0.5mm, circle, black}} + +\def \mybact#1#2#3#4#5{ + \stepcounter{bacteria}; + \coordinate (p#5) at #1; % position vector + \coordinate (d#5) at #2; % direction vector + \coordinate (n#5) at ($ (0,0)!1! 90:(d#5) $); % orthogonal vector + \coordinate (ft#5) at ($ (p#5) + { #3+#4 }*(d#5) + #4*(n#5) $); + \coordinate (fb#5) at ($ (p#5) + { #3+#4 }*(d#5) - #4*(n#5) $); + \coordinate (bt#5) at ($ (p#5) + {-(#3+#4)}*(d#5) + #4*(n#5) $); + \coordinate (bb#5) at ($ (p#5) + {-(#3+#4)}*(d#5) - #4*(n#5) $); + \draw[black,rounded corners=#4cm] + (bt#5) -- (bb#5) -- (fb#5) -- (ft#5) -- cycle; +% + \coordinate (f#5) at ($ (p#5) + #3*(d#5) $); + \coordinate (b#5) at ($ (p#5) - #3*(d#5) $); +% \node[coord,label=$p_{#5}$] at (p#5) {}; +% + \coordinate (ff#5) at ($ (p#5) + {2*#3}*(d#5) $); + \coordinate (bb#5) at ($ (p#5) - {2*#3}*(d#5) $); + \draw[very thin] (ff#5) -- (bb#5); +} +% Usage: +% \mybact {|position vector|} {|direction vector|} {width}{height}{name}; + +\begin{tikzpicture} + \draw [help lines] (0,0) grid (6,2); + \mybact{(3,1)}{(1,0)}{2}{1}{\arabic{bacteria}}; + \node[coord,label=above:$f_\arabic{bacteria}$] at (f1) {}; + \node[coord,label=below:$b_\arabic{bacteria}$] at (b1) {}; +\end{tikzpicture} + +\newcommand{\bactsPosAndAngle}{% + \coordinate (PosA) at ( 0 ,3); + \coordinate (AngA) at ($ (0,0) !1! 28:(1,0) $); + \coordinate (PosB) at (-0.7,0); + \coordinate (AngB) at ($ (0,0) !1! -3:(1,0) $); + \mybact{(PosA)}{(AngA)}{2}{1}{1}; + \mybact{(PosB)}{(AngB)}{2}{1}{2}; +} + +\begin{tikzpicture} + \bactsPosAndAngle + + \node[coord,label=above:$f_1$] at (f1) {}; + \node[coord,label=below:$f_2$] at (f2) {}; + \node[coord,label=below:$b_2$] at (b2) {}; + + \coordinate (po) at ($ (b1)!(f2)!(f1) $); + \draw[dashed] (f2) -- (po); + % \draw[rotate=-9] (po) rectangle ++(1mm,-1mm); + \node[coord,red,label=above:$\perp_{f_2}$] at (po) {}; + + \coordinate (pp) at ($ (b2)!(b1)!(f2) $); + \draw[dashed,thick,red] (b1) -- (pp); + \node[coord,red,label=below:$\perp_{b_1}$] at (pp) {}; + + \coordinate (pq) at ($ (b2)!(f1)!(f2) $); + \draw[dashed] (f1) -- (pq); + \node[coord,label=$b_1$] at (b1) {}; + \node[coord,red,label=right:$\perp_{f_1}$] at (pq) {}; + + \coordinate (pr) at ($ (b1)!(b2)!(f1) $); + \draw[dashed] (b2) -- (pr); + \node[coord,red,label=above:$\perp_{f_2}$] at (pr) {}; +\end{tikzpicture} + +\begin{tikzpicture} + \bactsPosAndAngle + + \coordinate (col) at ($(b1)!.5!(pp)$); + + \node[coord] at (f1) {}; + \node[coord] at (f2) {}; + \node[coord] at (b2) {}; + \node[coord] at (b1) {}; + + \node[coord,red] at ($ (b2)!(b1)!(f2) $) {}; + %\node[coord,label=left:$P$] at (col) {}; + \node[coord,label=left:$p_1$] at (p1) {}; + \node[coord,label=below:$p_2$] at (p2) {}; + + \draw[-Stealth] (p1) to node[auto] {$\orr{r_1}$} (col); + \draw[-Stealth] (p2) to node[auto,swap] {$\orr{r_2}$} (col); + \draw[-Stealth] (col) to node[auto] {$\orr{n}$} ($(col)!.4!(b1)$); + +\end{tikzpicture} + +\end{document} diff --git a/figures/complexification-ehresmann.tikz b/figures/complexification-ehresmann.tikz new file mode 100644 index 0000000..c87748d --- /dev/null +++ b/figures/complexification-ehresmann.tikz @@ -0,0 +1,315 @@ +\documentclass[crop,tikz]{standalone} +\input{common-headers} +\input{sigles} + +\begin{document} + +\tikzset{% + neuron/.style={fill,black,circle,inner sep=0,minimum width=5pt}, + family/.style={draw,fill=white,circle,inner sep=0,minimum width=2cm}, + link/.style={-Stealth}, + transition/.style={thick, double,-Stealth}, + curly/.style={decorate,decoration={brace,amplitude=10pt}}, + curlyM/.style={decorate,decoration={brace,amplitude=10pt,mirror}}, + idq1/.style={magenta!60!white}, + idq2/.style={orange!60!white}, + idq3/.style={red!60!white}, + idn1/.style={fill,violet!70!white}, + idn2/.style={fill,blue!70!white}, + idn3/.style={fill,cyan!70!white}, +} + +\begin{tikzpicture} + \draw (-1,1) rectangle (1,-2); + \node[neuron] (A1) at (0 ,0) {}; + \node[neuron] (B1) at (0.5 ,-1) {}; + \node[neuron] (C1) at (0.2 ,-1.5) {}; + \node[neuron] (D1) at (-0.5,-1.1) {}; + \draw[link] (A1) to (B1); + \draw[link] (A1) to (D1); + \draw[link] (C1) to (D1); + \draw[link] (B1) to (D1); + + \draw[transition] (1.5,-0.5) to node[auto] {$k_{t\rightarrow t'}$} (2.5,-0.5); + + \begin{scope}[xshift=4cm] + \draw (-1,1) rectangle (1,-2); + \node[neuron] (A2) at (0 ,0) {}; + \node[neuron] (B2) at (0.5 ,-1) {}; + \node[neuron] (C2) at (0.2 ,-1.5) {}; + \node[neuron] (D2) at (-0.5,-1.1) {}; + \draw[link] (A2) to (B2); + \draw[link] (A2) to (D2); + \draw[link] (C2) to (D2); + \draw[link] (B2) to (D2); + + \draw[transition] (1.5,-0.5) to node[auto] {$k_{t'\rightarrow t''}$} (2.5,-0.5); + \end{scope} + + \begin{scope}[xshift=8cm] + \draw (-1,1) rectangle (1,-2); + \node[neuron] (A3) at (0 ,0) {}; + \node[neuron] (B3) at (0.5 ,-1) {}; + \node[neuron] (C3) at (0.2 ,-1.5) {}; + \draw[link] (A3) to (B3); + \end{scope} + + \draw[dashed] (-2.5cm,-2.5cm) -- +(0.5cm,0cm); + \draw[dashed] ( 10cm,-2.5cm) -- +(0.5cm,0cm); + \draw ( -2cm,-2.5cm) -- + ( 10cm,-2.5cm); + \begin{scope}[yshift=-2.5cm] + \foreach \x/\t in {0/$t$,4/$t'$,8/$t''$} + \draw (\x,1pt) -- (\x,-3pt) node[anchor=north] {\t}; + \end{scope} +\end{tikzpicture} + +\begin{tikzpicture} + \node[neuron] (N1) at (0,0) {}; + \node[neuron] (N2) at (90:0.7cm) {}; + \node[neuron] (N3) at (10:0.5cm) {}; + \coordinate (Center) at (barycentric cs:N1=1,N2=1,N3=1); + \draw[thin] (Center) circle (1cm); + \node at ($(Center) + (-0.8,0)$) {$P$}; + + + \node[neuron] (N) at ($(Center) + ( 20:2.5cm)$) {}; + \node at ($(N.east) + (0.2,0)$) {$n_1$}; + \node[neuron] (D) at ($(Center) + (-20:2.5cm)$) {}; + \node at ($(D.east) + (0.2,0)$) {$n_2$}; + + \draw[dashed] ($(Center) + (90:1cm)$) to (N); + \draw[dashed] ($(Center) + (-50:1cm)$) to (N); + + \draw[link] (N1) to (N2); + \draw[link] (N1) to (N3); + \draw[link] (N) to node[auto] {$s_{12}$} (D); + \draw[link] (N1) to (D); + \draw[link] (N2) to (D); + \draw[link] (N3) to (D); +\end{tikzpicture} + +\begin{tikzpicture} + \node[neuron] (N1) at (0,0) {}; + \node[neuron] (N2) at (90:0.7cm) {}; + \node[neuron] (N3) at (10:0.5cm) {}; + \draw[link] (N1) to (N2); + \draw[link] (N1) to (N3); + + \coordinate (Center) at (barycentric cs:N1=1,N2=1,N3=1); + \draw[thin] (Center) circle (1cm); + \node at ($(Center) + (-0.8,0)$) {$P$}; + + \node[neuron] (N) at ($(Center) + ( 20:2.5cm)$) {}; + \node at ($(N.north) + (0,0.2)$) {$n$}; + + \draw[dashed] ($(Center) + (90:1cm)$) to (N); + \draw[dashed] ($(Center) + (-50:1cm)$) to (N); + + \coordinate (Center2) at ($(N) + (-20:2.5cm)$); + + \node[neuron] (N1') at ($(Center2) + (0,0) $) {}; + \node[neuron] (N2') at ($(Center2) + (110:0.7cm)$) {}; + \node[neuron] (N3') at ($(Center2) + (30:0.5cm)$) {}; + \node[neuron] (N4') at ($(Center2) + (-130:0.5cm)$) {}; + + \draw[link] (N1') to (N2'); + \draw[link] (N1') to (N3'); + \draw[link] (N1') to (N4'); + \draw[link] (N2') to (N3'); + + \draw[thin] (Center2) circle (1cm); + \node at ($(Center2) + (0.8,0)$) {$P'$}; + + \draw[dashed] ($(Center2) + ( 90:1cm)$) to (N); + \draw[dashed] ($(Center2) + (-130:1cm)$) to (N); +\end{tikzpicture} + + +\begin{tikzpicture} + \coordinate (cN1) at (0,0); + \coordinate (cN2) at (90:0.7cm); + \coordinate (cN3) at (10:0.5cm); + \coordinate (Center) at (barycentric cs:N1=1,N2=1,N3=1); + \coordinate (cN) at ($(Center) + ( 40:2.5cm)$); + \coordinate (cN') at ($(cN) + (4cm,0)$); + \coordinate (Center2) at ($(cN') + (-40:2.5cm)$); + + %Cluster + \fill[black!20] ($(Center) + (0,1cm)$) rectangle ($(Center2) + (0,-1cm)$); + + + %Bindings + \filldraw[white,draw=black,dashed,opacity=0.6] ($(Center) + (110:1cm)$) + -- (cN) + -- ($(Center) + (-30:1cm)$) + -- cycle; + \filldraw[white,draw=black,dashed,opacity=0.6] ($(Center2) + ( 70:1cm)$) + -- (cN') + -- ($(Center2) + (-150:1cm)$) + -- cycle; + + %Circles + \filldraw[white,draw=black,thin] (Center) circle (1cm); + \filldraw[white,draw=black,thin] (Center2) circle (1cm); + + %IDs + \node at ($(Center) + (-0.8,0)$) {$P$}; + \node at ($(Center2) + (0.8,0)$) {$P'$}; + + %Network P + \node[neuron] (N1) at (cN1) {}; + \node[neuron] (N2) at (cN2) {}; + \node[neuron] (N3) at (cN3) {}; + \draw[link] (N1) to (N2); + \draw[link] (N1) to (N3); + + %Network P' + \node[neuron] (N1') at ($(Center2) + (0,0) $) {}; + \node[neuron] (N2') at ($(Center2) + (110:0.7cm)$) {}; + \node[neuron] (N3') at ($(Center2) + (30:0.5cm)$) {}; + \node[neuron] (N4') at ($(Center2) + (-130:0.5cm)$) {}; + \draw[link] (N2') to (N1'); + \draw[link] (N1') to (N3'); + \draw[link] (N1') to (N4'); + \draw[link] (N3') to (N2'); + + %Cat-neurons + \node[neuron,label=above:$n_1$] (N) at (cN) {}; + \node[neuron,label=above:$n_2$] (N') at (cN') {}; + \draw[link] (N) to node[auto]{\small{$(P,P')$}} (N'); +\end{tikzpicture} + + +\begin{tikzpicture} + \coordinate (Center) at (0,0); + \coordinate (cN) at ($(Center) + ( 40:2.5cm)$); + \coordinate (cM) at ($(cN) + (4cm,0)$); + \coordinate (cN') at ($(cM) + (4cm,0)$); + \coordinate (Center2) at ($(Center) + (4cm,0)$); + \coordinate (Center3) at ($(cM) + (-40:2.5cm)$); + \coordinate (Center4) at ($(Center3) + (4cm,0)$); + + %Cluster + \fill[black!20] ($(Center) + (0,1cm)$) rectangle ($(Center2) + (0,-1cm)$); + \fill[black!20] ($(Center3) + (0,1cm)$) rectangle ($(Center4) + (0,-1cm)$); + + %Bindings + \filldraw[white,draw=black,dashed,opacity=0.6] ($(Center) + (110:1cm)$) + -- (cN) + -- ($(Center) + (-30:1cm)$) + -- cycle; + \filldraw[white,draw=black,dashed,opacity=0.6] ($(Center2) + (110:1cm)$) + -- (cM) + -- ($(Center2) + (-30:1cm)$) + -- cycle; + \filldraw[white,draw=black,dashed,opacity=0.6] ($(Center3) + ( 70:1cm)$) + -- (cM) + -- ($(Center3) + (-150:1cm)$) + -- cycle; + \filldraw[white,draw=black,dashed,opacity=0.6] ($(Center4) + ( 70:1cm)$) + -- (cN') + -- ($(Center4) + (-150:1cm)$) + -- cycle; + + %Neuron nets + \node[family] at (Center) {$P$}; + \node[family] at (Center2) {$Q$}; + \node[family] at (Center3) {$Q'$}; + \node[family] at (Center4) {$P'$}; + + %Cat-neurons + \node[neuron,label=above:$n_1$] (N) at (cN) {}; + \node[neuron,label=above:$n_2$] (N') at (cN') {}; + \node[neuron,label=above:$n_3$] (M) at (cM) {}; + \draw[link] (N) to node[auto]{\small{$(P,Q)$}} (M); + \draw[link] (M) to node[auto]{\small{$(Q',P')$}} (N'); + \draw[link,bend left] (N) to (N'); +\end{tikzpicture} + +\begin{tikzpicture} + + \coordinate (Center) at (0,0); + \coordinate (cN) at ($(Center) + ( 55:3cm)$); + \coordinate (cM) at ($(cN) + (4cm,0)$); + \coordinate (cN') at ($(cM) + (4cm,0)$); + \coordinate (Center2) at ($(Center) + (4cm,0)$); + \coordinate (Center3) at ($(cM) + (-55:3cm)$); + \coordinate (Center4) at ($(Center3) + (4cm,0)$); + + % Specific identity + \coordinate (silb1) at ($(cN) + (-1cm,2cm)$); + \coordinate (silb2) at ($(Center) + (-1.5cm,-2cm)$); + \coordinate (corner1) at ($(cN') + (1cm,-0.5cm)$); + \coordinate (corner2) at ($(Center4) + (1.5cm,1.5cm)$); + \coordinate (lalb1) at ($(corner1) + (0,2.5cm)$); + \coordinate (lalb2) at ($(corner2) + (0,-3.5cm)$); + \coordinate (IQde) at ($(corner2) + (-1cm,0.1cm)$); + \coordinate (IQa) at ($(corner1) + (0.1cm,1cm)$); + \coordinate (centerSep) at (barycentric cs:cM=4,Center2=1,Center3=1); + \coordinate (levelCue) at ($ (centerSep) + (-8cm,0cm) $); + \coordinate (curlyCue) at ($ (centerSep) + (7cm,0cm) $); + %\draw[thick] (silb1) rectangle (corner1); + %\draw[thick] (silb2) rectangle (corner2); + %\node at (silb1) [label=south east:{Identité spécifique}] {}; + %\node at (silb2) [label=north east:{Identité spécifique}] {}; + \node at (levelCue) [label=north east:{Niveau $n+1$},yshift=-1mm] {}; + \node at (levelCue) [label=south east:{Niveau $n$},yshift=1mm] {}; + + \draw[double] (levelCue) -- (curlyCue) -- ($ (curlyCue) + (3.2cm,0cm) $); + + % Curlies + \draw[curlyM] ($ (curlyCue) + (0cm,0.05cm) $) -- +(0cm,1.5cm) + node (idnh) [midway,anchor=west,xshift=0.4cm] {Identité spécifique}; + \draw[curly ] ($ (curlyCue) + (0cm,-0.05cm) $) -- +(0cm,-3cm) + node (idnb) [midway,anchor=west,xshift=0.4cm] {Identité spécifique}; + + %\draw[-Stealth, thick] ([xshift=-1cm]idnb.north) -- ([xshift=-1cm]idnh.south) + %node [midway,auto,swap,text width={width("Identification")},align=center, + %fill=white] {Identification\\ qualitative}; + + + %Cluster + \fill[black,opacity=0.4] ($(Center) + (0,1cm)$) rectangle ($(Center2) + (0,-1cm)$); + \fill[black,opacity=0.4] ($(Center3) + (0,1cm)$) rectangle ($(Center4) + (0,-1cm)$); + + %Bindings + \filldraw[idq1,dashed,opacity=0.6] ($(Center) + (110:1cm)$) + -- (cN) + -- ($(Center) + (-30:1cm)$) + -- cycle; + \filldraw[idq2,dashed,opacity=0.6] ($(Center2) + (110:1cm)$) + -- (cM) + -- ($(Center2) + (-30:1cm)$) + -- cycle; + \filldraw[idq2,dashed,opacity=0.6] ($(Center3) + ( 70:1cm)$) + -- (cM) + -- ($(Center3) + (-150:1cm)$) + -- cycle; + \filldraw[idq3,dashed,opacity=0.6] ($(Center4) + ( 70:1cm)$) + -- (cN') + -- ($(Center4) + (-150:1cm)$) + -- cycle; + + %Neuron nets + \node[family,idq1] at (Center) {$P$}; + \node[family,idq2] at (Center2) {$Q$}; + \node[family,idq2] at (Center3) {$Q'$}; + \node[family,idq3] at (Center4) {$P'$}; + + %Cat-neurons + \node[neuron,idq1,label=above:$n_1$] (N) at (cN) {}; + \node[neuron,idq2,label=above:$n_2$] (M) at (cM) {}; + \node[neuron,idq3,label=above:$n_3$] (N') at (cN') {}; + \draw[link] (N) to node[auto]{\small{$(P,Q)$}} (M); + \draw[link] (M) to node[auto]{\small{$(Q',P')$}} (N'); + + % Identité numérique + \begin{scope}[on background layer] + \node[fit=(N) (M) (N'),inner sep=5mm,idn1,rounded corners] {}; + \node[fit=(Center) (Center2), inner sep=1.2cm,idn2,rounded corners] {}; + \node[fit=(Center3) (Center4), inner sep=1.2cm,idn3,rounded corners] {}; + \end{scope} +\end{tikzpicture} + +\end{document} diff --git a/figures/dla-active000.png b/figures/dla-active000.png new file mode 100755 index 0000000..d85e93e Binary files /dev/null and b/figures/dla-active000.png differ diff --git a/figures/dla-active110.png b/figures/dla-active110.png new file mode 100755 index 0000000..ed996ac Binary files /dev/null and b/figures/dla-active110.png differ diff --git a/figures/dla-active687.png b/figures/dla-active687.png new file mode 100755 index 0000000..64eb393 Binary files /dev/null and b/figures/dla-active687.png differ diff --git a/figures/dla-normal000.png b/figures/dla-normal000.png new file mode 100755 index 0000000..b543598 Binary files /dev/null and b/figures/dla-normal000.png differ diff --git a/figures/dla-normal110.png b/figures/dla-normal110.png new file mode 100755 index 0000000..a60943d Binary files /dev/null and b/figures/dla-normal110.png differ diff --git a/figures/dla-normal687.png b/figures/dla-normal687.png new file mode 100755 index 0000000..55a3ec5 Binary files /dev/null and b/figures/dla-normal687.png differ diff --git a/figures/ds2.tikz b/figures/ds2.tikz new file mode 100644 index 0000000..ba2c9d1 --- /dev/null +++ b/figures/ds2.tikz @@ -0,0 +1,46 @@ +\documentclass{standalone} +\input{common-headers} +\input{sigles} +\begin{document} +\begin{tikzpicture} +\draw (0,-1.0) node {$S$}; + \draw[thick,scale around={1.2:(1.5,1.5)}] (0,0) rectangle (3,3); + \begin{scope}[dashed] + \draw (1.1,1.1) rectangle (1.9,1.9); + \draw (0,0) rectangle (0.9,1.9); + \draw[rotate around={ 90:(1.5,1.5)}] (0,0) rectangle (0.9,1.9); + \draw[rotate around={180:(1.5,1.5)}] (0,0) rectangle (0.9,1.9); + \draw[rotate around={270:(1.5,1.5)}] (0,0) rectangle (0.9,1.9); + \end{scope} + \draw (1.5,-1.0) node {$s_1$}; +% Middle S +\begin{scope}[xshift=4cm] + \draw[thick,scale around={1.2:(1.5,1.5)}] (0,0) rectangle (3,3); + \begin{scope}[dashed] + \draw (1.1,1.1) rectangle (1.9,1.9); + \draw (0,0) rectangle (1.9,0.9); + \draw[rotate around={ 90:(1.5,1.5)}] (0,0) rectangle (1.9,0.9); + \draw[rotate around={180:(1.5,1.5)}] (0,0) rectangle (1.9,0.9); + \draw[rotate around={270:(1.5,1.5)}] (0,0) rectangle (1.9,0.9); + \end{scope} + \draw (1.5,-1.0) node {$s_2$}; +\end{scope} +\draw (8.5,1.5) node {$\cdots$}; +% Right S +\begin{scope}[xshift=10cm] + \draw[thick,scale around={1.2:(1.5,1.5)}] (0,0) rectangle (3,3); + \begin{scope}[dashed] + \draw (1.1,1.1) rectangle (1.9,1.9); + \draw (0,0) rectangle (0.9,0.9); + \draw[rotate around={ 90:(1.5,1.5)}] (0,0) rectangle (0.9,0.9); + \draw[rotate around={180:(1.5,1.5)}] (0,0) rectangle (0.9,0.9); + \draw[rotate around={270:(1.5,1.5)}] (0,0) rectangle (0.9,0.9); + \draw (1.1,0) rectangle ++(0.8,0.9); + \draw[rotate around={ 90:(1.5,1.5)}] (1.1,0) rectangle ++(0.8,0.9); + \draw[rotate around={180:(1.5,1.5)}] (1.1,0) rectangle ++(0.8,0.9); + \draw[rotate around={270:(1.5,1.5)}] (1.1,0) rectangle ++(0.8,0.9); + \end{scope} + \draw (1.5,-1.0) node {$s_i$}; +\end{scope} +\end{tikzpicture} +\end{document} diff --git a/figures/evolution01.png b/figures/evolution01.png new file mode 100755 index 0000000..f2b8249 Binary files /dev/null and b/figures/evolution01.png differ diff --git a/figures/evolution02.png b/figures/evolution02.png new file mode 100755 index 0000000..1a3fd2e Binary files /dev/null and b/figures/evolution02.png differ diff --git a/figures/evolution03.png b/figures/evolution03.png new file mode 100755 index 0000000..381b4e7 Binary files /dev/null and b/figures/evolution03.png differ diff --git a/figures/fire-active05.png b/figures/fire-active05.png new file mode 100644 index 0000000..2a2a5ce Binary files /dev/null and b/figures/fire-active05.png differ diff --git a/figures/fire-active22.png b/figures/fire-active22.png new file mode 100644 index 0000000..766c602 Binary files /dev/null and b/figures/fire-active22.png differ diff --git a/figures/fire-active95.png b/figures/fire-active95.png new file mode 100644 index 0000000..57040c1 Binary files /dev/null and b/figures/fire-active95.png differ diff --git a/figures/fire-normal05.png b/figures/fire-normal05.png new file mode 100644 index 0000000..1e2201d Binary files /dev/null and b/figures/fire-normal05.png differ diff --git a/figures/fire-normal22.png b/figures/fire-normal22.png new file mode 100644 index 0000000..d5ed9f1 Binary files /dev/null and b/figures/fire-normal22.png differ diff --git a/figures/fire-normal95.png b/figures/fire-normal95.png new file mode 100644 index 0000000..e661346 Binary files /dev/null and b/figures/fire-normal95.png differ diff --git a/figures/fms.tikz b/figures/fms.tikz new file mode 100644 index 0000000..25eaff1 --- /dev/null +++ b/figures/fms.tikz @@ -0,0 +1,32 @@ +\documentclass[crop,tikz]{standalone} +\input{common-headers} +\input{sigles} + +\begin{document} + +\begin{tikzpicture}[scale=2, + model/.style={draw}, + system/.style={draw}, + arrowed/.style={auto,-Stealth,shorten <=2pt,shorten >=2pt,bend angle=10}, + darowed/.style={auto,double,Stealth-Stealth,shorten <=2pt,shorten >=2pt}, + validate/.style={arrowed}, + validate2/.style={arrowed,dashed}, + annotation/.style={font=\scriptsize}] + + \node[model] (F) at ( 1cm, 0) {Formalisme}; + \node[model] (M) at ( -1cm, 0) {Modèle}; + + \draw[validate] (F) to node[annotation,swap] {permet d'exprimer} (M); + %\draw[validate,bend right] (M1) to node[annotation,swap] {validation} (W); + + % Separation + \draw[dashed] (-1.5cm,-0.5cm) to ( 2.5cm,-0.5cm); + \coordinate (legend) at (2,-0.5cm); + \node at (legend) [label=north:{Abstrait}] {}; + \node at (legend) [label=south:{Concret}] {}; + + \node[system] (S) at ( 0cm,-1cm) {Système}; + \draw[darowed] (M) to node[annotation,yshift=2pt] {explique} (S); +\end{tikzpicture} + +\end{document} diff --git a/figures/ftl01.png b/figures/ftl01.png new file mode 100644 index 0000000..a21ec62 Binary files /dev/null and b/figures/ftl01.png differ diff --git a/figures/ftl02.png b/figures/ftl02.png new file mode 100644 index 0000000..1ee760c Binary files /dev/null and b/figures/ftl02.png differ diff --git a/figures/ftl03.png b/figures/ftl03.png new file mode 100644 index 0000000..b5335cc Binary files /dev/null and b/figures/ftl03.png differ diff --git a/figures/ftl04.png b/figures/ftl04.png new file mode 100644 index 0000000..b561178 Binary files /dev/null and b/figures/ftl04.png differ diff --git a/figures/ftl05.png b/figures/ftl05.png new file mode 100644 index 0000000..30353d9 Binary files /dev/null and b/figures/ftl05.png differ diff --git a/figures/gbf.tikz b/figures/gbf.tikz new file mode 100644 index 0000000..848266f --- /dev/null +++ b/figures/gbf.tikz @@ -0,0 +1,35 @@ +\documentclass{standalone} +\input{common-headers} +\input{sigles} +\begin{document} +\begin{tikzpicture} +\clip(-2,-2) rectangle (2,2); +\begin{scope}[shift={(.5,.5)}] +\draw[densely dotted] (-3,-3) grid (3,3); +\end{scope} +\draw[fill] (1,0) circle (1.5pt) node[right] + {\GBF{e}}; +\draw[fill] (0,1) circle (1.5pt) node[above] + {\GBF{n}}; +\draw[fill] (1,1) circle (1.5pt) node[above right] + {\GBF{ne}}; +\draw[fill] (1,-1) circle (1.5pt) node[below right] + {\GBF{se}}; +\draw[thick,->] (0,0) -- (1,0); +\draw[thick,->] (0,0) -- (0,1); +\draw[thick,->] (0,0) -- (1,1); +\draw[thick,->] (0,0) -- (1,-1); +\draw[fill] (-1,0) circle (1.5pt) node[left] + {\GBF{w}}; +\draw[fill] (0,-1) circle (1.5pt) node[below] + {\GBF{s}}; +\draw[fill] (-1,-1) circle (1.5pt) node[below left] + {\GBF{sw}}; +\draw[fill] (-1,1) circle (1.5pt) node[above left] + {\GBF{nw}}; +\draw[dashed,->] (0,0) -- (-1,-0); +\draw[dashed,->] (0,0) -- (-0,-1); +\draw[dashed,->] (0,0) -- (-1,-1); +\draw[dashed,->] (0,0) -- (-1, 1); +\end{tikzpicture} +\end{document} diff --git a/figures/graph-neuron-models.tikz b/figures/graph-neuron-models.tikz new file mode 100644 index 0000000..9e043a6 --- /dev/null +++ b/figures/graph-neuron-models.tikz @@ -0,0 +1,6 @@ +\documentclass{standalone} +\input{common-headers} +\input{sigles} +\begin{document} +%stub +\end{document} diff --git a/figures/link.tikz b/figures/link.tikz new file mode 100644 index 0000000..008fc5f --- /dev/null +++ b/figures/link.tikz @@ -0,0 +1,33 @@ +\documentclass{standalone} +\input{common-headers} +\input{sigles} +\begin{document} + +\begin{tikzpicture}[auto, + mout/.style={->,shorten >=1pt, >=Stealth, semithick}, + leg/.style={inner sep=1pt,font=\scriptsize,yshift=-1pt} +] + \node (S) at (0cm, 0cm) {\includegraphics[width=2.5cm]{figures/operateursS} }; + \node (fS) at (3cm, 1.5cm) {\includegraphics[width=2.5cm]{figures/operateursfS} }; + \node (StfS) at (6cm, 1.5cm) {\includegraphics[width=2.5cm]{figures/operateursStfS}}; + \node (StS) at (3cm,-1.5cm) {\includegraphics[width=2.5cm]{figures/operateursStS} }; + \node (fStS) at (6cm,-1.5cm) {\includegraphics[width=2.5cm]{figures/operateursfStS}}; + \node (LkS) at (9cm, 0cm) {\includegraphics[width=2.5cm]{figures/operateursLkS} }; + + \node[leg] at (S.south) {$S$}; + \node[leg] at (fS.south) {$\fermeture{S}$}; + \node[leg] at (StS.south) {$\etoile{S}$}; + \node[leg] at (StfS.south) {$\etoile{\fermeture{S}}$}; + \node[leg] at (fStS.south) {$\fermeture{\etoile{S}}$}; + \node[leg] at (LkS.south) {$\liaison{S}$}; + + \draw [mout] (S) to [out = -60, in = 180] node [swap] {$\etoile{\textvisiblespace}$} (StS); + \draw [mout] (S) to [out = 60, in = 180] node {$\fermeture{\textvisiblespace}$} (fS); + \draw [mout] (fS) to [out = 60, in = 120] node [swap] {$\etoile{\textvisiblespace}$} (StfS); + \draw [mout] (StS) to [out = -60, in =-120] node {$\fermeture{\textvisiblespace}$} (fStS); + \draw [semithick] (StfS.east) to [out = 0, in = 180] (LkS.west); + \draw [semithick] (fStS.east) to [out = 0, in = 180] (LkS.west); + \node (LkSt) at (7cm,0cm) {$\textvisiblespace - \textvisiblespace$}; +\end{tikzpicture} + +\end{document} diff --git a/figures/lks.png b/figures/lks.png new file mode 100755 index 0000000..57386a1 Binary files /dev/null and b/figures/lks.png differ diff --git a/figures/log-steamer-bear.png b/figures/log-steamer-bear.png new file mode 100644 index 0000000..a06f477 Binary files /dev/null and b/figures/log-steamer-bear.png differ diff --git a/figures/margolus.tikz b/figures/margolus.tikz new file mode 100644 index 0000000..3c62400 --- /dev/null +++ b/figures/margolus.tikz @@ -0,0 +1,273 @@ +\documentclass[crop,tikz]{standalone} +\input{common-headers} + +\begin{document} + +\tikzset{cell color/.style={black!20}} + +\newcommand{\common}{% + \coordinate (ll) at (-2.5cm,-2.5cm); + \coordinate (ur) at (2.5cm,2.5cm); + \draw (ll) rectangle (ur); + \clip (ll)+(0.1cm,0.1cm) rectangle ([shift={(-0.1cm,-0.1cm)}]ur); + \fill[cell color] (ll) rectangle (ur); + \draw[very thick, white] (ll) grid (ur); +} + +\begin{tikzpicture} + \coordinate (ll) at (-2.5cm,-2.5cm); + \coordinate (ur) at (2.5cm,2.5cm); + \draw (ll) rectangle (ur); + \clip (ll)+(0.1cm,0.1cm) rectangle ([shift={(-0.1cm,-0.1cm)}]ur); + \fill[cell color] (ll) rectangle (ur); + \draw[very thick, white, step=2cm] (ll) grid (ur); + + \begin{scope}[xshift=-2.5cm,yshift=-2.5cm] + \node at (1,1) {a1}; + \node at (1,2) {$\strut$a2}; + \node at (2,2) {$\strut$\underline{a3}}; + \node at (2,1) {a4}; + \draw[step=1cm, xshift=0.5cm, yshift=0.5cm] (0.1,0.1) grid (1.9,1.9); + \node[opacity=0.5] at (1.5,1.5) {\Huge{A}}; + \end{scope} + + \begin{scope}[xshift=-2.5cm,yshift=-0.5cm] + \node at (1,1) {$\strut$b1}; + \node at (1,2) {b2}; + \node at (2,2) {b3}; + \node at (2,1) {$\strut$\underline{b4}}; + \draw[step=1cm, xshift=0.5cm, yshift=0.5cm] (0.1,0.1) grid (1.9,1.9); + \node[opacity=0.5] at (1.5,1.5) {\Huge{B}}; + \end{scope} + + \begin{scope}[xshift=-0.5cm,yshift=-0.5cm] + \node at (1,1) {$\strut$\underline{c1}}; + \node at (1,2) {c2}; + \node at (2,2) {c3}; + \node at (2,1) {$\strut$c4}; + \draw[step=1cm, xshift=0.5cm, yshift=0.5cm] (0.1,0.1) grid (1.9,1.9); + \node[opacity=0.5] at (1.5,1.5) {\Huge{C}}; + \end{scope} + + \begin{scope}[xshift=-0.5cm,yshift=-2.5cm] + \node at (1,1) {d1}; + \node at (1,2) {$\strut$\underline{d2}}; + \node at (2,2) {$\strut$d3}; + \node at (2,1) {d4}; + \draw[step=1cm, xshift=0.5cm, yshift=0.5cm] (0.1,0.1) grid (1.9,1.9); + \node[opacity=0.5] at (1.5,1.5) {\Huge{D}}; + \end{scope} + + \draw[very thick, step=4cm, xshift=2cm, yshift=2cm ] (ll) grid (ur); +\end{tikzpicture} + +\begin{tikzpicture} + \common + \draw[very thick, step=2cm] (ll) grid (ur); + + \begin{scope}[xshift=-2.5cm,yshift=-2.5cm] + \node at (1,1) {A}; + \node at (1,2) {B}; + \node at (2,2) {C}; + \node at (2,1) {D}; + \end{scope} + +\end{tikzpicture} + +\begin{tikzpicture} + \common + + \begin{scope}[xshift=-2.5cm,yshift=-2.5cm] + \node (oG) at (0,0) {}; + \node (oH) at (0,1) {}; + \node (oI) at (0,2) {}; + \node (oJ) at (0,3) {}; + \node (oK) at (1,3) {}; + \node (oL) at (2,3) {}; + \node (oM) at (3,3) {}; + \node (oN) at (3,2) {}; + \node (oO) at (3,1) {}; + \node (oP) at (3,0) {}; + \node (oE) at (2,0) {}; + \node (oF) at (1,0) {}; + \end{scope} + + \begin{scope}[xshift=-1cm,yshift=-1cm, scale=0.5, + every node/.style={fill=black,inner sep=0, minimum size=0.5cm}] + \clip (-2,-2) rectangle (2,2); + \fill[cell color] (-2,-2) rectangle (2,2); + \draw[step=1cm] (ll) grid (ur); + \begin{scope}[scale=0.5, white] + \node at (-1,-1) {A}; + \node at (-1, 1) {B}; + \node at ( 1, 1) {C}; + \node at ( 1,-1) {D}; + \end{scope} + \draw[white] (-0.90,-0.90) grid (0.90,0.90); + + \begin{scope}[shift={(-1.5,-1.5)}, + every node/.style={inner sep=0, minimum size=2pt}] + \node (0) at ( 0, 0) {}; + \node (1) at ( 0, 3) {}; + \node (2) at ( 3, 3) {}; + \node (3) at ( 3, 0) {}; + \node (4) at ( 0, 1) {}; + \node (5) at ( 0, 2) {}; + \node (6) at ( 1, 3) {}; + \node (7) at ( 2, 3) {}; + \node (8) at ( 3, 2) {}; + \node (9) at ( 3, 1) {}; + \node (10) at ( 2, 0) {}; + \node (11) at ( 1, 0) {}; + \end{scope} + \end{scope} + \draw[very thick, step=2cm, black!50] (ll) grid (ur); + \draw[very thick] (-2,-2) rectangle (0,0); + + \draw[-stealth, thick] (oG.center) to (0.center); + \draw[-stealth, thick] (oJ.center) to (1.center); + \draw[-stealth, thick] (oM.center) to (2.center); + \draw[-stealth, thick] (oP.center) to (3.center); + \draw[-stealth, thick] [bend right] (oH.center) to (4.center); + \draw[-stealth, thick] [bend left] (oI.center) to (5.center); + \draw[-stealth, thick] [bend right] (oK.center) to (6.center); + \draw[-stealth, thick] [bend left] (oL.center) to (7.center); + \draw[-stealth, thick] [bend right] (oN.center) to (8.center); + \draw[-stealth, thick] [bend left] (oO.center) to (9.center); + \draw[-stealth, thick] [bend right] (oE.center) to (10.center); + \draw[-stealth, thick] [bend left] (oF.center) to (11.center); + +\end{tikzpicture} + +\begin{tikzpicture} + \common + + \begin{scope}[xshift=-1cm,yshift=-1cm, scale=0.5, + every node/.style={fill=black!50,inner sep=0, minimum size=0.5cm}] + \clip (-2,-2) rectangle (2,2); + \fill[cell color] (-2,-2) rectangle (2,2); + \draw[step=1cm, black!50] (ll) grid (ur); + \begin{scope}[scale=0.5, white] + \node at (-1,-1) {A'}; + \node at (-1, 1) {B'}; + \node at ( 1, 1) {C'}; + \node at ( 1,-1) {D'}; + \end{scope} + \end{scope} + + \begin{scope}[xshift=1cm,yshift=1cm, scale=0.5, + every node/.style={fill=black!50,inner sep=0, minimum size=0.5cm}] + \clip (-2,-2) rectangle (2,2); + \fill[cell color] (-2,-2) rectangle (2,2); + \draw[step=1cm, black!50] (ll) grid ([shift={(-4,-4)}]ur); + \begin{scope}[scale=0.5, white] + \node at (-1,-1) {}; + \end{scope} + \end{scope} + + \begin{scope}[black!50] + \draw[very thick] (-2,-2) rectangle (0,0); + \draw[very thick] (0,0) rectangle (2,2); + \end{scope} + + \draw[very thick, step=2cm, xshift=1cm, yshift=1cm] (ll) grid (ur); + +\end{tikzpicture} + +\begin{tikzpicture} + \common + + \begin{scope}[xshift=-1cm,yshift=-1cm, scale=0.5, + every node/.style={fill=black!50,inner sep=0, minimum size=0.5cm}] + \clip (-2,-2) rectangle (2,2); + \fill[cell color] (-2,-2) rectangle (2,2); + \draw[step=1cm, black!50] (ll) grid (ur); + \begin{scope}[scale=0.5, white] + \node (A') at (-1,-1) {A'}; + \node (B') at (-1, 1) {B'}; + \node at ( 1, 1) {C'}; + \node (D') at ( 1,-1) {D'}; + \end{scope} + \end{scope} + + \begin{scope}[xshift=0cm,yshift=0cm, scale=0.5, + every node/.style={fill=black!50,inner sep=0, minimum size=0.5cm}] + \clip (-2,-2) rectangle (0,0); + \fill[cell color] (-2,-2) rectangle (2,2); + \draw[step=1cm, black!50] (ll) grid (ur); + \begin{scope}[scale=0.5, white] + \node at (-1,-1) {C'}; + \end{scope} + \end{scope} + + \begin{scope}[xshift=0cm,yshift=0cm, scale=0.5, + every node/.style={fill=black!50,inner sep=0, minimum size=0.5cm}] + \clip (0,0) rectangle (2,2); + \fill[cell color] (-2,-2) rectangle (2,2); + \draw[step=1cm, black!50] (ll) grid (ur); + \begin{scope}[scale=0.5, white] + \node at (1,1) {}; + \end{scope} + \end{scope} + + \begin{scope}[black!50] + \draw[very thick] (-2,-2) rectangle (0,0); + \draw[very thick] (0,0) rectangle (2,2); + \end{scope} + + \begin{scope}[scale=0.25,xshift=-2cm,yshift=-2cm, + every node/.style={circle, inner sep=0, minimum size=2pt}] + \node (A) at (-1,-1) {}; + \node (B) at (-1, 1) {}; + \node (D) at ( 1,-1) {}; + \draw[stealth-, thick] (A.center) to +( 225:2cm); + \draw[stealth-, thick] (B.center) to [bend right] ([shift={(0,0.5)}]B'.center); + \draw[stealth-, thick] (D.center) to [bend left ] ([shift={(0.5,0)}]D'.center); + \end{scope} + + \draw[very thick, step=2cm, xshift=1cm,yshift=1cm] (ll) grid (ur); + +\end{tikzpicture} + +\begin{tikzpicture} + \common + + \begin{scope}[xshift=-1cm,yshift=-1cm, scale=0.5, + every node/.style={black!50, inner sep=0, minimum size=0.5cm}, + important/.style={white, fill=black!50}] + \clip (-2,-2) rectangle (2,2); + \fill[cell color] (-2,-2) rectangle (2,2); + \draw[step=1cm, black!50] (ll) grid (ur); + \begin{scope}[scale=0.5] + \begin{scope}[shift={(-2,-2)}] + \node[important] at (-1,-1) {A'}; + \node at (-1, 1) {B'}; + \node at ( 1, 1) {C'}; + \node at ( 1,-1) {D'}; + \end{scope} + \begin{scope}[shift={(-2, 2)}] + \node at (-1,-1) {A'}; + \node[important] at (-1, 1) {B'}; + \node at ( 1, 1) {C'}; + \node at ( 1,-1) {D'}; + \end{scope} + \begin{scope}[shift={( 2, 2)}] + \node at (-1,-1) {A'}; + \node at (-1, 1) {B'}; + \node[important] at ( 1, 1) {C'}; + \node at ( 1,-1) {D'}; + \end{scope} + \begin{scope}[shift={( 2,-2)}] + \node at (-1,-1) {A'}; + \node at (-1, 1) {B'}; + \node at ( 1, 1) {C'}; + \node[important] at ( 1,-1) {D'}; + \end{scope} + \end{scope} + \end{scope} + + \draw[very thick, white] (ll) grid (ur); + \draw[very thick, step=2cm, xshift=1cm,yshift=1cm] (ll) grid (ur); + +\end{tikzpicture} +\end{document} diff --git a/figures/model-categories.tikz b/figures/model-categories.tikz new file mode 100644 index 0000000..d79c1c6 --- /dev/null +++ b/figures/model-categories.tikz @@ -0,0 +1,297 @@ +\documentclass[crop,tikz]{standalone} +\input{common-headers} +\input{sigles} + +\begin{document} + +%1 +\begin{tikzpicture} + \node (A) at (0,0) {$\cat{A}$}; + \node (B) at (4,0) {$\cat{B}$}; + \node (C) at (2,0) {$\cat{C}$}; + \draw[-Stealth] (A) to node[auto] {$S$} (C); + \draw[-Stealth] (B) to node[auto,swap] {$T$} (C); +\end{tikzpicture} + +%2 +\begin{tikzpicture} + \node (sa1) at (0,2) {$S(\alpha)$}; + \node (sa2) at (2,2) {$S(\alpha')$}; + \node (tb2) at (2,0) {$T(\beta')$}; + \node (tb1) at (0,0) {$T(\beta)$}; + + \draw[-Stealth] (sa1) to node[auto] {$S(g)$} (sa2); + \draw[-Stealth] (sa1) to node[auto,swap] {$f$} (tb1); + \draw[-Stealth] (sa2) to node[auto] {$f'$} (tb2); + \draw[-Stealth] (tb1) to node[auto,swap] {$T(h)$} (tb2); +\end{tikzpicture} + +%3 +\begin{tikzpicture} + \node (M0) at (2,0) {$M_0$}; + \node (M1) at (1,2) {$M$}; + \node (M2) at (3,2) {$M'$}; + \draw[-Stealth] (M1) to node[auto,swap] {$v_{M}$} (M0); + \draw[-Stealth] (M2) to node[auto] {$v_{M'}$} (M0); + \draw[-Stealth] (M1) to node[auto] {$a$} (M2); +\end{tikzpicture} + +%4: Produit +\begin{tikzpicture}[node distance=1cm and 2cm] + \node (P) at (0,0) {$P$}; + \node (X) [left=of P] {$X$}; + \node (Y) [right=of P] {$Y$}; + \node (Q) [above=of P] {$Q$}; + + \draw[-Stealth] (P) to node[auto] {$p_1$} (X); + \draw[-Stealth] (P) to node[auto,swap] {$p_2$} (Y); + \draw[-Stealth] (Q) to node[auto,swap] {$p'_1$} (X); + \draw[-Stealth] (Q) to node[auto] {$p'_2$} (Y); + \draw[-Stealth,dashed] (Q) to node[auto] {$\exists ! u$} (P); +\end{tikzpicture} + +%5 Coproduit +\begin{tikzpicture}[node distance=1cm and 2cm] + \node (P) at (0,0) {$P$}; + \node (X) [left=of P] {$X$}; + \node (Y) [right=of P] {$Y$}; + \node (Q) [above=of P] {$Q$}; + + \draw[-Stealth] (X) to node[auto,swap] {$i_1$} (P); + \draw[-Stealth] (Y) to node[auto] {$i_2$} (P); + \draw[-Stealth] (X) to node[auto] {$i'_1$} (Q); + \draw[-Stealth] (Y) to node[auto,swap] {$i'_2$} (Q); + \draw[-Stealth,dashed] (P) to node[auto,swap] {$\exists ! u$} (Q); +\end{tikzpicture} + +%6 Produit fibré (1) aka Pullback +\begin{tikzpicture} + \node (X) at ( 0,0) {$X$}; + \node (Y) at ( 2,2) {$Y$}; + \node (Z) at ( 2,0) {$Z$}; + \node (P) at ( 0,2) {$P$}; + + \draw[-Stealth] (X) to node[auto,swap] {$f$} (Z); + \draw[-Stealth] (Y) to node[auto] {$g$} (Z); + \draw[-Stealth] (P) to node[auto,swap] {$p_1$} (X); + \draw[-Stealth] (P) to node[auto] {$p_2$} (Y); +\end{tikzpicture} + + +%7 Produit fibré (2) Pullback +\begin{tikzpicture} + \node (X) at ( 0,0) {$X$}; + \node (Y) at ( 2,2) {$Y$}; + \node (Z) at ( 2,0) {$Z$}; + \node (P) at ( 0,2) {$P$}; + \node (Q) at (-1,3) {$Q$}; + + \draw[-Stealth] (X) to node[auto,swap] {$f$} (Z); + \draw[-Stealth] (Y) to node[auto] {$g$} (Z); + \draw[-Stealth] (P) to node[auto,swap] {$p_1$} (X); + \draw[-Stealth] (P) to node[auto] {$p_2$} (Y); + \draw[-Stealth,bend right] (Q) to node[auto,swap] {$p'_1$} (X); + \draw[-Stealth,bend left] (Q) to node[auto] {$p'_2$} (Y); + \draw[-Stealth,dashed] (Q) to node[auto] {$\exists ! u$} (P); +\end{tikzpicture} + +%8 Somme amalgamée (1) aka Pushout +\begin{tikzpicture} + \node (X) at ( 0,0) {$X$}; + \node (Y) at ( 2,2) {$Y$}; + \node (Z) at ( 2,0) {$Z$}; + \node (P) at ( 0,2) {$P$}; + + \draw[-Stealth] (Z) to node[auto] {$f$} (X); + \draw[-Stealth] (Z) to node[auto,swap] {$g$} (Y); + \draw[-Stealth] (X) to node[auto] {$i_1$} (P); + \draw[-Stealth] (Y) to node[auto,swap] {$i_2$} (P); +\end{tikzpicture} + +%9 Somme amalgamée (2) aka Pushout +\begin{tikzpicture} + \node (X) at ( 0,0) {$X$}; + \node (Y) at ( 2,2) {$Y$}; + \node (Z) at ( 2,0) {$Z$}; + \node (P) at ( 0,2) {$P$}; + \node (Q) at (-1,3) {$Q$}; + + \draw[-Stealth] (Z) to node[auto] {$f$} (X); + \draw[-Stealth] (Z) to node[auto,swap] {$g$} (Y); + \draw[-Stealth] (X) to node[auto] {$i_1$} (P); + \draw[-Stealth] (Y) to node[auto,swap] {$i_2$} (P); + \draw[-Stealth,bend left] (X) to node[auto] {$i'_1$} (Q); + \draw[-Stealth,bend right] (Y) to node[auto,swap] {$i'_2$} (Q); + \draw[-Stealth,dashed] (P) to node[auto,swap] {$\exists ! u$} (Q); +\end{tikzpicture} + +%10 Slice catégorie +\begin{tikzpicture}[node distance=1.2cm and 1cm] + \node (X) at (0,0) {$X$}; + \node (Y1) [above left =of X] {$Y1$}; + \node (Y2) [above right=of X] {$Y2$}; + + \draw[-Stealth] (Y1) to node[auto] {$g$} (Y2); + \draw[-Stealth] (Y1) to node[auto,swap] {$f_1$} (X); + \draw[-Stealth] (Y2) to node[auto] {$f_2$} (X); +\end{tikzpicture} + +%11 +\begin{tikzpicture} + \node (M1) at (-5,0) {$\model{M}{1}$}; + \node (M12) at (-3,0) {$\model{M}{12}$}; + \node (M2) at (-1,0) {$\model{M}{2}$}; + \node (M) at (-3,2) {$\modelM'$}; + + \node (equiv) at (0,0) {$\Leftrightarrow$}; + + \node (E1) at (1,0) {$E_{\model{M}{1}}$}; + \node (E12) at (3,0) {$E_{\model{M}{12}}$}; + \node (E2) at (5,0) {$E_{\model{M}{2}}$}; + \node (ER) at (3,-2) {$E_{\model{M}{S}}$}; + \node (EM) at (3,2) {$E_{\modelM'}$}; + + + \draw[-Stealth] (M12) to node[auto,swap] {$\absA_1$} (M1); + \draw[-Stealth] (M12) to node[auto] {$\absA_2$} (M2); + \draw[-Stealth,dashed] (M) to node[auto] {$\absA'$} (M12); + \draw[-Stealth] (M) to node[auto,swap] {$\absA'_1$} (M1); + \draw[-Stealth] (M) to node[auto] {$\absA'_2$} (M2); + + \draw[-Stealth] (E1) to node[auto] {$f_{\absA_1}$} (E12); + \draw[-Stealth] (E2) to node[auto,swap] {$f_{\absA_2}$} (E12); + \draw[-Stealth,dashed] (E12) to node[auto,swap] {$f_{\absA'}$} (EM); + \draw[-Stealth] (E1) to node[auto] {$f_{\absA'_1}$} (EM); + \draw[-Stealth] (E2) to node[auto,swap] {$f_{\absA'_2}$} (EM); + \draw[-Stealth] (ER) to node[auto] {$\sigma_{\model{M}{1}}$} (E1); + \draw[-Stealth] (ER) to node[auto,swap] {$\sigma_{\model{M}{2}}$} (E2); +\end{tikzpicture} + +%12 +\begin{tikzpicture} + \node (M1) at (-5,0) {$\model{M}{1}$}; + \node (M12) at (-3,2) {$\model{M}{12}^0$}; + \node (M2) at (-1,0) {$\model{M}{2}$}; + \node (M0) at (-3,0) {$\modelM_0$}; + + \node (equiv) at (0,0) {$\Leftrightarrow$}; + + \node (E1) at (1,0) {$E_{\model{M}{1}}$}; + \node (E12) at (3,2) {$E_{\model{M}{12}^0}$}; + \node (E2) at (5,0) {$E_{\model{M}{2}}$}; + \node (ER) at (3,-2) {$E_{\model{M}{S}}$}; + \node (EM) at (3,0) {$E_{\modelM_0}$}; + + \draw[-Stealth] (M12) to node[auto,swap] {$\absA_1$} (M1); + \draw[-Stealth] (M12) to node[auto] {$\absA_2$} (M2); + \draw[-Stealth] (M1) to node[auto] {$\absA^0_1$} (M0); + \draw[-Stealth] (M2) to node[auto,swap] {$\absA^0_2$} (M0); + + \draw[-Stealth] (E1) to node[auto] {$f_{\absA_1}$} (E12); + \draw[-Stealth] (E2) to node[auto,swap] {$f_{\absA_2}$} (E12); + \draw[-Stealth] (EM) to node[auto,swap] {$f_{\absA^0_1}$} (E1); + \draw[-Stealth] (EM) to node[auto] {$f_{\absA^0_2}$} (E2); + \draw[-Stealth] (ER) to node[auto] {$\sigma_{\model{M}{1}}$} (E1); + \draw[-Stealth] (ER) to node[auto,swap] {$\sigma_{\model{M}{2}}$} (E2); + \draw[-Stealth] (ER) to node[auto,swap] {$\sigma_{\model{M}{0}}$} (EM); +\end{tikzpicture} + +%13 +\begin{tikzpicture} + \node (Mp) at (-3,1) {$\model{M}{+}$}; + \node (Mm) at (-1,1) {$\model{M}{-}$}; + \node (eq) at (0,1) {$\Leftrightarrow$}; + \node (Er) at (2,0) {$E_{\model{M}{S}}$}; + \node (Ep) at (1,2) {$E_{\model{M}{+}}$}; + \node (Em) at (3,2) {$E_{\model{M}{-}}$}; + \draw[-Stealth] (Mp) to node[auto] {$\absA$} (Mm); + \draw[-Stealth] (Er) to node[auto] {$\sigma_{\model{M}{+}}$} (Ep); + \draw[-Stealth] (Er) to node[auto,swap] {$\sigma_{\model{M}{-}}$} (Em); + \draw[-Stealth] (Em) to node[auto,swap] {$f_\absA$} (Ep); +\end{tikzpicture} + +%14 +\begin{tikzpicture} + \node (Mp) at (-3,2) {$\model{M}{+}$}; + \node (Mm) at (-1,2) {$\model{M}{-}$}; + \node (eq) at (0,2) {$\Leftrightarrow$}; + \node (Er) at (2,0) {$E_{\model{M}{S}}$}; + \node (Ep) at (1,2) {$E_{\model{M}{+}}$}; + \node (Em) at (3,2) {$E_{\model{M}{-}}$}; + \node (eq) at (4,2) {$\stackrel{\ftr{U}_\cat{AMon}}\mapsfrom$}; + \node (ap) at (5,2) {$\Phi_+$}; + \node (am) at (7,2) {$\Phi_-$}; + + \draw[-Stealth] (Mp) to node[auto] {$\absA$} (Mm); + \draw[-Stealth] (Er) to node[auto] {$\sigma_{\model{M}{+}}$} (Ep); + \draw[-Stealth] (Er) to node[auto,swap] {$\sigma_{\model{M}{-}}$} (Em); + \draw[-Stealth] (Em) to node[auto,swap] {$f_\absA$} (Ep); + \draw[-Stealth] (am) to node[auto,swap] {$h$} (ap); +\end{tikzpicture} + +%15 +\begin{tikzpicture} + \node (M1) at (-2,0) {$\model{M}{1}$}; + \node (M12) at (0,0) {$\model{M}{12}$}; + \node (M2) at (2,0) {$\model{M}{2}$}; + \node (M) at (0,2) {$\modelM'$}; + + \draw[-Stealth] (M1) to node[auto] {$\absA_1$} (M12); + \draw[-Stealth] (M2) to node[auto,swap] {$\absA_2$} (M12); + \draw[-Stealth,dashed] (M12) to node[auto,swap] {$\absA'$} (M); + \draw[-Stealth] (M1) to node[auto] {$\absA'_1$} (M); + \draw[-Stealth] (M2) to node[auto,swap] {$\absA'_2$} (M); +\end{tikzpicture} + +%16 +\begin{tikzpicture} + \node (M1) at (-2,0) {$E_{\model{M}{1}}$}; + \node (M12) at (0,0) {$E_{\model{M}{12}}$}; + \node (M2) at (2,0) {$E_{\model{M}{2}}$}; + \node (M) at (0,2) {$E_{\modelM'}$}; + \node (R) at (0,-2) {$E_{\model{M}{S}}$}; + + \draw[-Stealth] (M12) to node[auto,swap] {$f_{\absA_1}$} (M1); + \draw[-Stealth] (M12) to node[auto] {$f_{\absA_2}$} (M2); + \draw[-Stealth,dashed] (R) to node[auto,swap] {$\sigma_{\model{M}{12}}$} (M12); + \draw[-Stealth] (R) to node[auto] {$\sigma_{\model{M}{1}}$} (M1); + \draw[-Stealth] (R) to node[auto,swap] {$\sigma_{\model{M}{2}}$} (M2); + \draw[-Stealth] (M) to node[auto,swap] {$f_{\absA'_1}$} (M1); + \draw[-Stealth] (M) to node[auto] {$f_{\absA'_2}$} (M2); + \draw[-Stealth,dashed] (M) to node[auto] {$f_{\absA'}$} (M12); +\end{tikzpicture} + +%17 +\begin{tikzpicture} + \node (M1) at (-5,0) {$\model{M}{1}$}; + \node (M12) at (-3,0) {$\model{M}{12}^0$}; + \node (M2) at (-1,0) {$\model{M}{2}$}; + \node (M0) at (-3,2) {$\model{M}{0}$}; + + \node (equiv) at (0,0) {$\Leftrightarrow$}; + + \node (E1) at (1,0) {$E_{\model{M}{1}}$}; + \node (E12) at (3,0) {$E_{\model{M}{12}^0}$}; + \node (E2) at (5,0) {$E_{\model{M}{2}}$}; + \node (ER) at (3,-2) {$E_{\model{M}{S}}$}; + \node (EM) at (3,2) {$E_{\model{M}{0}}$}; + + + \draw[-Stealth] (M1) to node[auto] {$\absA_1$} (M12); + \draw[-Stealth] (M2) to node[auto,swap] {$\absA_2$} (M12); + %%\draw[-Stealth,dashed] (M0) to node[auto] {$\absA'$} (M12); + \draw[-Stealth] (M0) to node[auto,swap] {$\absA^0_1$} (M1); + \draw[-Stealth] (M0) to node[auto] {$\absA^0_2$} (M2); + + \draw[-Stealth] (E12) to node[auto,swap] {$f_{\absA_1}$} (E1); + \draw[-Stealth] (E12) to node[auto] {$f_{\absA_2}$} (E2); + %\draw[-Stealth,dashed] (E12) to node[auto,swap] {$f_{\absA'}$} (EM); + \draw[-Stealth] (E1) to node[auto] {$f_{\absA^0_1}$} (EM); + \draw[-Stealth] (E2) to node[auto,swap] {$f_{\absA^0_2}$} (EM); + \draw[-Stealth] (ER) to node[auto] {$\sigma_{\model{M}{1}}$} (E1); + \draw[-Stealth] (ER) to node[auto,swap] {$\sigma_{\model{M}{2}}$} (E2); + \draw[-Stealth,dashed] (ER) to node[auto,swap] {$\sigma_{\model{M}{12}^0}$} (E12); +\end{tikzpicture} + + +\end{document} diff --git a/figures/model-relations.tikz b/figures/model-relations.tikz new file mode 100644 index 0000000..ccc0ebe --- /dev/null +++ b/figures/model-relations.tikz @@ -0,0 +1,66 @@ +\documentclass[crop,tikz]{standalone} +\input{common-headers} +\input{sigles} + +\begin{document} + +\begin{tikzpicture}[scale=2, + model/.style={draw}, + system/.style={draw,circle}, + arrowed/.style={auto,-Stealth,shorten <=2pt,shorten >=2pt,bend angle=10}, + darowed/.style={auto,double,Stealth-Stealth,shorten <=2pt,shorten >=2pt}, + validate/.style={arrowed}, + validate2/.style={arrowed,dashed}, + annotation/.style={font=\scriptsize}] + + \node[model] (M1) at ( 0, 0.7) {$\modelM$}; + \node[model] (W) at ( 0, 0) {$\model{M}{S}$}; + + \draw[validate] (M1) to node[annotation,swap] {validation $\sigma_{\modelM}$} (W); + %\draw[validate,bend right] (M1) to node[annotation,swap] {validation} (W); + + % Returning diagram + %\draw[validate2,bend right] (W) to (M1); + + % Separation + \draw[dashed] (-1,-1) to [bend left=70] ( 1,-1); + + \node[system] (S) at ( 0,-0.8) {$S$}; + \draw[darowed] (W) to node[annotation,yshift=2pt] {expériences/mesures} (S); +\end{tikzpicture} + +\begin{tikzpicture}[scale=2, + model/.style={draw}, + system/.style={draw,circle}, + arrowed/.style={auto,-Stealth,shorten <=2pt,shorten >=2pt,bend angle=10}, + darowed/.style={auto,double,Stealth-Stealth,shorten <=2pt,shorten >=2pt}, + validate/.style={arrowed}, + validate2/.style={arrowed,dashed}, + abstract/.style={arrowed,thick}, + abstract2/.style={arrowed,dashed,thick}, + annotation/.style={font=\scriptsize}] + + \node[model] (M1) at (-1, 1) {$E_{\model{M}{1}}$}; + %\node[model] (M2) at ( 0, 1) {$M_2$}; + \node[model] (M3) at ( 1, 1) {$E_{\model{M}{2}}$}; + \node[model] (W) at ( 0, 0) {$E_{\model{M}{S}}$}; + + \draw[validate,bend left] (W.west) to node[annotation,swap] {$\sigma_{\model{M}{1}}$} (M1.south); + %\draw[validate] (M2) to node[annotation] {validation} (W.north); + \draw[validate,bend right] (W.east) to node[annotation] {$\sigma_{\model{M}{2}}$} (M3.south); + + \draw[abstract,bend left] (M1) to node[annotation,swap] {$a$} (M3); + %\draw[abstract,bend left] (M2) to node[annotation] {abstraction} (M3); + + % Returning diagram + %\draw[abstract2,bend left] (M2) to (M1); + %\draw[abstract2,bend left] (M3) to (M2); + %\draw[validate2,bend right] (W.north west) to (M1); + %\draw[validate2,bend left] (W.north east) to (M2); +\end{tikzpicture} + +\begin{tikzpicture}[scale=2] + +\end{tikzpicture} + +\end{document} diff --git a/figures/openGLPipeline.tikz b/figures/openGLPipeline.tikz new file mode 100644 index 0000000..dbbab28 --- /dev/null +++ b/figures/openGLPipeline.tikz @@ -0,0 +1,31 @@ +\documentclass[crop,tikz]{standalone} +\input{common-headers} + +\begin{document} + +\begin{tikzpicture}[% + shader/.style={draw,fill=white,nearly opaque, minimum size=1.5cm,% + align=center, node distance=5mm}, + prgrbl/.style={shader,opaque,thick,font=\bfseries}, + prgrbo/.style={prgrbl,dashed}, + f/.tip={Fast Triangle[cap angle=120]}, + >/.tip={Triangle Cap[cap angle=120] . f f}, % Normal tips + >-[reversed]} % Reversed tips + ] + \node[shader] (S1) at (0,0) {Vertex\\ Specification}; + \node[prgrbl,right=of S1] (S2) {Vertex\\ Shader}; + \node[prgrbo,right=of S2] (S3) {Tessellation}; + \node[prgrbo,right=of S3] (S4) {Geometry\\ Shader}; + \node[shader,right=of S4] (S5) {Vertex\\ Post-Processing}; + \node[shader,below=of S5] (S6) {Primitive\\ Assembly}; + \node[shader,left =of S6] (S7) {Rasterization}; + \node[prgrbo,left =of S7] (S8) {Fragment\\ Shader}; + \node[shader,left =of S8] (S9) {Per-Sample\\ Operations}; + \begin{scope}[on background layer] + \draw[line width=1cm, >->,black!40,rounded corners] + ($(S1.center) + (-3cm,0)$) to (S5.center)% + to (S6.center) to ($(S9.center) + (-3cm,0)$); + \end{scope} +\end{tikzpicture} + +\end{document} \ No newline at end of file diff --git a/figures/operateursLkS.tikz b/figures/operateursLkS.tikz new file mode 100644 index 0000000..903a69e --- /dev/null +++ b/figures/operateursLkS.tikz @@ -0,0 +1,49 @@ +\documentclass{standalone} +\input{common-headers} +\input{sigles} +\begin{document} +% Link de S +\begin{tikzpicture} + \input{operateurs} + + \draw[1cell] (D.corner 1) -- (D.corner 2); + \draw[1cell] (D.corner 2) -- (D.corner 3); + \draw[1cell] (D.corner 3) -- (D.corner 4); + \draw[1cell] (E.corner 2) -- (E.corner 3); + \draw[1cell] (E.corner 3) -- (E.corner 4); + \draw[1cell] (E.corner 4) -- (E.corner 5); + \draw[1cell] (F.corner 3) -- (F.corner 4); + \draw[1cell] (F.corner 4) -- (F.corner 5); + \draw[1cell] (F.corner 5) -- (F.corner 6); + \draw[1cell] (G.corner 4) -- (G.corner 5); + \draw[1cell] (G.corner 5) -- (G.corner 6); + \draw[1cell] (G.corner 6) -- (G.corner 1); + \draw[1cell] (B.corner 5) -- (B.corner 6); + \draw[1cell] (B.corner 6) -- (B.corner 1); + \draw[1cell] (B.corner 1) -- (B.corner 2); + \draw[1cell] (C.corner 6) -- (C.corner 1); + \draw[1cell] (C.corner 1) -- (C.corner 2); + \draw[1cell] (C.corner 2) -- (C.corner 3); + + \node[0cell] (g1) at (G.corner 1) {}; + \node[0cell] (b2) at (B.corner 2) {}; + \node[0cell] (c3) at (C.corner 3) {}; + \node[0cell] (d4) at (D.corner 4) {}; + \node[0cell] (e5) at (E.corner 5) {}; + \node[0cell] (f6) at (F.corner 6) {}; + + \node[0cell] (c1) at (C.corner 1) {}; + \node[0cell] (c2) at (C.corner 2) {}; + \node[0cell] (d2) at (D.corner 2) {}; + \node[0cell] (d3) at (D.corner 3) {}; + \node[0cell] (e3) at (E.corner 3) {}; + \node[0cell] (e4) at (E.corner 4) {}; + \node[0cell] (f4) at (F.corner 4) {}; + \node[0cell] (f5) at (F.corner 5) {}; + \node[0cell] (g5) at (G.corner 5) {}; + \node[0cell] (g6) at (G.corner 6) {}; + \node[0cell] (b6) at (B.corner 6) {}; + \node[0cell] (b1) at (B.corner 1) {}; +\end{scope} +\end{tikzpicture} +\end{document} diff --git a/figures/operateursS.tikz b/figures/operateursS.tikz new file mode 100644 index 0000000..59e0b13 --- /dev/null +++ b/figures/operateursS.tikz @@ -0,0 +1,26 @@ +\documentclass{standalone} +\input{common-headers} +\input{sigles} +\begin{document} +\begin{tikzpicture} + \input{operateurs} + + \draw[1cell] (A.corner 1) -- (A.corner 2); + \draw[1cell] (A.corner 2) -- (A.corner 3); + \draw[1cell] (A.corner 3) -- (A.corner 4); + \draw[1cell] (A.corner 4) -- (A.corner 5); + \draw[1cell] (A.corner 5) -- (A.corner 6); + \draw[1cell] (A.corner 6) -- (A.corner 1); + + \begin{scope}[0cell/.style={circle, inner sep=0, minimum width=5pt, + fill = black!20, draw = white, thick}] + \node[0cell] (a1) at (A.corner 1) {}; + \node[0cell] (a2) at (A.corner 2) {}; + \node[0cell] (a3) at (A.corner 3) {}; + \node[0cell] (a4) at (A.corner 4) {}; + \node[0cell] (a5) at (A.corner 5) {}; + \node[0cell] (a6) at (A.corner 6) {}; + \end{scope} +\end{scope} +\end{tikzpicture} +\end{document} diff --git a/figures/operateursStS.tikz b/figures/operateursStS.tikz new file mode 100644 index 0000000..86d6acf --- /dev/null +++ b/figures/operateursStS.tikz @@ -0,0 +1,35 @@ +\documentclass{standalone} +\input{common-headers} +\input{sigles} +\begin{document} +% étoile de S +\begin{tikzpicture} + \input{operateurs} + + \node[2cell] (a) at (A) {}; + \node[2cell] (b) at (B) {}; + \node[2cell] (c) at (C) {}; + \node[2cell] (d) at (D) {}; + \node[2cell] (e) at (E) {}; + \node[2cell] (f) at (F) {}; + \node[2cell] (g) at (G) {}; + + \draw[1cell] (A.corner 1) -- (A.corner 2); + \draw[1cell] (A.corner 2) -- (A.corner 3); + \draw[1cell] (A.corner 3) -- (A.corner 4); + \draw[1cell] (A.corner 4) -- (A.corner 5); + \draw[1cell] (A.corner 5) -- (A.corner 6); + \draw[1cell] (A.corner 6) -- (A.corner 1); + + \begin{scope}[0cell/.style={circle, inner sep=0, minimum width=5pt, + fill = black!20, draw = white, thick}] + \node[0cell] (a1) at (A.corner 1) {}; + \node[0cell] (a2) at (A.corner 2) {}; + \node[0cell] (a3) at (A.corner 3) {}; + \node[0cell] (a4) at (A.corner 4) {}; + \node[0cell] (a5) at (A.corner 5) {}; + \node[0cell] (a6) at (A.corner 6) {}; + \end{scope} +\end{scope} +\end{tikzpicture} +\end{document} diff --git a/figures/operateursStfS.tikz b/figures/operateursStfS.tikz new file mode 100644 index 0000000..ec085ab --- /dev/null +++ b/figures/operateursStfS.tikz @@ -0,0 +1,49 @@ +\documentclass{standalone} +\input{common-headers} +\input{sigles} +\begin{document} +% Étoile fermeture de S +\begin{tikzpicture} + \input{operateurs} + + \node[2cell] (a) at (A) {}; + \node[2cell] (b) at (B) {}; + \node[2cell] (c) at (C) {}; + \node[2cell] (d) at (D) {}; + \node[2cell] (e) at (E) {}; + \node[2cell] (f) at (F) {}; + \node[2cell] (g) at (G) {}; + + \draw[1cell] (A.corner 1) -- (A.corner 2); + \draw[1cell] (A.corner 2) -- (A.corner 3); + \draw[1cell] (A.corner 3) -- (A.corner 4); + \draw[1cell] (A.corner 4) -- (A.corner 5); + \draw[1cell] (A.corner 5) -- (A.corner 6); + \draw[1cell] (A.corner 6) -- (A.corner 1); + + \draw[1cell] (A.corner 1) -- (B.corner 2); + \draw[1cell] (A.corner 2) -- (C.corner 3); + \draw[1cell] (A.corner 3) -- (D.corner 4); + \draw[1cell] (A.corner 4) -- (E.corner 5); + \draw[1cell] (A.corner 5) -- (F.corner 6); + \draw[1cell] (A.corner 6) -- (G.corner 1); + + \node[0cell] (a1) at (A.corner 1) {}; + \node[0cell] (a2) at (A.corner 2) {}; + \node[0cell] (a3) at (A.corner 3) {}; + \node[0cell] (a4) at (A.corner 4) {}; + \node[0cell] (a5) at (A.corner 5) {}; + \node[0cell] (a6) at (A.corner 6) {}; + + \begin{scope}[0cell/.style={circle, inner sep=0, minimum width=5pt, + fill = black!20, draw = white, thick}] + \node[0cell] (g1) at (G.corner 1) {}; + \node[0cell] (b2) at (B.corner 2) {}; + \node[0cell] (c3) at (C.corner 3) {}; + \node[0cell] (d4) at (D.corner 4) {}; + \node[0cell] (e5) at (E.corner 5) {}; + \node[0cell] (f6) at (F.corner 6) {}; + \end{scope} +\end{scope} +\end{tikzpicture} +\end{document} diff --git a/figures/operateursfS.tikz b/figures/operateursfS.tikz new file mode 100644 index 0000000..186566b --- /dev/null +++ b/figures/operateursfS.tikz @@ -0,0 +1,24 @@ +\documentclass{standalone} +\input{common-headers} +\input{sigles} +\begin{document} +% Fermeture de S (pareil) +\begin{tikzpicture} + \input{operateurs} + + \draw[1cell] (A.corner 1) -- (A.corner 2); + \draw[1cell] (A.corner 2) -- (A.corner 3); + \draw[1cell] (A.corner 3) -- (A.corner 4); + \draw[1cell] (A.corner 4) -- (A.corner 5); + \draw[1cell] (A.corner 5) -- (A.corner 6); + \draw[1cell] (A.corner 6) -- (A.corner 1); + + \node[0cell] (a1) at (A.corner 1) {}; + \node[0cell] (a2) at (A.corner 2) {}; + \node[0cell] (a3) at (A.corner 3) {}; + \node[0cell] (a4) at (A.corner 4) {}; + \node[0cell] (a5) at (A.corner 5) {}; + \node[0cell] (a6) at (A.corner 6) {}; +\end{scope} +\end{tikzpicture} +\end{document} diff --git a/figures/operateursfStS.tikz b/figures/operateursfStS.tikz new file mode 100644 index 0000000..53332e6 --- /dev/null +++ b/figures/operateursfStS.tikz @@ -0,0 +1,78 @@ +\documentclass{standalone} +\input{common-headers} +\input{sigles} +\begin{document} +% fermeture de étoile S +\begin{tikzpicture} + \input{operateurs} + + \node[2cell] (a) at (A) {}; + \node[2cell] (b) at (B) {}; + \node[2cell] (c) at (C) {}; + \node[2cell] (d) at (D) {}; + \node[2cell] (e) at (E) {}; + \node[2cell] (f) at (F) {}; + \node[2cell] (g) at (G) {}; + + \draw[1cell] (A.corner 1) -- (A.corner 2); + \draw[1cell] (A.corner 2) -- (A.corner 3); + \draw[1cell] (A.corner 3) -- (A.corner 4); + \draw[1cell] (A.corner 4) -- (A.corner 5); + \draw[1cell] (A.corner 5) -- (A.corner 6); + \draw[1cell] (A.corner 6) -- (A.corner 1); + + \draw[1cell] (A.corner 1) -- (B.corner 2); + \draw[1cell] (A.corner 2) -- (C.corner 3); + \draw[1cell] (A.corner 3) -- (D.corner 4); + \draw[1cell] (A.corner 4) -- (E.corner 5); + \draw[1cell] (A.corner 5) -- (F.corner 6); + \draw[1cell] (A.corner 6) -- (G.corner 1); + + \draw[1cell] (D.corner 1) -- (D.corner 2); + \draw[1cell] (D.corner 2) -- (D.corner 3); + \draw[1cell] (D.corner 3) -- (D.corner 4); + \draw[1cell] (E.corner 2) -- (E.corner 3); + \draw[1cell] (E.corner 3) -- (E.corner 4); + \draw[1cell] (E.corner 4) -- (E.corner 5); + \draw[1cell] (F.corner 3) -- (F.corner 4); + \draw[1cell] (F.corner 4) -- (F.corner 5); + \draw[1cell] (F.corner 5) -- (F.corner 6); + \draw[1cell] (G.corner 4) -- (G.corner 5); + \draw[1cell] (G.corner 5) -- (G.corner 6); + \draw[1cell] (G.corner 6) -- (G.corner 1); + \draw[1cell] (B.corner 5) -- (B.corner 6); + \draw[1cell] (B.corner 6) -- (B.corner 1); + \draw[1cell] (B.corner 1) -- (B.corner 2); + \draw[1cell] (C.corner 6) -- (C.corner 1); + \draw[1cell] (C.corner 1) -- (C.corner 2); + \draw[1cell] (C.corner 2) -- (C.corner 3); + + \node[0cell] (a1) at (A.corner 1) {}; + \node[0cell] (a2) at (A.corner 2) {}; + \node[0cell] (a3) at (A.corner 3) {}; + \node[0cell] (a4) at (A.corner 4) {}; + \node[0cell] (a5) at (A.corner 5) {}; + \node[0cell] (a6) at (A.corner 6) {}; + + \node[0cell] (g1) at (G.corner 1) {}; + \node[0cell] (b2) at (B.corner 2) {}; + \node[0cell] (c3) at (C.corner 3) {}; + \node[0cell] (d4) at (D.corner 4) {}; + \node[0cell] (e5) at (E.corner 5) {}; + \node[0cell] (f6) at (F.corner 6) {}; + + \node[0cell] (c1) at (C.corner 1) {}; + \node[0cell] (c2) at (C.corner 2) {}; + \node[0cell] (d2) at (D.corner 2) {}; + \node[0cell] (d3) at (D.corner 3) {}; + \node[0cell] (e3) at (E.corner 3) {}; + \node[0cell] (e4) at (E.corner 4) {}; + \node[0cell] (f4) at (F.corner 4) {}; + \node[0cell] (f5) at (F.corner 5) {}; + \node[0cell] (g5) at (G.corner 5) {}; + \node[0cell] (g6) at (G.corner 6) {}; + \node[0cell] (b6) at (B.corner 6) {}; + \node[0cell] (b1) at (B.corner 1) {}; +\end{scope} +\end{tikzpicture} +\end{document} diff --git a/figures/otb-concentric-bact.png b/figures/otb-concentric-bact.png new file mode 100644 index 0000000..dcdc4e6 Binary files /dev/null and b/figures/otb-concentric-bact.png differ diff --git a/figures/otb-concentric-boundingbox.png b/figures/otb-concentric-boundingbox.png new file mode 100644 index 0000000..433c9bc Binary files /dev/null and b/figures/otb-concentric-boundingbox.png differ diff --git a/figures/otb-concentric-morpho.png b/figures/otb-concentric-morpho.png new file mode 100644 index 0000000..0c29c29 Binary files /dev/null and b/figures/otb-concentric-morpho.png differ diff --git a/figures/otb-multi-view.pdf b/figures/otb-multi-view.pdf new file mode 100644 index 0000000..7a345e8 Binary files /dev/null and b/figures/otb-multi-view.pdf differ diff --git a/figures/otb2-display.png b/figures/otb2-display.png new file mode 100644 index 0000000..15b6010 Binary files /dev/null and b/figures/otb2-display.png differ diff --git a/figures/otbModules.tikz b/figures/otbModules.tikz new file mode 100644 index 0000000..5192556 --- /dev/null +++ b/figures/otbModules.tikz @@ -0,0 +1,49 @@ +\documentclass{standalone} +\input{common-headers} +\input{sigles} +\begin{document} +\begin{tikzpicture}[node distance=4cm, + normalNodes/.style={inner sep=10pt,outer sep=2pt,minimum width=2.5cm}, + main/.style={normalNodes,draw=black}, + high/.style={normalNodes,draw=black,fill=black!20}, + low/.style= {normalNodes,draw=black,fill=black!40}, + regTo/.style={-Stealth,thick}, + mainTo/.style={-Stealth,thick}] + \node (Main) [main] {\texttt{Main}}; + \node (Morphogen) [high,below of=Main, xshift=-2cm] {\texttt{Morphogen}}; + \node (Bacterium) [high,left of=Morphogen] {\texttt{Bacterium}}; + \node (Zone) [high,right of=Morphogen] {\texttt{Zone}}; + \node (Coupling) [high,right of=Zone] {\texttt{Coupling}}; + \node (BoundingBox) [low,below of=Zone] {\texttt{BoundingBox}}; + \node (OpenCL) [low,below of=Coupling] {\texttt{OpenCL}}; + \node (SBGP) [low,right of=OpenCL] {\texttt{SBGP}}; + \node (Packfile) [low,below of=Morphogen] {\texttt{Packfile}}; + \node (Viewer) [low,below of=Bacterium] {\texttt{Viewer}}; + + \coordinate (MZ) % + at (barycentric cs:Morphogen=1,Zone=1) {}; + \draw [mainTo] (Main) to [out=-90,in=90] (Bacterium); + \draw [mainTo] (Main) to [out=-90,in=90] (Morphogen); + \draw [mainTo] (Main) to [out=-90,in=90] (Zone); + \draw [mainTo] (Main) to [out=-90,in=90] (Coupling); + \draw [mainTo] (Main) to [out=-90,in=120] (BoundingBox); + \draw [mainTo] (Main) to [out=0,in=90] (SBGP); + \draw [mainTo] (Main) to [out=-90,in=90] (MZ) to [out=-90,in=45] (Viewer); + + \node (BM) [inner sep=1pt, fill=black, draw=black, yshift=-10pt, circle]% + at (barycentric cs:Morphogen=1,Bacterium=1) {}; + \draw [thick] (Bacterium) to [out=0,in=135] (BM); + \draw [thick] (Morphogen) to [out=180,in=45] (BM); + \draw [regTo] (BM) to [out=-90,in=90] (Viewer); + \draw [regTo] (BM) to [out=-85,in=90] (Packfile); + \draw [regTo] (BM) to [out=-70,in=145] (BoundingBox); + \draw [regTo] (BM) to [out=-55,in=155] (OpenCL); + + \draw [regTo] (Zone) to (BoundingBox); + \draw [regTo] (Zone) to [out=-70,in=135] (OpenCL); + \draw [regTo] (Coupling) to (OpenCL); + \draw [regTo] (Coupling) to [out=-70,in=135] (SBGP); +% + +\end{tikzpicture} +\end{document} diff --git a/figures/plot-ff.tikz b/figures/plot-ff.tikz new file mode 100644 index 0000000..f27d350 --- /dev/null +++ b/figures/plot-ff.tikz @@ -0,0 +1,22 @@ +\documentclass{standalone} +\input{common-headers} +\input{sigles} +\begin{document} +\begin{tikzpicture} + \pgfplotsset{width=.6\textwidth} + \begin{axis}[% + xlabel=Itérations + ,scale only axis + ,ylabel=Quantité normalisée + ,ymin=0,ymax=1.1 + ,xmin=0,xmax=1000 + ,no markers + ,legend style={draw=none,at={(0.98,0.5)},anchor=east} + ,legend cell align=left] + \addplot+[blue!50] table[x=ITER,y=NONITERNORM] {data/speedup2.data}; + \addplot+[black] table[x=ITER,y=OPTITERNORM] {data/speedup2.data}; + \addplot+[black,dashed] table[x=ITER,y=ACTIVENORM] {data/speedup2.data}; + \legend{Simulation normale, Simulation optimisée, Cellules actives} + \end{axis} +\end{tikzpicture} +\end{document} diff --git a/figures/s.png b/figures/s.png new file mode 100755 index 0000000..9d0ced5 Binary files /dev/null and b/figures/s.png differ diff --git a/figures/schema-lv.tikz b/figures/schema-lv.tikz new file mode 100644 index 0000000..677a25a --- /dev/null +++ b/figures/schema-lv.tikz @@ -0,0 +1,23 @@ +\documentclass[crop,tikz]{standalone} +\input{common-headers} +\input{sigles} + +\begin{document} + +\begin{tikzpicture}[% + follow/.style={midway,sloped,above}] + \node (mv) at (0,0) {\model{M}{V}}; + \node (msv) at (2,1) {\model{M}{SV}}; + \node (ml) at (2,-1) {\model{M}{L}}; + \node (msvl) at (4,0) {?}; + \node (msl) at (6,0) {\model{M}{SL}}; + + \draw[-Stealth] (mv) to node[follow] {\scriptsize abstraction} (msv); + \draw[-Stealth] (mv) to node[follow] {\scriptsize abstraction} (ml); + + \draw[-Stealth, dashed] (msv) to node[follow] {?} (msvl); + \draw[-Stealth, dashed] (ml) to node[follow] {?} (msvl); + \draw[-Stealth, dashed] (msvl) to node[follow] {?} (msl); +\end{tikzpicture} + +\end{document} diff --git a/figures/sectors-original.png b/figures/sectors-original.png new file mode 100644 index 0000000..f1656fd Binary files /dev/null and b/figures/sectors-original.png differ diff --git a/figures/sectors.png b/figures/sectors.png new file mode 100644 index 0000000..c27bcd2 Binary files /dev/null and b/figures/sectors.png differ diff --git a/figures/stablePopulation.tikz b/figures/stablePopulation.tikz new file mode 100644 index 0000000..696dc02 --- /dev/null +++ b/figures/stablePopulation.tikz @@ -0,0 +1,17 @@ +\documentclass{standalone} +\input{common-headers} +\input{sigles} +\begin{document} +\begin{tikzpicture} + \pgfplotsset{width=14cm,height=6cm} + \begin{axis}[% + xlabel=Itérations + % ,scale only axis + ,ylabel=Nombre de bactéries + % ,ymin=0,ymax=1.1 + % ,xmin=0,xmax=1000 + ] + \addplot[black] table {data/stablePopulation.data}; + \end{axis} +\end{tikzpicture} +\end{document} diff --git a/figures/system-bounce.png b/figures/system-bounce.png new file mode 100644 index 0000000..8290c5d Binary files /dev/null and b/figures/system-bounce.png differ diff --git a/figures/system-bounce.svg b/figures/system-bounce.svg new file mode 100644 index 0000000..609e15a --- /dev/null +++ b/figures/system-bounce.svg @@ -0,0 +1,139 @@ + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + diff --git a/figures/time-discrete-shade.png b/figures/time-discrete-shade.png new file mode 100644 index 0000000..2935589 Binary files /dev/null and b/figures/time-discrete-shade.png differ diff --git a/figures/time-discrete.png b/figures/time-discrete.png new file mode 100644 index 0000000..d3c6eb9 Binary files /dev/null and b/figures/time-discrete.png differ diff --git a/figures/time-discrete.svg b/figures/time-discrete.svg new file mode 100644 index 0000000..f4c464e --- /dev/null +++ b/figures/time-discrete.svg @@ -0,0 +1,316 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/figures/time-leibniz.png b/figures/time-leibniz.png new file mode 100644 index 0000000..d12d054 Binary files /dev/null and b/figures/time-leibniz.png differ diff --git a/figures/time-newton-shade.png b/figures/time-newton-shade.png new file mode 100644 index 0000000..ff01f60 Binary files /dev/null and b/figures/time-newton-shade.png differ diff --git a/figures/time-newton.png b/figures/time-newton.png new file mode 100644 index 0000000..0b273a8 Binary files /dev/null and b/figures/time-newton.png differ diff --git a/figures/time-newton.svg b/figures/time-newton.svg new file mode 100644 index 0000000..c44203d --- /dev/null +++ b/figures/time-newton.svg @@ -0,0 +1,628 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + t=1,0 + t=1,7 + t=4,1 + t=6,0 + t=6,9 + t=8,4 + t=4,1 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/figures/time-notime-shadenotime.png b/figures/time-notime-shadenotime.png new file mode 100644 index 0000000..d0e4542 Binary files /dev/null and b/figures/time-notime-shadenotime.png differ diff --git a/figures/time-notime-shadetime.png b/figures/time-notime-shadetime.png new file mode 100644 index 0000000..2c490db Binary files /dev/null and b/figures/time-notime-shadetime.png differ diff --git a/figures/time-notime.png b/figures/time-notime.png new file mode 100644 index 0000000..d0bef94 Binary files /dev/null and b/figures/time-notime.png differ diff --git a/figures/time-notime.svg b/figures/time-notime.svg new file mode 100644 index 0000000..7bd8a4f --- /dev/null +++ b/figures/time-notime.svg @@ -0,0 +1,367 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/figures/wave01.png b/figures/wave01.png new file mode 100755 index 0000000..74c6f88 Binary files /dev/null and b/figures/wave01.png differ diff --git a/figures/wave02.png b/figures/wave02.png new file mode 100755 index 0000000..e2437d1 Binary files /dev/null and b/figures/wave02.png differ diff --git a/figures/wave03.png b/figures/wave03.png new file mode 100755 index 0000000..19e7167 Binary files /dev/null and b/figures/wave03.png differ diff --git a/figures/wave04.png b/figures/wave04.png new file mode 100755 index 0000000..0d1ff0d Binary files /dev/null and b/figures/wave04.png differ diff --git a/figures/wordcloud.pdf b/figures/wordcloud.pdf new file mode 100644 index 0000000..4cba827 Binary files /dev/null and b/figures/wordcloud.pdf differ diff --git a/fonts/Asana-Math.otf b/fonts/Asana-Math.otf new file mode 100644 index 0000000..a885c44 Binary files /dev/null and b/fonts/Asana-Math.otf differ diff --git a/fonts/FantasqueSansMono-Bold.ttf b/fonts/FantasqueSansMono-Bold.ttf new file mode 100644 index 0000000..915d32d Binary files /dev/null and b/fonts/FantasqueSansMono-Bold.ttf differ diff --git a/fonts/FantasqueSansMono-BoldItalic.ttf b/fonts/FantasqueSansMono-BoldItalic.ttf new file mode 100644 index 0000000..5bcb8c0 Binary files /dev/null and b/fonts/FantasqueSansMono-BoldItalic.ttf differ diff --git a/fonts/FantasqueSansMono-Italic.ttf b/fonts/FantasqueSansMono-Italic.ttf new file mode 100644 index 0000000..2130ccb Binary files /dev/null and b/fonts/FantasqueSansMono-Italic.ttf differ diff --git a/fonts/FantasqueSansMono-Regular.ttf b/fonts/FantasqueSansMono-Regular.ttf new file mode 100644 index 0000000..70eb993 Binary files /dev/null and b/fonts/FantasqueSansMono-Regular.ttf differ diff --git a/fonts/LinBiolinum-R.otf b/fonts/LinBiolinum-R.otf new file mode 100644 index 0000000..ada5880 Binary files /dev/null and b/fonts/LinBiolinum-R.otf differ diff --git a/fonts/LinBiolinum-RB.otf b/fonts/LinBiolinum-RB.otf new file mode 100644 index 0000000..d86721e Binary files /dev/null and b/fonts/LinBiolinum-RB.otf differ diff --git a/fonts/LinBiolinum-RI.otf b/fonts/LinBiolinum-RI.otf new file mode 100644 index 0000000..86d0cf4 Binary files /dev/null and b/fonts/LinBiolinum-RI.otf differ diff --git a/fonts/LinLibertine-R.otf b/fonts/LinLibertine-R.otf new file mode 100644 index 0000000..6d345d5 Binary files /dev/null and b/fonts/LinLibertine-R.otf differ diff --git a/fonts/LinLibertine-RB.otf b/fonts/LinLibertine-RB.otf new file mode 100644 index 0000000..811cea8 Binary files /dev/null and b/fonts/LinLibertine-RB.otf differ diff --git a/fonts/LinLibertine-RBI.otf b/fonts/LinLibertine-RBI.otf new file mode 100644 index 0000000..c1a4ff7 Binary files /dev/null and b/fonts/LinLibertine-RBI.otf differ diff --git a/fonts/LinLibertine-RI.otf b/fonts/LinLibertine-RI.otf new file mode 100644 index 0000000..288f5d0 Binary files /dev/null and b/fonts/LinLibertine-RI.otf differ diff --git a/main.tex b/main.tex new file mode 100644 index 0000000..d24cb83 --- /dev/null +++ b/main.tex @@ -0,0 +1,257 @@ +\documentclass[11pt,openright]{book} +\usepackage[a4paper]{geometry} +% BEFORE fancyhdr + +\usepackage{fancyhdr} +\fancypagestyle{plain} + +\fancyhead[LO]{\nouppercase{\rightmark}} +\fancyhead[RE]{\nouppercase{\leftmark}} +\fancyhead[LE,RO]{\thepage} +\fancyfoot{} + +\input{common-headers} + +\usepackage{amsthm} +\theoremstyle{plain} +\newtheorem{mpo-definition}{Définition}[section] +\newtheorem{mpo-proposition}{Proposition}[section] +\newtheorem{mpo-corollaire}[mpo-proposition]{Corollaire} +\theoremstyle{definition} +\newtheorem{mpo-exemple}{Exemple}[section] + +% For nested empth +% http://tex.stackexchange.com/questions/318374/emph-not-working-well-in-amsthms-plain-style-using-xelatex-or-lualatex +\ExplSyntaxOn +\cs_set:cpn {th@plain} { \int_zero:N \l__fontspec_em_int \em } +\ExplSyntaxOff + +\usepackage{placeins} % \FloatBarrier + +\usepackage{listings} +\usepackage{multirow} +\usepackage{multicol} +\usepackage{tabularx} + +\lstdefinestyle{code}{ + belowcaptionskip=1\baselineskip, + breaklines=true, + %xleftmargin=\parindent, + showstringspaces=false, + basicstyle=\ttfamily, + keywordstyle=\bfseries\color{green!40!black}, + commentstyle=\itshape\color{purple!40!black}, + identifierstyle=\color{black}, + stringstyle=\color{orange} +} +\lstdefinestyle{framed}{ + frame=tb, + basicstyle=\footnotesize\ttfamily, + %xleftmargin=\parindent +} +\lstdefinestyle{mgs}{ + style=code, + language=Caml, + basicstyle=\footnotesize\ttfamily, + morekeywords={trans,=>,gbf}, + morecomment=[l]{//} +} +\lstdefinestyle{ocaml}{ + style=code, + language=Caml, + basicstyle=\footnotesize\ttfamily, +} +\lstdefinestyle{sbgp}{ + style=code, + style=framed, + string=[s]{"}{"}, + stringstyle=\it + %language=Java +} +\lstdefinestyle{c}{ + style=code, + style=framed, + language=C +} + +\lstnewenvironment{MGScode}{\lstset{escapechar=@,style=mgs}}{} +\lstnewenvironment{SBGPcode}{\lstset{escapechar=@,style=sbgp}}{} +\lstnewenvironment{OCAMLcode}{\lstset{escapechar=@,style=ocaml}}{} +\lstnewenvironment{Ccode}{\lstset{escapechar=@,style=c}}{} +\newcommand\ç{\lstinline[style=code]} + +\newenvironment{shell}% Courtesy of scolobb + {\\[2mm]\texttt\bgroup\indent\ignorespaces}% + {\egroup\\[2mm]\noindent} + +\usepackage[ +french, +linesnumbered, +vlined, +boxed, +commentsnumbered, +titlenotnumbered]{algorithm2e} + +\usepackage[ + backend=biber, + style=numeric, + maxbibnames=99, + doi=false, + url=false, + isbn=false, + eprint=false, + defernumbers=true, + refsection=chapter, +]{biblatex} +\addbibresource{biblio/these2016.bib} +\addbibresource{biblio/standards.bib} + +\usepackage{hyperref} +\hypersetup{pdfauthor={Martin Potier}, + pdftitle={\@title}, + pdfsubject={Thèse de doctorat en Informatique}, + pdfkeywords={}, + pdfproducer={XeteX}, + pdfcreator={Xetex}} + +\graphicspath{{figures/}} + +\usepackage{caption} +\usepackage{subcaption} + +\usepackage{enumitem} +\setlist[itemize]{noitemsep} + +\usepackage{minitoc} +\mtcselectlanguage{french} +\usepackage{setspace} + + + + + + +\title{% +Un cadre théorique pour l'intégration des niveaux d'organisation dans les +modèles. Applications à l'activité spatiale et à la simulation de grandes +populations de bactéries.% +} +\author{Martin \textsc{Potier}}% +\date{{\small Version du \today}\xspace} + +\input{sigles} + +% Réglages pour les paragraphes +\setlength{\parindent}{1em} +\setlength{\parskip}{1ex} + +\newcommand{\makeway}{% + \clearpage{\pagestyle{empty}\cleardoublepage}} + +\makeatletter +\def\cleardoublepage{\clearpage\if@twoside \ifodd\c@page\else + \hbox{} + \thispagestyle{empty} + \newpage + \if@twocolumn\hbox{}\newpage\fi\fi\fi} +\makeatother + + +\begin{document} +%coupures +\hyphenation{quel-ques} +\hyphenation{u-ni-ver-sum} +\hyphenation{con-cer-ne} +\hyphenation{é-vè-ne-ments} +\hyphenation{e-ve-ne-ments} + +% Change itemize bullet +\renewcommand\labelitemi{\tikz{\filldraw (0,0) circle (2pt);}} + +\makeatletter +\begin{titlepage}\centering + {\bf UNIVERSITÉ PARIS-EST\par + ÉCOLE DOCTORALE MSTIC}\par + \vspace*{\fill} + {\LARGE\bf THÈSE DE DOCTORAT}\\ + pour obtenir le titre de\par + \vspace*{1cm} + {\LARGE\bf Docteur de l'Université Paris-Est}\par + \vspace*{1cm} + {\bf Spécialité : Informatique}\par + défendue par\par + \vspace*{1cm} + {\Large \@author}\par + \vspace*{1cm} + {\Large\bf \@title}\par + \vspace*{\fill} + Directeur de thèse : Olivier \textsc{Michel}\\ + préparée au LACL\par + \vspace*{\fill} + \begin{flushleft} + Soutenue le 6 juillet 2017 devant le jury composé de:\par + \end{flushleft} + \begin{tabularx}{\textwidth}{lXl} + \hline + \emph{Rapporteurs}: & Arnaud \textsc{Banos} & CNRS — Géographie-Cités\\ + & Hanna \textsc{Klaudel} & Université d'Évry — IBISC\\ + \emph{Examinateurs}:& Hugues \textsc{Berry} & INRIA\\ + & Nathalie \textsc{Corson} & Université du Havre — LMAH\\ + & Jean-Louis \textsc{Giavitto} & CNRS — IRCAM \\ + & Lisandru \textsc{Muzy} & CNRS — MS\&N\\ + \emph{Encadrant}: & Antoine \textsc{Spicher} & Université Paris-Est Créteil — LACL \\ + \emph{Directeur}: & Olivier \textsc{Michel} & Université Paris-Est Créteil — LACL \\ + \hline + \end{tabularx}\par +\end{titlepage} +\makeatother + +\makeway\thispagestyle{empty} +\vspace*{\fill} +\noindent +Thèse préparée au LACL\\ +(Laboratoire d'Algorithmique Complexité et Logique) + +\vspace{6mm}\noindent +LACL\\ +Faculté des Sciences et Technologie\\ +61 avenue du Général De Gaulle\\ +\num{94010} Créteil + +\vspace{6mm}\noindent +\makeatletter +\@date rédigée avec \LaTeX +\makeatother + +\newgeometry{a4paper,top=2.5cm, bottom=2cm, left=2.5cm, right=2.5cm} +\include{remerciements} +\restoregeometry + +\pagenumbering{roman} +\setcounter{tocdepth}{2} +\dominitoc +\tableofcontents +\listoffigures +\pagestyle{fancy} + +\makeway\thispagestyle{empty} +% DONE: wordcloud (www.jasondavies.com/wordcloud) +\begin{tikzpicture}[remember picture,overlay] + \node at (current page.center) {% + \includegraphics[width=1.2\textwidth]{wordcloud.pdf}% + }; +\end{tikzpicture} +\makeway\pagenumbering{arabic} + +\include{partie-introduction} +\include{partie-multi-modele}\printbibliography[heading=subbibliography] +\include{partie-activite}\printbibliography[heading=subbibliography] +\include{partie-otb}\printbibliography[heading=subbibliography] +\include{partie-conclusion} + +\makeway +\newgeometry{a4paper,top=2.5cm, bottom=2cm, left=2.5cm, right=2.5cm} +\include{resume} +\restoregeometry + +\end{document} diff --git a/operateurs.tex b/operateurs.tex new file mode 100644 index 0000000..7c1d01a --- /dev/null +++ b/operateurs.tex @@ -0,0 +1,52 @@ +\begin{scope}[% + every node/.style={regular polygon, regular polygon sides=6, + minimum width=1cm, + outer sep=0}, + 2cell/.style={fill, red!70!black, scale=0.8}, + 1cell/.style={draw, red!70!black, very thick}, + 0cell/.style={circle, inner sep=0, minimum width=5pt, + fill = red!70!black, draw = white, thick}, + transform shape] + \draw (-1.6cm,-1.6cm) rectangle (1.6cm,1.6cm); + \clip (-1.5cm,-1.5cm) rectangle (1.5cm,1.5cm); + \node (A) {}; + \node[anchor=corner 3] (B) at (A.corner 1) {}; + \node[anchor=corner 4] (C) at (A.corner 2) {}; + \node[anchor=corner 5] (D) at (A.corner 3) {}; + \node[anchor=corner 6] (E) at (A.corner 4) {}; + \node[anchor=corner 1] (F) at (A.corner 5) {}; + \node[anchor=corner 2] (G) at (A.corner 6) {}; + \node[anchor=corner 3] (H) at (G.corner 1) {}; + \node[anchor=corner 3] (I) at (B.corner 1) {}; + \node[anchor=corner 3] (J) at (C.corner 1) {}; + \node[anchor=corner 4] (K) at (C.corner 2) {}; + \node[anchor=corner 5] (L) at (C.corner 3) {}; + \node[anchor=corner 5] (M) at (D.corner 3) {}; + \node[anchor=corner 1] (N) at (D.corner 3) {}; + \node[anchor=corner 1] (O) at (E.corner 3) {}; + \node[anchor=corner 1] (P) at (F.corner 3) {}; + \node[anchor=corner 2] (Q) at (F.corner 4) {}; + \node[anchor=corner 3] (R) at (F.corner 5) {}; + \node[anchor=corner 3] (S) at (G.corner 5) {}; + \node[anchor=corner 3] (T) at (J.corner 1) {}; + \node[anchor=corner 6] (U) at (L.corner 2) {}; + \node[anchor=corner 1] (V) at (P.corner 3) {}; + \node[anchor=corner 2] (W) at (R.corner 6) {}; + + \begin{scope}[% + 2cell/.style={fill, black!20, scale=0.8}, + 1cell/.style={draw, black!20, very thick, shorten <=1pt, shorten >=1pt}, + 0cell/.style={circle, inner sep=0, minimum width=5pt, + fill = black!20, draw = white, thick}, + transform shape] + \foreach \nd in {A,...,W}{ + \node[2cell] (b\nd) at (\nd) {}; + } + \foreach \nd in {A,...,W}{ + \draw[1cell] (\nd.corner 6) -- (\nd.corner 1) -- (\nd.corner 2) -- (\nd.corner 3); + } + \foreach \nd in {A,...,W}{ + \foreach \cn in {1,2,3} + \node[0cell] (c\nd\cn) at (\nd.corner \cn) {}; + } + \end{scope} diff --git a/partie-activite.tex b/partie-activite.tex new file mode 100644 index 0000000..094f586 --- /dev/null +++ b/partie-activite.tex @@ -0,0 +1,1785 @@ +\chapter{L'activité dans la programmation spatiale}\label{chap:partie-activite} +\minitoc + +\section{Introduction} +% D'où activité ? +% C'est quoi le contexte + +Nous commencerons cette partie en introduisant la notion d'activité, ses +origines et son rapport à la modélisation multi-niveau. Après une partie +concernant \mgs{} et le formalisme qui lui est associé, nous aborderons ses +liens avec l'\emph{activité}. Il apparaît que cette notion est intimement liée à +la vision de l'espace que promeut le projet \mgs{} et ainsi, notre exploration +mettra en évidence des résultats à la fois formels et pratiques. + +\section{Activité} + +Intuitivement, nous dirons que l'activité est constitué d'un ensemble des choses +qui changent, c'est à dire sur lesquels une action a eu lieu, en opposition au +reste qui ne change pas. Au delà des différents sens communs accordés à +l'activité, on rencontre quelques autres termes qui y sont naturellement liés +comme état, énergie, changement ou mouvement. Le concept, plus formel, +d'activité est emprunté au domaine de la simulation \cite{tocher_art_1967} ; il +est reconnu, défini et utilisé dans plusieurs domaines scientifiques, dont la +physique, la biologie, l'économie, l'épistémologie et bien naturellement +l'informatique. L'article \cite{muzy_refounding_2013} fait la synthèse des +différents domaines et propose une définition de l'activité dans chacun de ces +contextes. + +\paragraph{Activité en simulation} +\begin{quote} +An activity is an operation that transforms the state of a system over time. +It begins with an event and ends by producing another event (linked to the +termination of the activity). \hfill\textbf{Muzy et al.}~\cite{muzy_refounding_2013} +\end{quote} +% +Une \emph{activité}, terme dénombrable dans ce cas, est une opération +transformant l'état d'un système au cours du temps. Elle commence avec un +évènement et termine en produisant un autre évènement (lié à la fin de cette +l'activité). Un \emph{évènement} est ce qui change l'état d'un système +(éventuellement composé de nombreux composants). Pour finir, on appelle un +\emph{processus} une séquence d'activités et d'évènements ordonnés dans le +temps. On peut remarquer que le terme «évènement» est central dans cette +définition des activités. De plus les activités sont des objets plutôt que la +mesure d'une quantité (la quantité d'activité). + +\paragraph{Activité dans DEVS} Deux définitions de l'activité pour les systèmes +à évènements discrets (Discrete-Event Systems ou DEVS) sont proposées : +% +\begin{itemize} +\item L'activité \emph{qualitative} : un système est qualitativement inactif + quand aucun évènement n'a lieu et est qualitativement actif sinon. +\item L'activité \emph{quantitative} : la somme des activités quantitatives + interne et externe est égale à la valeur de l'activité quantitative, pendant + un certain temps de simulation. Les évènements discrets peuvent être de deux + types : interne ou externe au modèle atomique (endogène ou exogène). + L'\emph{activité quantitative interne} correspond au nombre d'évènements + discrets internes, pendant un certain temps de simulation. L'\emph{activité + quantitative externe} correspond au nombre d'évènements discrets externes, + pendant un certain temps de simulation. L'activité externe fournit une + information sur la quantité de messages échangés par les modèles atomiques. +\end{itemize} + +\paragraph{Activité du vivant} En biologie, l'activité semble être liée au +vivant, à la propriété d'être vivant. Une cellule est dite active si elle est +\emph{vivante}, ce qui ramène à la question de la définition du vivant. À +l'échelle infra-cellulaire, cette définition fonctionne moins bien : il suffit +de considérer chaque partie d'une cellule et tenter de déterminer si elle est +vivante ou pas. Pour résoudre ce problème, la définition d'activité que l'on +souhaite considérer est celle du point de vue de la chimie, à l'échelle +moléculaire : +% +\begin{quote} + […] any biological object which is the locus of both exchanges (gas, liquids, + nutrients, molecules, etc.) and transformations (chemical transformations), + which result in maintaining the integrity of the object, is declared active.\\ + \hfill\textbf{Muzy et al.}~\cite{muzy_refounding_2013} +\end{quote} +Un objet biologique est dit \emph{actif} s'il est à la fois un locus d'échanges +(gaz, liquides, nutriments, molécules, …) et de transformations (transformations +chimiques) et que ces échanges et transformations assurent la persistance de cet +objet. + +% La biologie, c'est le royaume des exemples. +Avec ces deux définitions arrivent les problèmes de \emph{quantification} de +l'activité dans les systèmes biologiques ; les mesures sont indirectes et les +observables, c'est à dire les paramètres mesurables, sont nombreuses. En effet, +au delà de l'influence même de la mesure sur ces systèmes, parfois seules des +mesures de paramètres globaux, comme la quantité de CO$_2$ et de O$_2$ échangé +entre le système et l'extérieur, sont accessibles. Autre exemple, pour connaître +l'activité d'un réseau de neurones dans le cerveau, les chercheurs et les +médecins ont recourt à l'imagerie par résonance magnétique fonctionnelle (IRMf) +qui permet de connaître les zones du cerveau qui sont irriguées par du sang +oxygéné. Dans les deux cas les mesures sont indirectes : elles sont plus ou +moins globales et ne permettent pas de connaître l'activité de chacune des +parties du système, de chaque cellule ou de chaque partie d'une cellule. De +plus, de par la redondance des systèmes biologiques, une même sous-partie peut +avoir plusieurs fonctions et une même fonction peut-être assurée par des +sous-parties différentes dans un même système. Il est ainsi difficile de +déterminer quelle partie du système a contribué au fonctionnement global et dans +quelle proportion. + +% DONE: ajouter la définition de l'activité en économie +\paragraph{Activité économique} L'activité est au cœur des sciences +économiques de part l'objet d'étude de cette discipline. En effet l'économie +est une science qui se focalise sur la manière dont des ressources rares sont +utilisées dans le but de satisfaire les besoins humains. Elle s'intéresse par +conséquent aux opérations de production, de distribution et de consommation +des biens d'une part, aux institutions et aux structures dont le but est de +faciliter ces opérations d'autre part. Autrement dit, l'activité correspond à +« ce que les acteurs font » ; l'activité économique est donc un phénomène +impactant une ressource rare. + +Deux perspectives sur l'activité cohabitent : +\begin{itemize} + \item l'économie (néo)classique se penche sur les conséquences de + l'activité, c'est à dire sur l'utilité de la situation qui en découle + et non pas sur les décisions prises par les acteurs. Ces décisions sont + prises à la suite d'un calcul rationnel, soit seul (\emph{substantive + rationality}), soit en groupe après délibération (\emph{procedural + rationality}), en fonction de la valeur de gain liée à ce choix ; + \item l'économie comportementale (\emph{behavioral economics}) est plutôt + portée sur la manière dont les acteurs choisissent leurs activités, + comment ils choisissent ce qu'ils vont faire. Leurs choix sont dans ce cas + dictés par une règle préétablie (\emph{rule rationality}), un mode de + comportement qui incorpore toutes les situations concernées par cette + règle. +\end{itemize} +% +On remarque que dans chacune de ces perspectives on \emph{ignore} l'activité en +elle-même ; la valeur de l'utilité, conséquence d'un choix d'activité, est +mise en avant dans le premier cas, le choix du type d'activité lui-même est +mis en avant dans le second cas. En économie, établir la mesure de l'activité +ne suscite que peu d'intérêt et \emph{reste un défi à relever}. Par analogie +avec la définition de l'activité quantitative dans le cas des systèmes à +évènements discrets, on donne la définition suivante : l'activité est le +décompte du nombre d'évènements concernant des ressources rares. Un exemple +d'usage prospectif est donné dans la section intitulée « Optimal Control +Model of Activity » de \cite{muzy_refounding_2013}. + +% DONE: conclure avec une considération générale comme c'est bordélique, +% pourrait-on trouver un point de vue plus fédérateur pour la +% modélisation en tt cas ? +% DONE: donner dans chaque cas ce que ma thèse apporte + +\bigskip\noindent Pour conclure cette section sur l'activité, nous émettons les +remarques suivantes: +\begin{itemize} +\item Les différentes définitions de l'activité suivant les domaines d'études ne + se recouvrent pas exactement, néanmoins dans chaque cas l'activité, ou les + activités, nous offrent une mesure sur le système étudié ; +\item La mesure d'activité donne une représentation abstraite du système étudié, + une mesure agrégée qui \emph{appartient à un autre niveau de représentation + que le système} lui-même. +\end{itemize} +Nous verrons dans la suite de ce chapitre qu'il est possible de définir un +nouveau type d'activité, l'activité spatiale, dans le contexte de \mgs{} et que +cette activité nous apportera une représentation du système utile à la fois pour +la simulation et pour la modélisation. + +%L'activité est couramment utilisée pour décrire, durant ou après une simulation, +%ce qui change dans un système, que ce soit : +%\begin{itemize} +% \item en économie, pour décrire les tâches entreprises par des individus, et +% les moyens mis en œuvre pour y parvenir ; +% \item en biologie, pour décrire les parties du système étudié qui produisent, +% consomment ou échangent des éléments chimiques ; +% \item en DEVS, pour décrire un ensemble d'évènements répartis dans le temps +% \item ou initialement en simulation, comme l'intervalle entre chaque évènement +% de la simulation. +%\end{itemize} +% L'activité est aussi une manière de modéliser à un autre niveau de +% représentation, il reste à inventer cette nouvelle manière de modéliser. + +\section{Complexe cellulaire abstrait} +\label{sec:cca} +Les développements présentés dans la suite de ce chapitre reposent sur une +classe d'objets mathématiques nommés \emph{complexes cellulaires abstraits}, +une description formelle et abstraite de l'espace qui sert de fondement aux +collections topologiques de \mgs{} ainsi qu'à la définition de l'activité +spatiale. Cette section présente le formalisme et quelques propriétés +associées. + +Afin d'effectuer des calculs dans l'espace, il peut être pratique de découper +cet espace en éléments primordiaux, possédant une dimension, « accolés » les uns +aux autres. Nous appelons ces éléments primordiaux des \emph{cellules + topologiques} dont l'assemblage combinatoire forme un \emph{complexe + cellulaire abstrait} (\cca). Une \cell{p} est une cellule topologique de +dimension $p$. Par exemple, les \cells{0} sont des points, les \cells{1} sont +des arcs, les \cells{2} sont des surfaces, les \cells{3} des volumes, … Les +cellules topologiques sont « jointes » par une relation appelée \emph{relation + d'incidence}. Plus formellement, il s'ensuit les définitions correspondantes. + +% CCA +\begin{mpo-definition} +Soit $S$ un ensemble de symboles appelés \emph{cellules topologiques} muni d'un +ordre partiel localement fini $\cdot\,\preceq\,\cdot \subset S \times S$ appelé +\emph{relation d'incidence}. Le couple $\ccaK = (S, \preceq)$ est appelé +\emph{complexe cellulaire abstrait}. +\end{mpo-definition} + +% Dimension est une fonction monotone strictement croissante +\begin{mpo-definition} +Soit $\ccaK = (S, \preceq)$ un complexe cellulaire abstrait. La fonction +$\ccad_{\ccaK} : S \rightarrow \mathbb{N}$ telle que pour $\sigma_1, +\sigma_2 \in S,\:\sigma_1 \prec \sigma_2 \Rightarrow \ccad_{\ccaK}(\sigma_1) < +\ccad_{\ccaK}(\sigma_2)$ est appelée fonction de \emph{dimension}. +\end{mpo-definition} + +Dans la suite de ce manuscrit, on notera $\ccad$ au lieu de $\ccad_{\ccaK}$ +quand il n'y a pas d'ambigüité sur \ccaK. De plus, on notera parfois $\sigma +\in \ccaK$ au lieu de $\sigma \in S$. + +% Exemple +\begin{figure}[h] + \begin{center} + \includegraphics{cc} + \end{center} + \caption{Diagramme de Hasse (à gauche) de la relation d'incidence dans le + complexe cellulaire du milieu. Ce dernier est constitué d'une \cell{2} $f$, + de trois \cells{1} ($e_1, e_2, e_3$) et de trois \cells{0} ($c_1, c_2, + c_3$). Les trois arcs sont les faces de $f$ et par définition, $f$ est une + coface de $e_1$, $e_2$ et $e_3$. Ce complexe est décoré par des valeurs + arbitraires (à droite) comme des coordonnées pour les points, des distances + pour les arcs et une aire pour la surface.} + \label{fig:cc} +\end{figure} + +% Union +L'opération ensembliste \emph{union} est naturellement étendue aux complexes +cellulaires : soient $\ccaK_1 = (S_1, \preceq_1)$ et $\ccaK_2 = (S_2, +\preceq_2)$ deux complexes cellulaires, $\ccaK_1 \cup \ccaK_2 = (S_1 \cup S_2, +\preceq_1 \cup \preceq_2)$ si $\ccad_{\ccaK_1}$ et $\ccad_{\ccaK_2}$ coïncident +sur $S_1 \cap S_2$. + +% Sous-complexe +\begin{mpo-definition} +Soient $\ccaK_1 = (S_1, \preceq_1) $ et $\ccaK_2 = (S_2, \preceq_2)$ deux +complexes cellulaires abstraits. +On dit que $\ccaK_2$ est un sous-complexe de $\ccaK_1$, +noté $\ccaK_2 \subset \ccaK_1$, si : +\begin{itemize} + \item $S_2 \subset S_1$ + \item $\preceq_2 \subset \preceq_1$ et + \item $\ccad_{\ccaK_1}$ coïncide avec $\ccad_{\ccaK_2}$ sur $S_2$. +\end{itemize} +\end{mpo-definition} + +% Face coface +\begin{mpo-definition} + Soit $\ccaK = (S, \preceq)$ un complexe cellulaire abstrait et $\sigma \in + \ccaK$ une cellule. L'ensemble des \emph{faces} de $\sigma$ est l'ensemble : +\begin{equation*} +\left\{ \tau \in K \mid \tau \prec \sigma \wedge \ccad(\tau) = \ccad(\sigma) +- 1 \right\} +\end{equation*} +et $\sigma$ est appelée la \emph{coface} de $\tau$. +\end{mpo-definition} + +% Il est pratique de construire le diagramme de Hasse de la relation d'incidence +% d'un complexe $\ccaK$ (voir figure~\ref{fig:cc}). + +Nous définissons ci-dessous trois opérateurs (fermeture, étoile et liaison) +sur les \cca\ utilisant la relation d'incidence ; ils sont extraits des travaux +d'Axen~\cite{axen_topological_1998}. La fermeture d'un \cca\ « sélectionne » +toutes les cellules adjacentes de dimension inférieure, à l'inverse l'étoile +d'un \cca\ « sélectionne » toutes les cellules adjacentes de dimension +supérieure. L'opérateur liaison capture les cellules en lien avec les cellules +d'un \cca\ soit par une cellule de dimension supérieure, soit par une cellule +de dimension inférieure. La figure~\ref{fig:operateurs} présente une vue +intuitive du fonctionnement de ces opérateurs. Les définitions suivantes les +introduisent plus formellement. + + +% Fermeture et étoile +\begin{mpo-definition} +Soit $\ccaK$ un complexe cellulaire abstrait et $S \subset \ccaK$. On +nomme \emph{fermeture} de $S$ et on note $\fermeture{S}$ l'ensemble $\left\{ +\sigma \in \ccaK \mid \exists \tau \in S,\: \sigma \preceq \tau \right\}$. +Symétriquement, on nomme \emph{étoile} de $S \subset \ccaK$ l'ensemble +$\left\{ \sigma \in \ccaK \mid \exists \tau \in S,\: \tau \preceq \sigma +\right\}$. On note la fermeture de l'étoile $\fermeture{\etoile{}} S = +\fermeture{\etoile{S}}$. +\end{mpo-definition} + +% Link de Axen +\begin{mpo-definition} + Soit $\ccaK$ un complexe cellulaire abstrait et $S \subset \ccaK$. L'opérateur + de \emph{liaison} (\emph{Link} en anglais et noté par conséquent $\liaison{}$ + dans les travaux de~\cite{axen_topological_1998}) est défini ainsi : + $\liaison{S} = \fermeture{\etoile{S}} - \etoile{\fermeture{S}}$, où $-$ est + l'opérateur de soustraction classique de la théorie des ensembles. +\end{mpo-definition} +% +% +\begin{figure} + \centerline{% + \includegraphics[width=19cm]{link}} + \caption{Construction de la liaison (à droite) d'un sous-complexe $S \subset + \ccaK$ (à gauche). En passant par le haut, on applique successivement + l'opérateur fermeture suivi d'étoile, en passant par le bas c'est d'abord + étoile suivi de fermeture. La liaison de $S$, $\liaison{S}$, s'obtient par + la différence entre $\fermeture{\etoile{S}}$ et $\etoile{\fermeture{S}}$.} + \label{fig:operateurs} +\end{figure} +% +% Voisinage et chemin +% n-squelette (pas utile) + +\section[\mgs{} et \dsds]{\mgs{} : un langage dédié à la modélisation et à la +simulation des \dsds} + +\MGS{} est un langage dédié à la modélisation et à la simulation des \dsds. C'est +un langage de programmation spatial: un calcul consiste en un déplacement, +induit par la relation de voisinage, dans l'espace abstrait de la structure de +donnée (appelée \emph{collection topologique}) et aussi en une action sur cette +structure (appelée \emph{transformation}) dépendant du calcul. Dans ce but, +\mgs{} embarque les concept de collection topologique et de transformation dans +le framework d'un langage dynamiquement typé\footnote{Dans notre contexte, + \emph{dynamiquement} typé signifie qu'il n'y a pas de vérification statique + des types et que les erreurs de type sont détectées pendant l'exécution lors + de l'évaluation d'une expression.} et fonctionnel\footnote{\mgs{} est un + langage de programmation applicatif : les opérateurs combinent les valeurs sur + lesquels ils s'appliquent pour donner des nouvelles valeurs, ils ne produisent + pas d'effet de bord.}. Les collections topologiques sont les seules structures +de données disponibles dans le langage, c'est à dire qu'il n'existe pas d'autre +manière d'agréger des données par rapport à une certaine relation de voisinage +dans \mgs. Les transformations, définies par une syntaxe spécifique à base de +règles de réécriture, sont des fonctions définies par cas agissant sur ces +collections. + + +\subsection{Topologie des interactions} +%Point de vue agent ou point de vue spatial +Pour décrire l'évolution spatiale d'un processus, d'un élément ou d'une +sous-partie d'un système, il existe deux alternatives classiques : +\begin{itemize} +\item un point de vue spatial, dans lequel on considère ces mouvements par + rapport à un espace préexistant, fixé. Dans le cas d'un système + proie-prédateur par exemple, chaque position de l'espace peut-être occupée + soit par une proie, soit par un prédateur, soit vide ; +\item un point de vue agent, focalisé sur l'individu. Ce dernier émet et reçoit + des messages d'autres agents pour interagir avec son environnement. +\end{itemize} +% +Cependant, ni l'un ni l'autre de ces points de vue n'est satisfaisant +essentiellement parce qu'ils se concentrent chacun sur l'évolution locale d'une +unique entité. Par exemple, dans le cas d'un problème de collision de particules +dans un automate cellulaire un choix se fait entre une évolution en deux +étapes~\cite{toffoli_cellular_1987} (propagation et collision) et l'utilisation +d'un gaz sur réseau~\cite{chopard_cellular_1998}, une variante d'automate +cellulaire qui considère une évolution couplée de plusieurs cellules. Du point +de vue agent, le problème de synchronisation entre plusieurs agents amène aussi +au développement de stratégies plus flexibles~\cite{% +kubera_interaction-oriented_2008,mamei_field-based_2006,mamei_co-fields:_2003}. +Le parti pris dans \mgs{} est de dépasser ces deux points de vue en se +recentrant sur ce qui créée la dynamique d'un système : les \emph{interactions} +entre entités (qu'ils soient agents ou morceaux d'espace). Les interactions +représentent l'évolution simultanée d'une sous-partie (souvent petite) des +entités composant le système. + +Supposons maintenant qu'à chaque instant de l'évolution d'un \dsds, seules +quelques entités interagissent entre elles. Isoler ces groupes d'éléments en +interaction revient à partitionner le système en groupes d'interaction unitaires +(ou atomes) n'étant pas en relation entre eux \emph{à l'instant courant} comme +illustré par la figure~\ref{fig:topo-interactions}. Cette partition forme un +treillis d'atomes qu'il est possible et intéressant de voir comme une topologie : +c'est la \emph{topologie des interactions}~\cite{giavitto_data_2002, + giavitto_computations_2005}. Ce point de vue est incarné par les collections +topologiques de \mgs. + +\begin{figure}[ht] + \begin{center} + \includegraphics{ds2} + \end{center} + \caption{Les partitions successives du système $S$ forment une topologie, + c'est la topologie des interactions} + \label{fig:topo-interactions} +\end{figure} +% + + + + + +\subsection{Collections topologiques} + +Une collection topologique est une \emph{structure de données générique} se +fondant sur la topologie des interactions. Dans le paradigme adopté par \mgs, +l'espace où évolue un phénomène, l'espace de modélisation, est spécifié à partir +des interactions possibles entre les composantes du système à modéliser. Le +fondement formel des collections topologiques est un objet mathématique appelé +\emph{complexe cellulaire abstrait}~\cite{giavitto_computations_2005}, introduit +dans la section~\ref{sec:cca}. Présentons d'abord quelques structures de données +habituelles et leur implémentation sur des complexes cellulaires abstraits. + +\paragraph{Tableau} Un tableau est un ensemble compact de cases accolées les +unes aux autres par un de leur bord. En 1D un tableau $t$ est définit par sa +longueur $n$ et on le note par conséquent $t[n]$. À l'instar du modèle mémoire +du langage C, un tableau est une sous-partie de la \emph{mémoire}. La structure +de la mémoire peut être représentée par un complexe cellulaire constitué d'un +nombre non borné de cellules où chaque «case» est une \cell{0} $\forall i \in +\mathbb{N}\; c_i$. Nous représenterons le fait que deux \cells{0} +$(c_i,c_{i+1})$ soient voisines par une \cell{1} $d_{i,i+1}$ de sorte que +$\forall i \in \mathbb{N}\; c_i \preceq d_{i,i+1}$ et $c_{i+1} \preceq +d_{i,i+i}$. Un tableau est une sous-partie de la mémoire où des \cells{0} +consécutives sont décorées par $n$ valeurs différentes de la valeur spéciale +\emph{null}. + +\noindent +Dans \mgs, cette structure de donnée est directement disponible sous le type +\ç|'array|. La syntaxe pour construire un tableau de trois cases contenant les +valeurs $1,2,3$ est +\begin{MGScode} + 1, 2, 3, ():'array +\end{MGScode} + +\paragraph{Liste} Une liste chaînée est une autre structure de données +apparemment proche des tableaux où chaque élément d'une liste a soit un élément +successeur, soit \emph{n'en a pas}. Cette structure de données peut être +représentée par un complexe cellulaire abstrait où chaque élément $i$ est une +\cell{0} $c_i$. Nous représenterons le fait que deux cellules $(c_i,c_j)$ soient +voisines par une \cell{1} $d_{i,j}$ de sorte que $c_i \preceq d_{i,j}$ et $c_j +\preceq d_{i,j}$. Dans \mgs, cette structure de donnée est appelée séquence, son +type est \ç|'seq|. La syntaxe pour construire une séquence de trois éléments de +valeurs $1,2,3$ est +\begin{MGScode} + 1, 2, 3, ():'seq +\end{MGScode} + +La différence fondamentale entre liste et tableau tient au fait qu'il n'est pas +possible de retirer une case dans un tableau : sa structure est fixée, seules +ses valeurs peuvent être changées. Ces deux structures de données ont la même +représentation structurelle mais leur comportement diffère quant à la sémantique +de l'ajout et du retrait de valeurs décorant les cellules du complexe +sous-jacent. Cette remarque prendra du sens dans la +section~\ref{sec:transformations} consacrée aux transformations. + + +% \paragraph{Ensemble} Dans la structure de donnée Ensemble, chaque élément est +% voisin de tous les autres. Les éléments forment les points d'un graphe complet. +% Elle est donc représentée par un complexe cellulaire abstrait où chaque élément +% $i$ est une \cell{0} $c_i$. Toutes les cellules étant voisines, pour chaque +% paire de cellules $(c_i,c_j)$ en prenant $i \neq j$, il existe une \cell{1} +% $c_{i,j}$ telle que $c_i \preceq d_{i,j}$ et $c_j \preceq d_{i,j}$. Dans \mgs, +% cette structure de donnée a pour type \ç|'set| et la syntaxe pour un ensemble de +% trois éléments $a, b, c$ est +% \begin{MGScode} +% 'a, 'b, 'c, ():'set +% \end{MGScode} + + +\paragraph{\gbf} Les \emph{Group-Based Field} (\gbf) +\cite{giavitto_group-based_1996, spicher_topological_2004} sont une collection +topologique fondée sur les graphes de Cayley, des graphes qui encodent la +structure d'un groupe. Plus particulièrement, les \gbf{} sont issus de graphes +de Cayley de groupes Abélien, car ils ont un structure de grille. En pratique, +ils représentent les espaces où les déplacements sont commutatifs comme les +grilles carrées ou hexagonales où chaque générateur de la présentation d'un +groupe indique une direction. La syntaxe \mgs{} pour construire une collection +de type \ç|'gbf| représentant une grille hexagonale est +\begin{MGScode} + gbf hexa = < a, b, c | a + b = c > +\end{MGScode} +La collection \ç|hexa| possède trois opérateurs de voisinage notés \ç+|a>+, +\ç+|b>+ et \ç+|c>+, ainsi que leurs opposés \ç+ expression_1; + [...] + motif_i => expression_i; + [...] + motif_n => expression_n; + } +\end{MGScode} +À chaque motif de filtrage \ç|motif_i| correspond son expression +\ç|expression_i| qui sera évaluée, puis «recollée» dans la collection +topologique d'entrée. Un motif de filtrage prend la forme d'une succession +d'éléments séparés par l'opérateur de voisinage « \ç|,| », dont la sémantique +est la même \emph{quelle que soit la collection}. + +Le temps du modèle est déterminé par l'ordre et les conditions d'application des +règles données dans une transformation. Est-ce que les motifs doivent être +filtrés successivement (temps asynchrone), simultanément (temps synchrone) ou de +manière probabiliste? Le modèle détermine quelle stratégie adopter. Il existe +dans \mgs{} différentes \emph{stratégies} d'application des règles, dont les +suivantes ont été utilisées dans nos travaux: +\begin{itemize} +\item \ç|`default| (Maximal-Parallel): les règles sont appliquées successivement + jusqu'à ce que cela ne soit plus possible; +\item \ç|`asynchronous| (Asynchrone ou Séquentielle): simule une évolution + asynchrone, une seule règle est appliquée une fois, et l'ordre des règles fixe + la priorité; +\item \ç|`gillespie| (Gillespie): chaque règle décrit une réaction et se voit + accorder une constante de réaction, par exemple $C = \num{0.01}$, + \begin{MGScode} + motif_i ={ C = 0.01 }=> expression_i; + \end{MGScode} + et est appliquée en fonction de cette constante en suivant la méthode de + calcul stochastique proposée par Gillespie~\cite{gillespie_exact_1977}. +\end{itemize} + +\noindent +Comme pour la section précédente, cette courte présentation est fournie pour +donner au lecteur une intuition sur le fonctionnement des transformations +topologiques. Dans le reste du chapitre, un certain nombre d'exemples plus +complets seront fournis. Le manuscrit~\cite{spicher_transformation_2006} traite +en détail du sujet. + +\section{L'activité dans \mgs} \label{sec:activity}% +Nous nous intéressons au concept d'\emph{activité} dans \mgs. Comme nous l'avons +vu dans la section \ref{sec:activity}, l'activité est une mesure du nombre +d'évènements ou de changement d'état dans une simulation. Cette mesure peut être +utilisée pour différents objectifs, comme optimiser une simulation ou bien avoir +une meilleur compréhension de sa dynamique. Dans le contexte de \mgs, l'activité +nous permet +\begin{enumerate} + \item de développer un meilleur algorithme de filtrage par motifs et, + \item d'identifier des structures d'ordre supérieur dans un modèle ainsi que + de les suivre lors des simulations. +\end{enumerate} +% The former will be illustrated in a +% following paragraph, the latter will be reviewed in the discussion. + +% In this section, we present a generic way to track an active region +% throughout the simulation. +Dans cette section nous présentons une méthode générique pour suivre une région +active durant la simulation. +% +% This report provides, in its previous section, enough material to +% allow the reader to follow the next parts. To obtain complementary +% information about \mgs, one should refer to our previous +% publications~\cite{spicher_spatial_2010,bigo_spatial_2010,spicher_arbitrary_2012}. + +%Un \gbf{} est une collection topologique dont le complexe cellulaire abstrait +%sous-jacent est le graphe de Cayley de la présentation d'un groupe Abélien. Les +%éléments de ce groupe représentent les déplacements atomiques autorisés. + +Pour des raisons de simplicité, nous nous restreignons aux motifs ne comportant +au maximum que deux éléments en interaction. +% +%Par exemple, le motif \ç+x, y, z+ (\ie trois éléments où \ç+y+ +%est un voisin de \ç+x+ et \ç+z+ est un voisin de \ç+y+) +%est hors de notre champ d'étude. Néammoins, une généralisation est possible. +% +Nous illustrons cette idée avec un exemple simple mais paradigmatique : un +modèle de propagation de feu de forêt~\cite{potier_topological_2013} où le +\emph{feu} se propage au travers d'une \emph{forêt} en laissant derrière lui de +la matière calcinée sous la forme de \emph{cendres}. Ce modèle peut être décrit +par un automate cellulaire à trois états que l'on peut aisément écrire dans une +transformation \mgs: +\begin{MGScode} +trans fire_spread = { + `Forest as x / member(`Fire, neighbors x) => `Fire; + `Fire => `Ashes; +} +\end{MGScode} +Les états sont représentés par trois symboles : \ç+`Forest+ pour la +forêt, \ç+`Fire+ pour le feu et \ç+`Ashes+ pour les cendres. +La première règle spécifie comment un élément de forêt prend feu avec pour +voisin un élément de feu, la seconde règle spécifie comment un élément de feu +s'éteint une fois la combustion terminée et devient un élément de cendre. La +figure~\ref{fig:evolution} montre trois pas successifs de l'évolution de cet +automate sur une collection topologique à grille carrée. +% +\begin{figure}[ht] + \begin{center} + \includegraphics[width=0.30\linewidth]{evolution01}\hfill + \includegraphics[width=0.30\linewidth]{evolution02}\hfill + \includegraphics[width=0.30\linewidth]{evolution03}\\ + \begin{tikzpicture} + \node[white] at (0,0) {.}; + \node at (0.14\linewidth,0) {$C^0$}; + \node at (0.50\linewidth,0) {$C^1=T(C^0)$}; + \node at (0.84\linewidth,0) {$C^2=T(C^1)$}; + \node[white] at (1.0\linewidth,0) {.}; + \end{tikzpicture} + \caption{Trois premiers pas de la simulation de la propagation d'un feu de + forêt. Les cellules vertes (ou gris foncé) sont des cellules de forêt, les + cellules oranges (hachurées) représentent le feu et les cellules foncées + représentent les cendres.} + \label{fig:evolution} + \end{center} +\end{figure} +% + +Dans cet exemple, l'activité est située sur une sous-partie du domaine -- seuls +les éléments de feu et leur cellules voisines évoluent -- et progresse de +proche en proche. Néanmoins, l'algorithme de filtrage de motif de \mgs{} doit +itérer sur toute la collection à chaque application de la transformation +\ç+fire_spread+. +%% +Étant donné le faible nombre de cellules en interaction, le processus de +filtrage est ici assez peu efficace. Par la suite, nous chercherons à cibler le +filtrage sur les cellules qui évoluent grâce au mécanisme de filtrage. De plus, +l'activité met en avant une structure de niveau supérieur importante de la +propagation d'un feu de forêt: le \emph{front de propagation}. + +\paragraph{Activité et interactions} + +L'interprétation de l'activité dans \mgs{} correspond au nombre d'interactions +ayant lieu à chaque pas de la simulation. Puisque les interactions arrivent à +chaque fois qu'une règle de la transformation filtre une sous-collection, on +constate que l'activité sépare naturellement une collection en deux parties : +\begin{itemize} + \item une sous-collection \emph{active} où une interaction peut avoir lieu et + \item une sous-collection \emph{quiescente} où aucune interaction ne peut avoir lieu. +\end{itemize} +% +Définissons les sous-collections actives et quiescentes d'une manière formelle +et générale dans le cadre des collections topologiques. +%% +Soit $C$ un ensemble appelé collection topologique et $T$ une transformation. +On définit la \emph{fonction de filtrage} $\mathbb{M}_T : C \rightarrow +\mathcal{P}(C)$ de la transformation $T$ comme la fonction qui à $C$ fait +correspondre l'ensemble des sous-collections de $C$ filtrées par un motif de +$T$. En d'autres termes, la fonction de filtrage $\mathbb{M}_T$ représente un +appel au processus de filtrage de motif. +%% +La \emph{sous-collection active} $A$ de $C$ est ainsi définie par +% +$$ +A = \bigcup_{S\in \mathbb{M}_T(C)}{S} +$$ +% +c'est à dire l'assemblage\footnote{L'opérateur $\bigcup$ est utilisé à la place de +$+$ car certaines sous-collections filtrées par $\mathbb{M}_T$ peuvent +avoir des supports qui se recouvrent.} de toutes les sous-collections filtrées +de $C$. Ainsi, la \emph{sous-collection quiescente} $Q$ corresponds exactement +au complémentaire de $A$ dans $C$ : +% +$$ Q = C\;\backslash\;A $$ +% +La figure~\ref{fig:assembly} montre la décomposition d'une collection en deux +sous-collections actives et quiescentes dans le cas de l'exemple de propagation +du feu de forêt. +% +\begin{figure}[ht] + \begin{center} + \includegraphics[width=0.30\linewidth]{assembly03}\hfill + \includegraphics[width=0.30\linewidth]{assembly01}\hfill + \includegraphics[width=0.30\linewidth]{assembly02}\\ + \hspace{1cm}$C$\hfill $=$\hfill $A$\hfill $+$\hfill $Q$\hspace{1cm} + \caption{Décomposition d'une collection topologique en deux ensembles de + cellules actives et quiescentes. En vert (gris foncé), orange (hachuré) et + foncé on représente la forêt, le feu et les cendres, respectivement.} + \label{fig:assembly} + \end{center} +\end{figure} +% + +%% \begin{definition} Let $\text{Coll}$ be the type of a topological collection, +%% $C$ and $S_C$ be two topological collections and $T$ a transformation. We define +%% $$ +%% \begin{array}{lccl} +%% \mathbb{M}_T : &\text{Coll} &\rightarrow &\text{Coll}\\ +%% \mathbb{M}_T : &C &\rightarrow &S_C \\ +%% \end{array} +%% $$ +%% to be the matching function returning the topological subcollection $S_C$ of +%% cells matched in $C$ by a rule application of the transformation $T$. +%% \end{definition} +%% % +%% % +%% \begin{definition} +%% Let $C$ be a topological collection, $T$ a transformation and $\mathbb{M}_T$ the +%% matching function over $T$, then we define $A$, the \emph{active subcollection} +%% of $C$, as: +%% $$ A = \bigcup_{S_j \in \mathbb{M}_T(C)}{S_j} $$ +%% \end{definition} +%% % +%% \begin{definition}\label{def:quies} Let $C$ be a topological collection, let $A$ +%% be the active subcollection of $C$. We define the \emph{quiescent subcollection} +%% $Q$ of $C$ as: +%% $$ Q = C - A $$ +%% \end{definition} +%% % + +\paragraph{Dynamique de l'activité} + +Afin de suivre une région active au cours de la simulation d'un modèle, nous +définissons ci-après une manière de calculer l'évolution d'une région active +(agrandissement, rétrécissement, creusement, \etc) reposant sur les propriétés +topologiques de la sous-collection active. + +%% multiscale %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +La modélisation d'un système naturel implique souvent que des phénomènes +apparaissent à des échelles temporelles et spatiales distinctes : chaque niveau +est dédié à un phénomène se déroulant dans une fenêtre de temps et d'espace +particulière. Ces échelles apparaissent pour des raisons logiques (à une +certaine échelle, un système présente des propriétés uniformes et peut être +modélisé par des règles homogènes agissant sur des objets pertinents à cette +échelle) ou bien pour des raisons d'efficacité, par exemple la simulation +réductionniste de l'intégralité du système à partir des premiers principes est +difficile d'un point de vue calculatoire alors qu'une description plus grossière +du modèle est bien souvent satisfaisante. +% +Les modèles et simulations à plusieurs échelles sont considérés lorsque des +interactions apparaissent entre différentes échelles. Pour les échelles +spatiales, on doit considérer simultanément plusieurs représentations spatiales +comme dans le \emph{raffinement de maillage}~\cite{berger_adaptive_1984}. Cette +méthode repose sur une séquence de « grilles rectangulaires entrelacées » sur +lequel une \edp{} est discrétisée. Il est important de noter que ces +sous grilles ne sont pas incorporées dans la grille principale mais superposées +pour atteindre le but recherché. +% +Un autre exemple, dans le domaine de la modélisation discrète, est la classe +\emph{automate complexe}~\cite{hoekstra_towards_2007} qui correspond à un « +graphe d'automates cellulaires ». +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +% Sometimes scales can be separated, meaning that the coupling between scales +% can be localized at some isolated interaction points in space and time. +% Then, the resulting computation corresponds to a hierarchical process with a +% directed flow of information, although it is not always the case. + +Considérons $(C^0,C^1,\dots)$ la trajectoire des collections par l'application +successive de la transformations $T$, où $C^{i+1} = T(C^i)$ pour $i \ge 0$. +%% +En utilisant la décomposition active-quiescente sur $C^i=A^i+Q^i$, on peut +remarquer que l'application de la transformation agit seulement sur la partie +active et épargne $Q^i$ de telle sorte que le filtrage de motif peut n'être utilisé +que sur $A^i$ : +\begin{equation} +\label{eq:app1} + C^{i+1}=T(C^i)=T(A^i \mid F^i)+Q^i +\end{equation} +La notation $T(A^i \mid F^i)$ est introduite pour indiquer que le mécanisme de filtrage +pourrait nécessiter des informations de $Q^i$, dans le cas où il est +nécessaire de visiter le voisin d'un élément filtré. Par exemple, dans la précédente +transformation \ç+fire_spread+, \ç+member(`Fire, neighbors x)+ n'implique +pas que les voisins visités sont dans $A^i$. +% +Cette information, notée $F^i$, correspond à la sous-collection dont le +support est constitué de tous les éléments de $Q^i$ ayant un voisin dans +$A^i$ : +\begin{equation*} + F^i = \Lk\,A^i +\end{equation*} +% +L'opérateur \emph{link} $\Lk$ sélectionne par construction l'ensemble de toutes +les cellules voisines d'une cellule quelconque $\sigma$. Nous utilisons ici son +extension naturelle à l'ensemble des cellules actives. La figure~\ref{fig:lk} +montre un exemple d'application de $\Lk$ sur un complexe cellulaire. + +% +\begin{figure}[h] + \begin{center} + {\hfill + \includegraphics[width=0.30\linewidth]{s}\hfill + \includegraphics[width=0.30\linewidth]{lks}\hfill} + \caption{Application de l'opérateur $\Lk$ (droite) sur un complexe + cellulaire de dimension 2 (gauche).} + \label{fig:lk} + \end{center} +\end{figure} +% + +La décomposition de $C^{i+1}$ proposée dans l'équation (\ref{eq:app1}) ne +coïncide pas à la définition de $A^{i+1}$ et $Q^{i+1}$. En fait, quelques +cellules de $Q^{i}$ peuvent devenir actives et \emph{vice versa}. +% +Néanmoins, le comportement de la frontière active-quiescente au cours de la +simulation peut être raffiné en utilisant la sous-collection $F^i$. En effet, en +supposant que la règle de transformation n'implique au maximum que deux éléments +voisins, une cellule quiescente, à une certaine itération de la simulation, sans +voisins appartenant à la sous-collection active aura un environnement inchangé +et par conséquent restera dans son état courant à l'itération suivante. +Formellement, on a : +% +\begin{equation} +\label{eq:ineq} + Q^i-\Lk\,A^i\subset Q^{i+1}\qquad A^{i+1}\subset T(A^i \mid \Lk\,A^i)+\Lk\,A^i +\end{equation} +% +La seconde inclusion est obtenue en utilisant la complémentarité et signifie de +manière équivalente que la partie active ne peut grandir au delà de $F^i$. +L'équation (\ref{eq:app1}) se réécrit donc +\begin{equation} +\label{eq:app2} + C^{i+1}=\left[T(A^i \mid \Lk\,A^i)+\Lk\,A^i\right]+\left[Q^i-\Lk\,A^i\right] +\end{equation} + + +\paragraph{Un filtrage de motif optimisé} +Considérant l'équation~(\ref{eq:ineq}), il est clair que l'équation~(\ref{eq:app2}) +est une sur-approximation de la décomposition active-quiescente de $C^{i+1}$. +En exemple, sur la figure~\ref{fig:wave}, les lignes en gras représentent la limite +d'expansion de la partie active au prochain pas de simulation et certaines cellules +de cette sous-collection deviennent quiescentes. +%% +Ces cellules peuvent être identifiées comme les cellules de +$T(A^i \mid \Lk\,A^i)+\Lk\,A^i$ ne pouvant être impliquées dans aucune des interactions au +pas $i+1$. Autrement dit, elles ne sont pas sélectionnées par le mécanisme de filtrage : +\begin{equation*} + \mathbb{M}_T(C^{i+1}) = \mathbb{M}_T(T(A^i \mid \Lk\,A^i)+\Lk\,A^i) +\end{equation*} +et le calcul de la séquence $(A^i)_{i\in\N}$ suit +\begin{equation*} + \left\{ + \begin{array}{lll} + A^{0} & = & \bigcup_{S\in \mathbb{M}_T(C^{0})}{S}\\ + A^{i+1} & = & \bigcup_{S\in \mathbb{M}_T(T(A^i \mid \Lk\,A^i)+\Lk\,A^i)}{S} + \end{array} + \right. +\end{equation*} +Il est important de noter que cette définition de $A^i$ ne se réfère aucunement +à la sous-collection quiescente $Q^i$, car l'opérateur de voisinage $\Lk$ +sélectionne exactement les cellules nécessaires. En conséquence, suivre +l'activité durant la simulation nous permet de nous concentrer sur une partie +réduite de la collection lors du filtrage. L'optimisation induite est discutée +et illustrée dans les deux parties suivantes sur des exemples plus complexes. +% +\begin{figure}[h] + \begin{center} + \includegraphics[width=0.30\linewidth]{wave01}\hfill + \includegraphics[width=0.30\linewidth]{wave02}\hfill + \includegraphics[width=0.30\linewidth]{wave03} + \caption{Évolution de la frontière active-quiecsente pour les trois pas de + la figure~\protect\ref{fig:evolution}. Les cellules actives sont en rouge + (gris foncé), les cellules quiescentes en bleu clair (hachuré). Les lignes + en gras représentent la décomposition induite par + l'équation~(\protect\ref{eq:app2}).} + \label{fig:wave} + \end{center} +\end{figure} +% + + +\paragraph{Caractérisation topologique} \label{sec:morse} + +L'étude précédente peut être généralisée aux transformations impliquant plus de +deux éléments en interaction en reconsidérant la distance à laquelle la +sous-collection active peut s'étendre à chaque itération de la simulation. + +%% +Soit $r$ le \emph{rayon} d'interaction, \ie\ la distance minimale (en terme de +saut) entre éléments en interaction. La restriction précédente consistait à +considérer les transformations de rayon $r = 1$; considérons maintenant un rayon +arbitraire $r \in \N$. + +L'expansion de $F_r^i$ de $A^i$ pour un rayon $r$ est donnée récursivement par +\begin{equation*} + \left\{ + \begin{array}{lll} + F_0^i & = & 0\\ + F_{r+1}^i & = & \Lk(A^i + F_{r}^i) + F_{r}^i + \end{array} + \right. +\end{equation*} +% +Cette définition est analogue à la définition de l'\emph{opérateur de vague} +$W(n)$ dans~\cite{axen_topological_1998} et révèle la nature topologique de +l'activité. L'opérateur de vague est utilisé pour l'élaboration d'une théorie de +Morse combinatoire. La théorie de Morse est un outil mathématique pour étudier +la topologie des espaces. Brièvement, cette théorie traite des \emph{fonctions + de Morse} -- une manière d'inonder l'espace avec un « liquide » -- et des +\emph{points critiques} -- où le liquide révèle des bassins, des cols, des îles +dans la topographie de l'espace. +%% +% We are currently investigating the analogy between Morse theory and +% activity tracking: Morse functions will correspond to activity +% propagation and critical points to space-time positions where +% independent activity zones segregate or collide, pointing out +% important events in the model. + + +%% \begin{figure*}[!t] +%% \begin{center} +%% \begin{equation*} +%% \begin{array}{c} +%% (\Cl\,\sigma_1\cap\St\,\sigma_2)\cup +%% (\St\,\sigma_1\cap\Cl\,\sigma_2)=\emptyset +%% \\ +%% (\Cl\,\sigma_1\cap\Cl\,\sigma_2)\cup +%% (\St\,\sigma_1\cap\St\,\sigma_2)\neq\emptyset +%% \end{array} +%% \end{equation*} +%% \begin{equation*} +%% \begin{array}{c} +%% (s_2 \in \Cl(\St\,s_1) \vee s_2 \in \St(\Cl\,s_1)) \wedge s_2\notin(\Cl(\St\,s_1) \cap \St(\Cl\,s_1))\\ +%% (s_2 \in \Cl(\St\,s_1) \vee s_2 \in \St(\Cl\,s_1)) \wedge \neg(s_2\in\Cl(\St\,s_1) \wedge s_2\in\St(\Cl\,s_1))\\ +%% (\St\,s_2 \cap \St\,s_1\ne\emptyset \vee \Cl\,s_2 \cap \Cl\,s_1\ne\emptyset) \wedge \neg(\St\,s_2\cap\St\,s_1\ne\emptyset \wedge \Cl\,s_2\cap\Cl\,s_1\ne\emptyset)\\ +%% (\St\,s_2 \cap \St\,s_1\ne\emptyset \vee \Cl\,s_2 \cap \Cl\,s_1\ne\emptyset) \wedge (\St\,s_2\cap\St\,s_1=\emptyset \vee \Cl\,s_2\cap\Cl\,s_1=\emptyset)\\ +%% \\ +%% (\Cl\,\sigma_1\cap\St\,\sigma_2)\cup(\St\,\sigma_1\cap\Cl\,\sigma_2)=\emptyset\wedge(\Cl\,\sigma_1\cap\Cl\,\sigma_2)\cup(\St\,\sigma_1\cap\St\,\sigma_2)\neq\emptyset\\ +%% (\Cl\,\sigma_1\cap\St\,\sigma_2)=\emptyset\wedge(\St\,\sigma_1\cap\Cl\,\sigma_2)=\emptyset\wedge(\Cl\,\sigma_1\cap\Cl\,\sigma_2)\cup(\St\,\sigma_1\cap\St\,\sigma_2)\neq\emptyset\\ +%% (\Cl\,\sigma_1\cap\Cl\,\sigma_2)\cup(\St\,\sigma_1\cap\St\,\sigma_2)\neq\emptyset\wedge(\Cl\,\sigma_1\cap\St\,\sigma_2)=\emptyset\wedge(\St\,\sigma_1\cap\Cl\,\sigma_2)=\emptyset\\ +%% (\St\,\sigma_1\cap\St\,\sigma_2\neq\emptyset\vee\Cl\,\sigma_1\cap\Cl\,\sigma_2\neq\emptyset)\wedge(\Cl\,\sigma_1\cap\St\,\sigma_2)=\emptyset\wedge(\St\,\sigma_1\cap\Cl\,\sigma_2)=\emptyset\\ +%% \\ +%% (\Cl\,\sigma_1\cap\St\,\sigma_2)\cup(\St\,\sigma_1\cap\Cl\,\sigma_2)=\emptyset\\ +%% (\Cl\,\sigma_1\cup(\St\,\sigma_1\cap\Cl\,\sigma_2))\cap(\St\,\sigma_2\cup(\St\,\sigma_1\cap\Cl\,\sigma_2))=\emptyset\\ +%% (\Cl\,\sigma_1\cup\St\,\sigma_1)\cap(\Cl\,\sigma_1\cup\Cl\,\sigma_2)\cap(\St\,\sigma_2\cup\St\,\sigma_1)\cap(\St\,\sigma_2\cup\Cl\,\sigma_2)=\emptyset\\ +%% \\ +%% toto +%% \end{array} +%% \end{equation*} +%% \end{center} +%% \end{figure*} + +%% tau in cl(st(sigma)) \ st(cl(sigma)) cup st(cl(sigma)) \ cl(st(sigma)) + +%% tau in N sigma +%% <=> +%% (exists gamma, tau < gamma > sigma || tau > gamma < sigma) & +%% not (tau in cl(sigma) || tau in st(sigma)) +%% <=> +%% (tau in cl(st(sigma)) || tau in st(cl(sigma))) & +%% not (tau in cl(sigma) cup st(sigma)) +%% <=> +%% (tau in cl(st(sigma)) || tau in st(cl(sigma))) & +%% tau notin cl(sigma) cup st(sigma) + + +%% tau in cl(st(sigma)) & tau notin st(cl(sigma)) +%% <=> +%% (st(tau) cap st(sigma) ne empty) && + +%% (exists c1 tau < c1 > sigma & notexists c2 tau > c2 < sigma) || +%% (exists c1 tau > c1 < sigma & notexists c2 tau < c2 > sigma) +%% <=> +%% ((exists c1 tau < c1 > sigma) || (exists c1 tau > c1 < sigma & notexists c2 tau < c2 > sigma)) & +%% ((notexists c2 tau > c2 < sigma) || (exists c1 tau > c1 < sigma & notexists c2 tau < c2 > sigma)) +%% <=> +%% ((exists c1 tau < c1 > sigma) || (exists c1 tau > c1 < sigma)) & ((notexists c2 tau > c2 < sigma) || (notexists c2 tau < c2 > sigma)) & + +%% ((exists c1 tau < c1 > sigma) || (notexists c2 tau < c2 > sigma)) & +%% ((notexists c2 tau > c2 < sigma) || (exists c1 tau > c1 < sigma)) + + +%% Decomposing the evolution relation yields two members: a quiescent subcollection +%% $Q^i$ of $C^i$, where no rule of the transformation matches, and the +%% transformation of the active subcollection $A^i$ of $C^i$ \emph{knowing} $Q^i$. +%% % +%% \begin{equation} +%% \label{eq:split} +%% A^{i+1} + Q^{i+1} = T(A^i | Q^i) + T(Q^i) +%% \end{equation} +%% % +%% These unresolved terms represent the splitting of $A^i$ and $Q^i$ into +%% \emph{new} active cells and \emph{new} quiescent cells. + + + + +%% The trajectory of the simulation of a system with \MGS is given by the +%% successive application of the transformation rules as depicted in figure +%% \ref{fig:evolution}. At iteration $i$, given a topological collection $C^i$ of +%% the simulation of the system and a transformation $T$, the evolution relation is + +%% As stated in section \ref{sec:interaction}, two cells are neighbors if they may +%% interact during the simulation of the system. Thus, only neighbors of $A^i$ are +%% required to compute the transformation of $A^i$ knowing $Q^i$. We can replace +%% the term $T(A^i | Q^i)$ in (\ref{eq:split}) by $T(A^i | F^i)$, $F^i$ being the +%% subcollection of quiescent cells which have a neighbor in $A^i$. +%% % Là on fait un choix: |Fi| \in |Qi| et pas |Fi| \in |Ai| (même si c'est dual) +%% % +%% \begin{equation} +%% A^{i+1} + Q^{i+1} = T(A^i | F^i) + T(Q^i - F^i + F^i) +%% \end{equation} +%% % +%% % +%% \begin{equation} +%% A^{i+1} + Q^{i+1} = T(A^i | F^i) + T(Q^i - F^i) + T(F^i) +%% \end{equation} +%% % +%% There is a grey area, namely $T(F^i)$, for which we cannot predict in all +%% generality whether it yields new active or quiescent cells or both. Since +%% some cells of $F^i$ may be active cells at the next iteration, we can +%% \emph{over-approximate} here by choosing to include them in the new active +%% subcollection as represented on figure \ref{fig:assembly}. +%% % +%% \begin{equation}\label{eq:ident} +%% A^{i+1} + Q^{i+1} = +%% \left( T(A^i | F^i) + T(F^i) \right) + \left( T(Q^i - F^i) \right) +%% \end{equation} +%% % +%% Note that no rule of the transformation $T$ can ever match $Q^i-F^i$, thus +%% % +%% \begin{equation}\label{eq:noeffect} +%% T(Q^i - F^i) = Q^i - F^i +%% \end{equation} +%% % +%% and since $F^i$ is a part of $Q^i$, no rule of $T$ will ever match in $F^i$ +%% % +%% \begin{equation} +%% T(F^i) = F^i +%% \end{equation} +%% % +%% although the cells of $F^i$ can become active at the \emph{next} iteration. + +%% For the following proposition, we will consider that $C^i$ is a topological +%% collection at some iteration $i$ of the simulation, $A^i$ and $Q^i$ are +%% respectively the active and quiescent subcollections of $C^i$ at some iteration +%% $i$ of the simulation. $F^i$ is the subcollection of cells $Q^i$ which have +%% a neighbor in $A^i$. For a topological collection $X$, $|X|$ denotes the +%% underlying ACC structure of $X$. +%% % +%% \begin{proposition} +%% $$ |Q^i - F^i| \subseteq |Q^{i+1}| $$ +%% %\begin{proposition}$ |A^{i+1}| \subseteq |A^i - F^i| $\end{proposition} +%% % +%% Informally: any quiescent cell, at some iteration of the simulation, having +%% no active neighbor cells will remain quiescent at the next iteration of the +%% simulation. +%% \end{proposition} +%% % +%% \begin{proof} +%% We will show that if for any cell $c \in |Q^i-F^i|$, then $c \in |Q^{i+1}|$ +%% holds. +%% \begin{displaymath} +%% \begin{array}{rcll} +%% c \in |Q^i-F^i| &\Leftrightarrow & c \in | T(Q^i-F^i) | +%% & (\text{by (\ref{eq:noeffect})}) \\ +%% &\Leftrightarrow & c \in | Q^{i+1} | +%% & (\text{by id. in (\ref{eq:ident})}) \\ +%% \end{array} +%% \end{displaymath} +%% \end{proof} +%% % +%% In fact, $F^i$ can be automatically computed. We reintroduce here +%% Cl, the closure operator, and St, the star operator defined in +%% section~\ref{sec:topcol}, to work on ACC: +%% \begin{definition} +%% Let $S$ be an ACC, Cl and St are defined as +%% \begin{displaymath} +%% \text{Cl}(S) = \bigcup_{\sigma\in S}\text{Cl}~\sigma +%% \hspace{.5cm}\text{and}\hspace{.5cm} +%% \text{St}(S) = \bigcup_{\sigma\in S}\text{St}~\sigma +%% \end{displaymath} +%% \end{definition} + +%% Our $\mathbf{Lk}$ operator is an extension of the link operator of +%% combinatorial topology defined in \cite{axen98}. We define $\mathbf{Lk}(S)$ +%% to be the symetrical difference between $\text{Cl}(\text{St}(S))$ and +%% $\text{St}(\text{Cl}(S))$. Figure \ref{fig:lk} shows an application example. It +%% corresponds to the union of the usual $\text{Lk}$ and $\text{coLk}$ operators of +%% simplicial complexes. +%% % +%% \begin{definition} +%% Let $S$ be an ACC, let Cl be the closure operator on ACC, let St be the star +%% operator on ACC, and let $\Delta$ be the symetrical difference between two +%% ACC, the link operator $\mathbf{Lk}$ is defined as +%% % +%% $$\mathbf{Lk}(S) = \text{St}(\text{Cl}(S))~\Delta~\text{Cl}(\text{St}(S))$$ +%% % +%% Doing so allows us to catch cells that are neighbors of $S$ both through +%% higher and lower dimensional incidence cells. +%% \end{definition} +%% % +%% % +%% \begin{definition} +%% As the link operator catches all cells neighbors to $A$ and not in $A$, we +%% define $F^i$ as follows +%% $$ |F^i| = \mathbf{Lk}(|A^i|) $$ +%% \end{definition} +%% % +%% % +%% \begin{figure}[t] +%% \begin{center} +%% \includegraphics[width=0.45\linewidth]{s} +%% \hfill +%% \includegraphics[width=0.45\linewidth]{lks} +%% \caption{Application of the $\mathbf{Lk}$ operator (right) on a given ACC +%% (left).} +%% % +%% \label{fig:lk} +%% \end{center} +%% \end{figure} +%% % +%% By rewriting the evolution relation as follows, +%% \begin{equation} +%% C^{i+1} = T(A^i | F^i) + F^i + (Q^i - F^i) +%% \end{equation} +%% and using the $\mathbf{Lk}$ operator, computing $A^{i+1}$ only depends on $A^i$. +%% Let $X$ be a topological collection, $\mathbb{M}_T(X)$ represents the +%% subcollection matched in $X$ by a rule of a transformation $T$. +%% %DONE: Attention, erreur de typage entre une collection topologique et son +%% % support +\section{Propagation d'un feu de forêt} +\label{sec:fire} + +Dans cette section, nous illustrons les notions de collection topologique et de +transformation sur l'exemple paradigmatique de la propagation d'un feu de forêt. + +\subsection{Un exemple canonique} +Les incendies forestiers présentent des effets négatifs pour l'environnement. +D'après l'organisation des nations unies pour l'alimentation et +l'agriculture\footnote{\url{http://www.fao.org/news/story/fr/item/29097/icode/}}, +\begin{quote} + […] la destruction du couvert végétal par les incendies incontrôlés aggrave à + la fois le réchauffement climatique, la pollution de l'air, la désertification + et la perte de biodiversité. +\end{quote} +Ces effets nocifs incitent à développer les techniques de lutte contre les +incendies ainsi que leur gestion~\cite{good_challenges_1989}. De nombreux +modèles compliqués ont été établi dans le but de simuler la propagation d'un feu +de forêt en temps réel comme~\cite{hu_devs-fire:_2011,ntaimo_devs-fire:_2008}. +Ces modèles incluent des fonctionnalités supplémentaires comme un \emph{système + d'information géographique}~\cite{wagner_single-pulse_2004}, \ldots + +De plus, d'après~\cite{karafyllidis_model_1997}, il existe différent types de +modèle pour la propagation d'un feu de forêt, fondés soit sur la théorie des +probabilités~\cite{ivanilova_set_1985}, sur une extension d'un modèle +stochastique~\cite{hirabayashi_fire-spread_1988}, sur le principe de +Huygens~\cite{beer_australian_1989} ou encore sur la simulation de l'écoulement +d'un fluide~\cite{delemont_application_2007,tieszen_fluid_2001}. Remarquons que +ces modèles sont soit imprécis soit trop consommateur en +ressources~\cite{bardley_difficulties_1993}. De plus, aucun de ces modèle ne +prend en compte l'intégralité des facteurs affectant la propagation d'un feu de +forêt. + + +Afin de représenter l'activité spatiale dans un cadre un plus concret que +l'exemple ad hoc précédent, nous avons implémenté un modèle simple, efficace et +réaliste pour la propagation d'un feu de forêt utilisant le formalisme des +automates cellulaires (\AC)~\cite{karafyllidis_model_1997}, avec le langage de +programmation \mgs. Notre modèle de propagation de feu de forêt prend en compte +les principaux effets environnementaux, à savoir le vent (à la fois la force et +la direction), le type de carburant et la topographie de la zone de propagation. + +Le \emph{front de l'incendie} est la zone séparant la forêt des cendres. Le +principal objectif de notre modèle est de déterminer le prochain front de +l'incendie en utilisant : +\begin{itemize} +\item le front de l'incendie actuel, +\item la répartition des vitesses de propagation à chaque point de forêt, +\item la force et la direction du vent ainsi que +\item l'altitude de chaque point de la zone de propagation. +\end{itemize} + +\subsubsection{Représentation des états avec \MGS} + +\begin{figure} + \begin{center} + \includegraphics{gbf} + \vspace{-5mm} + \end{center} + \caption{Un \gbf\ définissant un voisinage de Moore, avec quatre générateurs + \GBF{e}, \GBF{n}, \GBF{ne} et \GBF{se} et deux contraintes $\GBF{n} + + \GBF{e} = \GBF{ne}$, $\GBF{e} - \GBF{n} = \GBF{se}$. Les + directions $\GBF{w}$, $\GBF{s}$, $\GBF{sw}$ et $\GBF{nw}$ sont + définies comme les inverses des générateurs.} +\label{fig:grids} +\end{figure} + +Chaque configuration de l'\ac\ est représenté par une collection topologique de +type \gbf\ de \mgs{} avec un voisinage de Moore. Par exemple, afin de définir une +grille avec un voisinage de Moore, on utilise quatre générateurs nord (\GBF{n}), +est (\GBF{e}), nord est (\GBF{ne}) et sud est (\GBF{se}): +\begin{MGScode} + gbf Land = < n, ne, e, se ; 100 n = 0, 100 e = 0, ne = e + n, se = e - n > ;; +\end{MGScode} +Les générateurs \verb$s = ( + let b = neighborsfold_indexed((\p,y,acc.( + x.burning_rate * + distance_effect(p,^x) * + wind_effect(p,^x) * + slope_effect(y,x) * + y.burnt + acc + )),x.burnt,x) in + x + { burnt = min(1.0,b) } + ); + +} ;; +\end{MGScode} + +L'extrait de code précédent présente une transformation \mgs{} constitué d'une +unique règle de réécriture pour mettre à jour l'état de chaque cellule. La +fonction \ç|neighborsfold_indexed| est une fonction \ç|fold| classique conçue +pour itérer sur chaque voisin d'une cellule. Elle prend en entrée une fonction à +trois paramètres, qui sont \ç|p| la position de la cellule voisine, sa valeur +\ç|y| et un accumulateur \ç|acc| des valeurs déjà réduites. Ainsi, cette simple +fonction de transition itère sur chaque cellule en mettant à jour l'avancée de +la combustion à chaque fois en prenant en compte l'effet de la distance aux +voisins, la force et la direction du vent et l'altitude des voisins. Aussi, de +part leur plus grande distance, les cellules en diagonale ont un effet moins +conséquent sur leurs voisines, limité à 83\% +(voir~\cite{karafyllidis_model_1997}). + +\subsection{Description de la propagation d'un feu de forêt du point de vue de +l'activité} +Nous avons réécrit l'exemple précédent afin que le mécanisme de filtrage ne +s'applique que dans la zone active. + +% As with the theoretical view that we presented earlier, the cellular automata +% space is split between Active cells which take part in a transformation of +% their neighbors and Quiescent cells which have no role to play whatsoever in +% the current iteration. As seen in the end of section~\ref{sec:mgs-activity}, +% activity spreads like a wave, as does forest fire. +En accord avec l'approche théorique présentée un peu plus tôt, l'espace +des cellules de l'\ac\ est partagé entre les cellules actives qui prennent +part à l'évolution de leurs voisines et les cellules quiescentes ne +jouant aucun rôle à l'itération courante. Comme présenté à la fin de la +section~\ref{sec:activity}, l'activité se propage comme une vague, à +l'instar du feu de forêt. + +\begin{figure}[ht] + \begin{center} + %\includegraphics{normal000}~\includegraphics{active000} \\[1ex] + %\includegraphics{normal110}~\includegraphics{active110} \\[1ex] + %\includegraphics{normal687}~\includegraphics{active687} + \includegraphics[width=.3\linewidth]{fire-normal05} + \includegraphics[width=.3\linewidth]{fire-normal22} + \includegraphics[width=.3\linewidth]{fire-normal95} \\[1ex] + \includegraphics[width=.3\linewidth]{fire-active05} + \includegraphics[width=.3\linewidth]{fire-active22} + \includegraphics[width=.3\linewidth]{fire-active95} + \caption{Propagation du feu présentée à 3 itérations différentes, de gauche à + droite, dans une simulation où les cellules enflammées sont initialement au + centre d'une grille de taille $50\times 50$. Dans la première série, les + cellules de forêt sont en vert (gris clair), les cellules enflammées sont en + orange (gris clair) et les cellules entièrement consumées sont en gris + foncé. Dans la seconde série (bas) les cellules actives sont en rouge (gris + clair) et les cellules quiescentes en bleu (gris foncé).} + % + \label{fig:fire-simu} + \end{center} +\end{figure} + +Nous avons développé un algorithme générique nous permettant de suivre la zone +active, dans laquelle des changement arrivent, au cours de la simulation. Ce +dernier est exécuté à chaque itération. + +Commençons par introduire quelques points de notation. L'ensemble $A$ est choisi +pour garder la trace des cellules actives durant la simulation et nous noterons +$A^i$ avec $i \in \{0,\ldots,n\}$ l'ensemble des cellules actives à l'itération +$i$ de la simulation, $n$ étant le dernier pas de la simulation. Au départ, +$A^0$ contient toutes les cellules. L'ensemble $Q$ contient toutes les cellules quiescentes +et $Q^0 = \emptyset$. L'ensemble $F^i$ permet de suivre les cellules pouvant devenir +actives à l'itération suivante et correspond exactement à notre définition précédente +d'un front d'incendie. Au début de la simulation, $F^0 = \emptyset$. + +\paragraph{Mise à jour de l'état des cellules} +% The first part of the algorithm is about updating the state of active cells. +% This operation is simply the application of the transformation rule $T$ on cells +% of $A$ instead of all cells. Once completed, a new separation between active an +% quiescent arises and needs to be computed: some cells become active, some other +% become quiescent. +La première partie de l'algorithme concerne la mise à jour des cellules actives. +Elle résulte de l'application des règles d'une transformation $T$ sur les cellules +de $A$ plutôt que sur toutes les cellules. Une fois effectuée, une nouvelle +ségrégation entre cellule active et quiescente apparaît et doit être calculée : +certaines cellules deviennent actives, d'autres deviennent quiescentes. + +\begin{algorithm} + \ForAll(\tcp*[f]{Mise à jour de l'état de toutes les cellules actives}) {$px \in A^i$} + { + \eIf {$syn < i$}{ + $x \gets state.(px).cur$\; + }{ + $x \gets state.(px).backup$\; + } + $state.(px) \gets \{cur=T(x), backup=state.(px).cur, syn=i\}$\; + } +\end{algorithm} + +\paragraph{Mise à jour de la zone active} +% To sort between active and quiescent cells, we need and use an activity +% predicate $P$ to point out which cells are active, either remaining active in +% $A^i$ or becoming active in $F^i$. +Afin de trier entre cellules active et quiescentes, nous utilisons un prédicat +d'activité $P$ pour déterminer quelles cellules sont actives, soit restant active +dans $A^i$ ou devenant active dans $F^i$. +% +\begin{MGScode} +fun P(state, px) = ( + let x = state.(px).cur in + (x.burnt != 1.0) + && + exists((\y.(y.cur.burnt != 0.0)), neighbors(state,px)) +) ;; +\end{MGScode} +% +Dans un premier temps, on rempli un ensemble $FQ$ comme stockage temporaire. Les +éléments de cet ensemble seront répartis, plus tard, soit dans $F^{i+1}$ soit +dans $Q^{i+1}$. + +\begin{algorithm}[H] + \ForAll(\tcp*[f]{Mise à jour de la zone active}) {$a \in A^i$} + { + \eIf {$P(a)$}{ + $A^{i+1} \gets a$\; + }{ + $FQ \gets a$\; + } + } + \ForAll {$f \in F^i$}{ + \eIf {$P(f)$}{ + $A^{i+1} \gets f$\; + }{ + $FQ \gets f$\; + } + } + \ForAll {$q \in Q^i$}{ + \eIf {$not(HasNeighbor(q,F^i))$}{ + $Q^{i+1} \gets q$\; + }{ + $FQ \gets q$\; + } + } +\end{algorithm} + +Les cellules qui, soit restent actives, soit le deviennent, sont stockées dans +$A^{i+1}$. Toutes les autres sont quiescentes, si elles sont suffisamment +distantes de la zone active, ou dans $F^{i+1}$, si elles ont un voisin dans +$A^{i+1}$ car elles peuvent devenir actives à la prochaine itération. + +\begin{algorithm} + \ForAll(\tcp*[f]{Séparation de FQ}) {$c \in FQ$} { + \eIf {$HasNeighbor(c,A^{i+1})$}{ + $F^{i+1} \gets c$\; + }{ + $Q^{i+1} \gets c$\; + } + } +\end{algorithm} + + + +\subsection{Mesure de performance} + +\begin{figure}[ht] + \begin{center} + \includegraphics{plot-ff} + \end{center} + \caption{Nombre de cellules actives et temps de calcul pour l'algorithme + classique et optimisé par itération sur une grille de taille 500 $\times$ + 500. + Les valeurs sont normalisées selon la taille totale (\num{250000} cellules) + en ce qui concerne le nombre de cellules, et le temps moyen de calcul d'une + simulation classique en ce qui concerne le temps de calcul.} + \label{fig:fire-speedup} +\end{figure} + +En utilisant l'algorithme de filtrage de motif classique, l'intégralité de la +collection doit être itérée à chaque mise à jour. Pour un \ac\ sur une grille +carrée de côté $n$, l'algorithme doit parcourir $n^2$ cellules ce qui résulte en +un pas d'itération en temps constant (voir figure~\ref{fig:fire-speedup}), +tandis que seul un nombre fluctuant de cellules voient leur état changer (ce qui +correspond à une fraction de la grille). + +Dans cette section, nous utilisons l'activité pour réduire le coût du filtrage. +Nous avons réécrit l'exemple de la propagation d'un feu de forêt précédent pour +que le filtrage n'ait lieu que dans la région active en ignorant la région +quiescente. À l'instar de la partie théorique de la section~\ref{sec:activity}, +l'espace de l'\ac\ est scindé entre cellules actives prenant part à la +transformation de leurs voisines et cellules quiescentes ne jouant aucun rôle +dans l'itération courante. Il en résulte une amélioration notable du temps de +calcul sur l'ensemble de la simulation. + +La figure~\ref{fig:fire-speedup} montre le nombre de cellules actives à chaque +itération ainsi que le temps de calcul par itération pour une simulation +classique et optimisée. Le temps est normalisé par rapport au temps de calcul de +la simulation classique de telle sorte qu'il soit aisé d'apprécier le gain +induit par l'algorithme optimisé. Les pics et les fluctuations du temps de +calcul proviennent de la variabilité des ressources disponibles lors du test. + +De la figure~\ref{fig:fire-simu}, on peut déduire qu'au début de la simulation, +très peu de cellules sont actives. Leur nombre s'accroit dramatiquement avec +la progression du feu pour ne diminuer qu'une fois la forêt consumée et +transformée en cendres. +% +Pour l'\ac\, le temps de calcul est linéaire avec le nombre de cellules : plus +il y a de cellules, plus le temps de calcul est élevé tout en restant constant +par cellule. +% +De la figure précédente, on peut remarquer que le temps de calcul pour +l'algorithme classique est le même à chaque itération : le mécanisme de filtrage +doit explorer chacune des \num{250000} cellules pour vérifier si un motif peut +s'appliquer ou non. Dans ce cas, qu'un motif corresponde ou non ne change pas le +temps de calcul nécessaire à l'application d'une règle de transformation. + +On remarque également que le nombre de cellules actives et le temps de calcul de +l'algorithme optimisé coïncident : ce dernier dépend effectivement du nombre de +cellules à explorer, d'où le fait que la forme des deux courbes soit +quasi identique. +% +Les cellules ne sont jamais toutes actives au même moment, c'est pourquoi, même +quand un grand nombre de cellules sont actives, le temps de calcul par itération +pour l'algorithme optimisé reste plus faible que pour sa contrepartie classique. +% +Le coût de la maintenance des ensembles des cellules actives et quiescentes peut +se lire à partir de la différence entre le temps de calcul pour l'algorithme +optimisé et le nombre de cellules actives. Cette optimisation dépend du problème +étudié et le graphe en sortie est totalement dépendant de la configuration des +données initiales. Ainsi, on ne peut pas parler en toute généralité d'une +optimisation en temps de calcul. Le cas suivant donne des résultats sensiblement +différents. + +\section{Agrégation limitée par diffusion} +\label{sec:dla} + +Dans cette section, nous considérons un exemple plus élaboré : nous avons choisi +d'implémenter le modèle d'un système présentant une \emph{agrégation limitée par + diffusion} (\ald). Contrairement au modèle de propagation d'un feu de forêt, +le modèle d'une \ald\ présente de réelles interactions entre deux particules au +lieu du changement d'état d'une cellule en fonction de l'état de ses voisines. +En \mgs, cela se traduit par le filtrage d'une paire de cellules au lieu d'un +seule. Nous verrons néanmoins que cela n'affecte pas la propagation en vague de +l'activité. +% +Les résultats suivants découlent de la section~\ref{sec:activity}, où + apportée par l'activité est utilisée pour accélérer le temps de +simulation en n'appliquant les règles de transformation \emph{qu'à la seule} +région active. + +\subsection{L'exemple d'une simulation d'une \ald} + +Le phénomène d'\ald\ est un phénomène physique dans lequel on observe un +ensemble de particules s'agrégeant pour former des arbres +Brownien~\cite{witten_diffusion-limited_1981}. Un modèle de ce phénomène a été +implémenté par~\cite{spicher_reactive_2009} sur un \ac{} avec \mgs{}. + +\subsubsection{Représentation des états avec \mgs} + +Le treillis régulier d'un \ac\ est représenté par un \gbf\ décrivant un +voisinage de Moore sur une grille carrée cyclique en deux dimensions. + +En \mgs, cette collection est spécifiée à partir de la présentation du groupe +des déplacements. Comme dans l'exemple précédent, la définition d'une grille au +voisinage de Moore nécessite une base de quatre mouvements, nord (\GBF{n}), est +(\GBF{e}), nord-est (\GBF{ne}) et sud-est (\GBF{se}) : +\begin{MGScode} + gbf Grid = < n, ne, e, se ; 50 n = 0, 50 e = 0, ne = e + n, se = e - n > ;; +\end{MGScode} +Les quatre équations additionnelles indiquent que la grille est cyclique et de +taille $50\times 50$, et définit les relations entre les directions horizontale, +verticale et diagonales tandis que les directions inverses sont générées +automatiquement. Ensuite, chaque cellule du \gbf\ est étiqueté par son état, qui +varie au cours des itérations de la simulation: +\begin{MGScode} + type cell = `empty | `mobile | `static ;; +\end{MGScode} +L'étiquette \ç+`mobile+ désigne une cellule contenant une particule pouvant se +déplacer dans une direction aléatoire à l'itération suivante ; l'étiquette +\ç+`static+ est utilisée pour les cellules contenant une particule qui restera +fixe jusqu'à la fin de la simulation. Finalement l'étiquette \ç+`empty+ est +utilisée pour les cellules vides, ne contenant aucune particule, et pouvant +accueillir une particule à l'itération suivante. + +\subsubsection{Spécification dynamique en \mgs} +Spécifier la dynamique d'une \ald\ dans une transformation revient à rédiger +deux règles appliquées suivant une stratégie \emph{maximal-parallel}: +%DONE: (WONTFIX) orly? Comment on fait du random alors? Pire, si on fait du +% random, comment on s'assure que la première match en priorité? +\label{mgs:ald-evol} +\begin{MGScode} +trans evolution = { + `mobile, `static => `static, `static ; + `mobile, `empty => `empty, `mobile ; +} ;; +\end{MGScode} +La première règle de la transformation est sélectionnée si deux cellules +voisines sont dans les états \ç+`mobile+ et \ç+`static+, et les remplace par +deux cellules dont l'état est \ç+`static+. +% +La seconde règle de la transformation s'applique si deux cellules voisines sont +dans les états \ç+`mobile+ et \ç+`empty+ auquel cas elles échangent leurs états +pour simuler un \emph{saut} d'un particule de la première vers la seconde. +% +On remarque que la priorité est donnée à la règle d'agrégation ce qui permet à +une cellule étiquetée \ç+`mobile+ entourée de plusieurs \ç+`empty+ et d'au moins +une \ç+`static+ de devenir \ç+`static+ plutôt que de continuer sa marche +aléatoire. +% +Cette fonction de transition itère sur toutes les cellules et mets à jour +leur état. La figure~\ref{fig:dla-simu} présente la simulation du modèle à +différentes itérations. +% +\begin{figure}[ht] + \begin{center} + \includegraphics[width=.3\linewidth]{dla-normal000} + \includegraphics[width=.3\linewidth]{dla-normal110} + \includegraphics[width=.3\linewidth]{dla-normal687} \\[1ex] + \includegraphics[width=.3\linewidth]{dla-active000} + \includegraphics[width=.3\linewidth]{dla-active110} + \includegraphics[width=.3\linewidth]{dla-active687} + \caption{\ald\ à trois itérations différentes, de gauche à droite, d'une + simulation comportant des particules mobiles au centre et des particules + statiques aux bords sur une grille de $50 \times 50$. Dans la série du + haut, les cellules \ç+`mobile+ sont en rouge, les cellules + \ç+`static+ sont en bleu et les \ç+`empty+ sont en blanc. + Dans la série du bas, les cellules actives sont en rouge et les cellules + quiescentes sont en bleu.} + % + \label{fig:dla-simu} + \end{center} +\end{figure} +% + +\subsection{L'activité dans une simulation d'\ald} +Comme on pourrait s'y attendre, la nature d'une simulation d'\ald\ est bien +différente de l'exemple précédent. On décèle moins bien la vague d'activité que +dans la propagation d'un feu de forêt. Néanmoins, les mêmes principes sont +utilisés sur l'exemple de l'\ald\ et les résultats sont présenté juste après. + +L'algorithme utilisé pour suivre l'évolution de l'activité doit prendre en +compte l'interaction entre deux cellules voisines : il doit d'abord en filtrer +une puis une seconde dans le voisinage de la première. Le mécanisme de filtrage +et de mise à jour de l'état d'une cellule est au cœur de l'algorithme de +filtrage de motif de \mgs. Mis à part la mis à jour de l'état d'une cellule, le +reste de la procédure est identique : il faut répartir les cellules itérées dans +$A^{i+1}$, $F^{i+1}$ et $Q^{i+1}$. + +\subsection{Mesure de performance} +\label{sec:dla-bench} + +Dans cette section, nous utilisons l'information fournie par l'activité pour +réduire le coût du filtrage. L'exemple d'une \ald\ a été réécrit pour que les +règles de la transformation ne s'appliquent qu'aux cellules des régions actives +en omettant les cellules quiescentes. À l'instar du point de vue théorique +présenté dans la section~\ref{sec:activity}, l'espace de l'\ac\ est partagé +entre cellules actives prenant par à la transformation et cellules quiescentes +ne jouant aucun rôle à l'itération courante. La simulation s'en retrouve +accélérée, mais dans de moins larges proportions par rapport à l'exemple +précédent. + +\begin{figure}[ht] +\begin{center} + %\includegraphics[width=\linewidth]{bench} + {\scriptsize\input{data/bench.tex}} + \caption{Nombre de cellules actives, et temps de calcul pour l'algorithme + optimisé par itération sur une grille de 100 $\times$ 100. Les valeurs ont + été normalisées en utilisant la taille totale de la grille (\num{10000} + cellules) et le temps de calcul par itération pour l'algorithme classique + respectivement.} + \label{fig:dla-speedup} +\end{center} +\end{figure} + + +La figure~\ref{fig:dla-speedup} présente un graphe du nombre de cellules actives +pour chaque itération et le temps de calcul par itération pour l'algorithme +optimisé. Les fluctuations occasionnelles sont causées par une variation des +ressources disponibles dans l'environnement de test. + +Comme montré sur la figure~\ref{fig:dla-simu}, au début de la simulation, +très peu de cellules sont actives ; il n'y a que la \emph{couronne} autour +du carré initial de particules mobiles représentant les particules ayant la +possibilité de bouger. Leur nombre croît dramatiquement avec la marche aléatoire +des particules remplissant l'espace et décroît dès qu'une particule mobile +s'attache à une particule fixe. Comme dans le cas d'un \ac\ classique, le +temps de calcul est linéaire avec le nombre de cellules : plus leur nombre est +important, plus le temps nécessaire au calcul est important par itération. De +plus, le temps de calcul pour l'algorithme classique est quasiment identique +à chaque itération : le mécanisme de filtrage doit parcourir l'ensemble des +\num{10000} cellules pour vérifier si un motif convient. Le fait qu'une règle +s'applique ou non ne change que marginalement le temps de calcul nécessaire par +cellule. + +Du graphe, nous remarquons que l'activité et le temps de calcul pour +l'algorithme optimisé coïncident : en effet ce dernier dépend de la taille de la +région active. Il semble donc naturel que l'allure générale de la courbe soit +identique à celle de la variation du nombre de cellules actives. + +Les cellules ne sont pas toutes actives au même moment. En fait, pour la +simulation présentée, le nombre maximum de cellules actives est très faible et +reste en dessous de 30\% du total. Par conséquent, même à son pic, l'algorithme +optimisé requiert moins de temps de calcul par itération que l'algorithme +classique. Le coût de la maintenance de la zone active peut être lu à partir de +la différence entre le temps de calcul pour l'algorithme optimisé et le nombre +de cellules actives. Dans notre cas, il est assez élevé, peut être parce que le +mécanisme d'optimisation lié à l'activité a été implémenté comme un programme +\mgs{} et n'est pas directement inclus dans le langage lui-même. Cette +optimisation est dépendante des données, cela se voit en comparant les +différences de résultats par rapport à l'exemple précédent. De manière générale, +il n'y a aucune garantie de l'optimisation en temps des calculs mais il ne peut +y avoir de ralentissement car le pire scénario revient à devoir filtrer +entièrement une collection topologique et calculer les collections $A, F$ et +$Q$, ce qui est le cas par défaut. Concernant l'\ald, l'accélération de la +simulation est aussi dépendante du type d'implémentation ; dans le cas d'un +modèle à agent, le suivi de l'activité nous a permis de nous focaliser sur les +particules mobiles et ainsi d'obtenir un temps de simulation optimal. + +\section{Conclusion et perspectives} +Cette courte section vise à rappeler les principaux résultats obtenus suite +à nos travaux sur l'activité spatiale ainsi que nos futures pistes de travail +sur le sujet. + +\subsection{Conclusion} +% Rappel du contexte et des résultats obtenus +Nous avons, dans ce chapitre, présenté quelques points clef du formalisme de +\mgs, en particulier: les collections topologiques et les transformations. +Nous avons aussi succinctement décrit deux modèles formels, les complexes +cellulaires abstraits et la réécriture topologique, servant de fondement au +langage. Nous avons d'abord utilisé un automate à trois états minimal pour +introduire le concept d'activité (section~\ref{sec:activity}) dans le domaine +du calcul spatial en définissant une zone active comme étant les régions de +l'espace filtrées, et où seules les cellules filtrées sont mises à jour. Bien +que ce concept ait été introduit sur un exemple de propagation de feu de forêt +(section~\ref{sec:fire}), le fait que l'activité progresse comme une vague +n'est pas restreint à ce seul cas et s'étend naturellement à d'autres cas +comme le modèle d'agrégation limitée par diffusion (section~\ref{sec:dla}). +La propagation d'un feu de forêt semble être un cas particulier où l'activité +est en adéquation presque parfaite avec la simulation où la sur-approximation +induite par le suivi de l'activité est minimale. + +\noindent +De nos précédentes observations, nous avons obtenus deux résultats principaux: +\begin{enumerate} +\item un résultat formel: la description générique du calcul de la zone active, + indépendamment de toute connaissance sur la zone quiescente, et +\item un résultat expérimental: la mise à jour de la zone active uniquement nous + a apporté un gain en vitesse d'exécution inversement proportionnel au nombre + de cellules actives, pour les deux applications. +\end{enumerate} + +Notre motivation à l'exploration de l'activité dépasse la simple +optimisation de temps des simulations avec \mgs. Elle découle de notre +approche de la modélisation multi-niveau que nous avons introduit dans le +chapitre~\ref{chap:partie-multi-modele}. À ce stade de nos travaux, au niveau +du langage, les zones actives ne sont pas des objets de première classe: elles +sont calculées à chaque pas de la simulation et il n'existe pas encore de lien +entre ces régions entre deux pas de simulation différents. Par cet aspect, +l'activité trace un chemin vers une définition générique et une utilisation du +\emph{front} actif, de la \emph{réification} des régions actives en des objets +de première classe. Reformulé en terme d'identité, notre implémentation permet +par identification qualitative de découvrir les zones actives, qui sont des +objets d'un autre niveau de modélisation. L'identité numérique de ce front actif +n'est pas encore inclus au niveau du langage. D'autres questions demandent à +être abordées avant de pouvoir manipuler les zones actives comme des objets de +premier ordre. Nous les présentons dans la section suivante. + +\subsection{Perspectives} +Nos travaux futurs s'articulent autour des grands axes suivants, conditions +nécessaires à la \emph{réification} des fronts de vague d'activité et à leur +inclusion en tant qu'objets de première classe dans \mgs: +\begin{description} + + \item[Identifier] + Nous avons déjà établi qu'il était possible, sans modifier le langage, + d'identifier la zone spatiale active dans une simulation \mgs: cette zone + est décrite par les trois ensembles de cellules $A$, $Q$ et $F$. Notre + prochaine étape est d'étendre les tests effectués sur des ensembles de + cellules plus grands, d'une part, et sur des modèles implémentés sur + d'autres collections topologiques, d'autre part, afin de confirmer nos + observations. Schématiquement, en prenant $C_i$ comme la collection + topologique au pas $i$ et $A_i$ comme l'ensemble des cellules actives au + pas $i$, alors nous avons: + \begin{center} + \begin{tikzpicture} + \node (ci) at (0,0) {$C_i$}; + \node (ai) at (0,1) {$A_i$}; + \draw[->] (ci) -- (ai); + \end{tikzpicture} + \end{center} + De plus, nous nous posons la question de la structure de donnée la mieux + adaptée à l'ensemble des cellules actives: est-ce la collection topologique + du modèle ? Ou bien d'autres candidats sont-ils plus appropriés ? + + \item[Suivre] + Nous avons également mis en œuvre un suivi rudimentaire de la zone active. + Cependant, ce suivi n'existe pas encore du point de vue de \mgs. Aussi, + il est nécessaire de déterminer une correspondance directe, à deux pas + successifs $i$ et $i+1$ de la simulation, entre $A_i$ et $A_{i+1}$. + Autrement dit, il nous faudrait établir une transformation agissant + directement sur $A_i$, indépendamment du modèle sous-jacent. Prenons $C_i$ + comme l'ensemble des cellules de la collection topologique du modèle au pas + $i$ et $C_{i+1}$ au pas $i+1$, si le diagramme suivant commute, alors cette + transformation est une abstraction: + \begin{center} + \begin{tikzpicture} + \node (ci) at (0,0) {$C_i$}; + \node (ai) at (0,1) {$A_i$}; + \node (cip1) at (2,0) {$C_{i+1}$}; + \node (aip1) at (2,1) {$A_{i+1}$}; + \draw[->] (ci) -- (ai); + \draw[->] (ci) -- (cip1); + \draw[->] (ai) -- (aip1); + \draw[->] (cip1) -- (aip1); + \end{tikzpicture} + \end{center} + + \item[Différencier] + Nous avons constitué les ensembles $A$, $Q$ et $F$ à partir de l'intégralité + des règles d'une transformation. Nous souhaitons enquêter sur le sens de + la distinction entre différents sous-ensembles d'activité engendrés par + une ou plusieurs règles d'une transformation. Par exemple, dans le cas de + la transformation de l'\ald, page \pageref{mgs:ald-evol}, nous avions deux + règles, la première décrivant la capture par accrétion d'une particule, et + l'autre décrivant leur déplacement brownien. Quel serait le sens, l'usage, + la portée et l'implémentation du front actif d'accrétion ou du front actif + de déplacement ? Qu'en est-il de leurs interactions ? + +\end{description} +Une fois les réponses à ces questions clarifiées, nous pourrons alors proposer +une syntaxe spécifique à la manipulation des fronts de vague d'activité au +niveau du langage \mgs. + +\noindent +À l'avenir, il sera intéressant de préciser les relations entre le contexte +original de l'opérateur de vague, emprunté à la théorie de Morse, et notre +exploration de l'activité spatiale. + + +% Organisation plutôt thématique que long/court terme +% I. Réifier le front d'activité +% Intégrer l'activité (sa reconnaissance) dans MGS +% - Implique de définir la reconnaissance de l'activité pour chaque collection +% topologique, c'est peut-être pas si simple +% - Implique de résoudre la question du suivi +% - Implique de définir une syntaxe +% Prouver le lien entre l'optimisation par activité et une technique +% classique d'optimisation sur les automates cellulaires. On peut ainsi +% démontrer que notre technique d'optimisation est plus générique. +% Lien entre suivi de activité et théorie de Morse +% Les différentes activités spatiales (elles sont issues des règles de +% transformation, donc on peut faire des groupes de règles, les prendre une +% par une, et voir ce que ça donne). Exemple potentiel: activité de capture, +% activité de déplacement (d'après les règles de l'ALD) et leur interaction. +% II. Étendre les exemples, traiter plus de cas +% Tester sur plus d'exemples: il faut étendre les résultat pour leur donner +% plus de poids +% III. Étendre diff --git a/partie-conclusion.tex b/partie-conclusion.tex new file mode 100644 index 0000000..ef62c1d --- /dev/null +++ b/partie-conclusion.tex @@ -0,0 +1,183 @@ +\chapter{Conclusion} + +Dans ce très court chapitre, nous résumons les chapitres précédents et +présentons nos contributions au projet de recherche ANR \synbiotic. +% C'est fini, on bien bossé, regardez. On va maintenant présenter: +% - le résumé des travaux, séparément, puis +% - synbiotic -> délivrable; +% - Quelles nouvelles questions ça ouvre ? +% - Et nous, on continue sur quoi ? (nos travaux futurs) + +% On a déjà fait une conclusion par chapitre, qu'ajouter dans celle-là ? +% - Donner un modèle de l'activité dans le cadre du multi-niveau de la partie 1 +% - + +% Résumé des travaux +%Deux nouvelles techniques de modélisation inspirées par un formalisme unifiant: +%modélisation par l'activité spatiale et par des automates cellulaires étendus + +\section{Résumé de nos travaux} + +\paragraph{\nameref{chap:partie-multi-modele}} Dans ce chapitre, nous +présentons la définition d'un formalisme unifiant dans le but de permettre +la spécification commune et la classification de modèles. En partant du +constat que modéliser revenait à définir une loi d'exclusion, c'est à +dire distinguer les comportements acceptés des comportements rejetés +par le modèle, nous avons donné une définition d'un modèle comme un +couple $(\sig,\bhv)$ constitué de la signature du modèle \sig{} et de son +comportement \bhv{}. Un modèle peut être construit suivant différentes +méthodes: par extension, dans le cas d'un modèle expérimental par exemple, +ou bien par intention. Après avoir fourni quelques exemples de reformulation +de modèles classiques dans notre formalisme, nous nous sommes attaqués à +l'expression des relations pouvant exister entre différents modèles. Il est +apparu nécessaire de considérer un modèle de référence pour définir +une flèche d'abstraction entre deux modèles : le modèle de référence +se présente comme le lien au système étudié, et peut être un modèle +expérimental. Nous avons également étudié l'expression formelle d'une +composition entre deux modèles. Ces définitions nous ont permi d'établir une +construction cohérente constituée de plusieurs modèles en relation les uns +avec les autres fournissant aussi une première partie concrète de réponse +au problème de la construction de modèles constitués de sous-modèles en +relation les uns avec les autres. + +\paragraph{\nameref{chap:partie-activite}} Dans ce chapitre, nous abordons une +nouvelle technique de modélisation fondée sur l'activité spatiale dans le cadre +d'un langage informatique pour la modélisation et la simulation spatiale nommé +\MGS. \MGS{} est un langage de programmation non-conventionnel qui met l'accent +sur la place centrale de l'espace dans la modélisation. Spécifier un modèle avec +\MGS{} revient à choisir une structure de donnée adaptée, appelée collection +topologique, et une fonction de transition, la transformation. Une simulation +d'un modèle écrit avec \MGS{} correspond à la réécriture successive de la +collection topologique choisie. Grâce à \MGS, nous avons introduit et mis en +situation un nouvel algorithme de calcul d'un front d'activité: premièrement cet +algorithme généralise des optimisations déjà connues sur les automates +cellulaires à toute collection topologique, deuxièmement, notre algorithme rend +accessible comme donnée de premier ordre les zones spatialement actives pendant +la simulation d'un modèle écrit avec \MGS. + +\paragraph{\nameref{chap:partie-otb}} Dans ce chapitre, nous présentons \otb, un +simulateur du comportement d'une population de bactéries \Ecoli{} écrit en OCaml +et en C. Ce simulateur repose sur un modèle du comportement des bactéries +\ecoli{} dans leur environnement qui est le fruit de la composition de trois +modèles: +\begin{itemize} +\item le \emph{moteur physique}, dédié au comportement physique des bactéries; +\item le \emph{moteur chimique}, dédié à la réaction et à la diffusion des + morphogènes dans l'environnement des bactéries, et +\item le \emph{moteur de décision}, dédié à l'interaction de ces deux + environnements, décrivant les interactions mutuelles entre les deux moteurs + précédents, il régit le comportement de chaque bactérie et fait appel aux deux + modèles précédents. +\end{itemize} +Les deux moteurs physiques et chimiques reposent sur les automates cellulaires +en deux dimensions pour lesquels nous avons développé une technique de +simulation originale, l'algorithme de Propagation Parallèle à la Margolus +(\ppm), dans le but de pouvoir simuler une population de l'ordre de \SI{E5}{} +individus sur des ordinateurs munis de cartes graphique grand public. + +\section{Contribution à \synbiotic} + +Ce manuscrit de thèse est un livrable du projet ANR \synbiotic. +Dans ce document nous avons contribué spécifiquement à deux +work-packages, WP2 (chapitre~\ref{chap:partie-activite}) et WP3 +(chapitre~\ref{chap:partie-otb}), ainsi qu'au projet de recherche en général +(chapitre~\ref{chap:partie-multi-modele}): +\begin{description} + \item[Contributions à WP2] + %MGS colle parfaitement à L1 (interactions) + Ce WP est dédié à l'élaboration d'un langage, nommé L1, de programmation + spatiale dont la fonction est de décrire les exemples déterminés dans le + WP1. Le langage \mgs, introduit dans le chapitre~\ref{chap:partie-activite}, + est un candidat idéal pour ce rôle. + % Raison 1: Collection topologiques + Tout d'abord, \mgs est construit sur les collections topologiques, une + structure de donnée dans lequel l'espace est traité explicitement. + Il dispose d'une primitive spatiale s'appliquant à toute collection + topologique: l'opérateur de voisinage «\ç{,}». + %Reformulé avec les concepts du chapitre~\ref{chap:partie-multi-modele}, . + Cet unique opérateur (et ses restrictions) permet de spécifier, + indépendamment de la collection, le modèle de chaque exemple du WP1. + % Raison 2: Transformations sur les collections + Ensuite, dans \mgs, le temps est modélisé par les altérations successives + d'une collection topologique au moyen d'une fonction définie par cas sur + des motifs de filtrage d'une collection topologique appelée transformation. + Cette fonction permet de traiter différents aspects temporels (asynchrone, + synchrone, déterministe, stochastique, etc.) de l'évolution et se trouve + particulièrement bien adapté à le description des exemples du WP1. + % Raison 3: Activité est un outil pour la description des exemples du WP1 + Finalement, la mise en évidence de l'activité spatiale dans \mgs nous permet + de simuler les exemples, dans certain cas, plus efficacement en restreignant + le filtrage de motif à la partie active de la collection topologique, c'est + à dire celle qui se trouvera modifiée au prochain pas de simulation. + \item[Contributions à WP3] + % OTB simule parfaitement L2 + Ce WP est dédié à l'élaboration d'un second langage, nommé L2, de + programmation prenant en entrée les concepts utilisés en sortie de + L1, et en les instanciant dans les individus (des bactéries). Le + simulateur \otb, muni du langage de description \sbgp, introduit dans le + chapitre~\ref{chap:partie-otb}, est un candidat idéal pour ce rôle. + % Raison 1: Réseau de régulation génétique décrit par \sbgp + Tout d'abord, le langage de description permettant d'instancier le + comportement des bactéries est \sbgp. Il décrit l'équivalent d'un Réseau + de Régulation Génétique (RRG) d'une bactérie, c'est à dire l'action de + l'environnement sur l'expression de son code génétique. Dans \otb, ce RRG + est décrit sous la forme d'un automate à états finis embarqué dans chacune + des bactéries, ce qui permet de retrouver des comportements de population + observés en laboratoire. + % Raison 2: Simulation efficace + Ensuite, nous avons fait en sorte que \otb soit le plus efficace possible, + en utilisant le parallélisme à disposition dans les cartes graphiques + grand public. Nous pouvons attendre en quelques minutes des population de + l'ordre des \num{E5} bactéries interagissant les unes avec les autres. + % Raison 3: OTB vu comme une collection topologique de MGS + Finalement, et même si cet objectif n'est pas encore atteint au moment + de l'écriture de ce manuscrit, nous estimons que \otb peut-être vu comme + une collection topologique particulière de \mgs, ce qui nous permettra + de lier les langages L1 et L2 directement au niveau de \mgs. Ainsi, les + primitives spatiales définies dans L1 pourront avoir une traduction + explicite directement dans \mgs et servir à définir le RRG incorporé dans + les bactéries de \otb. + \item[Contributions générales] + % Description du multi-niveau colle à tour de langages + Le projet \synbiotic a pour objectif de décrire le passage d'un comportement + de haut niveau, à l'échelle d'une population d'entités, à un comportement de + bas niveau, à l'échelle de l'individu, par le passage le long d'une tour de + langages, similaire au processus de compilation d'un programme informatique. + % Raison 1: Chacun des étages de la tour forme un niveau de description + Pour commencer, nous constatons que chacun de ces étages de cette tour de + compilation peuvent être vu comme des niveau de modélisation. À chaque + étage, un langage de programmation manipule des objets d'une certaine + manière, avec une certaine préférence, par exemple, dans \mgs, l'accent + est mis sur la description explicite de l'espace. Dans le cadre du + chapitre~\ref{chap:partie-multi-modele}, nous pourrions voir cet étage comme + un niveau de description où les modèles appartiennent tous à la classe des + modèles à champ, en y ajoutant certainement quelques contraintes pour mieux + coller à \mgs, les champs offrent une description plus abstraite que les + opérateurs de \mgs nous permettent. + % Raison 2: Nous avons un outil pour formaliser les liens entre chaque étage + % Est-ce un couplage simple / une complexification ? + Ensuite, le cadre formel développé dans le + chapitre~\ref{chap:partie-multi-modele}, nous donne un outil concret pour + aller caractériser les classes de modèles spécifiques à chaque étages et à + expliciter les liens entre chacun des étages de cette tour de langages. Nous + sommes désormais en mesure, dans des travaux futurs, de déterminer quel type + de flèche il existe entre chacun des niveaux de description du projet. + De plus, la description de l'activité spatiale dans le + chapitre~\ref{chap:partie-activite} nous donne déjà une voie vers une + représentation intermédiaire entre L0, le langage de haut niveau pour la + description des exemples du WP1 et L1. + % Raison 3: Formalisation aide WP5 sur calculabilité et WP6 sur la + % specification de Bio-sûreté et bio-sécurité + Finalement, les travaux effectués chapitre~\ref{chap:partie-multi-modele} + devraient apporter un éclairage bienvenu sur les travaux des autres WP, en + proposant un support à l'étude de la calculabilité des modèles de chacun des + niveaux pour le WP5, et un cadre de description général permettant d'étudier + au mieux le respect des spécifications dans le cadre du WP6. +\end{description} + +% Clôture/Humour +Nos perspectives de recherche globales sont bien sûr plus nombreuses que la +somme des perspectives de recherche de chacune des parties. Est-ce bien le cas? +Nous le saurons bien assez tôt. + +% ### THE END ### diff --git a/partie-introduction.tex b/partie-introduction.tex new file mode 100644 index 0000000..3ce20e7 --- /dev/null +++ b/partie-introduction.tex @@ -0,0 +1,704 @@ +\chapter{Introduction}%\minitoc + +%Intro barrée +Depuis l'avènement de la science informatique, les modèles sont de plus en plus +utilisés pour décrire et comprendre le monde qui nous entoure. Automatisés et +portés par les langages de programmation, ils sont de plus en plus imposants, +au sens où ils incorporent de plus en plus d'information et visent à être de +plus en plus complets. Barrant le chemin à une meilleure compréhension de notre +environnement, la modélisation des \emph{systèmes complexes} est le prochain col +à franchir dans la compréhension du vivant (pour les sciences du vivant) et dans +la compréhension des fondements des modèles (pour les sciences informatiques et +mathématiques). + +Il existe un riche vocabulaire entourant le monde des \emph{systèmes +complexes}: émergence, immergence, backward- et forward-causality, … +Ces notions sont difficiles à appréhender car elles se fondent sur +des cas particuliers (comme les exemples classiques du jeu de la +vie~\cite{gardner_mathematical_1970}, des boids~\cite{reynolds_flocks_1987} ou +de la fourmilière~\cite{wilensky_netlogo_1997}) et sur un certain laxisme formel +dans la description des modèles, provenant de la confusion entre les objets que +le modèle manipule et de notre propre identification de ces mêmes objets. Pour +chacun des exemples donnés ci-dessus, nous pouvons nommer des propriétés qui ne +font pas partie du modèle: +\begin{itemize} + \item Dans le jeu de la vie, un observateur parlera souvent de «glider», de + «canons» à glider, de «beacon», de «pulsar», etc.; + \item Dans le modèles des boids, un observateur identifiera un comportement + de groupe et cherchera à en identifier le «leader»; + \item Dans le modèle de la fourmilière, un observateur remarquera que les + individus sélectionnent le «plus court chemin» pour rapporter la nourriture + au nid, et qu'ils traitent les sources de nourriture dans l'ordre «du plus + proche au plus lointain». +\end{itemize} +Toutes les propriétés mises entre guillemets ci-dessus ne sont pas des +propriétés des modèles présentés, il n'y a pas de «glider» dans le modèle du +jeu de la vie, il n'y a pas de «leader» dans le modèle des boids ni de «plus +court chemin» dans le modèle de la fourmilière. Ce sont des interprétations qui +sont faites sur le déroulement d'une simulation, des propriétés d'un modèle +\emph{implicite} que l'observateur établi de lui-même. Rendre explicite ce +modèle puis lier formellement ces propriétés émergentes au modèle d'origine est +un enjeu de taille, car il permettrait de relier tout ensemble de propriétés +\emph{locales} à des propriétés \emph{globales}, c'est-à-dire des propriétés des +individus à des propriétés du groupe formé de ces individus. + +% Loi / simulation | global / local +Un outil classique de la modélisation, les équations différentielles, nous +donne l'occasion d'illustrer ce rapport local/global. Un système d'équations +différentielles permet de décrire le comportement d'entités locales (au cours +du temps, les unes par rapport aux autres, …). Lorsque ce système d'équations +différentielles possède une solution, alors la fonction solution est une +\emph{loi globale} du modèle établi au niveau local. Il existe un lien formel +entre le comportement local de ces entités et leur comportement global. Il +est possible d'étudier cette fonction \emph{directement} en toute généralité. +Toutefois, cette solution au système d'équations différentielles n'existe pas +forcément. Dans ce cas, il est toujours possible d'obtenir le comportement +global de ces entités par intégration numérique, c'est-à-dire en approchant +la fonction solution \emph{au cas par cas}. N'ayant pas accès à la fonction +solution, il n'est cependant pas possible d'étudier directement le comportement +global de cette population. + +%equadiff avec solution = loi (fast path) +%equadiff sans solution = simulation (slow path) + +% Le multi-modèle à la rescousse ? +Nous prendrons partie pour le fait que construire un modèle constitué de +plusieurs sous-modèles nous permet sous certaines conditions de répondre à la +problématique. Cela doit nous permettre de concilier les comportements locaux et +globaux de ce système. Nous appellerons cette technique la \emph{modélisation +multi-niveau}, que nous considérons comme une sous-branche de la modélisation +multi-modèle. + +La modélisation multi-modèle consiste à conjuguer différents modèles +d'un système, où chacun des modèles décrit une partie fonctionnelle ou +structurelle du système. Ces modèles, développés indépendamment, sont parfois +rédigés dans des formalismes si distincts qu'il est difficile de les faire +collaborer. Un exemple de discipline reposant sur cette problématique est la +\emph{mécatronique}~\cite{bishop_mechatronics_2002}, dont le sujet d'étude +est le couplage entre systèmes mécaniques et électroniques. La modélisation +multi-niveau s'intéresse aux modélisations multi-modèle ayant les propriétés +suivantes: +\begin{itemize} + \item Le système peut se représenter comme un \emph{empilement} de points + de vue appelés \emph{niveaux de description}. Même si ces niveaux ne + sont pas agencés dans un ordre total, il existe cependant une relation + caractérisable entre eux, comme par exemple une relation d'abstraction. + \item Un niveau de description du système peut n'être que partiellement + connu et c'est par leur couplage que la modélisation du système se trouve + \emph{renforcée}~\cite{banos_coupling_2015}. +\end{itemize} +Sans entrer dans les détails, nous considérerons qu'un modèle est réductionniste +s'il peut être découpé en sous-parties autonomes permettant, une fois assemblées +de décrire exactement son comportement. La construction précédente permet de +garder une vision réductionniste des parties du système, tout en indiquant que +parfois il n'est pas possible de fournir un modèle réductionniste du système +entier, notamment à cause d'un manque de connaissance sur le système. + +% Introduction trop longue, quand est-ce qu'on tappe ? +Nos travaux sont issus de réflexions sur la modélisation multi-niveau, +l'activité comme un niveau de description dans un langage de programmation +spatiale et la simulation de la morphogénèse dans de grandes populations de +bactéries, ayant pour origine les motivations du projet ANR Blanc \synbiotic. + + +\section{Le projet \synbiotic}\label{sec:synbiotic} +Dans cette section, nous présentons le projet ANR \synbiotic\footnote{La +page de présentation du projet est disponible en ligne à l'adresse +\url{http://synbiotic.spatial-computing.org}}. + +Le projet de recherche \synbiotic vise à développer des formalismes et +des outils informatiques permettant de spécifier un comportement spatial +global et de le compiler automatiquement à travers une tour de langages +intermédiaires dans des processus locaux de régulation cellulaire (régulation +génétique, métabolique, signalisation). La motivation finale est de permettre +l'exploitation des propriétés collectives d'une population bactérienne pour +créer des biosystèmes artificiels répondant à divers besoins dans le domaine de +la santé, des nanotechnologies, de l'énergie et de la chimie. + +\synbiotic s'inscrit dans le domaine des langages de programmation non +conventionnels et de l'analyse de propriétés des systèmes dynamiques, à +l'interface de l'informatique et de l'ingénierie biologique. Il s'appuie sur +les avancées de la biologie synthétique, les progrès réalisés dans la +modélisation et la simulation de processus biologiques complexes, et sur le +développement de nouvelles approches de la programmation permettant de faire +face à de nouvelles classes d'application caractérisées par l'émergence d'un +comportement global dans une grande population d'entités irrégulièrement et +dynamiquement connectées (le calcul amorphe et le calcul autonome). + +La biologie synthétique est un domaine scientifique qui concerne la conception +et la fabrication banalisée et standardisée de composants et de systèmes +biologiques sans correspondants naturels. Elle est toujours en quête de +principes de conception permettant une réalisation fiable et sécurisée à partir +de composants biologiques réutilisables. + +Dans ce contexte, l'objectif est de concevoir et développer les outils +permettant de « compiler » (au sens de la compilation des langages de +programmation) le comportement global d'une population, par exemple, de +bactéries, en des processus cellulaires locaux à chaque entité. Notre motivation +à très long terme est de permettre l'exploitation des propriétés collectives +d'une population (bactérienne) pour créer des biosystèmes artificiels répondant +à divers besoins dans le domaine de la santé, des nanotechnologies, de l'énergie +et de la chimie verte. L'approche originale que nous proposons se fonde sur une +tour de langages de programmation, dont l'étage le plus abstrait définit un +modèle computationnel pour une population cellulaire et l'étage le plus primitif +correspond à un agencement de séquences d'ADN. Chaque langage compile ses +constructions propres vers le langage de la couche inférieure et ce, jusqu'au +bioware (le « hardware biologique »). Cette approche, similaire à celle suivie +avec succès dans le domaine de la synthèse d'architecture matérielle (chaîne +de compilation vers le silicium), permet de combler le fossé existant entre la +description d'un système au niveau d'abstraction pertinent pour l'application +et la prise en compte de tous les détails de son implantation par des processus +physico-chimiques. Elle permet de modulariser la conception d'un système, +divisant les difficultés et isolant des niveaux d'abstraction qui peuvent +évoluer indépendamment. Dans cette approche, un programme ne définit pas une +fonction qui associe une sortie à une entrée mais spécifie un système dynamique +(biologique) distribué qui essaie de maintenir des invariants en dépit des +perturbations et des changements de l'environnement. + +% \synbiotic est un projet de recherche fondamentale à long terme qui s'inscrit +% dans le domaine à la fois des langages de programmation non conventionnels et +% dans l'analyse/validation de propriété de systèmes dynamiques. Il s'agit +% d'un projet informatique qui vise à utiliser les nouveaux supports de calcul +% fournis par les avancées de la biologie synthétique et non à les produire. +% \synbiotic a pour objectif d'étendre les techniques et les outils développés +% dans la modélisation et la simulation de processus biologiques complexes +% et d'intégrer de nouvelles approches de la programmation (programmation +% spatiale, programmation amorphe et programmation autonome) afin de faire face +% à de nouvelles classes d'applications caractérisées par l'émergence d'un +% comportement global dans une grande population d'entités localisées et +% irrégulièrement interconnectées de manière dynamique. +% +% \paragraph{Une approche informatique en amont de l'ingénierie génétique.} +% Si la plupart des études actuelles cherchent à formaliser, concevoir, +% caractériser et valider des composants biologiques réutilisables, nous nous +% positionnons en amont de cette étape. La biologie synthétique regroupe des +% stratégies scientifiques et des technologies très différentes qui incluent +% la conception et la construction de génomes, la conception de protéines, +% la synthèse de composés biochimiques par de nouvelles voies métaboliques +% et la construction de circuits de régulation génique dans des cellules et +% des micro-organismes. Pour ce qui nous concerne, nous faisons l'hypothèse +% qu'il existe des bibliothèques standardisées de comportements biochimiques +% élémentaires qui peuvent être composés dans une bactérie, comme par exemple +% les BioBricks. +% +Notre objectif est d'adresser la conception de grands systèmes biologiques +par une approche langage, de la même manière que VHDL permet la conception +de système de traitement de l'information à partir de portes et de blocs +logiques élémentaires. Ce projet informatique repose sur trois hypothèses : +l'apport des formalismes discrets, un processus de conception fondé sur la +compilation d'une tour de langages et la prise en compte des aspects spatiaux. + +Notre première hypothèse est que des modèles informatiques discrets sont +adéquats pour décrire des biosystèmes et parfois plus pertinents que des +approches mathématiques traditionnelles comme les équations différentielles. +Cette hypothèse est corroborée par l'important développement actuel des +formalismes informatiques dans le domaine la biologie des systèmes. En +particulier, ces formalismes sont plus à même de capturer de manière concise +les aspects qualitatifs et quantitatifs des grands réseaux d'interactions +biochimiques impliqués dans les processus biologiques. Ces formalismes +permettent de découpler les abstractions utilisés dans le processus de +conception (signal, gradient, mémoire, propagation, information de position…) +des processus biochimiques utilisés pour leur implémentation, de la même +manière qu'un bit abstrait de manière robuste une implantation électrique +dans une électronique à base de silicium. Par ailleurs, ces formalismes +permettent d'aborder la question de la validation : que peut-on garantir sur les +comportements du système biologique artificiel, quel est le domaine de viabilité +du système, quels sont les perturbations de l'environnement qui sont tolérables, +quels est la résilience du système, peut-on garantir que certains états sont +inatteignables, tracer les processus, tester les comportements attendus, etc. + +Notre seconde hypothèse est qu'à partir de ces formalismes, la compilation est +une approche descendante plus souple que l'assemblage direct de composants +biologiques prédéfinis. Le processus de compilation permet d'instancier des +composants élémentaires génériques dans un organisme particulier, permet de +prendre en compte des contraintes d'assemblage (comme l'évitement de cross-talk +entre circuits de régulation) ainsi que la simplification et l'optimisation +des circuits obtenus par assemblage. Cette approche de haut-niveau correspond +à la synthèse d'un système à partir de ses spécifications et repose sur la +possibilité de dériver le comportement des parties à partir du comportement +d'un tout. Ce problème est notoirement plus simple que celui de l'inférence de +propriétés globales à partir de comportements locaux (émergence) et a montré +toute son utilité dans le domaine de la synthèse d'architecture, mais aussi dans +le cadre de la programmation spatiale et de la programmation amorphe. Un des +enjeux du projet est de montrer que ces techniques peuvent être appliquées avec +succès à la synthèse de biosystèmes. + +% \paragraph{La prise en compte du spatial.} +Enfin, notre dernière hypothèse est que, même si pour l'instant la biologie +synthétique se focalise sur la « programmation d'une seule bactérie », +le développement de biosystèmes un tant soit peu complexe reposera sur +le fonctionnement intégré de colonies bactériennes et donc sur la prise +en compte d'interactions spatiales au sein d'une population de cellules +différenciées. Il est en effet douteux qu'une cellule puisse supporter un +nombre arbitraire de comportements artificiellement imposés. Au contraire, +l'exemple des processus biologiques naturels montrent toute l'importance de +l'organisation spatiale et de la compartimentalisation (membrane, vésicule, +cargo, compartiment, cellule, biofilm, tissus, organe, etc.) permettant la +spécialisation et le fonctionnement intégré au sein d'un système compris +comme une écologie. Par ailleurs, la maîtrise des interactions spatiales +ouvre la voie à une ingénierie du développement (« développement » au +sens biologique du terme), ce qui permet de rêver à des applications qui vont +bien au-delà de la conception de la cellule comme « usine chimique ». +% +% \paragraph{Un volet validation.} +% Le positionnement du projet est résolument informatique et se +% concentre sur le développement de techniques de compilation et de validation +% en amont de l'ingénierie génétique. Cependant, afin de valider les outils +% développés, nous souhaitons les mettre en œuvre concrètement à travers leur +% utilisation à l'intérieur du projet par une application de morphogénèse et, +% à l'extérieur, par une équipe iGEM. + +\paragraph{Découpage des tâches.} +Le projet \synbiotic est découpé en six \emph{Work Packages} (WP), dont les WP +1, 2, 3 et 4 forment une tour de langages reliant le hardware/wetware (WP4) au +langage de spécification global (WP1). Voici une description de ces quatre +tâches: +\begin{description} + \item[WP1: Ingénierie des formes] ce WP est en charge de concevoir, de + développer et d'implémenter des exemples d'applications qui pourront être + utilisées par les autres WP. + \item[WP2: Programmation spatiale déclarative] ce WP est en charge de + l'élaboration d'un langage de programmation spatiale L1, dont la fonction + est de décrire les exemples du WP1 (définis en terme de primitives spatiales + sur des populations) vers un langage de plus bas niveau servant d'entrée au + WP3. + \item[WP3: Programmation orientée entité] ce WP est en charge de l'élaboration + d'un nouveau langage L2 prenant en entrée les concepts utilisés en sortie de + L1 et les instanciant dans les individus (des bactéries). + \item[WP4: Programmation orientée réseau de régulation] l'enjeu de ce WP est + de permettre la traduction de la sortie de L2 vers un médium biologique, + afin d'obtenir une implémentation finale \emph{in vivo}. +\end{description} +Les WP 5 et 6 sont transversaux et se chargent de «calculabilité et complexité» +et de «Bio-sûreté et bio-sécurité» respectivement. + + + \section{Objectifs et organisation de cette thèse} +Dans cette section nous présentons brièvement les objectifs de ce manuscrit et +les chapitres qui le composent afin de donner au lecteur une vue d'ensemble des +résultats obtenus. + +Comment nous l'avons vu, nos travaux sont ancrés dans le contexte du projet +\synbiotic. Nous avons contribué aux WP2 (chapitre 3) et au WP3 (chapitre 4). +Nous avons également dépassé le cadre du projet en nous intéressant de plus près +à la nature des modèles (mathématiques) et à la définition de la modélisation +multi-niveau. + +\paragraph{Chapitre 2: Une approche formelle générale des niveaux de + modélisation} +Dans ce chapitre nous proposons une première voie de réponse à notre +problématique en nous attaquant au problème de la définition à la fois +formelle et générique des niveaux de modélisation. Nous introduisons une +définition claire de ce qu'est un \emph{modèle formel} qui nous permet de +présenter explicitement notre point de vue. Une fois ce socle à disposition, +nous présentons différentes classes de modèles avec leurs exemples dans notre +formalisme mettant en évidence la possibilité d'identifier ces classes de +modèles suivant plusieurs critères reposant sur la structure mathématique +associée à leur comportement. Nous proposons enfin une construction de +niveaux d'abstraction, reposant sur quelques principes issus de la théorie +des catégories, introduisant la validation, l'abstraction et la composition +des modèles dans ce cadre. Nous instancions finalement sur un exemple les +définitions précédentes mettant en lumière les relations existantes entre quatre +modèles d'un système proie-prédateur. +%enfin poser les fondements +%des relations entre modèles tel que nous les avons présentés plus + +\paragraph{Chapitre 3: L'activité spatiale comme outil de modélisation} +Dans ce chapitre nous présentons le langage L1 du WP2 en posant un cadre +pratique et théorique porté par le projet \MGS. Ce dernier développe un langage +de programmation dédié à la modélisation et la simulation de systèmes dynamiques +à structure dynamique. L'état du système est décrit à travers une structure +de données — la collection topologique — qui met l'accent sur les relations +topologiques entre les éléments du système. L'évolution du système est spécifiée +au moyen d'une structure de contrôle — la transformation — qui décrit, sous +forme de règles \emph{locales}, les interactions entre les éléments du système. +Nous présentons l'activité spatiale dans le contexte de \MGS, qui nous indique +la répartition dans une collection topologique de la sous-collection active +et nous implémentons un algorithme nous permettant de mettre à jour cette +collection sans connaissance de la sous-collection quiescente. Au delà de +l'optimisation en temps de calcul qu'il apporte à certaines simulation, cet +outil nous permet de capturer une \emph{propriété d'ordre supérieur} du modèle +et offre une voie pour la description, dans \MGS, de modèle à plusieurs niveaux +de description. + +\paragraph{Chapitre 4: Un exemple concret de simulation multi-niveaux} Dans +ce chapitre nous ouvrons une troisième voie de réponse à notre problématique, +tournée vers la pratique, où nous présentons la conception d'un simulateur de +populations de bactéries \Ecoli, nommé \otb, correspondant au langage L2 du WP3 +de \synbiotic. En effet, l'évolution de ces populations de bactéries montre +un fort potentiel pour la modélisation et la simulation multi-niveau: une +population suffisamment importante mène à des propriétés définies uniquement +à l'échelle de cette population, comme l'émergence et le maintient de formes +particulières — la morphogénèse. Le but de ce simulateur n'est pas, comme dans +les chapitres précédents, de fournir une méthode générique pour exprimer ces +propriétés mais plutôt de partir de la bactérie définie individuellement et +de tester, donc de mettre en évidence, le lien existant entre les propriétés +de l'individu (le réseau de régulation génétique) et les propriétés de la +population (les formes émergentes). Pour relever les défis posés par la +simulation d'un grand nombre d'individus, nous tirons partie du calcul parallèle +sur des cartes graphiques grand public et, dans ce cadre, nous avons développé +plusieurs algorithmes originaux pour le calcul parallèle dont le principal est +\ppm, inspiré des automates cellulaires et du voisinage de Margolus. + + +\section{Contributions} + +Voici une liste succincte des contributions scientifiques apportées par cette +thèse. + +\subsection*{Théorie et formalisation} +\begin{itemize} + \item établissement d'un cadre formel pour l'expression unifiée des niveaux + de modélisation, indépendamment de leur formalisme d'origine; + \item définition de l'activité spatiale; + \item élaboration d'un algorithme pour l'identification et le maintient d'une + zone spatialement active dans \MGS; + \item définition d'un algorithme générique (\ppm) pour le calcul parallèle. +\end{itemize} + +\subsection*{Développement} +\begin{itemize} + \item développement d'un simulateur pour mettre en évidence l'émergence et le + maintient de formes dans une population de bactéries \ecoli. +\end{itemize} + +\subsection*{Communications orales} +\begin{itemize} +\item présentation de «Computing Activity in Space» au workshop SCW13 de la + conférence AAMAS 2013 à St Paul (Minnesota, USA), du 6 au 10 mai 2013; +\item présentation de «Topological Computation of Activity Regions» au workshop + Work In Progress de la conférence SIGSIM PADS 2013 à Montréal (Québec, + Canada), du 19 au 22 mai 2013; +\item présentation au séminaire du LACL, intitulé «Implementing Multiple Levels + of Organization in a Spatial Programming Language» le 10 février 2014, à + Créteil; +\item participation au workshop SCW14 attaché à la conférence AAMAS qui s'est + tenu à Paris du 5 au 9 mai 2014; +\item participation au workshop 228 de l'INSERM intitulé : «Experimental + approaches in mechanotransduction: from molecules to tissues and pathology», + du 21 au 23 Mai à Bordeaux, France; +\item présentation d'un tutoriel \MGS à la conférence ICCSA 2014, le 24 Juin + au Havre, France; +\item présentation de «Managing the Interoperability Between Models of a Complex + System» au workshop 6 satellite de la conférence ICCSA 2014, du 23 au 26 Juin + au Havre, France; +\item présentation de «Spatial Computing for Integrative Modeling» au ComBio à + Turku, Finlande, le 29 octobre 2015. +\end{itemize} + +\subsection*{Communications écrites} Les travaux présentés dans ce manuscrit +ont donné lieu à plusieurs publications dans des conférences internationales +et nationale~\cite{potier_computing_2013, potier_topological_2013, +pascalie_developmental_2016}. Deux publications sont en cours de préparation en +vue de rendre public les travaux du chapitre \ref{chap:partie-multi-modele} et +du chapitre \ref{chap:partie-otb}. + +\printbibliography[heading=subbibliography] + +\subsection*{Autres contributions} +\begin{itemize} + \item Encadrement à 50\% du stage de Master 1 de Romain Carriquiry Borchiari + intitulé «Modélisation et simulation d'une population de bactéries en + \opencl» duquel la toute première version de \otb est issu. +\end{itemize} +% \begin{itemize} +% \item DEVS-FIRE (X Hue) +% \item Parallèle avec la physique du solide et la physique du point -> +% complexification (même si tout marcherai avec de la mécanique du point); +% Distinction entre règles internes et règles externes. +% \item Discrete Differential Forms for Computational Modeling (Desbrun, Kanso, +% Tong) +% \item Computation with competing patterns in Life-like automaton (Martinez, +% Adamatzky, Morita, Margensten) +% \item Predicting Wildfire Spreading Through a Hexagonal Cellular Automata Model +% (Trunfio, p401 de Cellular Automata) +% \item Modelling Wildfire Dynamics via Interacting Automata (Dunn, Milne, CA +% p411) +% \item Downward Causation and the autonomy of Weak Emergence (Mark Bedeau) +% \item Multi-level simulation of farmer's land use and social organization +% decision-making; an agent-based approach (Speelman, Jager, Grot, Garcia, +% Tittonell) +% \item Problème de l'identité (Derek Parfit - Reasons and Persons - Livre de +% 400p) +% \item Mail du 16 avril 2013 à 19:06 (+photos) +% \item Accroche toi au niveau, j'enlève l'échelle (Gil-Quijano, Hutzler, Louail) +% \item Closes point method (Forest fire, level sets on surfaces) +% \item Symbiotic simulation (Fujimoto et al), Rapport Dagstuhl +% \item Filippi front tracking (modèle MGS dans le CVS +% Exemple/Exemble-bezier/Front) +% \item Can we computerize an Elephant (David Harel, 2009, 2015) (AAMAS 2015) +% \item The detection of intermediate-level emergent structures and patterns +% (Villani et al) +% \item Thèse Duboz : intégration de modèles hétérogènes pour la modélisation et +% la simulation de systèmes complexes. (c'est du DEVS) +% \item WAVE parallel programming language +% \item Méchanotransduction (INSERM Workshop) +% \item Mathematical formulation of multi-layer networks (à mettre dans les +% modèles formels) +% \item Introduction to the Mathematical Theory of Systems and Control (Polderman +% \& Willems) -- inspiration pour la définiton générale de modèle. +% \item Kurtz, the relationship between stochastic and deterministic models for +% chemical reactions. +% \item Spicher, Verlan -- Generalized Communicating P Systems Working in Fair +% Sequential Mode +% \item +% \end{itemize} + + +% Appel à projet pour la création d'un DIM recherche transversale sur +% les systèmes complexes + + + + +% \section{Modéliser des systèmes complexes} +% % Modéliser? +% Concevoir des modèles est une pratique courante pour comprendre le +% fonctionnement d'un phénomène ou la structure d'un objet \emph{compliqué}. Le +% modélisateur a pour tâche de +% \begin{enumerate} +% \item \emph{identifier} les parties du phénomène étudié et en donner une +% représentation simplifiée, +% \item \emph{assembler} ces parties, à l'aide d'un formalisme ou d'un langage de +% programation, +% \item \emph{comparer} les propriétés principale du phénomène étudié avec les +% propriétés annoncées par son modèle. +% \end{enumerate} +% +% \bigskip +% La première tâche du modélisateur est d'identifier les parties du système qu'il +% souhaite modéliser. C'est au modélisateur que revient la décision de nommer une +% partie qu'il a identifiée; cette tâche peut-être rendue difficile suivant les +% cas. En philosophie, la notion d'identité recouvre plusieurs concepts proches, +% elle est donc ambigüe et poser des problèmes dans certains cas, voici quelques +% exemples de paradoxes concernant l'identité. +% +% \paragraph{Un tas de riz}% +% Dans le langage courant, nous utilisons des mots pour nous réferer aux objets +% qui nous entourent. Quand plusieurs objets sont regroupés, ils peuvent être +% assimilés à un nouvel objet unique. Un exemple est le tas de riz. Le mot tas +% désigne un objet unique, constitué de multiples autres objets, en l'occurence +% des grains de riz. Comme il n'y a pas de limite claire concernant le nombre de +% grains de riz nécessaires à former un tas, il est apparemment difficile de +% déterminer lequel de ces raisonnements est approprié: +% % +% \begin{itemize} +% \item Un grain de riz n'est pas un tas. Ajouter un grain de riz à ce grain de +% riz ne forme pas un tas. Ajouter un grain de riz à ces deux grains de riz ne +% forme pas un tas. Donc ajouter un grain de riz à plusieurs grains de riz ne +% forme pas un tas. Il semblerait, en raisonnant par récurrence qu'\emph{un +% nombre arbitraire de grains de riz ne forme pas un tas}; +% \item Un tas n'est pas un grain de riz. Enlever un grain de riz à un tas ne +% change pas sa nature. Nous devrions pouvoir répéter cette opération jusqu'à +% atteindre le moment où il ne reste qu'un seul grain de riz et déduire +% qu'\emph{un grain de riz est un tas}. +% \end{itemize} +% +% +% +% \bigskip Pour la seconde tâche du modélisateur, construire le modèle, la science +% informatique et l'outil informatique sont principalement utilisés. Il existe de +% nombreuses techniques et outils de modélisation suivant les besoins et les +% domaines. Par exemple, la modélisation qualitative ou quantitative, discrète ou +% continue et l'étude des systèmes dynamiques. Couramment, les approches +% classiques de modélisation individu-centrés nécessitent la description des +% entités et des lois qui régissent les évolutions du système à un seul et unique +% \emph{niveau de description}: la molécule, la cellule ou le tissu en biologie; +% le quartier, la ville ou le pays en urbanisme; la note, la mesure ou le thème en +% musique… Certains phénomènes à modéliser opèrent clairement à plusieurs niveaux +% de description. Par exemple en biologie, l'embryogenèse est typiquement un +% problème décrit comme étant multiniveau. Comment, à partir d'une unique cellule, +% se développe un organisme multicellulaire autonome ? Comment modéliser le +% passage de l'individu à la population ? Comment décrire le phénomène de +% mécanotransduction, où l'application d'une force mécanique altère le +% développement d'un embryon ? Pour répondre à ces questions, il nous faut de +% nouveaux outils de modélisation prenant en compte plusieurs niveaux de +% description. +% +% Pour les nouvelles sciences de la complexité, les phénomènes ayant plusieurs +% niveau de description sont parfois appelés \emph{systèmes complexes}. Voici une +% définition qu'en donne l'Institut des Systèmes Complexes (\ISC): +% \begin{quote} +% Les systèmes complexes sont des systèmes présentant un grand nombre d'entités +% différenciées, interagissant de manière complexe : interactions non linéaires, +% boucles de rétroaction, mémoire des interactions passées. Ils se caractérisent +% par l'\emph{émergence}, au niveau global, de propriétés nouvelles non +% observables au niveau des entités constitutives. Le niveau local fait émerger +% des formes organisées au niveau global, lequel influence en retour le niveau +% local (appelé «immergence»). Interactions locales et interactions globales +% peuvent ainsi se conjuguer dans la description de leurs dynamiques. \hfill\ISC +% \end{quote} +% Cette définition nous fourni une image où deux niveaux de description, le niveau +% local et le niveau global, interagissent l'un sur l'autre, de local à global par +% l'émergence et de global à local par l'immergence, et où les propriétés des +% éléments observés sont restreintes à leur niveau de description. +% +% % le 2016-09-08, Martin a une révélation… Il était temps… +% \begin{quote} +% Les propriétés d'un objet du monde réel \emph{dépendent} de son cadre de +% modélisation, c'est à dire du modèle utilisé pour le décrire. +% \end{quote} +% En d'autre termes, les propriétés d'un objet modélisé \emph{ne sont pas} des +% propriétés de l'objet mais des propriétés du modèle. Cette hypothèse de travail +% est importante et se trouve au fondement de nos travaux. Sa première implication +% est qu'un niveau de description correspond à un modèle particulier. +% +% Cette limitation a pour conséquence directe de ne pas permettre de référencer +% les entités intervenant dans d'autres niveaux de description. Ainsi, en biologie +% moléculaire, ne disposant d'aucune notion de cellule, on ne peut décrire +% directement des processus tels que le \emph{transport actif} ou le \emph{quorum +% sensing}. De façon plus générale, ces approches purement locales et +% réductionnistes ne permettent pas de prendre en compte des connaissances dont on +% dispose aux autres niveaux de description ni des relations causales qui existent +% entre les niveaux de description. Le défi que nous nous proposons de relever est +% de proposer un cadre à la fois pratique et théorique pour modéliser et simuler +% des systèmes dynamiques complexes en prenant en compte plusieurs niveaux de +% description. +% +% %Niveau de description +% +% Dans quelques travaux de recherche en informatique et en philosophie nous avons +% pu rencontrer le terme d'\emph{émergence}. Par exemple : +% \begin{itemize} +% \item Émergence forte ou émergence faible +% \item Émergence synchronique et diachronique +% \item Émergence computationnelle et combinatoire +% \end{itemize} +% Pour le reste de ce manuscrit, nous supposerons que la notion d'émergence, en +% tant que concept transversal et définit de manière différente suivant les +% domaines et les travaux, peut se résumer comme un problème de vocabulaire +% permettant d'énumérer les propriétés d'un modèle. Nous faisons donc l'hypothèse +% suivante : +% \begin{quote} +% Soit un modèle $m_1$; une \emph{propriété émergente} du modèle $m_1$ est une +% propriété appartenant nécessairement à un autre modèle que $m_1$. +% \end{quote} +% Comme parfois la présence de propriétés émergentes détermine l'aspect complexe +% du modèle d'un système, nous rendons par ce fait explicitement non-complexe les +% propriétés déterminables dans le modèle utilisé. +% +% +% +% %\subsection{Compliqué n'est pas complexe} +% \paragraph{Ce qui est compliqué: la complexité comme une mesure} +% Dans le champ de l'algorithmique, la complexité est une \emph{mesure} sur une +% chaîne de caractères $s$ où plus une chaîne est complexe, plus elle est +% difficile à compresser. D'un côté, la complexité de Kolmogorov est la longueur +% du plus petit programme informatique, écrit dans un langage formel donné, +% produisant $s$. D'un autre côté, les modèles de calculs sont des formalisations +% mathématiques d'une méthode de calcul d'un résultat $f(x)$ par une fonction $f$ +% sur une entrée donnée $x$. En terme de puissance d'expression, tous les modèles +% de calculs universels se valent, leur complexité est donc évalué: +% \begin{itemize} +% \item en fonction du \emph{nombre de pas de calculs} nécessaire à une machine de +% Turing pour reconnaître un mot donné, appelé complexité en temps, puis +% \item en fonction de la \emph{taille de la bande} nécessaire à une machine de +% Turing pour reconnaître un mot donné, appelé complexité en espace. +% \end{itemize} +% Cette mesure donne naissance à toute une hiérarchie de classes de complexités. +% Nous ne nous intéressons pas, dans ce manuscrit, à la \emph{complexité comme une +% mesure} dans le cadre de l'alogrithmique. +% +% \paragraph{Ce qui est complexe: la complexité comme une «propriété»} +% Nous nous intéressons dans nos travaux aux systèmes possédant la propriété +% d'être complexe, qualifiés de systèmes complexes dont les exemples les plus +% courants sont les systèmes biologiques, à tous leurs niveaux de description. +% Cette appellation porte à confusion et nous n'avons pas trouvé de définition +% faisant consensus. Nous avons cependant défini, grâce à \MGS, une catégorie de +% modèles recouvrant la plupart des systèmes complexes: ce sont les Systèmes +% Dynamiques à Structure Dynamique\footnote{en anglais Dynamical Systems with a +% Dynamical Structure, abbrégé en DSDS, ou encore (DS)²}. C'est la définition à +% laquelle nous nous réfèrerons et nous nous abstiendrons d'utiliser le terme de +% système complexe dans la mesure du possible. + +% La présente thèse apporte sa contribution sur trois plans principaux: le premier +% concerne la participation au WP2 avec la définition de l'activité spatiale +% au sein du langage \mgs, la seconde concerne le WP3 avec la conception du +% simulateur de bactéries \otb et le troisième livre une réflexion en cours sur la +% nature des modèles du multi-niveau, thématiques au cœur du projet \synbiotic. +% +% %simulateur +% \paragraph{Un accès aux grandes populations} La simulation par \otb\ d'une +% population de bactéries concerne le bas de la tour des langages, au plus près +% de l'assembleur génétique. Sa conception a pour vocation d'accélérer les +% retours concernant des hypothèses de travail et nous permet de savoir si elles +% sont plausibles, ou bien à rejeter. C'est donc une étape préalable à la +% conception d'une expérience en laboratoire. De plus, il est moins coûteux +% d'obtenir des réponses d'un simulateur que de construire une expérience +% \emph{in vivo} et d'attendre qu'une population de bactérie se développe +% dans un environnement contrôlé ; \otb\ a donc une place centrale pour une +% partie des travaux de recherche du projet. \otb, par son rendu grahpique +% accéléré par OpenGL et son usage du calcul parallèle avec OpenCL, permet +% d'observer la croissance d'une importante population de bactérie avoisinnant +% le million d'individus, dans un environnement de taille variable s'adaptant +% à la répartition spatiale des entités. Il permet ainsi de tirer des +% conclusions qualitatives sur le comportement de grandes populations. \otb\ +% utilise également un langage d'entrée déclaratif, Synthetic Biology Genetic +% Programming~\cite{pascalie_morphogenetic_2016}, proche de celui de \gro~% +% \cite{jang_specification_2012}, ce qui permet de reprendre des précédentes +% simulations pour des tests à plus grande échelle. De par sa conception, +% \otb\ est aisément extensible grâce au langage de haut niveau OCaml et son +% architecture est modulaire, ce qui permet à un développeur d'ajouter ou de +% modifier facilement des fonctionnalités au simulateur. Enfin ce logiciel est +% libre, ouvrant la voie à des corrections et des améliorations sans entrave. +% +% %multi-modèle +% \paragraph{Un travail transversal} +% Nos travaux présentent, dans le premier chapitre, une approche formelle +% à la modélisation multi-niveau, issu d'un point de vue particulier sur +% le multi-modèle. +% % +% L'approche choisie par le projet \synbiotic est celle de l'ingénierie +% génétique : en choisissant d'emprunter la même voie que l'ingénierie des +% machines qui a donné le jour aux ordinateurs modernes et aux langages de +% programation, le projet tente de révéler des relations réductionnistes et +% de définir des sous-tâches plus simples à résoudre. De part l'élaboration +% de cette \emph{tour de langages}, le projet de recherche emprunte une approche +% informatique, où la complexité est entendue avec son sens algorithmique. +% Il est cependant intéressant de noter que la principale difficulté rencontrée +% concerne la description et la compréhension de ce qui constitue une forme de +% complexité inhérente au monde biologique : \emph{la complexité du vivant}. +% % Complexité +% Il n'y a pour l'instant pas de correspondance claire entre la complexité +% algorithmique et la complexité associée au vivant. Les systèmes complexes, au +% sens de la définition de l'ISC présentent la singulière caractéristique d'être +% simulables mais extrèmement difficiles à prédire. En d'autre terme, nous ne +% connaissons pas de \emph{lois} décrivant leur comportement \emph{global}. Les +% populations de cellules biologiques, par exemple, font partie des systèmes +% complexes. À l'inverse, la complexité des algorithmes est formellement définie. +% Les problèmes sont répartis en classes de complexité, dont on sépare les +% classes en temps ($\text{TIME}(t(n))$, $\text{NTIME}(t(n))$, …) des classes en +% espace ($\text{SPACE}(s(n))$, $\text{NSPACE}(s(n))$, …) ; toutes ces classes +% sont définies par rapport à un modèle de calcul central en informatique : les +% machines de Turing. Les classes en temps reflètent le nombre de pas nécessaire à +% une machine de Turing pour résoudre un problème tandis que les classes en espace +% reflètent la longueur de la bande, c'est à dire le nombre de cases mémoire, +% nécessaire pour résoudre un problème. La simulation d'un système complexe étant +% effectuée par un ordinateur, cette simulation fait donc au moins partie de la +% classe des problèmes décidables, car il suffit d'attendre l'itération de la +% simulation qui permet de décider d'une propriété. +% +% À l'instar de \synbiotic, d'autres projets de recherche s'intéressent à la +% question de la complexité du vivant. L'approche générique suivie par ces autres +% projet revient à assembler plusieurs modèles mathématiques ensemble pour +% reproduire les valeurs des observables observées dans la nature. Le lecteur +% trouvera d'autres exemples dans l'introduction au chapitre suivant. + + +% \paragraph{Aggrégation spatiale (Spatial Aggregation)}: L'aggrégation spatiale +% est un paradigme et un langage générique~\cite{yip_spatial_1996} unifiant la +% descriptions plusieurs solveurs de problème imagistiques. Ce langage leur permet +% de proposer un cadre commun pour décrire le fonctionnement de trois solveurs de +% problèmes spécialisés dans l'extraction d'informations qualitatives depuis des +% systèmes hamiltoniens (\textsc{Kam}), les structures d'espace d'était de +% systèmes dissipatifs (\textsc{Maps}) et de systèmes mécaniques à parties rigides +% (\textsc{Hipair}). Certains concepts utilisés se rapprochent de la programmation +% spatiale telle qu'implémentée dans \mgs{} telle que la structure de données +% générique sous forme de graphe de voisinage est un cas particulier de collection +% topologique. Dans chaque cas, l'objet à analyser est assimilable à un champ +% continu duquel l'outil utilisé tire des informations et correspond au niveau +% d'abstraction le plus bas. Le langage inclus des opérateurs pour transformer +% chaque niveau un niveau plus abstrait, par le biais d'agrégation et de +% classification. Les rapports montant et descendant entre les niveaux sont +% apparemment maintenu. Ces travaux adressent bien une partie de notre propre +% problématique, à ceci près qu'ils sont limités à quelques cas particuliers. diff --git a/partie-multi-modele.tex b/partie-multi-modele.tex new file mode 100644 index 0000000..50f87d6 --- /dev/null +++ b/partie-multi-modele.tex @@ -0,0 +1,4469 @@ +% Individu multi-optimisé (écologie) +% Patrick Coquillard + +\chapter{Modèles et modélisation multi-niveau}\label{chap:partie-multi-modele} +\minitoc + +\section{Introduction} +Dans ce chapitre, nous nous intéressons au développement d'un cadre formel pour +la spécification de \emph{modélisations multi-niveau}. +%% +Ce type de modélisation est souvent rencontrée dans les approches intégratives +des \emph{systèmes complexes}, dans de nombreuses disciplines: +%% +\begin{itemize} + +\item pour le couplage de modèles pour la description d'une cellule entière + (en biologie) ou la description d'un système de villes (en géographie); +\item pour le raffinement de modèles par la transformation de modèles (en + ingénierie des modèles) ou le raffinement de données et de processus (en + biologie); +\item pour la complexification de modèles dans les Cellular Non-linear Networks + (\cnn, en électronique), ou dans les Memory Evolutive Neural Systems (\mens, + en mathématiques), ces deux exemples étant présentés dans la section suivante. +%\item l'unification de la théorie de la relativité générale et de la théorie des +% quanta, deux modèles de la physique moderne dont les fondements sont +% incompatibles; +% +%\item l'établissement d'un modèle complet d'un organisme multicellulaire, +% incorporant toutes les connaissances disponibles à son sujet; +% +%\item l'étude des liens existants entre un individu et sa population, par le +% biais d'un modèle exhaustif et constructif, que ce soit dans les sciences +% sociales ou en biologie pour les liens entre cellules et organes, organes et +% organismes; etc. + +\end{itemize} +%% +Notre objectif n'est évidemment pas de répondre à ces questions mais d'apporter +un cadre de description commun, adapté et opérationnel (au sens où l'effectivité +d'un couplage pourrait être démontrée) pour les formaliser. + +Ce chapitre est consacré au rapport entre modèles et modélisation multi-niveau. +Il nous paraît important d'aborder la question de la modélisation multi-niveau +d'abord dans sa généralité, plutôt que le cas particulier que constitue le champ +d'une discipline, tel que la biologie, la physique, l'écologie, ou un objet +d'étude comme la dynamique des populations, la cellule, les feux de forêts, +etc. Même si ces cas particuliers présentent un intérêt pratique et permettent +de valider une démarche ou répondre à une question immédiate, ils pourraient se +trouver limités par les habitudes et les usages liés à la discipline dont ils +sont issue. + +% +L'objet de notre étude est donc de décrire l'étape franchie lors d'un changement +de niveau de description. Nous partirons donc d'une définition très générale des +modèles qui sera raffinée pour correspondre à des modèles existants et +mettre en lumière les différences et similarités entre ces formalismes. +% +%Un modèle est une représentation abstraite d'un système, +% +Nous nous intéressons exclusivement aux modèles formels, c'est-à-dire des +modèles donnés sous la forme d'une définition utilisant le langage des +mathématiques et pouvant potentiellement être calculés par un programme +informatique. Dans la suite de ce document, sauf exception, nous emploierons le +terme «modèle» pour désigner un modèle formel. + +Nous remarquons tout d'abord que déterminer des relations entre plusieurs +modèles est possible d'autant plus aisément que ces modèles évoluent dans la +même «classe», celle des modèles d'un même système, et qu'ils sont rédigés dans +un formalisme commun. Par exemple, nous avons agencé les différents modèles +de la dynamique temporelle du potentiel de la membrane neuronale en terme de +«finesse» de description dans la \textsc{Fig.}~\ref{fig:neuron-models-relation}; +ces modèles sont tous décrits à l'aide d'équations différentielles ordinaires, +déterministes, et décrivent des dynamiques dans le domaine continu. + +\begin{figure}[ht] + \centering +\begin{tikzpicture}[auto,% + arc/.style={-stealth, shorten >=2pt, semithick}, + model/.style={draw, rounded corners=2pt}] +\node[model] (HH) at (0,0) {Hodgkin-Huxley}; +\node[model] (IF) [above left=25pt and -20pt of HH] {Integrate-and-Fire}; +\node[model] (H) [above=of IF] {Hopfield}; +\node[model] (ML) [above right=28pt and -20pt of HH] {Morris-Lecar}; +\node[model] (CWM) [below left=of HH] {CWM}; +\node[model] (C85) [below=of HH] {Chay '85}; +\node[model] (C90) [below right=of HH] {Chay '90}; + +\node[model] (FN) [right=of ML] {FitzHugh-Nagumo}; +\node[model] (VDP) [above=of FN] {Van-Der-Pol}; +\node[model] (RH) [below=of FN] {Hindmarsh-Rose}; + +\node[model] (G) [left=of IF] {Golovasch}; +\node[model] (GGG) [above=of G] {GGG}; + +\node[model] (WC) [below=of G] {Wilson-Cowan}; +\node[model] (SLOM) [below=of WC] {SLOM}; + + +\draw[arc] (H) to node {\cite{abbott_model_1990}} (IF); +\draw[arc] (IF) to node[swap,pos=0.3] {\cite{abbott_model_1990,burkitt_review_2006}} (HH); +\draw[arc] (ML) to node[pos=0.3] {\cite{morris_voltage_1981}} (HH); +\draw[arc] (FN) to node {\cite{hindmarsh_model_1984}} (RH); +\draw[arc] (VDP) to node {\cite{fitzhugh_impulses_1961}} (FN); +\draw[arc] (WC) to node {\cite{stein_improved_1974}} (SLOM); +% Just looking at the equations and because in Stein +% they "follow Cowan's suggested formulation" +\draw[arc] (HH) to node[swap] {\cite{abarbanel_synchronisation_1996}} (CWM); +\draw[arc] (HH) to node {\cite{abarbanel_synchronisation_1996}} (C85); +\draw[arc] (HH) to node {\cite{abarbanel_synchronisation_1996}} (C90); +\draw[arc] (GGG) to node {\cite{golomb_reduction_1993}} (G); + +% subgraph clusterTimeDiscrete { +% Rulkov -> RoseHindmarsh % Hinted in Rulkov ("using the same approach") +% [style=dashed]; % Discrete -> Continuous (change in time) +\end{tikzpicture} +\caption{Revue de quelques modèles de neurones. Nous avons fait pointer + informellement les flèches vers les modèles ayant un «niveau de détail» plus + grand.} + \label{fig:neuron-models-relation} +\end{figure} + +Plusieurs champs de recherche s'intéressent aux relations entre modèles, chacun +ayant sa portée et ses limites. Nous donnons, dans la section suivante, une +courte présentation de quelques uns de ces domaines, ainsi qu'un bref aperçu des +résultats qu'ils apportent. + +\FloatBarrier +\section{Modélisation multi-niveau}\label{sec:multiniveau} +%% +La \emph{modélisation multi-niveau} est un terme que nous avons adopté pour +rendre compte des techniques de modélisation couplant plusieurs modèles pour +décrire un système. Dans ce contexte, un modèle propose d'observer le système +étudié à travers le prisme d'un point de vue particulier, appelé \emph{niveau de +description}. Le notion de \emph{niveau} met ici l'accent sur le fait que chaque +modèle peut ne s'intéresser qu'à une sous-partie du système (peu importe ce que +l'on entend par sous-partie ici) et propose donc une description incomplète du +système. C'est par le couplage entre les modèles que ces \emph{descriptions} +complémentaires se complètent mutuellement, pour finalement obtenir une +description plus pertinente du système dans son ensemble. +%% +Ainsi, la modélisation multi-niveau met en avant une méthodologie générique +pour l'élaboration d'un modèle par composition (d'autres modèles). Dans +cette section, nous nous intéressons à différents exemples de composition de +modèles pour en analyser les difficultés. Nous en concluons que la notion +d'\emph{identité} est au cœur de la modélisation multi-niveau. + +\subsection{Couplage de modèle} +%% + + +Dans cette section nous nous intéressons à deux exemples types de couplages de +modèles. +%% +Le premier exemple concerne la \emph{modélisation intégrative} du phénotype +d'une cellule biologique entière à partir des modélisations des différents +mécanismes moléculaires qui la composent. +%% +Le second exemple s'intéresse à la \emph{morphogénèse} d'une communauté de +villes à partir de modélisations orientées quartier. +%% +Dans ces deux exemples, des modèles élémentaires sont utilisés pour en conjuguer +les points de vue et obtenir une description plus complète du système. Dans les +deux cas également, un changement d'échelle s'opère, entre les considérations +micro(scopiques) des modèles élémentaires, et le niveau macro(scopique) du +système étudié. +% Chapeau: modèles ensembles sur le même pied d'égalité. 1) modélisation +% intégrative de cellule entière, 2) modélisation en géographie de la croissance +% des villes + +\subsubsection{Modélisation intégrative d'une cellule entière} +%% +En modélisation, l'approche \emph{intégrative} consiste à construire des modèles +en cherchant à expliquer \emph{simultanément} plusieurs phénomènes, permettant +de révéler des dynamiques n'apparaissant pas dans des approches indépendantes. +%% +Ces modèles sont construits par l'accumulation de modèles préexistants jugés +valides et par l'établissement d'un réseau de communication entre ces modèles, +voire la conception d'adaptateurs permettant de «traduire» la sortie d'un modèle +en l'entrée d'un autre. +%% +Cette approche est particulièrement développée dans le monde de la recherche +sur le vivant~\cite{grace_integrative_2016}, et permet des échanges prolifiques +entre les nombreuses disciplines de la biologie (généticiens, physiologistes, +comportementalistes, paléontologistes, écologistes, etc.) et donc entre les +nombreuses perspectives d'un même système qu'il est possible de récolter. + +De nombreux projets utilisent cette approche pour comprendre le fonctionnement +d'un organisme biologique complet, comme par exemple une cellule. À titre +d'exemple, un modèle computationel d'une cellule entière de \emph{Mycoplasma +genitalium} est proposé dans~\cite{karr_whole-cell_2012-1}. Ce modèle donne +l'expression complète du phénotype de la cellule à partir de son génome en +formulant des hypothèses sur de nouveaux mécanismes biologiques. +%% +L'approche de ce projet passe par le concept de \emph{modularité biologique} qui +permet de déterminer une liste d'observables du système dont les valeurs +correspondent à des états de la cellule. Plusieurs modèles permettent +d'expliquer séparément comment certaines observables sont liées entre elles. Une +fois ces modules établis, les modèles sont assemblés en suivant les relations +entre les observables, puis ajustés pour respecter les contraintes physiques et +biologiques du système dans son ensemble. + +Les solutions élaborées durant ce type de projet sont pour le moment \emph{ad +hoc} et la recherche de méthodes génériques pour rendre cette approche +utilisable pour la description d'autres systèmes biologiques est en cours. +%% +Le projet précédent a par exemple mis en lumière, dans une seconde +publication~\cite{macklin_future_2014}, une liste de sept limites à dépasser +pour généraliser leur approche intégrative à d'autres organismes. Parmi ces +points, les suivants, attireront plus particulièrement notre attention car ils +évoquent les limites des outils pour la modélisation intégrative:% + +\begin{description} + +\item[Agrégation des données] L'acquisition des données disponibles + dans la littérature a été compliquée par l'absence d'une source \emph{unifiée} + permettant de compiler l'ensemble des connaissances sur un sujet en + particulier, dans ce cas sur l'organisme étudié. La modélisation d'une + cellule entière bénéficierai grandement d'outils permettant d'agréger et de + \emph{normaliser} toutes les données nécessaires à la calibration des modèles; + +\item[Construction et intégration de modèles] Un facteur limitant a + été la disparité des types de modèles décrivant à différentes échelles + d'espace et de temps l'organisme. Unifier la modélisation intégrative + passerait donc par une \emph{généralisation} du concept de modèle à travers + un cadre mathématique commun à l'ensemble de la modélisation. Comprendre et + \emph{analyser} les relations entre modèles dépend de l'existence ce cadre + commun; + +\item[Calcul accéléré] La simulation numérique est un outil clef de la + réussite de ce projet. Chaque simulation de \emph{Mycoplasma genitalium} a été + très consommatrice en temps de calcul, ce qui est un facteur limitant pour la + réussite des projets futurs. Élaborer des modèles d'organismes plus complexes + dépendra donc fortement de la capacité des simulateurs à explorer une large + portion de l'espace des paramètres dans un temps plus restreint. Le calcul + général sur carte graphique, via un framework tel que CUDA ou OpenCL, est une + piste à explorer pour améliorer l'efficacité des simulateurs; + +\end{description} + +\subsubsection{Modélisation multi-échelle de la croissance des villes} +% DONE: Louail + +Les modèles à base d'agents sont souvent utilisés en géographie pour rendre +compte des dynamiques observables sur une carte: le système est étudié +à travers des effets de masse observés dans les populations d'agents. + +Le projet +SimPop~\cite{pumain_simpop:_1995}\footnote{\url{http://www.simpop.parisgeo.cnrs. +fr}}, illustre cette approche dès 1996 avec une collaboration entre géographes +et informaticiens aboutissant à Simpop1, le premier modèle géographique à base +d'agents s'intéressant à la construction de réseaux de villes et à la transition +urbaine. +%% +En 2006, l'évolution à la fois de la puissance de calcul des machines et de +l'expressivité des langages de programmation, permet le développement d'une +version améliorée, Simpop2~\cite{bretagnolle_theory_2006}. Ce nouveau simulateur +prend en compte de nombreuses \emph{fonctions urbaines} de différents types, +résidentielles, politiques, économiques, culturelles, liées au transport et +aux communications, sociales, etc. Le support de modélisation est un graphe +dynamique dont les nœuds sont les villes et dont l'évolution repose sur 4 +grandes étapes, à savoir la constitution d'un réseau d'échanges, d'un marché +d'échanges, d'un équilibrage de ces échanges et l'évaluation des changements. + +Le projet SimPop propose également d'autres modèles, tel que SimpopNano qui +prend le contre-pied des plateformes précédentes en se concentrant non seulement +sur les relations inter-urbaines mais intra-urbaines: les villes qui étaient +les agents deviennent les objets d'étude décrits comme des agrégations de +quartiers. +%% +SimpopNano s'intéresse en effet à l'évolution d'une ville, vue comme un graphe +statique dont les nœuds en sont les quartiers et où la dynamique est donnée à +travers neuf règles d'évolution locale, chacune correspondant à une fonction +urbaine. + +Le couplage entre Simpop2 et SimpopNano est un des enjeux du projet SimPop. +Simpop3, proposé dans~\cite{louail_comparer_2010}, est un simulateur de la +dynamique des villes répondant à cette problématique. +%% +Le couplage entre ces deux modèles est \emph{vertical} : il assemble trois +échelons d'une échelle d'espace géographique, à savoir quartier, ville et +système de villes, et exprime l'interdépendance entre les deux modèles:% +\begin{itemize} +\item le système de villes contraint la dynamique au niveau ville du système ; +\item rétroactivement, l'activité intra-urbaine influence les entrées du modèle + inter-urbain. +\end{itemize} +%% +La ville est donc le point d'articulation entre les deux modèles et constitue un +niveau de représentation intermédiaire, \emph{mésoscopique}. Le point essentiel +consiste à \emph{identifier} les agrégats de quartiers de SimpopNano et les +agents-villes de Simpop2. Nous reviendrons en fin de section sur cette notion +d'identité. + +En terme de dynamique, dans SimpopNano, les villes sont construites à partir +des quartiers et sont mises à jour à chaque pas de la simulation. Dans Simpop2, +les agents-villes sont à l'origine de la dynamique d'un système de villes. Le +couplage se fait simplement car la concurrence sur la ressource agent-ville +n'est pas prise en compte, ce qui autorise une indépendance entre les modèles. +Ainsi, au cours d'une simulation de Simpop3, les deux sous-modèles sont juste +appelés alternativement. + + + +\subsection{Transformation de modèles}\label{sec:modeltrans} + +Dans la section précédente, la modélisation multi-niveau était synonyme de +modélisation multi-échelle, avec un rapport entre un niveau macro et un niveau +micro. +%% +Dans cette section, les modèles entretiennent un rapport différent: les modèles +décrivent les mêmes objets, mais le niveau de granularité entre ces descriptions +varie. +%% +L'opération fondamentale de ces approches est le passage d'un niveau de +granularité à un autre niveau de granularité par une \emph{transformation de +modèles}. Les deux paragraphes suivants illustrent cette approche. +% Chapeau: multi-niveau veut dire multi-échelle (micro-macro) dans la section +% précédente, MAIS ici, multi-niveau veut dire granularité, raffinement + +\subsubsection{Ingénierie des modèles} + +%% +%% à ne pas citer : https://tel.archives-ouvertes.fr/tel-00916856/document +%% +%% à citer : Anneke KLEPPE, Jos WARMERet Wim BAST:MDA Explained. The Model Driven Architec-ture : Practice and Promise. Addison-Wesley, 2003. Cité pages 6 et 8. +%% +%% + +Dans le domaine de l'informatique et de la conception logicielle, +l'\emph{ingénierie des modèles} (\emph{model-driven engineering} +% Remarque de Olivier: enlève cette ref qui fait pédant :) +%\footnote{À +%ne pas confondre avec le \emph{Model Engineering} qui était, au XIX\ieme{} +%siècle, une discipline dont le but était la construction de représentations +%miniatures proportionnellement mises à l'échelle de machines, comme des +%moteurs, des locomotives à vapeur, des horloges, etc.} +en anglais) est une méthodologie de développement se concentrant sur la partie +métier du logiciel, c'est-à-dire ce qui dans un logiciel fait abstraction de +l'implémentation. L'objectif de cette discipline est l'automatisation de la +conception logicielle à partir d'une représentation abstraite pouvant ensuite +être \emph{transformée} en des représentations de plus en plus concrètes +jusqu'au logiciel final. L'ingénierie des modèles part du principe qu'un +domaine d'application est plus fortement dépendant d'une représentation +abstraite des connaissances et des activités liées à ce domaine, que des +concepts algorithmiques et des techniques nécessaires à la mise en œuvre d'une +implémentation. Par exemple, pour un problème donné, il existe plusieurs +logiciels répondant à ce problème, implémentés de façons différentes: il existe +bien \emph{quelque chose} d'unique et de plus abstrait qu'un logiciel qui est +propre à la fois au problème et à la solution. + +Considérant les modèles comme des objets de première classe, l'ingénierie des +modèles cherche à développer, maintenir et faire évoluer un logiciel au moyen +de \emph{transformations} : des fonctions d'ordre supérieur prenant des modèles +en argument. Ces fonctions sont implémentables et exécutables afin que les +transformations de modèles soient des procédures automatiques. +%% +Ce type de procédure est fréquent en informatique. La compilation est un exemple +historique de transformation de modèles, où l'on entend ici les langages de +programmation comme des « modèles de code source »: compiler consiste à définir +des transformations de code source à code source. Le langage diagrammatique +d'\emph{Unified Modeling Language} (UML~\cite{UML}), qui permet d'exprimer +des modèles de conception, est un candidat classique à la transformation de +modèles. Dans ce contexte, les transformations se présentent comme des règles +de réécriture de graphe (voir~\cite{taentzer_model_2005} pour une étude sur les +transformations de graphes appliquées aux transformations de modèles). + +Pour notre approche multi-niveau, l'ingénierie des modèles nous apporte deux +éléments importants. +%% +Le premier élément provient de la définition même de modèle, qui y est vu +comme la description d'un système spécifiée dans un \emph{langage bien +défini}~\cite{kleppe_mda_2003}. Le langage de description est si important +qu'il est souvent lui-même décrit comme un modèle; on parlera alors de +\emph{méta-modèle}. On rapprochera ce langage de description de la notion de +\emph{formalisme}. +%% +Le second élément provient des transformations de modèles dont une taxonomie est +donnée dans~\cite{mens_taxonomy_2006}. +On retiendra notamment les catégories suivantes: +% +\begin{description} + +%% \item Syntaxique \emph{vs.} sémantique: + +\item[Transformation endogène \emph{vs.} transformation exogène:] une +transformation est exogène lorsque le langage de description du modèle cible est +différent du modèle de description du langage source. + +\item[Transformation horizontale \emph{vs.} transformation verticale:] nous +retrouvons ici la notion de granularité mentionnée plus haut; lors d'une +transformation verticale le niveau d'abstraction entre le modèle source et le +modèle cible est modifié. La notion d'abstraction jouera un rôle important dans +notre proposition. + +\end{description} +% + + +\subsubsection{Raffinement de modèles}\label{sec:raffinement} + +Bien que la description précédente de l'ingénierie des modèles soit orientée +informatique, les mêmes considérations se retrouvent dans d'autres disciplines. +%% +Par exemple, une méthodologie classique de la modélisation à base d'équations +différentielles de systèmes (bio)chimiques consiste à élaborer un modèle simple +à partir d'un ensemble initial d'espèces et de réactions, puis de l'enrichir +soit avec de nouvelles espèces (on parlera de \emph{raffinement des données}), +soit avec de nouvelles réactions (on parlera de \emph{raffinement des + processus}). +%% +À chaque itération, un nouveau modèle est établi puis ajusté pour prendre en +compte les observations du système. +%% +Le processus de raffinement à l'œuvre génère ainsi une suite de modèles ordonnés +du moins détaillé au plus détaillé. +%% +La preuve de raffinement entre deux modèles peut se faire de façon classique ou +bien via un outil spécialisé comme le langage Z~\cite{stepney_more_1998}. + +Une des difficultés du raffinement de modèles se situe dans l'ajustement +des modèles construits. Une méthode systématique a été développée pour +dériver à partir d'un modèle établi et préalablement ajusté, un modèle +raffiné préservant l'ajustement. Cette méthode ne se limite pas aux +systèmes d'équations différentielles mais couvre également le champ des +réseaux de Petri, des systèmes réactifs et des langages à commandes +gardées~\cite{gratie_quantitative_2013}. + + + +\subsection{Complexification}\label{sec:complexification} +% DONE: Chapeau sur les systèmes complexes + +La modélisation des systèmes complexes constitue l'un des enjeux +principaux de l'approche multi-niveau que nous souhaitons développer. +L'Institut des Systèmes Complexes (\ISC), une structure française +pluridisciplinaire de recherche spécialisée sur le sujet, en donne, +dans sa proposition de DIM «Approches interdisciplinaires des systèmes +complexes»\footnote{Document disponible en ligne à l'adresse \url{ +https://iscpif.fr/wp-content/uploads/2016/09/PreProjetDim2017.pdf}}, la +définition suivante: +% - Def ISC, présentation non naïve +\begin{quote} + Les systèmes complexes sont des systèmes présentant un grand nombre d’entités + différenciées, dont la multitude des interactions locales conduisent à + l’émergence de propriétés globales difficilement prédictible par la seule + connaissance des propriétés de ces entités. Le niveau local fait ainsi émerger + des formes organisées au niveau global, lequel influence en retour le niveau + local (immergence). Interactions locales et structures globales peuvent ainsi + se conjuguer dans la description des dynamiques des systèmes complexes. +\end{quote} +% +Cette définition n'est pas sans rappeler les exemples de couplage de modèles que +nous avons vu plus haut, qui entrent en effet dans le cadre des systèmes +complexes. + +Dans cette section, notre intérêt ne se portera pas sur la modélisation des +systèmes complexes dans toute sa généralité, mais plus particulièrement sur le +concept de \emph{complexification}, c'est-à-dire sur la façon de capturer dans +ces modèles les «phénomènes émergents» et sur comment les réifier au niveau +local afin qu'ils deviennent des acteurs de leur propre dynamique. +%% +Nous présentons pour cela la complexité à travers 3 points de vue théoriques. +%% +Le premier exemple montre la difficulté d'appréhender la complexité à cause d'un +manque de vocabulaire au niveau bas de description. +%% +Le deuxième exemple attribue la complexité à une cause énergétique par le +phénomène d'\emph{activité locale}. +%% +Finalement, dans un dernier exemple, le processus de complexification est +analysé d'un point de vue structurel par l'établissement d'un modèle formel +connexionniste. + + + + + +\subsubsection{Raffinement et émergence} +% DONE: fix la description qui est naze… On veut exprimer le fait que raffiner +% des propriétés émergentes pose un problème aux gens qui font du raffinement, +% pourquoi et comment ils tentent de résoudre la question. + +En 2005, F. Polack et S. Stepney~\cite{polack_emergent_2005} présentent une +approche de la complexité en rapport avec le raffinement de modèles, que nous +avons présenté dans la section~\ref{sec:raffinement}. L'idée centrale de leur +approche est qu'une propriété d'un modèle est émergente s'il n'est pas possible +de l'obtenir par un raffinement naïf, c'est à dire par une unique relation de +raffinement. Dans cet article, les auteurs prennent pour exemple le raffinement +d'une propriété considéré comme émergente, volontairement simple et observable +dans le fonctionnement d'un automate cellulaire en deux dimensions, pour +mettre en évidence les difficultés que posent le raffinement d'un comportement +émergent. +%% +Nous présentons la démarche de raffinement simplifiée pour lier une propriété +donnée au composants bas niveau d'un système formel, dans notre cas ce système +est un automate cellulaire en deux dimensions muni des lois d'évolution du «jeu +de la vie». Elle repose habituellement sur les 3 étapes suivantes: +\begin{enumerate} +\item Exprimer la propriété dans un formalisme; +\item Exprimer l'automate cellulaire dans un formalisme (potentiellement + différent du précédent); +\item Exprimer la relation entre les deux formalismes, prouvant ainsi que la + propriété est exprimable dans le contexte des automates cellulaires. +\end{enumerate} +%% +Posséder un \emph{glider}~\cite{gardner_mathematical_1970} est une propriété +connue pour être émergente, aussi il serait intéressant de déterminer +comment la raffiner. Elle est initialement spécifiée informellement par: +\begin{quote} + Le système doit présenter une région, traversée par un motif répété, appelé + «glider». Lorsque deux gliders se rencontrent, il en résulte un unique glider + qui se déplace dans la direction d'un des deux gliders incidents. +\end{quote} +%% +Cette propriété est précise, cependant elle reste non déterministe. Tentons +de la raffiner: nous prendrons naturellement les automates cellulaires comme +support cible, car notre objectif est d'identifier les composants bas niveau +responsables de ce comportement. +%% +Un glider se définit par la fenêtre qu'il traverse et un vecteur de déplacement. +Il est aussi nécessaire de décrire la collision de deux gliders et le résultat +de cette collision. Pour spécifier un automate cellulaire, nous formalisons +d'abord sa cellule, son état, sa fonction de transition et son voisinage. +Ensuite, nous choisissons une représentation formelle d'une collection de +ses cellules et de l'application synchrone des fonctions de transitions, +habituellement appelées fonctions de transition locales (pour une définition +complète, voir page \pageref{def:ca}). + +Pour poursuivre la procédure, une sous-division discrète de la fenêtre traversée +par le glider est introduite, par exemple sous la forme d'une grille $4 \times +4$. Le premier problème qui se pose est que le raffinement de la spécification +informelle est plus précise que la spécification originale, ce qui est voulu, +mais également plus précise que la représentation ciblée. Dans le cas d'un +raffinement classique, au contraire, le raffinement d'une propriété de haut +niveau amène à un niveau d'abstraction intermédiaire, c'est-à-dire entre la +spécification d'origine et la spécification cible. +% +\begin{figure}[t] + \centering + \includegraphics[page=1,height=2cm]{ca-glider} + \includegraphics[page=2,height=2cm]{ca-glider} + \includegraphics[page=3,height=2cm]{ca-glider} + \includegraphics[page=4,height=2cm]{ca-glider} + \includegraphics[page=5,height=2cm]{ca-glider} + \caption{Les cinq configurations possibles d'un glider contenues dans une + fenêtre de $4 \times 4$ cellules.} + \label{fig:ca-glider} +\end{figure} +% +Lors de la mise en œuvre du raffinement des \emph{données} de la spécification +d'un glider, à savoir «fenêtre» et «glider», il apparaît qu'il n'est pas +possible de décrire un glider par un unique état spatial: un glider est en +fait constitué d'une succession des cinq configurations présentées dans la +\textsc{Fig.}~\ref{fig:ca-glider}. De plus, la configuration initiale de +l'automate est importante: elle doit exactement correspondre à une de ces cinq +configurations possibles. +%% +Ensuite, lors de la spécification des \emph{opérations} du glider, à savoir +«déplacement», «collision» et «résolution», il est déjà difficile d'exprimer ces +opérations sur une grille. Pour le déplacement par exemple, la fenêtre pourrait +se déplacer sur une grille extérieure, dans une direction une fois tous les +quatre pas des états du glider \emph{dans la fenêtre}, ne pas bouger ou bien +faire un pas dans la direction orthogonale. Les opérations de collision et de +résolution sont tout aussi difficiles à décrire. +% DONE: \emph{Pour que ce soit pertinent, il faut pas que se soit difficile mais +% impossible, sinon ça perd son sens. Comme je ne pense pas que ce soit +% impossible si on prépare bien le terrain dans le formalisme lié au système, il +% doit y a voir un élément qui n'est pas transcrit ici.}% +% >>> Ça n'est pas impossible, effectivement. Par contre les auteurs considèrent +% comme quasi-impossible le raffinement par une unique relation de raffinement. + +Nous constatons qu'il est difficile d'exprimer la relation de raffinement de la +propriété «posséder un glider» dans des termes propres aux automates cellulaires +en deux dimension en une étape. De plus, cette relation ne sera manifestement +pas unique. +%% +Les difficultés à rendre concrète une propriété témoigne de son caractère +émergent: elle est observable mais n'est pas concrètement implémentée dans le +système. L'idée centrale de~\cite{polack_emergent_2005} est la suivante: il +existe une incompatibilité entre les langages de description qui (1) rend la +spécification concrète des gliders difficiles et (2) empêche toute élaboration +directe d'une preuve de raffinement avec le vocabulaire des automates. Cette +caractéristique est propre aux systèmes possédant des propriétés émergentes. +%DONE:Compléter la description de la deuxième partie ou la supprimer + +% se déplacer, entrer en collision et résoudre la collision. Et c'est ici que le +% raffinement classique «casse»: il n'y a aucun moyen d'exprimer la +% spécification en terme d'automate cellulaire, du moins pas directement. Les +% langages utilisés, le premier pour exprimer le système abstrait (émergent) et +% le système concret, sont incompatibles. Il est peut-être possible de raffiner +% ces deux systèmes vers une représentation intermédiaire, cette dernière +% pouvant être raffinée vers le système concret. + + + + + + +\subsubsection{Complexification dans les \cnn} +% L'activité du point de vue énergétique. L'activité locale n'explique pas +% vraiment les systèmes complexes comme les nuées d'oiseaux, ou bien +% l'auto-organisation d'une fourmillière +L. Chua a introduit en 1998 le concept d'\emph{activité locale} (\emph{local +activity})~\cite{mainzer_local_2013}. Ce concept est décrit comme le maillon +manquant permettant d'expliquer l'apparition de motifs complexes dans un médium +homogène. +%% +L'activité locale, définie initialement dans le cadre des circuits +électroniques~\cite{chua_cnn:_1997}, caractérise la propriété +d'auto-organisation, c'est à dire la capacité d'un système à posséder une +dynamique qui lui est propre, à travers une construction mathématique explicite. +La définition a été par la suite généralisée à la classe plus larges des +systèmes de réaction-diffusion non linéaires utilisés en physique, en chimie, en +biologie et dans le cadre de la recherche sur le cerveau. +%% +L'activité locale permet d'expliquer la brisure de symétrie dans un médium +homogène. Dans les paragraphes suivants, nous présentons de manière succincte +quelques définitions proposées par les auteurs pour l'activité locale, la +complexité et le seuil du chaos (\emph{edge of chaos}). + +%DONE: refaire la figure avec tikz +\begin{figure}[ht] + \centering + \includegraphics[page=1,width=.48\textwidth]{cnn-synapses}\hfill + \includegraphics[page=2,width=.48\textwidth]{cnn-synapses} + \caption[Schéma des synapses des cellules d'un CNN]{Connexion des synapses + pour le signal de contrôle (à gauche) et pour le signal de rétroaction (à + droite) pour la cellule au centre, entourée de huit voisines (cette + illustration est inspirée de~\cite{chua_cnn:_1997})} + \label{fig:cnn-synapses} +\end{figure} + +L'activité locale est à l'origine définie dans le cadre des réseaux non +linéaires de cellules (\cnn pour \emph{Cellular Non-linear Networks}). +Un \cnn est un modèle formel constitué d'une grille orthogonale en trois +dimensions sur les nœuds de laquelle est disposée une collection de systèmes +dynamiques continus et non linéaires. Chaque cellule isolée d'un \cnn est +décrite par quatre paramètres: son entrée, son état, son seuil et sa sortie. +Les cellules du \cnn sont alors couplées à leurs voisines inclues dans +une sphère d'influence prédéfinie avec un certain rayon. Pour une cellule +donnée, son entrée est la somme pondérée des sorties de ses voisines (signal +de rétroaction) \emph{et} la somme pondérée des entrées de ses voisines +(signal de contrôle). Une représentation graphique est donnée dans la +\textsc{Fig.}~\ref{fig:cnn-synapses}. + +L'état d'une cellule est définie par un système d'équations de +réaction-diffusion. Il est notamment caractérisé par deux variables +vectorielles\footnote{Nous utilisons ici les notations + de~\cite{mainzer_local_2013}.}: +\begin{itemize} + +\item $\mathbf{V}_a$, une fonction continue du temps, homogène à une tension et +représentant l'état interne de la cellule; + +\item $\mathbf{I}_a$, une fonction continue du temps, homogène à une intensité +et représentant l'entrée de la cellule. + +\end{itemize} +%% +L'activité locale s'intéresse aux fluctuations d'énergie induites par +des variations de l'entrée d'une cellule initialement placée en un point +d'équilibre. +%DONE: (I + i).(V + v) = I.V + I.v + V.i + i.v ??? p 284 -- linéarisation +%WONTFIX +En notant $\mathbf{v}_a$ et $\mathbf{i}_a$ les variations respectives de +$\mathbf{V}_a$ et $\mathbf{I}_a$, la fluctuation d'énergie entre l'instant +initial et un instant $T < \infty$, est donnée par: +\begin{equation} + w(T) = \int_0^T \mathbf{v}_a(t).\mathbf{i}_a(t).dt +\end{equation} +%% +On dira qu'une cellule est \emph{localement active} à l'instant $T$ si et +seulement si $w(T) < 0$. En effet, en supposant nulle l'énergie de la cellule à +$t=0$, une énergie stockée strictement négative à $t=T$ signifie que la cellule +a \emph{apporté} de l'énergie au système. Une cellule active agit comme une +source de puissance en amplifiant un signal faible. +%% +Par exemple, un transistor muni d'une batterie dans un circuit, ou bien un +neurone muni d'une réserve de glucose dans un réseau, sont des éléments actifs; +batterie et glucose jouent le rôle d'une réserve d'énergie disponible que la +cellule peut utiliser ou distribuer. + +La complexité est finalement caractérisée comme la présence d'un motif (statique +et non homogène, ou spatio-temporel) dans un médium (discret ou continu) +constitué de cellules identiques interagissant avec leurs cellules voisines +(sphère d'influence), obéissant aux mêmes lois d'interaction, et avec des +conditions initiales et de bord homogènes. On peut alors montrer qu'un médium +de \emph{réaction-diffusion} présente de la complexité si, et seulement si, il +existe des cellules localement actives dans ce médium. + +Bien qu'aucun vocabulaire ne soit disponible au niveau des cellules pour en +parler directement, ce travail montre comment des motifs peuvent être +représentés par l'ensemble des cellules localement actives. Il s'agit bien là +d'un exemple de complexification à rapprocher fortement des considérations +développées chapitre~\ref{chap:partie-activite} sur l'identification des zones +actives dans les modélisations \mgs. + +Une question reste néanmoins en suspens: lorsque les motifs ont des propriétés +spatio-temporelles, l'ensemble des cellules localement actives peut varier en +fonction du temps, amenant à la problématique du suivi des motifs malgré un +support fluctuant. Les travaux d'A. Ehresmann, que nous introduisons dans la +section suivante, proposent une réponse à cette question. + + + + + + + +\subsubsection{Complexification structurelle}\label{sec:ehresmann} +% DONE: C'est moche de dire à la, faut changer les titres +% DONE: Mettre à jour les figures avec les nouvelles notations +% DONE: Jolifier les itemize: moins de marges, plus d'interstice, points plus +% gros + +Nous tâchons ici de présenter, sans entrer dans les détails, le \emph{processus + de complexification} introduit par A. Ehresmann et J.-P. +Vanbermeersch~\cite{ehresmann_mens:_2012}. +%% +Leurs travaux s'intéressent à l'utilisation des \emph{systèmes évolutifs à + mémoire} pour la modélisation du vivant, et plus particulièrement de la +complexité. L'approche cherche à être la plus générale possible et repose sur +une formalisation catégorique des systèmes dynamiques. + +Pour plus de clarté, nous nous concentrons ici sur le concept de \emph{Memory +Evolutive Neural System} (\mens), une des applications de la méthodologie +proposée à la modélisation des interactions neuronales. L'objectif de cette +construction est de fournir des arguments en faveur de l'émergence des fonctions +cognitives depuis les interactions neuronales, allant jusqu'aux concepts de +conscience, de pensée et d'intention. Nous ne nous intéresserons ici qu'au +processus de complexification. + +Un réseau de neurones est représenté par un graphe $\text{Neur}_t$ dont +les nœuds, notés $N(t)$, sont des neurones et dont les arcs (orientés), +notés $S(t)$, décrivent les liens entre les neurones. Chaque lien est +pondéré par un délai de propagation. Le graphe est nécessairement fermé +transitivement: étant donnés trois neurones $n_1,n_2,n_3 \in N(t)$, si +les arcs $(n_1,n_2)$ et $(n_2,n_3)$ existent, l'arc $(n_1,n_3)$ existent +également. Un réseau est un objet dynamique et s'inscrit donc dans le temps +(représenté par l'indice $t$). Au cours de son évolution, des nœuds peuvent +apparaître ou disparaître, entraînant l'apparition ou la disparition d'arcs. +L'ensemble des réseaux $\text{Neur}_t$ forme une collection $\text{Neur}$ (voir +\textsc{Fig.}~\ref{fig:ce-neur}) munie d'une fonction de \emph{transition} $k$ +qui, pour chaque couple d'instants $t < t'$, relie les nœuds de $N(t)$ à ceux +de $N(t')$ et les arcs de $S(t)$ à ceux de $S(t')$ en préservant l'incidence, +propriété assurée par la fonctorialité de $k$ (la définition d'un foncteur est +donnée définition~\ref{def:foncteur}), et en vérifiant la transitivité suivante +(présentée ici sur les nœuds uniquement): pour trois instants $t < t' < t''$ et +trois nœuds $(n_1,n_2,n_3)\in N(t) \times N(t') \times N(t'')$: + +\begin{itemize} +\item si $n_2$ est l'image de $n_1$ par $k_{t \rightarrow t'}$ et $n_3$ est + l'image de $n_2$ par $k_{t' \rightarrow t''}$, alors $n_3$ est l'image de + $n_1$ par $k_{t \rightarrow t''}$; et + +\item si $n_2$ est l'image de $n_1$ par $k_{t \rightarrow t'}$ et $n_3$ est + l'image de $n_1$ par $k_{t \rightarrow t''}$, alors $n_3$ est l'image de $n_2$ + par $k_{t' \rightarrow t''}$. +\end{itemize} + +%0. (v) Neur, le réseau des neurones +\begin{figure}[p] + \centering + \includegraphics[page=1,width=.75\textwidth]{complexification-ehresmann} + \caption{$\text{Neur}$ propose un point de vue dynamique sur un réseau + de neurones. À chaque instant $t$, l'état du réseau est vu comme un graphe + $\text{Neur}_t$.} + \label{fig:ce-neur} +\end{figure} + +%1. (v) Neurone catégoriel ou Cat-neurone +\begin{figure}[p] + \centering + \includegraphics[page=2,width=.25\textwidth]{complexification-ehresmann} + \caption{Le cat-neurone $N$ est un neurone abstrait ayant le même + comportement fonctionnel que les neurones de la famille $P$.} + \label{fig:ce-catneur} +\end{figure} + +%2. (v) Cat-neurones: Liens simples + Bascule complexe (complex switch) +\begin{figure}[p] + \centering + \qquad + \includegraphics[page=4,width=.5\textwidth]{complexification-ehresmann} + \hfill + \includegraphics[page=3,width=.35\textwidth]{complexification-ehresmann} + \qquad + \caption{ + À gauche, un lien simple: si $P$ et $P'$ forment un cluster, symbolisé par + une bande grise, alors il existe un lien simple entre $N$, le binding de + $P$et $N'$ le binding de $P'$. % + À droite, une bascule complexe: un cat-neurone peut être fonctionnellement + équivalent à plusieurs familles de neurones.} + \label{fig:ce-simplelink-complexswitch} +\end{figure} + +%3. (v) Cat-neurones: l'apparition de liens complexes +\begin{figure}[p] + \centering + \includegraphics[page=5,width=.75\textwidth]{complexification-ehresmann} + \caption{Un lien complexe est la composition de deux liens + simples à travers une bascule complexe.} + \label{fig:ce-complexlink} +\end{figure} + + +Le processus de complexification est compris dans ce contexte comme la +reconnaissance d'un comportement synchronisé, en prenant en compte les délais +de communication imposés par les arcs du réseau, d'un groupe de neurones +agissant collectivement sur d'autres neurones. Le point important de cette +complexification est que ce comportement collectif peut lui-même être représenté +par un neurone $n$. +%% +Ainsi, lorsqu'une famille $P$ de neurones agit collectivement avec un neurone +$n'$ du réseau, cette action peut être représentée par un lien unique $s$ entre +$n$ et $n'$. Le lien $s$ joue un rôle totalement équivalent à la somme des liens +des neurones de $P$ vers $n'$ (voir \textsc{Fig.}~\ref{fig:ce-catneur}). +%% +Formellement, $n$ correspond à une colimite du diagramme défini par $P$, +appelée \emph{binding} dans ce contexte. Le cas intéressant apparaît lorsque le +\emph{binding} n'existe pas, c'est-à-dire lorsqu'aucun neurone de $\text{Neur}$ +ne représente de façon élémentaire le comportement collectif. On propose +alors d'enrichir le système initial $\text{Neur}$ avec ces nouveaux neurones +abstraits, appelés \emph{cat-neurones}, et correspondant aux \emph{bindings} +manquants. +%% +Une hiérarchie de complexification peut alors être mise en place: les neurones +de $\text{Neur}$ sont des \emph{cat-neurones} de niveau 0, alors que les +\emph{bindings} manquants sont des cat-neurones de niveau 1. Le processus peut +être itéré pour obtenir des cat-neurones de niveau $l$ à partir des cat-neurones +de niveau $l-1$. + +En plus d'être capable de réifier les comportements «émergents» en tant +qu'objets de base, ici des neurones, le modèle permet également le suivi au +cours du temps de ces comportements. +%% +Ce suivi repose sur deux notions: + +\begin{enumerate} + +\item \emph{Lien simple}: un lien simple permet d'associer l'évolution d'un + cat-neurone à l'évolution de la famille qui l'engendre. + % + Soient $P$ et $P'$ deux familles de neurones. Un \emph{cluster} entre $P$ et + $P'$ est une famille maximale de liens entre les neurones de $P$ et ceux de + $P'$ représentant l'évolution des neurones de $P$ en neurones de $P'$ (nous ne + rentrerons pas plus dans les détails techniques). Si $P$ et $P'$ admettent $n$ + et $n'$ comme \emph{bindings} respectifs, le \emph{cluster} admet également + une colimite sous la forme d'un lien entre $n$ et $n'$, appelé \emph{lien + simple}. Ce lien représente l'évolution de $n$ en $n'$ (voir + \textsc{Fig.}~\ref{fig:ce-simplelink-complexswitch} à gauche). + +\item \emph{Bascule complexe}: un lien simple ne permet pas à lui seul le suivi + d'un cat-neurone car la famille $P$ peut disparaître au cours de son + évolution. Cependant, d'autres familles que $P$ peuvent engendrer le même + cat-neurone. + %% + On dira que deux familles de neurones $P$ et $P'$ forment une \emph{bascule + complexe} lorsque $P$ et $P'$ engendrent le même \emph{binding} (voir + \textsc{Fig.}~\ref{fig:ce-simplelink-complexswitch} à droite). + +\end{enumerate} +%% +On trouvera \textsc{Fig.}~\ref{fig:ce-complexlink} une illustration de la notion +de \emph{lien complexe} montrant comment combiner \emph{lien simple} et +\emph{bascule complexe} pour déterminer l'évolution d'un cat-neurone malgré la +structure dynamique du réseau. + + + +\subsection{Bilan} + +L'ensemble des travaux présentés ci-dessus nous amènent à considérer qu'un outil +de modélisation devrait regrouper les propriétés suivantes: +% +\begin{description} + +\item[Cadre unifié:] Les conclusions de~\cite{macklin_future_2014} sur leur + expérience de multi-modélisation d'une cellule entière de \emph{Mycoplasma + genitalium} montrent qu'une uniformisation des descriptions est nécessaire + pour produire un outil adapté à l'intégration de données provenant de sources + multiples. + %% + Les différents points de vue pris sur un même objet, voire la disparité des + systèmes étudiés, impliquent une indépendance de l'outil par rapport aux + modèles pour permettre l'\emph{identification} des concepts partagés. Un + cadre unifiant et générique doit donc être développé de façon agnostique + vis-à-vis des sujets d'étude. + +\item[Cadre formel:] L'analyse d'un modèle, allant de la simple simulation à + des techniques mathématiquement plus complexes (\emph{model checking}, analyse + abstraite, etc.), repose sur une description précise des modèles. Pour cela, + les modèles sont souvent décrits dans un cadre mathématique spécifique, appelé + \emph{formalisme}, dont la frontière permet d'assurer l'applicabilité des + techniques d'analyse. + + Au-delà des facilités mathématiques offertes par les formalismes, un grand + nombre d'approches utilisent de façon formelle les propriétés «syntaxiques» + des spécifications des modèles afin de les manipuler. Les transformations de + modèles illustrent parfaitement cette dépendance à la description des modèles. + Les preuves de raffinement imposent que le modèle transformé traduise + effectivement les éléments du modèle d'origine. + + La prise en compte de plusieurs formalismes va néanmoins à l'encontre du + caractère unifiant que nous impose le point précédent. Trouver un + sur-formalisme unique à un ensemble de formalismes classiques amène + nécessairement à lever les frontières qui faisaient des approches classiques + leur intérêt: plus un formalisme est général, moins il pourra nous apprendre + sur les modèles étudiés. Il est donc primordial de trouver un point + d'équilibre entre ces deux premiers points. + +\item[Sémantique:] Un modèle ne se résume pas à une spécification mathématique + décrite dans un formalisme donné. En effet, si tel était le cas, un modèle se + réduirait à un objet symbolique vide de relations au système qu'il décrit. Sa + relation avec l'objet d'étude passe par une sémantique, c'est-à-dire, par une + structure supplémentaire décrivant l'interprétation des symboles. + + La sémantique joue un rôle déterminant dans la compréhension et la + manipulation des modèles. Par exemple, le couplage de modèles repose + essentiellement sur l'\emph{identification} de concepts communs traités + différemment par les modèles. Une telle sémantique agit comme un moteur du + couplage: elle permet d'\emph{identifier} au sein de leurs spécifications les + éléments en relation avec les mêmes concepts. Un projet tel que l'intégration + dans un seul modèle de résultats scientifiques indépendants profiterait d'une + description homogène faisant référence à une ontologie partagée, c'est-à-dire + une base de concepts communs. + % L'établissement d'une ontologie est une problématique en soi. + % En effet, une ontologie n'est pas une simple collection de concepts mais + % également des relations entre ces concepts. + % Il va sans dire que les modèles eux-mêmes peuvent être utilisés pour établir + % ces relations; l'ontologie devient alors le support de la modélisation + +\item[Abstraction:] Comme le montrent les techniques de raffinement, il est + naturel d'élaborer un modèle à partir d'une spécification grossière qui sera + incrémentalement transformée vers une forme plus dense prenant en compte des + aspects de plus en plus précis du système étudié. Si un modèle est vu comme + une abstraction d'un système, ce type de construction consiste à passer + d'une description abstraite vers une autre plus concrète, en respectant + la sémantique, dont l'objectif est de s'approcher à la limite du système + lui-même. + + Les travaux cités précédemment nous laissent penser que ce mécanisme est à la + base de toute modélisation. À titre d'exemple, le couplage de modèles peut + être vu comme une forme d'utilisation de l'abstraction: le modèle obtenu par + couplage peut être vu comme le raffinement le plus abstrait obtenu en + combinant les modèles initiaux. Ainsi, Simpop3 est à la fois un raffinement de + Simpop2 et un raffinement de SimpopNano. + +\item[Multi-niveau:] La problématique de la complexification, notamment à + travers les travaux de S. Stepney, montre que l'abstraction n'est pas une + opération suffisante pour parler des propriétés émergentes. La difficulté + vient essentiellement du manque de vocabulaire disponible à certains + niveaux de description pour exprimer des concepts présents de façon + élémentaire à d'autres niveaux, bien qu'il soit possible de les caractériser + qualitativement. La modélisation multi-niveau a pour objectif de mettre en + avant cette possibilité d'\emph{identifier} les entités de base d'un niveau + comme étant des propriétés observées à un autre niveau. Les travaux de A. + Ehresmann et L. Chua proposent d'\emph{identifier} cette fois une propriété + émergente à travers le comportement corrélé d'entités, par l'activation + commune d'un même cat-neurone dans le premier cas ou par la mesure de + l'activité d'une cellule dans le second. Les entités du niveau inférieur + enrichissent le niveau supérieur, mais ne le définissent pas entièrement. Un + cat-neurone ou une cellule localement active a la capacité d'influer en retour + sur le niveau inférieur et c'est l'association de ces deux mécanismes qui + détermine les entités des niveaux supérieurs. + +\end{description} + + + + + +\paragraph{Le Bateau de Thésée.}% + +Les propriétés précédentes reposent fondamentalement sur différentes formes +d'identification, que ce soit entre les symboles d'un modèle et les concepts +sémantiques associés, les relations entre un modèle abstrait et son raffinement, +ou encore durant un processus de complexification. +%% +Cependant, l'identité est une notion polysémique riche dont les différentes +compréhensions peuvent aider à préciser certaines problématiques rencontrées en +modélisation. + +Pour mettre en avant la profondeur du concept d'identité, le paradoxe du bateau +de Thésée est souvent employé. Plutarque, dans l'ouvrage «La vie de Thésée» +(traduit par D. Ricard~\cite{ricard_vie_1858}), fait état de la conservation de +son bateau par les athéniens après la mort de Thésée: +\begin{quote} + Le vaisseau sur lequel Thésée s'était embarqué avec les autres jeunes gens, et + qu'il ramena heureusement à Athènes, était une galère à trente rames, que les + Athéniens conservèrent jusqu'au temps de Démétrios de Phalère. Ils en ôtaient + les vieilles pièces, à mesure qu'elles se gâtaient, et les remplaçaient par + des neuves qu'ils joignaient solidement aux anciennes. Aussi les philosophes, + en disputant sur ce genre de sophisme qu'ils appellent croissant, citent ce + vaisseau comme un exemple de doute, et soutiennent les uns que c'était + toujours le même, les autres que c'était un vaisseau différent. +\end{quote} + +La question est donc de déterminer si le bateau de Thésée, malgré sa +conservation et son entretien par les athéniens, garde son identité une fois que +toutes ses parties ont été remplacées. De plus, si lors des réparations chaque +pièce remplacée était utilisée pour reconstruire un bateau complet, ce dernier +serait-il le bateau de Thésée ? + +Ces questions autour de l'identité qui hantent les philosophes depuis +l'antiquité, ont abouti à en donner différentes interprétations. +Dans~\cite{ferret_bateau_1996}, S. Ferret fait un état des lieux de ces +interprétations dont voici une brève description: +\begin{description} + +\item[Identité numérique:] Il s'agit de la relation qu'entretient un objet avec + lui-même au cours du temps. Dans l'exemple précédent, l'\emph{identité + numérique} du bateau de Thésée est conservée au cours du temps, même si le + bateau subit des modifications au fur et à mesure. C'est la seule identité qui + résiste au temps. + +\item[Identité spécifique:] Il s'agit de l'appartenance à une catégorie + commune, indépendamment de l'objet concerné. Ainsi, les planches constituant + initialement le bateau de Thésée font partie de la même \emph{identité + spécifique} et s'opposent aux planches nouvellement installées. D'un point + de vue logique, une identité spécifique peut être associée à la propriété + séparant les objets qui lui appartiennent de ceux qui ne lui appartiennent + pas. + +\item[Identité qualitative:] Aussi appelée indiscernabilité, il s'agit de + l'identification d'objets que l'expérience ne permet pas de distinguer. Pris + au sens le plus strict, deux objets ayant les mêmes propriétés (qualités), + c'est-à-dire répondant de la même façon à \emph{toutes} les questions qui + leurs seraient posées, sont identiques. + +\end{description} + +Il est intéressant de constater que ces points de vue se mêlent en modélisation. +Notamment, la complexification structurelle d'A. Ehresmann permet d'observer les +trois identités à l'œuvre au sein d'une même construction. La +\textsc{Fig.}~\ref{fig:id-complexlink} présente leurs interactions lors de la +construction d'un lien complexe: l'identité numérique des (cat-)neurones dont +on suit l'évolution au cours du temps, l'identité spécifique des cat-neurones +d'un même niveau tous descriptibles de la même façon, et l'identité qualitative +des familles de neurones avec \emph{binding} caractérisées par leur comportement +synchronisé. On remarquera notamment sur ce dernier point l'indiscernabilité à +l'œuvre lorsque des familles d'une bascule complexe -- se comportant en tout +point de la même façon avec les autres neurones -- sont représentées par le même +cat-neurone. + +% DONE: modification de la figure % +% v Pas de cadres% +% v Suppression du lien de clôture +% v Deux accolades à gauche pour les deux identités numériques (persistance au +% cours du temps)% +% v Ligne de démarcation entre niveau n et n+1 +% DONE: modification de la figure 2 % +% v numérique -> spécifique +% v binding = propriété commune -> id qualitative (en couleur) +% v entourer l'identité numérique +%DONE: WONTFIX améliorer les couleurs +\begin{figure}[h!] + \centering + \includegraphics[page=6,width=.95\textwidth]{complexification-ehresmann} + \caption[Identités et lien complexe]{% + Identités et lien complexe: les identités qualitatives sont données en + magenta, en orange et en rouge, les identités numériques sont données en + violet, en bleu et en cyan.% + } + \label{fig:id-complexlink} +\end{figure} + + + + + + + + + +\FloatBarrier +\section{Une notion générale de modèle}\label{sec:consmodel} + +Comme nous venons de le voir, le concept de modèle est riche et sa compréhension +varie suivant le domaine ou la technique utilisée. Notre objectif étant de +s'écarter des cas particuliers pour proposer un outil générique pour comprendre +la modélisation multi-niveau, il nous est nécessaire de définir une notion de +modèle qui permettra de rendre compte du plus grand nombre de cas d'application. +Dans cette section, nous proposons une telle définition. + +Nous commençons par fixer une partie du vocabulaire utilisé pour finalement +proposer la définition générale qui nous intéresse. Cette généralité étant +un frein à l'étude des modèles, nous en proposons ensuite différentes +instanciations permettant de retrouver quelques classes de modèles couramment +rencontrées. Nous terminons par la présentation de différents modèles d'un même +système, un système proie/prédateur. + + +\subsection{Vocabulaire}\label{sec:formalism-model-system} + +\newcommand{\modele}{\emph{modèle}\xspace} +\newcommand{\systeme}{\emph{système}\xspace} +\newcommand{\formalisme}{\emph{formalisme}\xspace} +\newcommand{\modeles}{\emph{modèles}\xspace} +\newcommand{\systemes}{\emph{systèmes}\xspace} +\newcommand{\formalismes}{\emph{formalismes}\xspace} + +\begin{figure}[t] + \centering + \includegraphics[page=1,width=.65\textwidth]{fms} + \caption{Schéma des relations entre de notions de \systeme, \modele et + \emph{formalisme}.} + \label{fig:fms} +\end{figure} + +Les trois notions importantes qui nous intéressent dans ce chapitre sont +celles de \systeme, de \modele et de \formalisme. Bien que, d'un point de +vue général, elles sont acceptées de tous, l'usage de ces termes peut varier +suivant le domaine. Notre objectif est de lever toute ambigüité en proposant au +lecteur notre propre compréhension de ces notions. En outre, nous utiliserons +ces définitions comme fondement de notre proposition. Ainsi, la figure +\textsc{Fig.}~\ref{fig:fms}, résumant les relations que nous avons pu mettre +en avant section~\ref{sec:multiniveau}, constitue le canevas du développement +décrit section~\ref{sec:compmodel}. + + + +\paragraph{Système.} + +On trouve dans de nombreuses disciplines l'utilisation du mot \systeme. En voici +quelques exemples: +% grosse liste de tous les systèmes +\begin{itemize} + + \item En informatique, le \systeme d'exploitation est un \emph{assemblage} de + programmes et de processus chargés de la gestion des périphériques au sens + large: la mémoire, les communications via une carte réseau, les entrées + utilisateur, les ressources processeur, etc.; + + \item En anatomie, le terme \systeme désigne un \emph{assemblage} d'organes + interagissant au sein d'un organisme dans la réalisation d'une fonction + biologique commune: le \systeme nerveux, le \systeme digestif, etc.; + + \item En physique, un \systeme est un \emph{assemblage} de points, de solides, + constitutif d'un fluide, d'un gaz, … dont il faut décrire l'évolution au + cours du temps; + + \item En logique, un \systeme formel est un \emph{assemblage} comprenant + un vocabulaire, un ensemble d'axiomes et des règles de déduction. + +\end{itemize} +Tous les exemples supplémentaires que nous pourrions trouver reposeraient eux +aussi sur deux notions essentielles: +\begin{enumerate} + + \item Le terme \systeme désigne un objet d'étude. Il s'oppose à + l'environnement, c'est-à-dire à ce que l'on ne souhaite pas étudier mais qui + est potentiellement en interaction avec l'objet d'étude. Suivant le degré + d'importance de ces interactions, les termes de \systeme ouvert, fermé ou + isolé seront plus particulièrement employé. + + \item Dans son étude, le \systeme est décomposé en parties, et l'étude porte + sur la compréhension des relations entre ces parties. D'ailleurs, l'origine + étymologique du mot \systeme est σύστημα qui, en grec ancien, désigne un + tout composé de plusieurs parties ou membres. Cette décomposition a son + importance dans notre approche car elle offre le vocabulaire nécessaire pour + désigner le système et, nous le verrons par la suite, constitue une base + pour la définition d'une sémantique. + +\end{enumerate} + + +\paragraph{Modèle.} + +L'acceptation générale du terme \modele fait état d'un objet utilisé comme +représentation d'un autre\footnote{Il existe néanmoins une compréhension opposée +de la notion de modèle, que l'on trouve par exemple dans le monde artistique où +un \modele est utilisé pour ensuite être représenté dans une œuvre (peinture, +dessin, littérature, etc.). Dans ce sens, on parle d'une forme d'idéal qu'on +cherche à atteindre. La définition à laquelle nous nous réfèrerons est celle du +\modele scientifique.}. Suivant la définition que nous venons de donner, l'objet +représenté correspond à un \systeme, dont un \modele a la charge d'en donner +une représentation suffisamment fidèle pour procéder à l'étude attendue. Dans +certains cas, le \systeme est existant et le \modele servira de représentation +simplifiée en vue d'une analyse souvent explicative du \systeme; dans d'autres +cas, il correspondra à une construction que nous souhaitons réaliser, le \modele +permettra alors, dans une approche d'ingénierie, d'étudier la possibilité de +réaliser le système, voire d'en guider la construction. + +L'aspect dégradé de la représentation offerte par le \modele en fait une +abstraction du \systeme. Elle place les deux concepts dans des mondes \emph{a +priori} différents, l'un abstrait et l'autre concret. Par exemple le premier +peut être mathématique lorsque la modélisation est formelle et le second réel +quand l'objet d'étude existe dans la nature. Cependant, c'est bien la relation +entre le \modele et le \systeme qui fait la modélisation et non le \modele +seul. En effet, les abstractions apportées par le \modele ne font sens que +lorsqu'elles se font \emph{par rapport} \systeme. Ainsi, la sémantique associant +les abstractions du \modele au vocabulaire amené par le \systeme complète la +relation \modele-\systeme. Nous développerons cette idée formellement dans la +section~\ref{sec:compmodel}. + + + +\paragraph{Formalisme.} + +Tout \modele nécessite un langage comme support d'expression. Ce langage peut +être compris au sens large et prend de nombreuses formes. Prenons par exemple +la réalisation d'une maquette d'un pont pour en étudier la réponse aux vents en +soufflerie. Le support de description dans ce cas n'est autre que le matériel +constituant la maquette. + +Nous nous limiterons ici aux modélisations dont le langage de description repose +sur une construction mathématique. Ces constructions sont appelées \formalismes +et sont la donnée d'une théorie, au sens mathématique, c'est-à-dire un ensemble +d'affirmations et un mécanisme de déduction. Cette théorie est accompagnée d'une +syntaxe permettant d'en formuler les affirmations. + +Comme évoqué plus haut, la difficulté des approches combinant plusieurs +\modeles d'un même \systeme vient de la diversité des \formalismes utilisés. +Il nous semble que la théorie des ensembles offre un cadre commun minimal +suffisant pour élaborer notre outil. En effet, la plupart des \formalismes +que nous avons rencontrés se fondent sur une représentation ensembliste. +C'est le cas par exemple des algèbres (au sens de l'algèbre universelle) +vues comme des ensembles munis de lois de composition internes. Nous verrons +section~\ref{sec:consmodel} comment l'enrichissement d'un ensemble par une +structure mathématique, c'est-à-dire en se plaçant dans un \formalisme +particulier, permet de retrouver certaines classes de \modeles. Nous verrons +également, section~\ref{sec:compmodel}, comment oublier ces structures permet +aux \modeles de collaborer. + + + + +\newcommand{\lsys}{L-system\xspace} +\newcommand{\lsyss}{L-systems\xspace} + +\paragraph{Les systèmes de Lindenmayer.} + +Dans ce paragraphe, nous souhaitons montrer que si, dans une situation +particulière, nous savons différencier \systeme, \modele et \formalisme, un même +objet peut servir suivant le contexte de \systeme, de \modele ou de \formalisme. + +Les systèmes de Lindenmayer, ou \emph{\lsyss}, en sont un bon exemple. +Les \lsyss sont des grammaires formelles introduites par A. +Lindenmayer~\cite{de_koster_discrete_1987}. Formellement\footnote{Pour la +simplicité du propos, nous restreignons notre présentation au D0-\lsys, +c'est-à-dire aux \lsyss déterministes sans contexte.}, un \lsys est un triplet +$(\Sigma, w_0, P)$ où $\Sigma$ est un ensemble fini de symboles appelé +\emph{alphabet}, $w_0\in \Sigma^*$ est un mot fini initial appelé \emph{axiome}, +et $P \subset \Sigma \rightarrow \Sigma^*$, appelé l'ensemble des règles, est +une fonction associant à chaque lettre de $\Sigma$ un mot. Un \lsys transforme +ainsi un mot $a_1 \dots a_n$ en $w_1 \dots w_n$ tel que pour tout $i$, $w_i = +P(a_i)$. + +Les \lsyss peuvent être observés sous le prisme des trois concepts que nous +avons abordés: +\begin{enumerate} + + \item \lsys comme \modele : Au même titre que le + $\lambda$-calcul~\cite{church_set_1932}, les machines de + Turing~\cite{turing_computable_1937} ou les grammaires de + Chomsky~\cite{chomsky_three_1956}, les \lsyss ont leur place dans l'étude + du calcul en tant que \modeles de calcul. Dans ce contexte, c'est-à-dire + celui de calculabilité, le \systeme désigne les fonctions calculables et les + modèles énumérés ci-dessus en proposent différents points de vue. En effet, + nous pouvons associer un langage à un \lsys à travers l'ensemble des mots + qu'il génère à partir de l'axiome. Durant les années 70, un important effort + de recherche a été entrepris pour comprendre la puissance de calcul proposé + par les \lsyss~\cite{rozenberg_mathematical_1980}. + + \item \lsys comme \systeme : Afin de les élever comme modèles de calcul, les + \lsyss ont fait l'objet d'une étude formelle devenant alors un \systeme, + suivant le sens évoqué plus haut. Ainsi, nous trouvons également + dans~\cite{rozenberg_mathematical_1980} des abstractions qui ont permis + de mener à bien cette étude. Pour n'en donner qu'un exemple simple, les + \emph{fonctions de croissance} permettent à partir d'un \lsys d'obtenir la + longueur du mot obtenu après $n$ transformations issues de l'axiome initial. + Dans notre cas, décrire la fonction de croissance revient à poser un système + d'équations mutuellement récursives dénombrant le nombre d'occurrences de + chaque lettre à une génération donnée. + + \item \lsys comme \formalisme : Il s'agit ici de l'utilisation initiale des + \lsyss proposée par A. Lindenmayer qui avait pour objectif de modéliser le + développement des plantes et des bactéries. Dans ce troisième contexte, les + \lsyss sont utilisés comme \formalisme pour décrire des modèles biologiques. + Par exemple, dans~\cite{prusinkiewicz_algorithmic_2012} se trouve, parmi de + nombreuses autres applications montrant la richesse de l'approche, le \lsys + $L_\mathrm{AC} = (\{r,R,l,L\}, R, P_\mathrm{AC})$ comme \modele symbolique + du comportement de croissance de l'algue \emph{Anabaena catenula}. Cette + algue se présente sous la forme d'un filament de cellules. Les cellules sont + polarisées (vers la gauche ou vers la droite) et le filament présente un + motif de polarisation spécifique. Les règles de $P_\mathrm{AC}$, données par + $$ + \begin{array}{lll} + r & \Rightarrow & R \\ + l & \Rightarrow & L \\ + R & \Rightarrow & Lr \\ + L & \Rightarrow & lR + \end{array} + $$ + décrivent comment naît ce motif. Il repose sur une asymétrie de longueur + des cellules filles lors de la division cellulaire. Dans cet exemple, + $r$ est l'abstraction d'une cellule courte orientée vers la droite, $L$ + d'une cellule longue orientée vers la gauche, etc. La règle $R \Rightarrow + Lr$ abstrait la division d'une cellule longue orientée à droite, en deux + cellules, respectivement longue et orientée à gauche, et courte et orientée + à droite. + +\end{enumerate} + + +\let\formalisme\undefined +\let\systeme\undefined +\let\modele\undefined +\let\formalismes\undefined +\let\systemes\undefined +\let\modeles\undefined +\let\lsyss\undefined +\let\lsys\undefined + + + +\FloatBarrier +\subsection{Constructions de modèles} +\label{sec:consmodel} + +Comme nous l'avons présenté précédemment, nous souhaitons nous placer dans +le contexte de la théorie des ensembles, dénominateur commun de tous les +formalismes formalismes de modélisation introduits jusqu'à présent. Ainsi, +nous considérons qu'un modèle est un ensemble de «faits» à propos du système +concerné. + +Cette simple définition confirme, d'une part, que sans sémantique, un modèle +ne nous apprend que peu d'informations sur le système qu'il décrit. Pire +encore, en supposant qu'une telle sémantique existe, que l'absence de structure +des ensembles ne nous permet pas de relier entre eux les faits que le modèle +contient. +%% +Le prix à payer pour unifier les formalismes semble trop élevé pour mener à bien +notre objectif. + +Cependant, un modèle n'est pas n'importe quel ensemble, mais un ensemble issu +d'un formalisme bien particulier et qui présente donc les reliquats d'une +structure préexistante. Ainsi, tous les modèles correspondant à un formalisme +donné exhiberont une forme commune qui peut être utilisée pour classer les +modèles. +%% +Dans cette section, nous présentons à travers quelques exemples comment enrichir +cette vue ensembliste de la modélisation pour retrouver des classes de modèles +fréquemment rencontrées. + +Dans la suite, nous utiliserons la notation $\modelM$ pour désigner un modèle. +Afin de distinguer la façon de construire l'ensemble des faits d'un modèle du +modèle lui-même, nous noterons $E_\modelM$ l'ensemble des faits de $\modelM$. + +\subsubsection{Modèle à observables} + +Dans ce premier exemple, nous considérons que les faits que contiennent les +modèles représentent les \emph{états} du système, c'est-à-dire une description +des différentes configurations que peut prendre le système. Chaque état +correspond à une observation du système et peut être décrit comme un tuple de +valeurs, appelées \emph{observables}. En d'autres termes, le modèle correspond à +un ensemble de mesures relevées sur le système étudié. + +Chaque observable produit une mesure dans un ensemble de valeurs, appelé +le \emph{domaine} de l'observable. Un modèle définit donc une \emph{loi +d'exclusion} : il distingue parmi l'ensemble de toutes les mesures théoriques +possibles la classe des comportements propres au système et exclut +celles qui ne le sont pas. Cette approche a été développée par J.C. +Willems~\cite{willems_paradigms_1991}. L'ensemble des mesures possibles, donné +par le produit cartésien des domaines des observables est parfois appelé +\emph{universum} dont un modèle est le sous-ensemble. Cela nous amène à la +définition formelle suivante. +%%Avant de poser la définition formelle des modèles à observables, donnons +%%quelques notations. +% Nous pouvons maintenant poser une définition formelle d'un modèle général +% qui englobe tout ce que nous souhaitons appeler un modèle. Commençons par +% appeler $\obs$ l'ensemble des observables d'un modèle et $\dom$ l'ensemble +% des domaines qui leur sont associées. Pour lier chaque observable à son +% domaine, nous définissons la fonction $\cfg : \obs \rightarrow \dom$ appelée +% la configuration d'un modèle. L'ensemble exhaustif de tous les états possibles +% du modèle est +% donné par sa \emph{signature} +% \[ +% \sig = \prod\limits_{o\in\obs}{\cfg(o)} +% \] +% Le \emph{comportement} d'un modèle est une relation entre ses observables, +% c'est-à-dire une partie de $\sig$. Il nous arrivera de confondre une observable +% $o$ avec son domaine $\cfg(o)$ lorsque le contexte ne provoque pas d'ambigüité. + +\begin{mpo-definition}[Modèle à observables] + Soit $\{ \dom_i \}_{i \in I}$, une famille d'ensembles. + Un \emph{modèle à observables} $\modelM$ est un modèle caractérisé par un + couple $\langle \sig_\modelM, \bhv_\modelM \rangle$ où + \begin{itemize} + + \item $\sig_\modelM = \dom_1 \times \dom_2 \times \dom_3 \times \ldots$ est + la \emph{signature} (encore appelé \emph{universum}) du modèle \modelM; + + \item $\bhv_\modelM \subseteq \sig_\modelM$ est le \emph{comportement} du + modèle \modelM. + + \end{itemize} + Les projections $\pi_i : \sig_\modelM \rightarrow \dom_i$ sont appelées les + \emph{observables} du modèle et $\dom_i$ est le \emph{domaine} de l'observable + $\pi_i$. + Les éléments de $\bhv_\modelM$ sont appelés les \emph{états} du modèle. + + \noindent + L'ensemble des faits est donné par $E_\modelM = \bhv_\modelM$. +\end{mpo-definition} + +Un modèle à observables pourra être plus ou moins précis dans sa description du +système, en présentant plus ou moins d'observables, en reposant sur des domaines +plus ou moins fins, ou en dénombrant plus ou moins d'états. Cette précision sera +formalisée dans la section suivante par un mécanisme d'abstraction entre modèle. + +% L'exemple~\ref{ex:malthus} revient à dire que tous les nombres d'individus +% tel que $P(t) - P_0 \cdot e^{r \cdot t} \neq 0$ sont exclus du modèle: elles ne +% font pas partie du \emph{comportement} du système selon ce modèle. + +%% \paragraph{Exemple.} + + +\begin{mpo-exemple} %[Modèle expérimental des états de l'eau] + Nous reprenons ici la modélisation des états de l'eau + de~\cite{willems_paradigms_1991}. Suivant la température, l'eau existe dans + différents états solide, liquide ou gazeux. Le modèle $\model{M}{\it eau}$ + suivant décrit les états que prend l'eau pour différentes températures, + données ici en degrés Celsius (\si{\celsius}), à une pression constante de + \SI{1013,25}{\hecto\pascal}: + \[ + \begin{array}{rcl} + \dom_\obsn{Phase} + &=& \{\text{solide},\text{liquide},\text{gaz}\} \\ + \dom_\obsn{Température} + &=& [-273,\infty[ \\ + \sig_{\model{M}{\it eau}} + &=& \dom_\obsn{Phase} \times \dom_\obsn{Température} \\ + \bhv_{\model{M}{\it eau}} + &=& \{\text{solide}\} \times [-273,0] \\ + &\cup& \{\text{liquide}\} \times [0,100] \\ + &\cup& \{\text{gaz}\} \times [100,\infty[ + \end{array} + \] + Notons que d'après ce modèle, l'eau à une température de \SI{0}{\celsius} peut + présenter les deux phases, liquide et solide. + \label{ex:model-eau} +\end{mpo-exemple} + +% Dans l'exemple~\ref{ex:model-eau}, $\bhvxp$ distribue simplement le domaine +% associé à l'observable $\obsn{Température}$ sur les éléments du domaine associé +% à l'observable $\obsn{Matière}$ tel qu'observé et mesuré pendant une expérience. + + + + + + +\subsubsection{Modèle expérimental} + +Voir un modèle comme un ensemble ne dit rien sur la façon de construire ce +modèle. Une première manière de spécifier un ensemble est d'en donner une +définition par extension. +%% +On parlera de \emph{modèle expérimental} lorsque l'ensemble est défini par +extension à partir des résultats d'expériences. + +% : le comportement est construit itérativement par ajouts +% successifs des états du modèle. Si ces états sont issus d'expériences faites sur +% le système, alors nous construisons un modèle expérimental et on notera son +% comportement \bhvxp. Il représente l'ensemble des données issues d'expériences +% sur le système: un modèle expérimental représentera donc \emph{l'ensemble des +% mesures connues} sur un système. + +\begin{figure}[t] + \centering + \includegraphics[width=\textwidth]{figures/log-steamer-bear} + \caption{Extrait d'une page du journal de bord du bateau à vapeur Bear de l'US Navy, le 22 juin 1884.} + \label{fig:steamer-bear} +\end{figure} + +\begin{mpo-exemple} %[Modèle expérimental des états de l'eau] + Une méthode directe de construction d'un modèle à observables consiste à noter + les valeurs mesurées de chaque observable sur une feuille, comme dans le cas + d'un journal de bord «maritime», où les observations relevées se limitent à + celles qui sont estimées pertinentes pour la navigation (voir + \textsc{Fig.}~\ref{fig:steamer-bear}), et à effectuer autant de relevés que + possible. + %% + On peut considérer qu'à chaque ligne un \emph{état du système} est décrit et + que les valeurs relevées définissent une relation (au sens mathématique) entre + les observables. Les colonnes correspondent aux observables ($\pi_i$ dans la + définition ci-dessus) et toutes les valeurs qu'une observable peut prendre + forment son domaine ($\dom_i$ ci-dessus). Par exemple, + \[ + \dom_\obsn{WINDS Direction} \in \{ \textit{N}, \textit{NE}, \textit{E}, + \textit{SE}, \textit{S}, \textit{SW}, \textit{W}, \textit{NW} \} + \] +\end{mpo-exemple} + + +\subsubsection{Modèle équationnel} + +Distinguer un ensemble dans un sur-ensemble de possibilités consiste à donner +un prédicat décidant de l'appartenance d'un élément à l'ensemble. Une façon de +spécifier un tel prédicat est décrit dans~\cite{willems_paradigms_1991} par la +donnée d'une équation mettant en relation deux quantités. Ce principe amène à la +notion suivante de modèle équationnel. + +\begin{mpo-definition}[Modèle équationnel]\label{def:modelequa} + Un \emph{modèle équationnel} $\modelM$ est caractérisé par un couple de + fonctions $\langle f_\modelM, g_\modelM \rangle$ de même signature $X + \rightarrow Y$ pour deux ensembles $X$ et $Y$ donnés, tel que l'ensemble des + faits de $\modelM$ est donné par + \[ + E_\modelM = \{ x \in X \mid f_\modelM(x)=g_\modelM(x) \} + \] +\end{mpo-definition} + + +\begin{mpo-exemple}\label{ex:gazparfait} + Associés à la notion de modèle à observables, les modèles équationnels sont + fréquents en physique. À ce titre, l'équation la plus couramment utilisée pour + caractériser les gaz parfaits illustre la définition~\ref{def:modelequa}. + + D'un point de vue macroscopique, l'état de $n$ moles d'un gaz parfait + à l'équilibre thermodynamique est décrit par les trois observables + $\obsn{Volume}$, $\obsn{Pression}$ et $\obsn{Température}$. On peut construire + le modèle $\model{M}{\it gaz}$ des gaz parfaits dont l'ensemble des états est + donné par: + $$ + E_{\model{M}{\it gaz}} = \{ (V,P,T) \in \dom_\obsn{Volume} \times \dom_\obsn{Pression} \times \dom_\obsn{Température} \mid PV=nRT \} + $$ + où $R =$ \SI{8,3144621}{\joule\per\kelvin\per\mole} représente la constante + des gaz parfaits. Le modèle $\model{M}{\it gaz}$ est donc un modèle + équationnel caractérisé par le couple de fonctions + $$ + \langle (V,P,T) \mapsto P V, (V,P,T) \mapsto n R T \rangle. + $$ +\end{mpo-exemple} + + +\subsubsection{Modèle à observables privilégiées} + +Les classes de modèles que nous avons données jusqu'ici correspondent à la +distinction d'un sous-ensemble admissible de faits à partir d'un univers +plus grand. Avec cette nouvelle classe, nous commençons à nous intéresser +aux modèles dont l'ensemble associé peut être enrichi d'une structure +mathématique particulière provenant d'une propriété qu'il exhibe. Dans ce +premier exemple, on s'intéresse aux modèles à observables dont le comportement +est entièrement déterminé par une partie de ses observables, que nous +appellerons \emph{observables privilégiées}. + +\begin{mpo-definition}[Modèle à observables privilégiées]\label{def:modfct} + Soient $\modelM = \langle \sig_\modelM, \bhv_\modelM \rangle$ un modèle avec + observables $I$ (\ie $\sig_\modelM = \prod_{i\in I} \dom_i$) et $J \subset I$ + un sous-ensemble d'observables. Le modèle $\modelM$ est \emph{à observables + privilégiées} $J$ si, et seulement si, + $$ + \forall b_1,b_2 \in \bhv_\modelM\quad + \pi_J(b_1) = \pi_J(b_2) \Rightarrow b_1 = b_2 + $$ +\end{mpo-definition} + +Cette définition n'est pas sans rappeler quelques concepts propres au +domaine des bases de données relationnelles, introduites par E. F. Codd +dans~\cite{codd_relational_1970}. Un modèle à observables $\modelM$ est très +proche d'une relation, au sens de l'algèbre relationnelle, avec sa signature +$\sig_\modelM$ pour \emph{schéma} et son comportement $\bhv_\modelM$ comme +\emph{extension}, l'ensemble des tuples de la relation. Les observables +privilégiées sont elles à rapprocher de la notion de \emph{clé primaire} +(ou plus précisément de \emph{super-clé}): dans un modèle à observables +privilégiées, chaque $p \in \prod_{j\in J} \dom_j$ identifie de manière unique +un tuple de $\bhv_\modelM$ s'il existe. +%% +Plus précisément, c'est à la notion de \emph{dépendance fonctionnelle} que +correspondent les observables privilégiées. En effet, l'équation de la +définition décrit l'existence d'une fonction codée au sein de $\bhv_\modelM$. + +\begin{mpo-exemple} +En reprenant le modèle $\model{M}{\it gaz}$ de l'exemple~\ref{ex:gazparfait}, il +est possible de remarquer que l'équation des gaz parfaits permet de déterminer +sans ambiguïté n'importe laquelle de ces observables à partir des deux autres. +%% +Nous pouvons donc montrer qu'à partir de $\model{M}{\it gaz}$, trois modèles +à observables privilégiées reposant sur les trois dépendances fonctionnelles +peuvent êtres construits: +$(\obsn{Volume}, \obsn{Pression} \rightarrow \obsn{Température})$, +$(\obsn{Température}, \obsn{Pression} \rightarrow \obsn{Volume})$ et +$(\obsn{Température}, \obsn{Volume} \rightarrow \obsn{Pression})$. +\end{mpo-exemple} + + +\subsubsection{Modèle dynamique} + +L'étude des \emph{systèmes dynamiques} porte sur l'évolution des états du +système au cours du temps. Usuellement, les aspects temporels sont modélisés par +l'action du temps sur l'état du système. +%% +Cette action repose sur la nature monoïdale~\cite{giunti_dynamical_2012} de +l'ensemble utilisé pour représenter le temps. +%% +Un \emph{monoïde} est un triplet $ \Time = \langle D_\Time, 0_\Time, +_\Time +\rangle$ (noté ici additivement) tel que $D_\Time$ est un ensemble arbitraire, +$+_\Time$ est une loi de composition interne binaire \emph{associative} +($\forall x,y,z \in D_\Time, x +_\Time (y +_\Time z) = (x +_\Time y) +_\Time z$) +et munie d'un élément \emph{neutre} $0_\Time$ ($\forall x \in D_\Time, 0_\Time ++_\Time x = x +_\Time 0_\Time = x$). +%% +Dans le cadre de la modélisation du temps, les éléments de $D_\Time$ +correspondent à des \emph{durées} et la loi de composition fournit un moyen de +cumuler ces \emph{durées}. +%% +L'\emph{action} d'un monoïde sur un ensemble arbitraire $E$ est une +fonction $\Phi: E \times D_\Time \rightarrow E$ telle que $\forall x \in E, \forall \delta_1, \delta_2 \in +D_\Time$: +$$ +\Phi(x, 0_\Time) = x \qquad \qquad \Phi(\Phi(x,\delta_1), \delta_2) = \Phi(x,\delta_1 +_\Time \delta_2) +$$ +En interprétant les éléments de $E$ comme une modélisation des états d'un +système, l'action $\Phi$ spécifie une fonction de transition précisant comment, +après une durée $\delta\in D_\Time$, le système passe d'un état $x \in E$ à un +nouvel état $\Phi(x,\delta)$. + +Cette définition très générale n'impose aucune propriété particulière sur le +monoïde utilisé pour modéliser le temps. On retrouve naturellement les modèles +de temps classiques, en prenant l'ensemble des réels pour modéliser un temps +continu ou l'ensemble des entiers pour modéliser un temps discret. Mais cette +définition s'applique également dans des cas moins courants. Par exemple, +considérons un automate à états finis, décrivant les transitions d'état en +état à la lecture d'un mot construit à partir d'un alphabet, disons $\Sigma += \{a,b\}$. On peut interpréter $\Sigma^*$, le monoïde libre engendré par +les lettres de l'alphabet, comme une modélisation d'un temps dont les durées +sont des accumulations de $a$ et de $b$. On peut montrer facilement que la +fonction de transition de l'automate spécifie une action de monoïde. Ce qui +est intéressant dans cette description est que le temps n'est pas ici un temps +linéaire où les «instants» s’enchaînent d'une façon totalement ordonnée, mais un +temps arborescent dont les branches peuvent être interprétées comme différentes +possibilités d’exécutions. Cet exemple rend bien compte de la souplesse de cette +définition. + +Nous proposons de caractériser les \emph{modèles dynamiques} en s'inspirant +de la définition des système dynamiques\footnote{On remarquera qu'ici le +terme \emph{système} ne correspond pas à la notion que nous avons définie +section~\ref{sec:formalism-model-system} mais est plus à rapprocher de celle +d'un \emph{formalisme} permettant la \emph{modélisation} de la dynamique d'un +\emph{système}.} donnée dans~\cite{giunti_dynamical_2012}. +%% +\begin{mpo-definition}[Modèle dynamique]\label{def:moddyna} +Un \emph{modèle dynamique} est un modèle $\modelM$ caractérisé par un triplet +$\langle \bhv_\modelM, \Time_\modelM, \Phi_\modelM \rangle$ tel que +%% +\begin{enumerate} + + \item $\Time_\modelM$ est un monoïde appelé \emph{modèle du temps} et dont les + éléments $\delta \in D_\Time$ sont appelés \emph{durées}, + + \item $\bhv_\modelM$ est un ensemble non vide appelé l'\emph{espace des états} + et dont les éléments sont appelés \emph{états}, + + \item $\Phi_\modelM$ est une action de monoïde de $\Time_\modelM$ sur + $\bhv_\modelM$ appelée \emph{fonction de transition}. + +\end{enumerate} +%% +L'ensemble des faits de $\modelM$ est donné par: +$$ +E_\modelM = \{ (x,\delta,\Phi(x,\delta)) \mid x \in \bhv_\modelM, \delta \in \Time_\modelM \} +$$ +\end{mpo-definition} + +Dans cette définition, chaque triplet d'un modèle dynamique $(x,\delta,x')$ +représente la transition du système de l'état $x$ vers l'état $x'$ après une +durée $\delta$. Nous remarquerons également que $E_\modelM$ spécifie exactement +la fonction $\Phi_\modelM$: un modèle dynamique est donc également un modèle +à observables privilégiées tel que décrit définition~\ref{def:modfct}, les +observables privilégiées étant ici le temps et les conditions initiales. + +% Bien que les conditions assurent que les actions du temps sur les états doivent se composer, conformément à la vision défendue dans~\cite{giunti2012dynamical}, notre définition est assez large et permet notamment de prendre en compte des modélisations non-déterministes. +% En effet, rien n'interdit d'observer au sein de $E_\modelM$ deux triplets $(s,t,s')$ et $(s,t,s'')$ pour $s' \neq s''$. +% Cela correspond à deux avenirs possibles à partir du même état $s$ et après une même durée $t$. +% Des définitions plus restrictives des systèmes dynamiques imposent le déterminisme, voire la réversibilité, des évolutions. +% Nous pourrons retrouver ces contraintes en considérant des \emph{modèles dynamiques à observables privilégiées}, c'est-à-dire en combinant les définitions~\ref{def:moddyna} et~\ref{def:modfct}. +% La dépendance fonctionnelle associée imposera l'unicité de $s'$ connaissant l'état initial $s$ et la durée d'évolution $t$ dans un triplet $(s,t,s')$. +% La réversibilité sera obtenue en ajoutant une autre dépendance fonctionnelle donnant $s$ à partir de $s'$ et $t$. + + +\begin{mpo-exemple}\label{ex:malthus} + Le modèle de croissance Malthusien décrit l'évolution de la taille d'une + population suivant un taux de natalité $r$ sans aucune autre restriction. Ce + type de système présente une croissance exponentielle répondant à l'équation: + $$ + P(t) = P_0 e^{rt} + $$ + où $t$ représente le temps, $P_0$, le nombre d'individus constituant + initialement la population, et $P(t)$, la taille de la population après une + période de $t$ unités de temps. + %% + Cette caractérisation décrit très clairement un système dynamique tel que nous + l'avons évoqué ci-dessus et peut être représentée par le modèle dynamique + $\model{M}{\it malthus}$ dont l'ensemble des faits est le suivant: + $$ + E_{\model{M}{\it malthus}} = \{(P,t,P e^{rt})\mid P,t\in\mathbb{R}^+\} + $$ + Le modèle du temps $\langle \mathbb{R}^+, 0, + \rangle$ correspond à la + modélisation continue classique utilisant les réels et l'addition standard. + L'état du système est également représenté par un élément de $\mathbb{R}^+$ + correspondant, cette fois-ci, à un nombre d'individus. +\end{mpo-exemple} + + +\subsubsection{Modèle à base de champ} + +La notion de champ est particulièrement répandue en modélisation. Un champ +associe une donnée à chaque point d'un espace. Lorsque nous parlons de champ, un +rapprochement apparaît avec les champs scalaires ou vectoriels de la physique +classique où les données représentent des quantités physiques, telles que +la température ou la vitesse de déplacement d'un fluide, cependant, suivant +les contextes, les champs prennent des formes différentes. D'un point de vue +général, on parle de champ lorsque l'on est en présence d'une population +d'objets de même nature, comme les cellules d'un automate cellulaire, les agents +d'un système multi-agent, les ou les places d'un réseau de Petri, que l'on +caractérise individuellement par un certain état, l'état d'une cellule, l'état +d'un agent, l'état d'une place, etc. Cette population décrit également une +organisation mettant en relation les objets les uns par rapport aux autres. On +parle alors d'un espace et des points de cette espace. Bien souvent, la valeur +associée en chaque point est également structurée et on demande au champ de +varier \emph{continûment} sur cet espace, c'est-à-dire sans présenter de rupture +par rapport à l'organisation des valeurs. + +Mathématiquement, ces considérations sont affiliées aux notions d'espaces +topologiques et de fonctions continues. +%% +Un \emph{espace topologique} $\mathbb{S}$ est la donnée d'un ensemble de +\emph{points} $E_\mathbb{S}$, d'un ensemble d'\emph{ouverts} $\Omega_\mathbb{S} +\subset \mathbb{2}^{E_\mathbb{S}}$, contenant $E_\mathbb{S}$ et $\emptyset$, et +clos par union arbitraire et par intersection finie. +%% +Une \emph{fonction continue} d'un espace topologique vers un autre est une +fonction entre les points qui respectent ces structures: la préimage d'un ouvert +doit être un ouvert. + +Ces définitions peuvent être interprétées en termes logiques. En tant que +sous-ensembles, les ouverts peuvent être compris comme des prédicats offrant un +vocabulaire pour classer les points les uns par rapport aux autres. L'union et +l'intersection correspondent respectivement aux opérations de disjonction et de +conjonction dans cette classification. +%% +La continuité impose que le vocabulaire de l'espace d'arrivée corresponde au +vocabulaire de l'espace de départ. Ainsi, en comprenant un ouvert comme une +variation autour d'un point suivant une certaine propriété, la préimage de +cette variation sera une variation autour des préimages du point considéré. +%% +L'exemple du champ de température illustre cette idée de variation: +considérons l'espace euclidien comme espace de départ et les réels comme +espace d'arrivée avec leurs topologies usuelles, c'est-à-dire où une variation +autour d'une valeur revient à prendre un intervalle ouvert autour de cette +valeur\footnote{Pour être exact, il s'agit ici d'une base de la topologie +usuelle.}. Ainsi, pour un champ de température donné, si l'on considère +l'ensemble $P$ de tous les points de température $20°C$, les points de +températures comprises entre $19°C$ et $21°C$ seront «autour» de ceux de $P$. +%% +Cette idée s'applique également pour un réseau d'interactions entre agents: +plus deux agents sont dans des états «proches», c'est-à-dire partageant de +plus en plus de propriétés, plus leurs environnements d'interactions seront +comparables. + +Nous proposons de caractériser les \emph{modèles à base de champ} comme la +représentation d'une fonction continue. +%% +\begin{mpo-definition}[Modèle à base de champs]\label{def:modfield} +Un \emph{modèle à base de champ} est un modèle $\modelM$ caractérisé par un +triplet $\langle \Space_\modelM, \mathbb{V}_\modelM, f_\modelM \rangle$ tel que +\begin{enumerate} + + \item $\Space_\modelM$ et $\mathbb{V}_\modelM$ sont des espaces topologiques, + et + + \item $f_\modelM:\Space_\modelM \rightarrow \mathbb{V}_\modelM$ est une + fonction continue. + +\end{enumerate} +%% +L'ensemble des faits de $\modelM$ est donné par: +$$ +E_\modelM = \{ (x,f(x)) \mid x \in \Space_\modelM \} +$$ +\end{mpo-definition} +%% +L'avantage du point de vue topologique est qu'il autorise tout type de champ. +En effet, n'importe quelle fonction entre deux ensembles pourra être rendue +continue en utilisant par exemple la topologie discrète\footnote{ La topologie +discrète est celle où tout sous-ensemble de points est un ouvert. Il ne faut +cependant pas la comprendre comme \textbf{la} topologie des modèles discrets.} +sur l'espace de départ. La qualité d'un modèle à base de champ viendra du choix +judicieux des topologies utilisées. Nous remarquerons enfin que la définition +fonctionnelle de $E_\modelM$ permet d'inclure les modèles à base de champs comme +car particulier de modèles à variables privilégiées. + + +\begin{mpo-exemple} +En théorie des réseaux sociaux, la séparation, c'est-à-dire la longueur de la +plus petite chaîne de connaissances sociales permettant de relier un individu +à un autre, est une mesure importante. Elle est par exemple à la base de +la théorie des \emph{six degrés de séparation}~\cite{travers_small_1967} +établissant que toute personne sur la planète est reliée socialement à n'importe +quelle autre par une chaîne de longueur au plus 6. + +Il est possible de modéliser la séparation comme un champ de distance sur le +graphe des liens sociaux. Pour un graphe donné $G$, le champ de distance à un +sommet $v_0$ associe à chaque sommet $v$ de $G$ la longueur $d(v)$ du plus court +chemin entre $v_0$ et $v$. Le champ $d$ se présente donc comme une fonction des +sommets de $G$ dans $\mathbb{N}$. + +Il est possible de considérer la continuité de $d$ en associant au graphe $G$ +et à $\mathbb{N}$ leur \emph{topologie digitale}. Pour cette topologie, notée +$\Omega^{\rm dig.}_G$, un ouvert d'un graphe $G$ (vu comme un ensemble de +sommets et d'arcs) est défini comme une union d'ouverts de base: +\begin{itemize} + + \item pour tout arc $e$, le singleton $\{e\}$ est un ouvert; + + \item pour tout sommet $v$, l'ensemble $\{v\} \cup \{ e \in G \mid v \prec e + \}$, où $v \prec e$ signifie que $e$ est incident à $v$ dans $G$, est un ouvert. + +\end{itemize} +Les entiers peuvent être munis de la même topologie en considérant $\mathbb{N}$ +comme un graphe dont les sommets sont les entiers et où un arc $\{n,n+1\}$ relie +chaque entier $n$ à son successeur. + +On peut remarquer que pour toute paire de sommets voisins $(v_1,v_2)$, le champ +de distance ne varie qu'au plus de 1: +$$ +|d(v_1) - d(v_2)| \leq 1 +$$ +La fonction $d$ peut alors être étendue aux arcs de telle sorte que pour tout +arc $e$ entre $v_1$ et $v_2$, +$$ +d(e) = \left\{ + \begin{array}{ll} + d(v_1) & \textnormal{si } d(v_1) = d(v_2) \\ + \{d(v_1),d(v_2)\} & \textnormal{sinon} + \end{array} +\right. +$$ +Ainsi, la fonction $d$ est continue et peut être utilisée pour constituer un +modèle à base de champ $\model{M}{\it sép.}$ de la séparation d'un réseau par: +$$ +\Space_{\model{M}{\it sép.}} = \langle G, \Omega^{\rm dig.}_G \rangle +\qquad +\mathbb{V}_{\model{M}{\it sép.}} = \langle \mathbb{N}, \Omega^{\rm dig.}_\mathbb{N} \rangle +\qquad +f_{\model{M}{\it sép.}} = d +$$ +\end{mpo-exemple} + + + + +\subsubsection{Modèle à structure dynamique} + +Les classes de modèles que nous avons proposées jusqu'ici ne sont pas +indépendantes les unes des autres. Comme nous l'avons déjà vu par exemple, les +modèles dynamiques et à base de champ sont des cas particuliers de modèles +à observables privilégiées. Ces deux classes s'intéressent en fait à deux +aspects qui reviennent fréquemment dans les modélisations, le \emph{temps} et +l'\emph{espace}, et il est classique de retrouver ces deux aspects en même temps +au sein du même modèle. L'intersection entre les modèles dynamiques et les +modèles à base de champ n'est pas vide, loin s'en faut. + +Il est intéressant de noter que l'interdépendance entre temps et espace nous +amène en fait à considérer quatre types de modélisation à variables privilégiées +spatio-temporelles: + +\begin{enumerate} + + \item $\Space \times \Time \rightarrow \dots$\\ + L'espace ne varie pas dans le temps et le temps est le même partout dans + l'espace. Ainsi, \emph{temps} et \emph{espace} sont indépendants. + %% + On retrouve par exemple ce type de modèles en physique classique ou avec les + automates cellulaires. + + \item $\Space \rightarrow (\Time \rightarrow \dots)$ + %\antoine{La bonne notation avec types dépendants $\prod_{p:\Space} + %\(\Time(p) rightarrow \dots)$}\\ + Le temps varie d'un point de l'espace à un autre. Autrement dit, chaque point + à son horloge. Ce cas est représentable par un modèle à base de champs qui + associe à chaque point de l'espace un modèle dynamique. + %% + Par exemple, une étude de charge dans une grille de calcul amènera à ce type + de modélisation: les processeurs tournent chacun à leur propre vitesse alors + que la structure du réseau reste fixe. + + \item $\Time \rightarrow (\Space \rightarrow \dots)$ + %\antoine{La bonne notation avec types dépendants $\prod_{\delta:\Time} + %(\Space(\delta) \rightarrow \dots)$}\\ + L'espace varie au cours du temps: à chaque instant, le domaine spatial est + différent. Une représentation reposant sur un modèle dynamique dont l'espace + des états sera constitué de modèles à base de champ, sera privilégiée. + %% + Nous appelons ces systèmes, des systèmes dynamiques à structure dynamique. + + \item $\SpaceTime \rightarrow \dots$\\ + L'espace et le temps forment ici un tout, $\SpaceTime$, qui ne peut être + dissocié. En physique, la relativité est une parfaite illustration d'étude + ce type de système. Bien qu'il soit possible de n'observer que l'action du + temps sur un point de l'espace en suivant les lignes d'univers, la description + qui en résulte n'est pas complète. En effet, un changement d'observation, + c'est-à-dire le passage d'une ligne d'univers à une autre, modifie la + perception du temps \emph{et} de l'espace sur les autres événements. + +\end{enumerate} + + + +\subsubsection{Modèle probabiliste} + +Nous terminons la description de ces quelques classes de modèles en évoquant +les systèmes que nous souhaitons modéliser de façon probabiliste. Pour ces +modélisations, le formalisme repose essentiellement sur les notions d'espace +mesurable et de probabilité. Formellement, un espace mesurable $\mathbb{X}$ est +un ensemble $X_\mathbb{X}$ muni d'une \emph{tribu} $\mathcal{A_\mathbb{X}}$, +c'est-à-dire d'un ensemble de sous-ensembles de $X_\mathbb{X}$ contenant +$X_\mathbb{X}$, clos par complémentation et par union dénombrable. Dans le cadre +de la théorie de la probabilité, $X_\mathbb{X}$ est appelé un \emph{univers}, +représentant l'ensemble de toutes les résultats d'une expérience donnée, et +$\mathcal{A}_\mathbb{X}$ l'ensemble des événements. Une mesure de probabilité +$\mathbb{P}$ associe à chaque événement sa probabilité, c'est-à-dire une +valeur de $[0,1]$ telle que $\mathbb{P}(X_\mathbb{X})=1$ et $\mathbb{P}(\cup_i +A_i)=\sum_i \mathbb{P}(A_i)$ pour toutes familles dénombrables d'événements +disjoints $\{A_i\}$. + +Un modèle peut être la représentation d'une expérience probabiliste: nous +parlerons ici de \emph{modèle probabiliste}. +%% +\begin{mpo-definition}[Modèle probabiliste]\label{def:probmodel} +Un \emph{modèle probabiliste} est un modèle $\modelM$ caractérisé par un couple +$\langle \mathbb{X}_\modelM, \mathbb{P}_\modelM \rangle$ tel que +\begin{enumerate} + +\item $\mathbb{X}_\modelM = \langle X_\modelM, \mathcal{A}_\modelM \rangle$ est + un espace mesurable, et + +\item $\mathbb{P}_\modelM$ est une probabilité sur $\mathbb{X}_\modelM$. + +\end{enumerate} +L'ensemble des faits de $\modelM$ est donné par: +$$ +E_\modelM = \{ (A,\mathbb{P}_\modelM(A)) \mid A \in \mathcal{A}_\modelM \} +$$ +\end{mpo-definition} +On remarquera que cette définition décrit les modèles probabilistes comme des +modèles à observables privilégiées particuliers. + + + +\begin{mpo-exemple}\label{ex:malthus2} + La croissance de Malthus décrite exemple~\ref{ex:malthus} peut être modélisée + par un processus aléatoire reposant sur une simple règle de reproduction, + semblable à une division cellulaire: + \begin{equation} + X \stackrel{r}\longrightarrow 2 X\label{eq:divrule} + \end{equation} + où $X$ représente un individu et $r$ est le taux de division des individus. + Étant donnée une population composée de $N_0$ individus, nous cherchons à + décrire le temps d'attente avant la prochaine division. + + On suppose pour cela que deux divisions ne peuvent être simultanées et que les + individus se divisent de façon indépendante. + À partir de la règle~(\ref{eq:divrule}), nous posons la probabilité + infinitésimale $r d\tau$ qu'un individu se divise à l'instant $\tau$, + c'est-à-dire durant l'intervalle de temps infinitésimal $[\tau,\tau + d\tau]$. + Ces observations nous permettent de déduire les probabilités suivantes: + \begin{itemize} + + \item $r N d\tau$, la probabilité infinitésimale d'une division pour une + population de $N$ individus (indépendants par hypothèse) à l'instant $\tau$, + + \item $e^{-r N_0 \tau}$, la probabilité qu'aucune division n'ait lieu durant + l'intervalle $[0,\tau]$, et + + \item $N_0 r e^{-r N_0 \tau} d\tau$, la probabilité infinitésimale que la + prochaine division ait lieu à l'instant $\tau$. + + \end{itemize} + Cette dernière expression nous amène à considérer la probabilité que la + prochaine division se produise durant un certain intervalle de temps, posant + ainsi les termes d'un modèle probabiliste $\model{M}{\it div.}$ de la + croissance Mathusienne. + Pour cela, considérons + %% + d'une part l'espace mesurable $\mathbb{X}_{\model{M}{\it div.}}$ comme étant + l'ensemble des réels positifs $\mathbb{R}^+$ muni de sa tribu Borélienne + classique, c'est-à-dire engendrée par les intervalles fermés $[t_1,t_2]$, + %% + et d'autre part la mesure de probabilité: + $$ + \mathbb{P}_{\model{M}{\it div.}}([t_1,t_2]) = + \int_{t_1}^{t^2} r N_0 e^{-r N_0 \tau} d\tau = + [ -e^{-r N_0 \tau} ]_{t_1}^{t_2} = + e^{-r N_0 t_1} - e^{-r N_0 t_2} + $$ + L'ensemble des faits de $\model{M}{\it div.}$ est alors donné par: + $$ + E_{\model{M}{\it div.}} = + \{ ([t_1,t_2], \mathbb{P}_{\model{M}{\it div.}}([t_1,t_2])) + \mid t_1,t_2 \in \mathbb{R}^+\} + $$ +\end{mpo-exemple} + + +% Un modèle à observables privilégiées ne prend-il pas partie pour la vision de +% l'espace et du temps de Newton au détriment d'un conception Leibnizienne ? Ne +% fixe-t-on pas précocément une \emph{structure} ? Pour rappel, Newton considérait +% que l'espace et le temps précédait les corps physiques et les évènements et +% qu'ainsi, ces objets pouvaient être annotés par une mesure de position dans le +% temps et dans l'espace faite par rapport à des repères \emph{absolus} et +% \emph{prééxistant}. Cette vision semble s'opposer à celle de Leibniz qui +% estimait de son côté que l'espace et le temps sont \emph{engendrés} par les +% corps physiques et les évènements. Ces deux postures philosophiques sont +% cependant conciliées par notre approche, et d'après la définition précédente, +% nous pouvons remarquer les points suivants: +% \begin{itemize} +% \item un modèle est un point de vue \emph{a posteriori} du système que l'on +% modélise et la question de la prééxistance du temps et de l'espace n'influe +% pas sur le modèle. Dans les deux cas, il appartient au modélisateur de +% \emph{déterminer} les structures \emph{nécessaires} à l'obtention de la +% relation entre les observables voulues. +% \item un modèle n'est qu'une relation entre des observables ce qui implique que +% la structure du domaine d'une observable espace ou temps est \emph{implicite} +% et résulte également d'un choix de modélisation. Ces structures doivent être +% ajoutées au domaine d'une observable, par exemple dans le cas d'une observable +% $\obsn{Espace}$ ayant pour domaine associé $\mathbb{R}^2$, on peut y ajouter +% une structure d'espace vectoriel. +% \end{itemize} +% Pour conclure cette remarque, que le temps et l'espace soient préexistants ou +% bien qu'ils soient construits à partir des évènements et des points disponibles, +% le travail du modélisateur est le même. Bien que cette question soit +% intéressante d'un point de vue philosophique, elle n'a \emph{aucune} influence +% sur notre définition des modèles. + + + + + + + + +% Nous considérerons qu'un modèle exéprimental peut être compris comme le modèle +% de référence pour tous les autres modèles du même système. Un modèle +% expérimental établit un rapport au système étudié, donc à la réalité, \emph{par +% la mesure}, il dépend donc des outils de mesure utilisés et de leurs +% imperfections éventuelles. Un modèle expérimental, de part sa simplicité et son +% lien direct au système, jouera le rôle de modèle de référence lors de la +% comparaison entre modèles d'un même système (voir +% Fig.~\ref{fig:model-abstraction}). + +% Remarquons que de manière exactement équivalente, on peut utiliser +% $\chi_{\bhv}$, la fonction caractéristique sur les ensembles de la relation +% $\bhv$ sur l'ensemble $\sig$, pour définir la sous-relation: +% \begin{align*} +% \chi_{\bhv} : \sig &\longrightarrow \{0,1\} \\ +% \sigma &\longmapsto \left\{ +% \begin{array}{l} +% 1 \quad\text{si}\quad \sigma \in \bhv \\ +% 0 \quad\text{si}\quad \sigma \notin \bhv +% \end{array} +% \right. +% \end{align*} + +% La fonction $\chi_{\bhv}$ interdit explicitement certains tuples du comportement +% ne pouvant satisfaire la loi de comportement. Notons que cette fonction est +% rarement connue à l'avance lors des expériences et, si elle l'est, il est +% important de la mettre de côté pour éviter un biais de confirmation. C'est un +% premier pas vers une loi de comportement gouvernant le rapport entre +% \emph{observables du modèle}. Néammoins, cette définition reste trop générale +% pour que nous puissions tirer des informations intéressantes sur le +% fonctionnement de ce modèle. Aucune hypothèse n'est faite sur le type de +% fonction qu'est $\chi_{\bhv}$. Cette approche a toutefois le mérite de nous +% présenter une seconde manière de définir un modèle: si le comportement peut-être +% obtenu algorithmiquement ou bien par une structure mathématique, alors on peut +% définir un modèle par intention. + +% \begin{mpo-definition}[Modèle comportemental] +% Soit $I$ un ensemble dénombrable d'indices et $(\sig,\bhvpo)$ un modèle où +% $\sig$ est de la forme $\sig = \prod_{i\in I} \dom_i$, soit $J \subset I$ un +% ensemble non vide d'indices, on peut réécrire la signature $\sig = P \times R$ +% où +% \[ +% P = \prod\limits_{j \in J} \dom_j \quad +% \text{et} \quad +% R = \prod\limits_{i \in I \setminus J} \dom_i +% \] +% Un \emph{modèle comportemental} est un couple $M = +% (\Phi_P,\bhvpo)$ où +% \begin{itemize} +% \item $\Phi_P(\sig) = \left( R \right)^P$ est \emph{l'ensemble des +% comportements fonctionnellement dépendant des observables privilégiées} et +% \item $\bhvpo \subset \Phi_P(\sig)$ est le \emph{comportement} de M. +% \end{itemize} +% \end{mpo-definition} + +% Cette définition apporte une nouvelle structure mathématique à la signature d'un +% modèle expérimental qui met en exergue la dépendance fonctionnelle existante +% entre quelques observables et les autres. Le comportement qui en est issu +% apporte plus de contraintes sur la manière dont la relation $\bhvpo$ peut être +% construite. + +% Remarquons que $\bhvpo$ et $\bhv$ sont de natures différentes: le premier est +% une relation sur les éléments de $\sig$ et le second est une relation sur les +% éléments de $\Phi_P(\sig)$. On peut néammoins se rendre compte en exprimant +% $\bhvpo$ en fonction de $\bhv$ +% % +% \begin{equation} \label{eq:bhvpo-bhv} +% \bhvpo = \Big\{ \big(p,b(p)\big) \bigm| p \in P \land b \in \bhv \Big\} +% \end{equation} +% % +% que $\bhvpo$ ne permet pas de distinguer les cas où $(p,b_1(p)) = (p,b_2(p))$, +% c'est-à-dire qu'elle «oublie» une partie de la structure sur le comportement. +% $\bhvpo$ possède donc une structure moins contraignante que $\bhv$. + +% Remarque: lien avec la BDD, Schéma et clef primaire +% Remarque: relations complexes +% La définiton d'un modèle à observables privilégiées n'est pas sans rappeler +% quelques concepts propres au domaine des bases de données relationnelles, +% introduit par \textsc{Codd} dans \cite{codd_relational_1970}. Une signature +% $\sig$ peut-être vue comme un \emph{schéma} et un comportement $\bhv$ comme +% une \emph{relation}. Le concept de \emph{clef primaire} est associé aux éléments +% de $P$ qui ne peuvent avoir qu'une seule image par fonction de $\bhv$ ce qui est +% immédiat d'après l'équation~\ref{eq:bhvpo-bhv}. Dans un modèle à observables +% privilégiées, chaque $p \in P$ identifie de manière unique un tuple de +% $\bhvpo$. + +% Les premières observables privilégiées dont nous voudrions rendre compte sont le +% temps, désigné par $\obsn{Temps}$ où $\cfg(\obsn{Temps})=\Time$, et l'espace, +% désigné par $\obsn{Espace}$ où $\cfg(\obsn{Espace})=\Space$. En effet il est +% habituel de définir la valeur d'une observable par rapport au temps, par rapport +% à l'espace et par rapport au temps et à l'espace. + + +% Cette remarque nous amène d'abord à définir une nouvelle classe de modèle qui +% considèrent le temps comme une observable privilégiée par rapport aux autres. +% Ces modèles sont appelés des \emph{modèles dynamiques} en référence aux systèmes +% dynamiques. + +% \begin{mpo-definition}[Modèle dynamique] +% Un \emph{modèle dynamique} est un modèle à observables privilégiées $M = +% (\Phi_\Time,\bhv)$ où $\Time$ est un ensemble appelé \emph{le domaine +% temporel}. Il existe une relation $\cdot : \Time \times \Time \rightarrow +% \Time$ telle que $(\Time,\cdot)$ possède la structure d'un monoïde, c'est à +% dire que: +% \begin{enumerate} +% \item $\forall a,b,c \in \Time \quad (a \cdot b) \cdot c = a \cdot (b \cdot c)$ +% (associativité) +% \item $e \in \Time, \forall a \in \Time \quad e \cdot a = a \cdot e = a$ +% (existence d'un neutre) +% \end{enumerate} +% Les éléments de $\bhv$ sont appelés les \emph{traces} de $M$. +% \end{mpo-definition} + +% Pour se rapprocher de la théorie des systèmes dynamiques, nous pouvons apporter +% une structure plus contraignante sur un modèle dynamique par la définition +% suivante. + +% \begin{mpo-definition}[Modèle dynamique classique] +% Un \emph{modèle dynamique classique} est un modèle dynamique $M = +% (\Phi_\Time,\bhv)$ où $\Time$ possède la structure d'un monoïde et $\bhv$ +% rempli les propriétés supplémentaires suivantes: +% \[ +% \forall b \in \bhv, +% \forall t_1 \in \Time, +% \exists b' \in \bhv, +% \forall t_2 \in \Time, \qquad +% b(t_1) = b'(0) \quad +% \text{et} \quad +% b(t_1 + t_2) = b'(t_2) +% \] +% \end{mpo-definition} + +% D'où vient le choix d'une structure monoïdale +% Remarque sur memoryless de M +% Petite preuve sur la correspondance systèmes dynamiques / modèles dynamiques + +% Nous pouvons ainsi reformuler le modèle par relation de Malthus afin +% d'expliciter sa nature dynamique. + + +%Constantes des modèles +% Certains modèles ont des constantes permettant de les ajuster suivant le système +% étudié. Ces modèles décrivent en fait une \emph{classe de modèles} pouvant +% décrire plusieurs systèmes à la fois: ils identifient un comportement commun à +% chacun de ces systèmes. Il est ainsi important de remarquer que les constantes +% d'un modèle ne sont \emph{pas des observables} et que nos définitions ne +% concernent que des instances de modèles. Notre but, pour l'instant, est +% d'adresser la question des relations entre modèles d'un même système et pas +% d'identifier plusieurs systèmes décrit par la même classe de modèles. + +% Une autre observable privilégiée est l'\emph{espace}. Similairement au temps qui +% est constitué d'\emph{évè\-nements}, l'espace est constitué de \emph{points}. On +% le définit de manière symétrique aux modèles dynamiques généraux. + +% \begin{mpo-definition}[Modèle spatial] +% Un \emph{modèle spatial} est un modèle à observables privilégiées $M = +% (\Phi_\Space,\bhv)$ possédant un observable nommée \obsn{Espace} où $\bhv$ est +% un appelé un \emph{champ} et les éléments de $\Space$ sont appelés les +% \emph{points} de l'espace. +% \end{mpo-definition} + +% Nous ne fixons pas dans cette définition de structure mathématique propre à +% l'espace. Il ne semble pas évident de trouver un structure permettant de +% représenter les différents usages du concept d'espace. L'espace se +% représenterait-il mieux par un groupe, un espace vectoriel, ou bien une +% structure topologique, plus générale est-elle préférable ? Nous laissons ouvert +% le choix de la structure convenant le mieux en fonction du problème étudié. + +% Exemple 1: le jeu d'échecs +% \begin{mpo-exemple}[Modèle spatial d'un jeu d'échecs] +% \newcommand{\chessk}{\text{Roi}} +% \newcommand{\chessq}{\text{Dame}} +% \newcommand{\chessb}{\text{Fou}} +% \newcommand{\chessn}{\text{Cavalier}} +% \newcommand{\chesst}{\text{Tour}} +% \newcommand{\chessp}{\text{Pion}} + +% Un jeu d'échecs est constitué d'un plateau sur lequel est représentée une +% grille carrée de 8 $\times$ 8 cases de couleurs alternées noire ou blanche où +% deux cases adjacentes n'ont pas la même couleur. Les case noires sont notées +% $\text{even}$ et les cases blanches sont notées $\text{odd}$: +% \[\begin{array}{rcl} +% \text{even} &=& \big\{ (i,j) \in [1 \ldots 8] \times [1 \ldots 8] +% \mid i+j\ \text{est paire} \big\} \\ +% \text{odd} &=& \big\{ (i,j) \in [1 \ldots 8] \times [1 \ldots 8] +% \mid i+j\ \text{est impaire} \big\} \\ +% P &=& \text{odd} \cup \text{even} \\ +% \end{array}\] + +% Sur ce plateau sont disposées 32 pièces divisées en deux équipes de 16 pièces +% blanches et 16 pièces noires. Les pièces des deux équipes sont identiques et +% sont les éléments de l'ensemble suivant, indicés par leur abscisse: +% \[ +% A = \left\{ +% \begin{array}{cccccccc} +% \chessp_1,& \chessp_2,& \chessp_3,& \chessp_4,& \chessp_5,& \chessp_6,& \chessp_7,& \chessp_8, \\ +% \chesst_1,& \chessn_2,& \chessb_3,& \chessq_4,& \chessk_5,& \chessb_6,& \chessn_7,& \chesst_8 +% \end{array} +% \right\} +% \] +% Chacune de ces pièces possède un mode de déplacement qui lui est propre. +% Informellement, à chaque tour un joueur choisi une pièce de sa couleur et la +% déplace en fonction du mode de son mode déplacement: +% \begin{itemize} +% \item un $\chessk$ peut faire exactement un pas dans une des 8 directions, +% \item une $\chessq$ peut faire un pas ou plus dans une des 8 directions, +% \item un $\chessb$ peut faire un pas ou plus dans une des 4 directions +% diagonales, +% \item un $\chessn$ peut effectuer exactement deux pas dans une direction puis +% exactement un pas dans orthogonalement à la direction de départ, +% \item une $\chesst$ peut effectuer un pas ou plus dans une des 4 directions +% verticales ou horizontales et +% \item un $\chessp$ peut effectuer exactement un pas en avant, c'est-à-dire en +% direction de l'équipe adverse. +% \end{itemize} + +% \noindent +% Un modèle spatial $(\Phi_\Space,\bhv)$ des positions accessibles par chacune +% des pièces se défini en posant: + +% \[ \begin{array}{rcl} +% \sig &=& A \times P \\ +% \Space &=& A \\ +% \Phi_\Space &=& P^A \\ +% \bhv &:& A \longrightarrow P \\ +% \bhv(e)&=& \left\{ \begin{array}{ll} +% \text{odd} +% &\text{si}\quad e \in \{ \chessb_6 \} \\ +% \text{even} +% &\text{si}\quad e \in \{ \chessb_3 \} \\ +% \{1\} \times [1 \ldots 8] +% &\text{si}\quad e \in \{ \chessp_1 \} \\ +% \{2\} \times [1 \ldots 8] +% &\text{si}\quad e \in \{ \chessp_2 \} \\ +% \{3\} \times [1 \ldots 8] +% &\text{si}\quad e \in \{ \chessp_3 \} \\ +% \{4\} \times [1 \ldots 8] +% &\text{si}\quad e \in \{ \chessp_4 \} \\ +% \{5\} \times [1 \ldots 8] +% &\text{si}\quad e \in \{ \chessp_5 \} \\ +% \{6\} \times [1 \ldots 8] +% &\text{si}\quad e \in \{ \chessp_6 \} \\ +% \{7\} \times [1 \ldots 8] +% &\text{si}\quad e \in \{ \chessp_7 \} \\ +% \{8\} \times [1 \ldots 8] +% &\text{si}\quad e \in \{ \chessp_8 \} \\ +% P &\text{sinon} +% \end{array} \right. \\ +% \end{array} \] + +% Notez que le cas où un pion se déplacerait en diagonale en prenant une pièce +% ennemie est ici ignoré. +% \end{mpo-exemple} + +% Dans ce modèle, le comportement est un simple map. On ignore toute structure sur +% l'ensemble de départ et l'ensemble d'arrivée. Néammoins, si l'ensemble de départ +% avait eu une structure particulière, $\bhv$ ne l'aurait pas nécessairement +% conservée. Les prochaines définitions décrivent des modèles spatiaux accompagnés +% des structures usuelles. + +% \begin{mpo-definition}[Modèle spatial topologique] +% Un \emph{modèle spatial topologique} est un modèle à observables privilégiées +% $M = (\Phi_\Space,\bhv)$ où $(S,\Space)$ est une topologie et $\bhv$ a sa +% définition usuelle. + +% Notez que dans ce cas, $\Space$ désigne l'ensemble des ouverts. +% \end{mpo-definition} + +% % Exemple 2: Complexe simpliciaux +% \begin{mpo-exemple}[Modèle spatial à complexes simpliciaux] +% Soit $C = (V,F)$ un complexe simplicial abstrait où $V$ désigne l'ensemble des +% sommets et $F$ l'ensemble des faces, c'est-à-dire un ensemble des parties +% non-vides de $V$ stable par sous-partie non vide, et $L$ est un ensemble dont +% les valeurs étiquettent chaque face du complexe simplicial. Un modèle à +% complexes simpliciaux pourrait se décrire comme un modèle spatial topologique +% $(\Phi_\Space,\bhv)$ où: + +% \[ \begin{array}{rcl} +% \sig &=& L \times V \\ +% \Space &=& L \\ +% \Phi_\Space &=& V^L \\ +% \bhv &:& L \longrightarrow V \\ +% \end{array} \] + +% $C$ est un espace topologique car $F$ décrit l'ensemble des ouverts de $V$ et +% $\tau$ est la topologie induite sur $L$ de sorte que $\bhv$ soit une fonction +% continue. +% \end{mpo-exemple} + +%% Exemple 2: un champ de température +%\begin{mpo-exemple}[Modèle spatial d'un champ de température] +% Un modèle spatial $(\Phi_\Space,\bhv)$ d'un champ de température, mesurée en +% Kelvin, dans une pièce close se défini par : +% +% \[ \begin{array}{rcl} +% \sig &=& \mathbb{R}^3 \times [ -273 ; +\infty [ \\ +% \Space &=& \mathbb{R}^3 \\ +% \Phi_\Space &:& ([ -273 ; +\infty [)^{\mathbb{R}^3} +% \end{array} \] +% +%\end{mpo-exemple} + +%Voici par exemple un modèle de répartion hexagonale de points. +%\begin{mpo-exemple}[Modèle spatial d'un(e)] +% Le modèle spatial $(\obs,\dom,\cfg,\bhv_s)$ avec +% \begin{array}{rcl} +% \cfg(\obsn{Espace}) &=& \mathbb{Z}^2 \\ +% \bhv_t &=& \big\{ (t,p(t)) \mid t \in \mathbb{R} \big\} \\ +% p(t) &=& P_0 \, e^{rt} +% \end{array} +% \] +% est un modèle spatial d'une grille hexagonale. +%\end{mpo-exemple} + +% \begin{mpo-definition}[Modèle équationnel] +% Soient $\sig = P \times R$, $(\Phi_P,\bhv)$ un modèle à observables +% privilégiées et $f_1$, $f_2$ deux fonctions de $P$ dans $X$ où $X$ est un +% ensemble d'arrivée quelconque, un modèle équationnel est un triplet +% $(f_1,f_2,\bhv)$ où $f_1$,$f_2 : P \longrightarrow X$ et +% \[ \begin{array}{rl} +% \forall p \in P & f_1(p) = f_2(p) \\ +% \bhv \subset & (R)^P \\ +% \end{array} \] +% \end{mpo-definition} + + +\FloatBarrier +\subsection{Modélisations d'un système proie-prédateur}\label{sec:preypred} + +Nous proposons dans cette dernière section d'illustrer comment les différentes +classes de modèles que nous venons d'énumérer permettent plusieurs +compréhensions d'un même système. Nous nous intéressons en particulier à la +modélisation des systèmes proie-prédateur. + +Un système proie-prédateur est un système dans lequel deux populations, celles +des proies et celle des prédateurs, varient à cause de leurs interactions, dont +la principale est la prédation. Voici deux exemples de ces systèmes: +\begin{itemize} + +\item La variation du nombre d'individus dans les populations de lynx et de + lièvres des neiges, dont un modèle expérimental a été constitué par la + Compagnie de la Baie d'Hudson~\cite{odum_fundamentals_1959}. + +\item La variation du nombre d'individus dans les populations de loups et + d'élans, dont un modèle expérimental a été constitué par le parc national + d'Isle Royale~\cite{peterson_ecological_1997}. + +\end{itemize} +En suivant au cours du temps les tailles des deux populations, il est possible +d'observer des oscillations couplées plus ou moins régulières. À certaines +périodes, un déficit en prédateurs permet aux proies de se développer, alors +qu'à d'autres périodes les prédateurs dominent et les proies se font rares. + +Ces oscillations sont explicables en considérant le comportement des proies et +des prédateurs à partir des trois processus suivants: +\begin{description} + + \item[Naissance:] Les proies se reproduisent en fonction des ressources + disponibles, des individus apparaissent avec un certain taux de natalité. + + \item[Mort:] Les proies et les prédateurs n'étant pas éternels, les individus + disparaissent avec un certain taux de mortalité. + + \item[Prédation:] Il s'agit de l'activité principale des prédateurs et la + seule interaction considérée entre les deux populations; elle est nécessaire + à la reproduction des prédateurs et induit un facteur de mortalité + supplémentaire pour les proies. + +\end{description} +En 1920, A. J. Lotka propose dans~\cite{lotka_analytical_1920} une +description formelle d'un tel modèle à travers un système de réactions +autocatalytiques, à la façon d'un jeu de réaction chimique. L'étude de ce +type de systèmes l'amena quelques années plus tard à proposer une analyse +de la dynamique de ce système sous la forme d'un système d'équations +différentielles couplées~\cite{lotka_elements_1925}. Le même type d'équations +furent également proposées indépendamment par V. Volterra à la même +période~\cite{volterra_fluctuations_1926}. Depuis, plusieurs autres modèles +plus élaborés ont été proposés pour prendre en considération d'autres facteurs +environnementaux, ou encore l'incidence de l'organisation spatiale des +populations. + +%% From Gillespie: +%% (21) A. J. Lotka, J. Am. Chem. SOC., 42, 1595 (1920); Proc. Natl. Acad. Sci. U.S., 6, 410 (1920). +%% (22) For a comprehensive review of Volterra’s and other nonlinear models of interacting populations, see N. S. Goel, S. C. Maitra, and E. W. Montroll, Rev. Mod. Phys., 43, 231 (1971). + +Les études des systèmes proies-prédateurs nous offrent ainsi un échantillon de +modèles nous permettant d'illustrer notre approche. Nous allons dans la suite de +cette section décrire quelques modèles de systèmes proie-prédateur repris des +travaux de A.J. McKane~\cite{mckane_predator-prey_2005,lugo_quasicycles_2008}. + +\paragraph{Modèle \emph{à la} Volterra.} +% +Dans cette description, nous considérons que le système est décrit par +deux observables représentant les densités de population des proies et des +prédateurs. En notant, $U_V$ et $U_P$ respectivement ces densités, les +trajectoires du système au cours du temps sont décrites par le système +d'équations différentielles suivant: +\begin{equation} + \left\{ + \begin{array}{rcl} + \displaystyle\frac{dU_V}{dt} &=& r U_V (1 - \displaystyle\frac{U_V}{K}) + - g U_P U_V\\[1.5ex] + \displaystyle\frac{dU_P}{dt} &=& n U_V U_P - \mu U_P + \end{array} + \right. + \label{eq:volterra} +\end{equation} +Ce modèle dépend des paramètres $r$, $K$, $g$, $n$ et $\mu$. Comme précisé +dans~\cite{mckane_predator-prey_2005}, on rencontre souvent sous le nom de +modèle de Lotka-Volterra ce même système où le terme $U_V/K$ est absent. Le +coefficient $K$ quantifie la capacité limite de l'environnent à accueillir des +individus. + +Cette formalisation permet de constituer un modèle $\model{M}{V}$ +\emph{dynamique à observables}. On définit la signature du modèle par: +$$ +\sig_{\model{M}{V}} = \dom_{\obsn{Initial}} \times \dom_{\obsn{Temps}} \times \dom_{\obsn{Etat}} +$$ +où $\dom_{\obsn{Initial}} = \dom_{\obsn{Etat}} = \mathbb{R}^+ \times +\mathbb{R}^+$ correspondant à des couples \emph{(densité de proie, densité +de prédateur)} et $\dom_{\obsn{Temps}} = \mathbb{R}^+$ avec sa structure de +monoïde usuelle représentant des durées. L'ensemble des faits est donné comme un +sous-ensemble de $\sig_{\model{M}{V}}$ par: +$$ +E_{\model{M}{V}} = \left\{ (U_V(0),U_P(0),t,U_V(t),U_P(t)) + \mid U_V, U_P \textnormal{ sol. de (\ref{eq:volterra})} \right\} + \subset\sig_{\model{M}{V}} +$$ +Une \emph{solution de (\ref{eq:volterra})} correspond à tout couple de fonctions +du temps vérifiant l'équation; toutes les conditions possibles sont prises en +compte. Nous remarquons de plus que la résolution de l'équation se fait une +fois les paramètres fixés. Ainsi, à chaque jeu de paramètres correspondra un +modèle. + +En tant que modèle dynamique, on peut extraire de la définition de +$E_{\model{M}{V}}$ une action de monoïde donnée par: +$$ +\Phi_{\model{M}{V}}( [U_V(0),U_P(0)], t ) = [ U_V(t),U_P(t) ] +$$ +pour chaque élément de $E_{\model{M}{V}}$. + + + +\paragraph{Modèle \emph{à la} Volterra spatialisé.} +% +Dans sa version spatialisée, les densités de population sont distribués sur un +espace particulier, disons l'espace euclidien de dimension 2 $\mathbb{E}^2$, +représentant la région dans laquelle les individus peuvent se déplacer. +En d'autres termes, les densités $U_V$ et $U_P$ deviennent des champs, +respectivement $u_V$ et $u_P$, définis sur $\mathbb{E}^2$. Les équations sont +modifiées en ajoutant un terme de diffusion modélisant ces déplacements: +\begin{equation} + \left\{ + \begin{array}{rcl} + \displaystyle\frac{du_V}{dt} &=& r u_V (1 - \displaystyle\frac{u_V}{K}) + - g u_P u_V + D_V (\nabla^2 u_V + u_V \nabla^2 u_P - u_P \nabla^2 u_V) + \\[1.5ex] + \displaystyle\frac{du_P}{dt} &=& n u_V u_P - \mu u_P + + D_P (\nabla^2 u_P + u_P \nabla^2 u_V - u_V \nabla^2 u_P) + \end{array} + \right. + \label{eq:spacevolterra} +\end{equation} +où $D_V$ et $D_P$ sont les coefficients de diffusion respectifs des populations +de proies et de prédateurs, et $\nabla^2$ dénote le Laplacien. Suivant les +remarques de~\cite{lugo_quasicycles_2008}, les termes exprimant une diffusion +croisée en $(u_V \nabla^2 u_P - u_P \nabla^2 u_V)$ entre les deux populations +sont peu conventionnels mais correspondent à la considération d'une limitation +de la capacité d'accueil de l'environnement. Ces termes disparaissent lorsque +cette limite est levée. + +Il est possible d'associer à ce nouveau système d'équations une extension du +modèle non spatialisé $\model{M}{V}$, un modèle $\model{M}{SV}$ \emph{dynamique +à observables et à base champs}. L'ensemble des faits du modèle se construit de +la même façon que précédemment en prenant en compte l'espace. +$$ +E_{\model{M}{SV}}= \{\; (t,x,y,u_V(0,x,y),u_P(0,x,y),u_V(t,x,y),u_P(t,x,y)) + \mid u_V, u_P \textnormal{ sol. de (\ref{eq:spacevolterra})} \;\} +$$ +En tant que modèle dynamique, on peut extraire de cette définition une action de +monoïde donnée par: +$$ +\Phi_{\model{M}{SV}}( [(x,y) \mapsto u_V(0,x,y),(x,y) \mapsto u_P(0,x,y)], t) + = [(x,y) \mapsto u_V(t,x,y), (x,y) \mapsto u_P(t,x,y)] +$$ +agissant sur l'ensemble des fonctions deux fois différentiables de +$\mathbb{E}^2$ dans $\mathbb{R}^+ \times \mathbb{R}^+$, pour chaque élément de +$E_{\model{M}{SV}}$. + +En tant que modèle à base de champs, une fonction continue donnée par: +$$ +f_{\model{M}{SV}}(t,x,y) = (u_V(0,x,y),u_P(0,x,y),u_V(t,x,y),u_P(t,x,y)) +$$ +peut être extraite de la définition de $E_{\model{M}{SV}}$ en munissant +l'espace de départ $\mathbb{E}^2 \times \mathbb{R}^+$ et l'espace d'arrivée +$\mathbb{R}^+ \times \mathbb{R}^+ \times \mathbb{R}^+ \times \mathbb{R}^+$, de +leurs topologies habituelles. +%% +Une autre approche mettant en avant l'indépendance temps/espace telle que nous +l'avons décrite plus haut, est donnée par la définition suivante: +$$ +f_{\model{M}{SV}}(x,y) = ([u_V(0,x,y),u_P(0,x,y)],t) \mapsto [u_V(t,x,y),u_P(t,x,y)] +$$ +allant de $\mathbb{E}^2$ muni de sa topologie classique vers un espace d'actions +de monoïde. La topologie de cet espace est héritée de celle sur $\mathbb{E}^2$. + +\paragraph{Modèle \emph{à la} Lotka.} +% +Cette approche, radicalement différente des précédentes, est fondée sur les +premières descriptions de A. J. Lotka à base de réactions chimiques. On assimile +le système à une solution chimique de taille fixe composée de $N$ molécules +prises parmi trois types d'éléments différents: $V$ représentant une proie, +$P$ pour un prédateur, et $E$ une place vide. Les interactions entre les trois +espèces chimiques sont régies par les réactions suivantes: +\begin{equation} +\begin{array}{c} + V + E \overset{b}{\longrightarrow} 2\,V \\ + P + V \overset{p_1}{\longrightarrow} 2\,P \qquad P + + V \overset{p_2}{\longrightarrow} P + E \\ + V \overset{d_V}{\longrightarrow} E \qquad P \overset{d_P}{\longrightarrow} E +\end{array} +\end{equation} +On reconnaît facilement les trois processus décrits en début de section: la +naissance d'une proie représentée comme une division cellulaire consommant une +place vide, la prédation qui occasionne certaine fois la reproduction d'un +prédateur, et la mort des deux types d'individus donnant de nouvelles places +vides. Chaque réaction est paramétrée par une constante, appelée \emph{constante +stochastique\footnote{On reprend ici le vocabulaire de D.T. Gillespie qui +discute dans~\cite{gillespie_exact_1977} de la différence entre constante +stochastique et constante cinétique.}}. Cette constante représente le taux avec +lequel le processus correspondant a lieu. En terme de probabilité, $d_V d\tau$ +est par exemple la probabilité infinitésimale qu'une proie meurt de sa belle +mort (c'est-à-dire sans avoir été chassée) pendant l'intervalle de temps +infinitésimal $d\tau$. + +D. T. Gillespie a proposé dans~\cite{gillespie_exact_1977} une méthode de +simulation stochastique exacte de système de réactions chimiques sous hypothèse +d'homogénéité. Nous pouvons ainsi considérer un modèle \emph{dynamique +probabiliste} des systèmes proie-prédateur $\model{M}{L}$ à partir des +trajectoires simulées. De façon informelle, l'ensemble des faits correspond +à toutes ces trajectoires. Chacune de ces trajectoires peut être pondérée +par une probabilité d'occurrence au sein des trajectoires partageant les +mêmes conditions initiales. Ainsi, un sous modèle probabiliste au sens de la +définition~\ref{def:probmodel} peut être établi pour chaque population initiale. + +Nous préférons ici mettre l'accent sur les aspects temporels du modèle. +Ainsi, nous établissons un ensemble de faits, équivalent à celui que nous +venons d'évoquer. Pour se faire, nous considérons d'une part la probabilité +$P(n_V,n_P,t|n_V^0,n_P^0)$ que \emph{le système soit composé de $n_V$ proies +et $n_P$ prédateurs au temps $t$ considérant une population initiale de +$n_V^0$ proies et $n_P^0$ prédateurs}, et d'autre part, le domaine \emph{fini} +$\dom_\obsn{Pop}$ des populations possibles: +$$ +\dom_\obsn{Pop} = \{ (n_V,n_P)\in \mathbb{N}^2 \mid n_V + n_P \le N \} +$$ +Considérant que les densités de probabilité sur $\dom_\obsn{Pop}$ sont des +fonctions $d:\dom_\obsn{Pop} \rightarrow [0,1]$ telles que +$$ +\sum_{s\in\dom_\obsn{Pop}} d(s) = 1, +$$ +l'action de monoïde\footnote{On montre facilement qu'il s'agit d'une action de +monoïde en remarquant que +$$ +P(s',0|s) = \delta_s^{s'} +\qquad +P(s,t_1 + t_2|s'') = \sum_{s'\in\dom_\obsn{Pop}} P(s,t_2|s') P(s',t_1|s'') +$$} de $\mathbb{R}^+$ est défini sur les densités de probabilité par: +$$ +\Phi_{\model{M}{L}}(d, t) = s \mapsto \sum_{s' \in \dom_\obsn{Pop}} d(s') P(s,t|s') +$$ +pour finalement obtenir la description de $\model{M}{L}$ comme un modèle +dynamique. + +\paragraph{Modèle \emph{à la} Lotka spatialisé.} +% +L'objet principal présenté dans~\cite{lugo_quasicycles_2008} est une version +spatialisée du modèle à base de réactions chimiques $\model{M}{L}$ que nous +venons de voir. L'extension consiste en deux points: +\begin{enumerate} + + \item Le modèle $\model{M}{L}$ est copié sur chaque position d'une + organisation spatiale discrète $\Omega$. Afin de se rapprocher du modèle + $\model{M}{SV}$, on définit $\Omega$ comme un ensemble d'indices permettant + d'identifier les positions d'une grille carrée à 2 dimension. Chaque + molécule est alors positionnée: $V^i$, $P^i$ et $E^i$ correspondent + respectivement à une proie, un prédateur et une place libre en position $i + \in \Omega$. + + \item Les réactions chimiques de $\model{M}{L}$ sont également positionnées + sur $\Omega$, et deux règles de déplacement sont ajoutées pour simuler le + mouvement des individus: + \begin{equation} + \begin{array}{c} + V^i + E^i \overset{b}{\longrightarrow} 2\,V^i \\ + P^i + V^i \overset{p_1}{\longrightarrow} 2\,P^i \qquad + P^i + V^i \overset{p_2}{\longrightarrow} P^i + E^i\\ + V^i \overset{d_V}{\longrightarrow} E^i \qquad + P^i \overset{d_P} {\longrightarrow} E^i\\ + V^i + E^j \overset{m_V}{\longrightarrow} E^i + V^j \qquad + P^i + E^j \overset{m_P}{\longrightarrow} E^i + P^j + \end{array} + \end{equation} + pour toutes positions \emph{voisines} $i, j \in \Omega$. + +\end{enumerate} +Cette extension formalise un nouveau modèle $\model{M}{SL}$ qui est à la fois +\emph{probabiliste, dynamique et à base de champ}. + +Nous n'entrerons pas dans les détails de ces définitions qui restent +très proches des constructions que nous avons déjà vues. Cependant, nous +pouvons en conclure que les modèles $\model{M}{V}$, $\model{M}{SV}$, +$\model{M}{L}$ et $\model{M}{SL}$ sont proches les uns des autres. +Dans~\cite{mckane_predator-prey_2005, lugo_quasicycles_2008} se trouvent +d'ailleurs les clés de ces relations, expliquant comment établir des ponts +formels entre les modèles. Ainsi, on constatera que $\model{M}{V}$ décrit le +comportement moyen des trajectoires de $\model{M}{L}$, alors que $\model{M}{SV}$ +coïncide avec $\model{M}{V}$ lorsque les densités de populations sont +spatialement homogènes. + +Dans la suite, nous proposons un cadre formel pour décrire ces relations. +Notre construction se fonde sur la notion d'abstraction telle que celle que +nous avons de mentionné rapidement entre $\model{M}{V}$ et $\model{M}{L}$, +ou entre $\model{M}{V}$ et $\model{M}{SV}$. L'abstraction autorise également +la composition de modèles pour obtenir des descriptions plus précises +couplant des travaux initialement indépendants. Ainsi, on pourra poser la +question d'un modèle permettant de coupler à la fois $\model{M}{SV}$ et +$\model{M}{L}$, combinant d'un part une représentation stochastique des +interactions individuelles, et la dynamique de la répartition spatiale des +populations d'autre part. On pourra également s'intéresser aux relations +entre ce couplage et la description proposée par $\model{M}{SL}$. La +\textsc{Fig.}~\ref{fig:model-lv} synthétise cette situation. + +\begin{figure}[ht] + \centering + \includegraphics[page=1,width=.60\textwidth]{schema-lv} + \caption{Comment définir le couplage des modèles $\model{M}{SV}$ et + $\model{M}{L}$ ? Quel rapport existe-t-il entre ce couplage et + $\model{M}{SL}$ ?} + \label{fig:model-lv} +\end{figure} + + + + + +% Comme ces trois modèles décrivent le même système, il devrait être possible d'en +% caractériser les relations. \modelVolterra décrit la dynamique \emph{moyenne} de +% chaque population, alors que \modelLotka nous fourni, à chaque instant, les +% quantités discrètes d'indivivdus de chaque population. Intuitivement, +% \modelVolterra est moins détaillé que \modelLotka, et nous dirons donc qu'il en +% constitue une abstraction. \modelVolterra décrit la dynamique moyenne de chaque +% population \emph{aggrégée} en un unique point de l'espace: à chaque instant les +% deux populations se recouvrent, alors que \modelSVolterra décrit également la +% dynamique de répartition spatiale des populations. De ce point de vue, +% \modelVolterra est moins détaillé que \modelSVolterra et nous dirons également +% qu'il en constitue une abstraction. Existe-t-il un modèle \modelSLotka tel que +% \modelSVolterra soit une abstraction de \modelSLotka et tel que \modelLotka soit +% une abstraction de \modelSLotka? + +% Dans la suite de cette section, nous introduirons le cadre théorique nécessaire +% à la définition formelle de cette flèche d'abstraction. + + + + +% Chacun de ces systèmes peut être décrit grâce aux différents modèles classiques +% suivants: le modèle de Volterra généralisé, à équations différentielles que l'on +% notera \modelVolterra et le modèle de Lotka généralisé, à réactions chimiques +% que l'on notera \modelLotka. Ces deux modèles sont généralisés, c'est-à-dire +% qu'ils sont paramétrés pour pouvoir décrire, suivant les valeurs de leurs +% paramètres, différents systèmes proie-prédateurs. + +% % http://www.scholarpedia.org/article/Predator-prey_model +% %Kolmogorov predator-prey model +% \begin{mpo-definition} Le modèle \modelVolterra décrit la variation de trois +% observables: la concentration de \obsn{Prédateur}, la concentration de +% \obsn{Proie} et le \obsn{Temps}. C'est donc le modèle dynamique définit comme +% le couple $(\Phi_\Time,\bhv)$ où $\Phi_\Time = \big(\cfg(\obsn{Prédateur}) +% \times \cfg(\obsn{Proie})\big)^\Time$ avec +% \begin{align*} +% \cfg(\obsn{Prédateur}) &=[\SI{0,0}{}\mathop{;}\SI{1,0}{}]\\ +% \cfg(\obsn{Proie}) &=[\SI{0,0}{}\mathop{;}\SI{1,0}{}]\\ +% \Time &= \mathbb{R} +% \end{align*} +% et où les trajectoires autorisées sont définies par le système d'équation +% couplées suivantes, en prenant $u_v$ comme variable pour l'observable +% \obsn{Proie}, $u_p$ pour \obsn{Prédateur} et $t$ pour $\Time$: +% \begin{equation} +% \left\{ +% \begin{array}{rcl} +% \displaystyle\frac{du_v}{dt} &=& u_v(\alpha_1 - \beta_1 u_p)\\[1.5ex] +% \displaystyle\frac{du_p}{dt} &=& u_p(\gamma_1 u_v - \delta_1) +% \end{array} +% \right. +% \label{eq:m1} +% \end{equation} +% Ce modèle équationnel de Lotka-Volterra décrit par deux équations +% différentielles couplées le comportement d'une \emph{classe} de systèmes +% proie-prédateur ayant pour paramètre $(\alpha_1, \beta_1, \gamma_1, +% \delta_1)$. +% \end{mpo-definition} + +% \begin{mpo-definition} Le modèle \modelLotka décrit la variation de trois +% observables: la quantité de \obsn{Prédateurs}, la quantité de \obsn{Proies} et +% le \obsn{Temps}. \modelLotka est un modèle dynamique définit comme le couple +% $(\Phi_\Time, \bhv)$ où $\Phi_\Time = \big( \cfg(\obsn{Prédateurs}) \times +% \cfg(\obsn{Proies}) \big)^\Time$ avec +% \begin{align*} +% \cfg(\obsn{Prédateurs}) &= \mathbb{N}_+\\ +% \cfg(\obsn{Proies}) &= \mathbb{N}_+\\ +% \Time &= \mathbb{R}_+ +% \end{align*} +% et où les trajectoires autorisées, \bhv, sont définies par les quatre +% équations de réécriture suivantes, en prenant $v$ comme variable pour +% l'observable \obsn{Proies} et $p$ pour \obsn{Prédateurs}. Toutes les +% observables sont \emph{implicitement modélisées} par ces équations, nous les +% définirons explicitement par une simulation de ces quatre équations par la +% méthode de Gillespie, afin d'obtenir les quantité de proies et de prédateurs +% et d'orchestrer tous les évènements successifs sur un temps continu. +% \begin{align*} +% v & \overset{\alpha_2}{\longrightarrow} 2\,v \\ +% v + p & \overset{\beta_2}{\longrightarrow} p \\ +% v + p & \overset{\gamma_2}{\longrightarrow} 2\,p \\ +% p & \overset{\delta_2}{\longrightarrow} . +% \end{align*} +% \modelLotka est modèle de Markov à temps continu qui décrit par quatre +% équations de réaction chimique le comportement d'une classe de systèmes +% proie-prédateur dont les paramètres sont $(\alpha_2, \beta_2, \gamma_2, +% \delta_2)$. +% \end{mpo-definition} + +% À ces deux modèles clasisques, on propose d'ajouter une version spatialisée de +% \modelVolterra, appelé \modelSVolterra. + +% \begin{mpo-definition} Le modèle \modelSVolterra décrit les variations des +% observables: concentration de \obsn{Proie}, concentration de \obsn{Prédateur}, +% coordonnées dans l'\obsn{Espace} et dans le \obsn{Temps}. \modelSVolterra est +% un modèle spatio-temporel définit comme le couple $(\Phi_{\Space \times +% \Time},\bhv)$ où $\Phi_{\Space \times \Time} = \big( \cfg(\obsn{Proie}) +% \times \cfg(\obsn{Prédateur}) \big)^{\Space \times \Time}$ avec: +% \begin{align*} +% \cfg(\obsn{Prédateur}) &= [\SI{0,0}{}\mathop{;}\SI{1,0}{}]\\ +% \cfg(\obsn{Proie}) &= [\SI{0,0}{}\mathop{;}\SI{1,0}{}]\\ +% \Space &= \mathbb{R}\times\mathbb{R}\\ +% \Time &= \mathbb{R} +% \end{align*} +% et où les trajectoires autorisées, \bhv, sont définies par les deux équations +% différentielles partielles couplées suivantes, pour lequelles $u_v$ correspond +% à l'observable \obsn{Proie}, $u_p$ à \obsn{Prédateur}, $t$ à \obsn{Temps} et, +% cachées dans le laplacien en deux dimensions $\Delta$, les variables $x,y$ +% correspondent à l'observable \obsn{Espace}: +% \begin{equation*} +% \left\{ +% \begin{array}{l} +% \displaystyle\frac{du_v}{dt} = u_v(\alpha_3 - \beta_3 u_p) % +% + D_v\.\laplacien u_v \\[1.5ex] +% \displaystyle\frac{du_p}{dt} = u_p(\gamma_3 u_v - \delta_3) % +% + D_p\.\laplacien u_p +% \end{array} +% \right. +% \end{equation*} +% Ce modèle équationnel spatialisé de Volterra décrit par deux équations +% différentielles partielles couplées le comportement d'une \emph{classe} de +% systèmes proie-prédateur ayant pour paramètre $(\alpha_3, \beta_3, \gamma_3, +% \delta_3, D_V, D_p)$. +% \end{mpo-definition} + + + + + + + + + + + + + + + + +%\FloatBarrier +\section{Composition des modèles}\label{sec:compmodel} + +Les sections~\ref{sec:multiniveau} et~\ref{sec:consmodel} nous ont amené à voir +un modèle comme un ensemble de faits. De ce point de vue, la comparaison entre +modèles est limitée à l'étude de leurs propriétés ensemblistes. +%% +Comme nous l'avons vu section~\ref{sec:multiniveau}, l'abstraction entre +modèles est un élément clé de la modélisation multi-niveau. Nous proposons +ici d'en faire une interprétation ensembliste permettant de raffiner et +coupler différents modèles d'un même système. Ainsi, le passage d'un +modèle $\model{M}{+}$ à un modèle $\model{M}{-}$ s'effectue à travers la +reconnaissance d'une \emph{flèche d'abstraction} entre ces modèles définie +de la façon suivante: \emph{si $\model{M}{+}$ est une abstraction de +$\model{M}{-}$, alors chaque fait de $\model{M}{-}$ peut être associé à un fait +de $\model{M}{+}$}. L'étude des relations entre les modèles proie/prédateur de +la section~\ref{sec:preypred} illustre ce type de construction; les trajectoires +stochastiques du modèle probabiliste sont associées aux trajectoires moyennes du +modèle déterministe. + +Cette description nous amène à considérer l'ensemble des fonctions de +$\model{M}{-}$ vers $\model{M}{+}$, chacune comprise comme une relation +d'abstraction possible entre les deux modèles. Cependant, il est raisonnable +de se demander si toutes ces fonctions sont éligibles au titre d'abstraction. +Ce n'est définitivement pas le cas au regard de l'exemple des modèles de +proie/prédateur. La construction de la flèche d'abstraction repose sur des +techniques mathématiques précises qui assurent une cohérence entre les +trajectoires stochastiques et les trajectoires déterministes. Cette cohérence +vient du fait que les deux modèles développent deux compréhensions différentes +du \emph{même} système, et une fonction arbitrairement choisie entre les +ensembles de faits de $\model{M}{-}$ et de $\model{M}{+}$ a peu de chance de +respecter ce \emph{rapport au système}. Comparer deux modèles d'un système +proie-prédateur a du sens, justement car ce sont deux modèles du même système, +ils parlent de la même «chose»: les faits de $\model{M}{-}$ concernant les +proies sont envoyés vers des faits de $\model{M}{+}$ concernant les proies, les +prédateurs de $\model{M}{-}$ vers les prédateurs de $\model{M}{+}$, le temps de +$\model{M}{-}$ vers le temps de $\model{M}{+}$, l'espace de $\model{M}{-}$ vers +l'espace de $\model{M}{+}$, etc. Il est raisonnable donc d'attendre que les +flèches d'abstraction soient les fonctions de $\model{M}{-}$ vers $\model{M}{+}$ +qui respectent la \emph{sémantique} imposée par le système. + +En se référant aux notations précédentes, il est clair qu'un modèle $\modelM$ +ne peut être restreint qu'à son seul ensemble de faits $E_\modelM$. Il est +nécessaire de lui associer également une sémantique $\sigma_\modelM$. La +question qui nous est alors posée est comment formaliser cette sémantique. Nous +développons ici une proposition fondée sur la définition usuelle des modèles vus +comme des \emph{abstractions} du système. La sémantique $\sigma_\modelM$ serait +alors vu comme une flèche d'abstraction au sens que nous venons d'évoquer. +L'idée générale consiste donc, pour un système $S$ donné, de considérer un +\emph{modèle de référence} $\model{M}{S}$ auquel tout autre modèle $\modelM$ de +$S$ se rapportera par une fonction $\sigma_\modelM$ allant de $E_{\model{M}{S}}$ +vers $E_\modelM$. + +Dans cette section, nous proposons d'utiliser la théorie des catégories pour +élaborer un cadre formel suffisant à la réalisation de cette proposition. Pour +plus de clarté, nous commençons par une instanciation informelle dans le cadre +des sciences expérimentales. Nous introduisons ensuite les éléments de la +théorie des catégories nécessaires à la compréhension de notre formalisation +avec laquelle nous clôturerons le chapitre. + +%\FloatBarrier +\subsection{Application en sciences expérimentales}\label{sec:scexp} + +La méthodologie que nous proposons est adaptée au cadre des sciences +expérimentales où le rapport entre un modèle et le système qu'il décrit est +donné par l'expérience. En effet, le contexte expérimental nous invite à +considérer comme modèle de référence d'un système $S$, l'ensemble de tous les +résultats d'expériences possibles sur $S$. Tout modèle sera alors \emph{validé} +s'il est en accord avec l’expérience, c'est-à-dire lorsque les faits +expérimentaux seront associés aux faits que le modèle décrit. +%% +La \textsc{Fig.}~\ref{fig:model-validation} illustre la situation: le modèle +$\modelM$ se rapporte au système $S$ \emph{via} le modèle expérimental +$\model{M}{S}$. Ce lien est noté ici par une flèche d'abstraction qui correspond +à la validation du modèle $\modelM$ faisant appel à une démarche expérimentale +usuelle: +\begin{enumerate} + + \item Collecter des données par des mesures, des expériences: peupler + $\model{M}{S}$ + + \item Proposer un modèle permettant de rendre compte de ces mesures: + construire le modèle $\modelM$ + + \item \emph{Valider} les prédictions du modèles en les comparant aux mesures + directement prises du système étudié: établir la fonction + $\sigma_{\model{M}{S}}$ de $\model{M}{S}$ vers $\modelM$. + +\end{enumerate} +Nous noterons en particulier dans cette figure la frontière claire, représentée +en pointillés, entre les modèles et le système: le système $S$ n'est pas un +modèle et les flèches d'abstraction et notamment les validations, ne relient +que des modèles. On montre ici que la modélisation dépend de la qualité des +expérimentations (par exemple de la précision des outils de mesure utilisés) +et peut être réévaluée (soit en rejetant un modèle, soit en l'approuvant plus +fortement encore) avec l'évolution des méthodes expérimentales, c'est-à-dire en +reconsidérant la définition de $\model{M}{S}$. + +\begin{figure}[ht] + \centering + \includegraphics[page=1,width=.45\textwidth]{model-relations} + \caption{Représentation schématique de la relation entre un modèle $\modelM$ + et un système $S$ où $\model{M}{S}$ est le modèle de référence.} + \label{fig:model-validation} +\end{figure} + +Pour illustrer nos propos, considérons le système expérimental $S$ suivant: +un ballon de baudruche gonflé à l'azote est attaché au fond d'une cuve d'eau +maintenue à \SI{20}{\celsius}, entièrement immergé. On cherche à comprendre la +force de traction qu'exerce le ballon à son point de fixation. + +On remarque après quelques tests que cette force dépend du volume $V_e$ +qu'occupe le ballon, sachant que celui-ci éclatera au-delà d'un volume maximal +$V_\mathrm{max}$. + +Deux modélisateurs s'attaquent au problème et cherchent à établir une loi +reliant force et volume. Après avoir longuement considéré les +données récoltées, ils proposent les modèles suivants: +\begin{description} + + \item[Modèle $\model{M}{1}$:] + le premier modélisateur établit que \emph{la relation entre la force et le + volume repose sur un rapport de proportionnalité} en accord avec la poussée + d'Archimède et propose le modèle équationnel: + $$ + E_{\model{M}{1}} = \{ (F,V) \in \dom_\obsn{Traction} \times \dom_\obsn{Volume} + \mid F= c_0 V \} \uplus \{ \bot, \mathit{éclaté} \} + $$ + à deux observables $\obsn{Traction}$ (en Newton dans $\dom_\obsn{Traction} = + \mathbb{R}^+$) représentant la force de traction verticale et orientée vers + le haut au point de fixation $P$ du ballon, et $\obsn{Volume}$ (en mètre + cube dans $\dom_\obsn{Volume} = \mathbb{R}^+$), le volume de fluide déplacé. + Le coefficient de proportionnalité $c_0 = \rho_E g$ est donné par $\rho_E = + \SI{1.0}{\kilogram\per\metre\cubed}$, la masse volumique de l'eau, et $g = + \SI{9.81}{\newton\per\kilogram}$, l'accélération de la pesanteur terrestre. + + La validation de ce modèle passe par une comparaison entre les mesures faites + expérimentalement et les résultats théoriques apportés par la loi proposée. + Il s'avère que dans une certaine marge, à savoir lorsque le volume $V$ + déplacé est supérieure à un seuil $V_a$ (c'est-à-dire lorsque le ballon est + suffisamment gonflé mais qu'il n'a pas encore éclaté), les calculs produisent + des résultats très proches de l'observation, l'écart pouvant être attribué + à l'appareil de mesure\footnote{Plus précisément, la différence observée + peut être expliquée par la non prise en compte dans $\model{M}{1}$ du poids + du ballon et de l'azote qu'il contient. On peut en effet rajuster la force + s'exerçant au point de contact par l'équation $F = (c_0 - c_1) V - c_2$ + où $c_1 = \rho_N g$ avec $\rho_N = \SI{1.25}{\gram\per\liter}$ à la masse + volumique de l'azote, et $c_2 = m_B g$ avec $m_B$ la masse du ballon (de + l'ordre d'une dizaine de grammes par exemple).}. En dehors de cette marge, + l'équation proposée est fausse, et l'on peut se reporter sur le symbole + $\mathit{éclaté}$ pour les volumes $V > V_\mathrm{max}$, ou sur le symbole + $\bot$ représentant l'absence d'explication par le modèle $\model{M}{1}$ + lorsque $V < V_a$. Ainsi la sémantique de $\model{M}{1}$ revient à associer + à une mesure expérimentale $V_e$ du volume du ballon, le calcul théorique + lorsque l'on est dans l'intervalle d'acceptation $[V_a,V_\mathrm{max}]$ du + modèle: + $$ + \sigma_{\model{M}{1}}(V_e) = + \left\{ \begin{array}{ll} + \bot & \textnormal{si } V_e < V_a\\ + (c_0 V_e, V_e) & \textnormal{si } V_a \le V_e < V_\mathrm{max} \\ + \mathit{éclaté} & \textnormal{si } V_e = \mathit{éclaté} + \end{array}\right. + $$ + + %% Deux particularités : on voit qu'un modèle peut proposer plus de faits que + %% nécessaires, mais ceux-ci ne sont pas adressé par la sémantique, et qu'un + %% modèle peut proposer un << absorbant >> comme $\bot$ pour les faits qu'il + %% n'est pas capable d'expliquer. + + \item[Modèle $\model{M}{2}$:] + Dans ce second modèle décrivant le système de manière qualitative, les + observables sont données empiriquement par des valeurs discrètes symboliques: + $$ + E_{\model{M}{2}} = \{ (\mathit{faible},\mathit{petit}), + (\mathit{faible},\mathit{moyen}), + (\mathit{forte},\mathit{moyen}), + (\mathit{forte},\mathit{gros}), + \mathit{éclaté} \} + $$ + La sémantique de ce second modèle, moins précis, repose simplement sur une + observation visuelle du ballon. + %% + Pour ce qui est de la force exercée, lorsque le nœud du ballon \emph{semble} + tendu, la traction est considérée $\mathit{forte}$, sinon $\mathit{faible}$. + %% + La taille du ballon est appréciée sur une échelle à 3 niveaux + ($\mathit{petit}$, $\mathit{moyen}$, $\mathit{gros}$), sans compté l'état + $\mathit{éclaté}$. En définitif, les mesures expérimentales du volume $V_e$ + sont classées en quatre catégories définies par trois valeurs seuils $V_k$ + ($k\in\{1,2,3\}$) à travers la sémantique suivante: + $$ + \sigma_{\model{M}{2}}(V_e) = + \left\{ \begin{array}{ll} + (\mathit{faible},\mathit{petit}) & \textnormal{si } V_e < V_1 \\ + (\mathit{faible},\mathit{moyen}) & \textnormal{si } V_1 \le V_e < V_2\\ + (\mathit{forte},\mathit{moyen}) & \textnormal{si } V_2 \le V_e < V_3 \\ + (\mathit{forte},\mathit{gros}) & \textnormal{si } V_3 \le V_e < V_\mathrm{max}\\ + \mathit{éclaté} & \textnormal{si } V_e = \mathit{éclaté} + \end{array}\right. + $$ +\end{description} + +Il est clair que le modèle $\model{M}{2}$ est plus abstrait que $\model{M}{1}$. +Formellement, on peut traduire cette abstraction en mettant en relation +les faits constituant les deux modèles à travers une fonction $a$ de +$E_{\model{M}{1}}$ vers $E_{\model{M}{2}}$. Pour les besoins de l'exemple, on +suppose que $V_a < V_1$. La flèche d'abstraction $a$ est définie par: +$$ + a(s) = + \left\{\begin{array}{ll} + (\mathit{faible},\mathit{petit}) & \textnormal{si } s = \bot\\ + (\mathit{faible},\mathit{petit}) & \textnormal{si } s = (F,V) + \textnormal{ et } V < V_1\\ + (\mathit{faible},\mathit{moyen}) & \textnormal{si } s = (F,V) + \textnormal{ et } V_1 \le V < V_2\\ + (\mathit{forte},\mathit{moyen}) & \textnormal{si } s = (F,V) + \textnormal{ et } V_2 \le V < V_3\\ + (\mathit{forte},\mathit{gros}) & \textnormal{si } s = (F,V) + \textnormal{ et } V_3 \leq V < V_\mathrm{max}\\ + \mathit{éclaté} & \textnormal{si } s = (F,V) + \textnormal{ et } V_\mathrm{max} \le V\\ + \mathit{éclaté} & \textnormal{si } s = \mathit{éclaté} + \end{array}\right. +$$ +Il est facilement de vérifier que la fonction d'abstraction $a$ respecte les +sémantiques proposées par : +$$ +\sigma_{\model{M}{2}} = a \circ \sigma_{\model{M}{1}} +$$ +Autrement dit, tout fait expérimental (représenté ci-dessus par une mesure +$V_e$) est envoyée vers le même fait de $\model{M}{2}$ en passant soit +directement par la sémantique de $\model{M}{2}$, soit indirectement en utilisant +la sémantique de $\model{M}{1}$ composée avec la fonction d'abstraction. Cette +situation est illustrée \textsc{Fig.}~\ref{fig:model-abstraction}. + +\begin{figure}[ht] + \centering + \includegraphics[page=2,width=.45\textwidth]{model-relations} + \caption{Représentation schématique de la relation d'abstraction entre deux + modèles $\model{M}{1}$ et $\model{M}{2}$ assujettis à leur validation par + rapport au modèle de référence $\model{M}{S}$. Le modèle $\model{M}{2}$ est + une abstraction de $\model{M}{1}$.} + \label{fig:model-abstraction} +\end{figure} + + +%\FloatBarrier +\subsection{Introduction aux catégories} + +Nous pensons que la théorie des catégories propose un cadre mathématique +adapté à la formalisation des notions que nous venons d'évoquer. En +particulier, les diagrammes donnés \textsc{Fig.}~\ref{fig:model-abstraction} +et \textsc{Fig.}~\ref{fig:model-lv} sont typiques de cette théorie. Dans cette +section, nous introduisons les éléments catégoriques nécessaires pour atteindre +notre objectif. + +\subsubsection{Catégorie} + +Une catégorie est constituée de deux types d'éléments appelés objets et +morphismes. Dans une représentation diagrammatique, les premiers sont en général +représentés par des sommets et les seconds par des flèches. Une catégorie +représente formellement comment les flèches peuvent se composer pour transiter +d'objet en objet. + +\begin{mpo-definition}[Catégorie~\cite{adamek_abstract_2004}] + Une \emph{catégorie\footnote{localement petite}} est un quadruplet $\cat{K} = + (O_\cat{K},\khom_\cat{K},\kid_\cat{K},\circ_\cat{K})$ où + \begin{enumerate} + + \item $O_\cat{K}$ est une classe\footnote{Dans la théorie des ensembles, les + \emph{classes} ont été introduites afin d'éviter les contradictions issues + d'énoncés tels que le paradoxe de Russell (\emph{Est-ce que l'ensemble des + ensembles n'appartenant pas à eux-même, $x \notin x$, appartient à lui-même + ?}). Tout comme les ensembles, les classes sont des collections d'éléments + pouvant être caractérisées par un prédicat d'appartenance. La différence + entre ensembles et classes tient à la limitation imposée sur les prédicats + d'appartenance des ensembles par les axiomatisations utilisées (Z, ZF, ZFC, + etc.). Ainsi tout ensemble est une classe, mais certaines classes, dites + propres, ne sont pas des ensembles.}, + dont les membres sont appelés des \emph{\objs{K}}; + + \item pour chaque paire d'objets $(A,B)$ de $\cat{K}$, $\khom_\cat{K}(A,B)$ + est un ensemble dont les membres sont appelés des \mrphs{K} de $A$ vers $B$: + on appelle $A$, le domaine de $f$ (noté $\kdom(f)$) et $B$, le codomaine + de $f$ (noté $\kcod(f)$)\footnote{Pour assurer l'unicité du domaine et du + codomaine, les ensembles $\khom_\cat{K}(A,B)$ sont supposés deux à deux + disjoints.}; l'expression $f \in \khom_\cat{K}(A,B)$ est également notée + \morphism{f}{A}{B} ou encore $f : A \rightarrow B$; + + \item pour chaque \obj{K} $A$, $\kid_\cat{K}(A)$ est un morphisme de $A$ vers + $A$ appelé la $\cat{K}$-identité sur $A$, également noté $\kid_A$; + + \item $\circ_\cat{K}$ est une loi de composition associant à chaque paire de + \mrphs{K} $(f : A \rightarrow B, g : B \rightarrow C)$ un \mrph{K} $(g + \circ_\cat{K} f) : A \rightarrow C$, appelé la composition de $f$ et $g$, + assujettie aux conditions suivantes: + \begin{enumerate} + + \item la composition est associative: tout triplet de \mrphs{K} $(f: A + \rightarrow B,g: B \rightarrow C,h: C \rightarrow D)$ vérifie l'équation + $h circ_\cat{K} (g \circ_\cat{K} f) = (h \circ_\cat{K} g) \circ_\cat{K} + f$; + + \item les $\cat{K}$-identités sont neutres pour la composition: pour + tout \mrph{K} $f : A \rightarrow B$, on a $\kid_B \circ_\cat{K} f = f = f + \circ_\cat{K} \kid_A$. + + \end{enumerate} + + \end{enumerate} +\end{mpo-definition} + +La difficulté de la présentation des catégories vient de son caractère +désincarné. Voici quelques exemples de catégories que nous avons déjà évoquées +et dont nous ferons usage dans la suite. + +\begin{mpo-exemple}[Catégorie des ensembles]\label{def:cat} + On note $\cat{Set} = + (O_\cat{Set},\khom_\cat{Set},\kid_\cat{Set},\circ_\cat{Set})$ la catégorie des + ensembles où: + \begin{enumerate} + + \item $O_\cat{Set}$ est la classe de tous les ensembles, + + \item $\khom_\cat{Set}(A,B)$ pour deux ensembles $A$ et $B$ est l'ensemble des + fonctions de $A$ dans $B$, + + \item $\kid_\cat{Set}(A)$ est la fonction identité pour chaque ensemble $A$, + et + + \item $\circ_\cat{Set}$ est l'opérateur de composition de fonctions usuel en + théorie des ensembles. + + \end{enumerate} +\end{mpo-exemple} + +\begin{mpo-exemple}[Catégorie des espaces topologiques] + La catégorie des espaces topologiques $\cat{Top}$ a pour objets les espaces + topologiques et pour morphismes, les fonctions continues. Pour tout espace + $\Space$, $\kid_\Space$ est la fonction identité (toujours continue). La + composition est la composition de fonctions usuelle dont on peut montrer + qu'elle respecte la continuité: toute composition de fonctions continues est + continue. +\end{mpo-exemple} + +\begin{mpo-exemple}[Catégorie des monoïdes] + La catégorie des monoïdes $\cat{Mon}$ a pour objets les monoïdes et pour + morphismes, les \emph{morphismes de monoïdes}, c'est-à-dire les fonctions $h : + \Time_1 \rightarrow \Time_2$ respectant les neutres et les lois de composition + internes: + $$ + h(0_{\Time_1}) = 0_{\Time_2} + \qquad + h(x +_{\Time_1} y) = h(x) +_{\Time_2} h(y) + $$ + Là encore, l'identité et la composition usuelles respectent la + définition~\ref{def:cat} et sont utilisées pour compléter la définition de + $\cat{Mon}$. +\end{mpo-exemple} + +\begin{mpo-exemple}[Catégorie des actions de monoïdes] + On définit la catégorie $\cat{AMon}$ ayant pour objets les actions de monoïdes + définies précédemment. On définit un morphisme entre deux actions $\Phi: E + \times \Time \rightarrow E$ et $\Phi':E' \times \Time' \rightarrow E'$ comme + un couple $\langle h,f \rangle$ où $h$ est un morphisme de monoïde de $\Time$ + dans $\Time'$, et $f$ est une fonction de $E$ dans $E'$ tels que pour tout + $t\in\Time, x\in E$: + $$ + \Phi'(f(x), h(t)) = f(\Phi(x,t)) + $$ + Il est aisé de montrer que + $$ + \kid_\cat{AMon}(\Phi) = \langle \kid_\cat{Mon}(\Time),\kid_\cat{Set}(E) \rangle + \qquad + \langle h,f \rangle \circ_\cat{AMon} \langle h',f' \rangle = \langle h \circ_\cat{Mon} h',f \circ_\cat{Set} f' \rangle + $$ +\end{mpo-exemple} + +La théorie des catégories s'attache à comprendre les objets à travers les +propriétés de transition qu'exposent les morphismes. La définition de +$\cat{Top}$ par exemple nous invite à comprendre les espaces topologiques à +travers les fonctions continues. Ce point de vue est illustré par la notion +d'\emph{isomorphisme}, qui s'intéresse à savoir si deux objets ont des rôles +interchangeables dans un catégorie. La définition qui suit repose uniquement sur +les flèches reliant les deux objets concernés. +%% +\begin{mpo-definition}[Objets isomorphes]\label{def:isomor} +Soit $\cat{K}$ une catégorie. Deux \objs{K} $A$ et $B$ sont dits +\emph{isomorphes} s'il existe une paire de \mrphs{K} $f:A \rightarrow B$ et $g: +B \rightarrow A$ tels que: +$$ +\kid_A = g \circ_\cat{K} f +\qquad\textnormal{ et }\qquad +\kid_B = f \circ_\cat{K} g +$$ +Les morphismes $f$ et $g$ sont qualifiés d'\emph{isomorphismes}. +\end{mpo-definition} + +Les objets extrémaux sont un exemple de propriété, là encore décrits en terme de +flèches. +\begin{mpo-definition}[Objet initial, objet final] + Soit \cat{K} une catégorie. + %% + Un \obj{K} $I$ est appelé \emph{objet initial} si pour chaque \obj{K} $O$, il + existe un unique morphisme allant de $I$ vers $O$. + %% + De même, un \obj{K} $F$ est appelé un \emph{objet final} si pour chaque + \obj{K} $O$ il existe un unique morphisme allant de $O$ vers $F$. +\end{mpo-definition} +À titre d'exemple, $\cat{Set}$ possède un objet initial, l'ensemble vide +$\emptyset$, alors que tout singleton constitue un objet final. Nous +constaterons d'ailleurs que lorsqu'il existe plusieurs objets initiaux +(respectivement finaux), ceux-ci sont tous isomorphes. + +\subsubsection{Quelques diagrammes classiques} + +Nous remarquons que les propriétés intéressantes proviennent des multiples +façons d'atteindre un objet destination à partir d'un même objet source. C'est +par exemple ce qu'exprime la définition d'isomorphisme qui implique qu'il y a +un moyen de ne pas «bouger» dans $A$ tout en passant par $B$. La propriété pour +deux chemins d'être égaux après composition s'appellent la \emph{commutativité}. +Cette notion est au cœurs de nombreuses constructions catégoriques. + +Nous nous intéressons ici en particulier aux notions de \emph{limite} et de +\emph{colimite}. De façon informelle, une (co)limite consiste à trouver un objet +qui résume au mieux le comportement d'un groupe d'objets et de morphismes. +Il s'agit d'une certaine façon de la possibilité de factoriser un grand +nombre de flèches en une seule. Nous avons déjà rencontré cette construction +section~\ref{sec:ehresmann}, dans la description des travaux d'A. Ehresmann sur +la complexification structurelle: un cat-neurone, défini dans ce formalisme +comme une colimite, représente à lui seul le comportement fonctionnel d'une +famille de neurones. + +Plutôt que de présenter formellement les définitions générales de limite et +colimite, nous préférons nous concentrer sur 4 constructions particulières qui +nous seront utiles dans la suite. + +\paragraph{Produit et coproduit.} +%% +Ce premier groupe de (co)limites cherche à définir un représentant $P$ résumant +le comportement de deux objets $X$ et $Y$ sur n'importe quel autre objet +$Q$. On entend ici par comportement deux flèches $f$ et $g$ provenant de (ou +tombant sur) $Q$ et tombant sur (ou provenant de) $X$ et $Y$. S'il existe un +représentant $P$ résumant $X$ et $Y$ alors tout couple de flèches $(f,g)$ doit +être résumable en une unique flèche entre $P$ et $Q$. Ces considérations amènent +aux définitions suivantes. + +\begin{mpo-definition}[Produit]\label{def:prod} + Soient les deux objets $X, Y$. Le \emph{produit} de $X$ et $Y$, s'il existe, + consiste en un objet $P$ et deux morphismes $p_1 : P \rightarrow X$ et $p_2 : + P \rightarrow Y$ tels que pour tout autre objet $Q$ et morphismes $p'_1 : Q + \rightarrow X$ et $p'_2 : Q \rightarrow Y$, il existe un unique morphisme $u : + Q \rightarrow P$ tel que le diagramme suivant commute + \begin{center} + \includegraphics[page=4]{model-categories} + \end{center} +\end{mpo-definition} +%% +En renversant les flèches de cette définition, on obtient le \emph{coproduit}, +la construction \emph{duale} du produit. +%% +\begin{mpo-definition}[Coproduit]\label{def:coprod} + Soient les deux objets $X, Y$. Le \emph{coproduit} de $X$ et $Y$, s'il existe, + consiste en un objet $P$ et deux morphismes $i_1 : X \rightarrow P$ et $i_2 : + Y \rightarrow P$ tels que pour tout autre objet $Q$ et morphismes $i'_1 : X + \rightarrow Q$ et $i'_2 : Y \rightarrow Q$, il existe un unique morphisme $u : + P \rightarrow Q$ tel que le diagramme suivant commute + \begin{center} + \includegraphics[page=5]{model-categories} + \end{center} +\end{mpo-definition} + +Illustrons ces constructions dans le cas des ensembles en commençant par le +produit. En interprétant $X$ et $Y$ comme des ensembles, la construction cherche +à définir le meilleur ensemble possible nous permettant de factoriser en une +seule fonction $u$ n'importe quel couple de fonctions $f,g$ de même domaine +$Q$. Autrement dit, pour un même élément $q \in Q$, les fonctions produisent +deux valeurs $f(q)$ et $g(q)$ respectivement dans $X$ et $Y$, et l'on cherche à +représenter ces deux valeurs en une seule dans $P$ sans perte d'information. Le +meilleur ensemble $P$ permettant de satisfaire ces contraintes est le produit +cartésien $X \times Y$. +%% +Par un raisonnement similaire, on arrive à la conclusion que le coproduit dans +\cat{Set} correspond à l'union disjointe $X \uplus Y$. + +\paragraph{Produit fibré et somme amalgamée.} +%% +Ces nouvelles constructions sont proches des précédences. Le produit fibré peut +être vu comme une construction comparable à un produit avec une contrainte +supplémentaire: deux morphismes vers un troisième objet $Z$ sont utilisés pour +représenter une forme de cohérence entre $X$ et $Y$. + +\begin{mpo-definition}[Produit fibré]\label{def:pullback} + Soient trois objets $X, Y, Z$ et deux morphismes $f: X \rightarrow Z$ et $g: + Y \rightarrow Z$. Le \emph{produit fibré} des morphismes $f, g$, s'il existe, + consiste en un objet $P$ et deux morphismes $p_1 : P \rightarrow X$ et $p_2 : + P \rightarrow Y$ tel que le diagramme suivant commute + \begin{center} + \includegraphics[page=6]{model-categories} + \end{center} + et soit \emph{universel}, c'est-à-dire que pour tout autre objet $Q$ et + morphismes $p'_1 : Q \rightarrow X$ et $p'_2 : Q \rightarrow Y$ alors il + existe un unique morphisme $u : Q \rightarrow P$ tel que le diagramme suivant + commute + \begin{center} + \includegraphics[page=7]{model-categories} + \end{center} +\end{mpo-definition} +%% +En renversant les flèches de cette définition, on obtient la \emph{somme +amalgamée}, la construction \emph{duale} du produit fibré. +%% +\begin{mpo-definition}[Somme amalgamée]\label{def:pushout} + Soient trois objets $X, Y, Z$ et deux morphismes $f: Z \rightarrow X$ et $g: Z \rightarrow Y$. + La \emph{somme amalgamée} des morphismes $f, g$, si elle existe, consiste en + un objet $P$ et deux morphismes $i_1 : X \rightarrow P$ et $i_2 : Y \rightarrow + P$ tel que le diagramme suivant commute + \begin{center} + %\includegraphics[page=1,width=.45\textwidth]{model-categories} + \includegraphics[page=8]{model-categories} + \end{center} + et soit \emph{universel}, c'est-à-dire que pour tout autre objet $Q$ et + morphismes $i'_1 : X \rightarrow Q$ et $i'_2 : Y \rightarrow Q$ alors il existe + un unique morphisme $u : P \rightarrow Q$ tel que le diagramme suivant commute + \begin{center} + \includegraphics[page=9]{model-categories} + \end{center} +\end{mpo-definition} + +Dans \cat{Set}, ces constructions existent toujours. Le produit fibré correspond +à l'opération de $\theta$-jointure, c'est-à-dire à la construction du produit +cartésien de $X$ et de $Y$ dans lequel ne seront sélectionnés que les couples +$(x,y)$ vérifiant l'équation $f(x) = g(y)$. De la même façon, la somme amalgamée +peut être vue comme l'union disjointe de $X$ et $Y$ quotientée par la relation +$f(z) \equiv g(z)$ pour tout élément $z \in Z$. + +\subsubsection{Foncteurs} + +Il est naturel de munir une structure algébrique d'une notion de morphisme +permettant de passer d'une algèbre à une autre en préservant la structure. Les +catégories ne font pas exception, et l'on appelle \emph{foncteur} la notion de +morphisme de catégories. + +\begin{mpo-definition}[Foncteur]\label{def:foncteur} + Soient \cat{C} et \cat{D} deux catégories. Un + \emph{foncteur\footnote{covariant}} de \cat{C} vers \cat{D} est un couple de + fonctions $\ftr{F} = \langle F_0, F_1 \rangle$ tel que + \begin{itemize} + \item $F_0$ associe à chaque \obj{C} $X$, un \obj{D} $F_0(X)$, + \item $F_1$ associe à chaque \mrph{C} $f : X \rightarrow Y$, un \mrph{D} + $F_1(f) : F_0(X) \rightarrow F_0(Y)$ de sorte que: + \begin{enumerate} + \item $F_1(\kid_\cat{C}(X)) = \kid_\cat{D}(F_0(X))$ pour tout \obj{C} + $X$, et + \item $F_1(g \circ_\cat{C} f) = F_1(g) \circ_\cat{D} F_1(f)$ pour tous + \mrphs{C} $f : X \rightarrow Y$ et $g : Y \rightarrow Z$. + \end{enumerate} + \end{itemize} +\end{mpo-definition} +Remarquons que les foncteurs peuvent être composés pour donner de nouveaux +foncteurs. Il est d'usage d'utiliser $\ftr{F}$ en lieu et place de $F_0$ +et $F_1$ pour éviter les indices et alléger les notations. Nous présentons +ci-dessous quelques exemples de foncteurs. + +\begin{mpo-exemple}[Foncteur identité] + Pour toute catégorie $\cat{C}$, on peut définir son \emph{foncteur + identité} qui envoie chaque \obj{C} sur lui-même et chaque \mrph{C} sur + lui-même. Avec ce foncteur, tous les ingrédients sont présents pour pouvoir + définir la catégorie \cat{Cat} des catégories. Il convient ainsi de noter + $\kid_\cat{Cat}(\cat{C})$ (ou encore $1_\cat{C}$) le foncteur identité d'une + catégorie $\cat{C}$. +\end{mpo-exemple} + +\begin{mpo-exemple}[Foncteur d'oubli] + De façon informelle, les \emph{foncteurs d'oubli} permettent d'envoyer les + objets d'une catégorie vers ceux d'une autre catégorie possédant moins de + contraintes (justifiant le terme d'oubli). + %% + Nous intéresserons en particulier au foncteur d'oubli permettant de passer + d'une catégorie $\cat{C}$ vers la catégorie des ensembles. Par exemple, on + peut définir les foncteurs d'oubli suivants: + \begin{itemize} + + \item $\ftr{U}_\cat{Top}: \cat{Top} \rightarrow \cat{Set}$ qui envoie tout + espace topologique $\Space = \langle E_\Space, \Omega_\Space \rangle$ vers + son ensemble support $E_\Space$ (en oubliant la structure décrite par les + ouverts de $\Omega_\Space$), et toute fonction continue vers elle-même; + + \item $\ftr{U}_\cat{Mon}: \cat{Mon} \rightarrow \cat{Set}$ qui envoie tout + monoïde $\Time = \langle D_\Time, 0_\Time, +_\Time \rangle$ vers son + ensemble support $D_\Time$ (en oubliant l'opération de composition entre ses + éléments), et tout morphisme de monoïde vers lui-même, en tant que fonction + de l'espace support; + + \item $\ftr{U}_\cat{AMon}: \cat{AMon} \rightarrow \cat{Set}$ qui envoie toute + action $\Phi: E \times \Time \rightarrow E$ vers son ensemble support défini + par: + $$ + \ftr{U}_\cat{AMon}(\Phi) = \{\; (x,\delta,\Phi(x,\delta)) \mid x \in E, \delta \in \Time \;\} + $$ + et tout morphisme d'action $\langle h, f \rangle: \Phi \rightarrow \Phi'$ + vers la fonction: + $$ + \begin{array}{llll} + \ftr{U}_\cat{AMon}(\langle h, f \rangle): & + \ftr{U}_\cat{AMon}(\Phi) & \rightarrow & \ftr{U}_\cat{AMon}(\Phi')\\ + & (x,t,x') & \mapsto & (f(x), h(t), f(x')) + \end{array} + $$ + + \end{itemize} +\end{mpo-exemple} + + + +\subsubsection{Constructions catégoriques} + +Nous terminons cette introduction aux catégories avec deux constructions: +l'opposée d'une catégorie et la catégorie des flèches au-dessus (ou au-dessous) +d'un objet (ou \emph{slice} catégorie). + +\begin{description} + +\item[Catégorie opposée:] +%% +Étant donnée une catégorie $\cat{C}$, il est toujours possible de considérer +son \emph{opposée} $\catop{C}$ qui possède les mêmes objets que $\cat{C}$ mais +dont les morphismes sont les flèches de $\cat{C}$ inversées. En d'autres termes, +entre $\cat{C}$ et $\catop{C}$, domaines et codomaines échangent leurs rôles. + +Cette construction est purement symbolique et n'apporte pas de propriétés +supplémentaires à $\catop{C}$ qui n'étaient pas déjà présente chez $\cat{C}$. +Cependant, travailler dans la catégorie opposée permet souvent de travailler +avec des flèches allant dans une direction plus naturelle pour la compréhension. +L'un des principaux avantages de cette construction est de mettre en avant la +dualité entre limites et colimites. En effet, comme nous l'avons indiqué en +exemple plus haut, produit et coproduit sont des notions duales: passer de l'une +à l'autre s'effectue en changeant le sens des flèches. Ainsi, un produit dans +$\cat{C}$ se présentera sous la forme d'un coproduit dans $\catop{C}$, et vice +versa. Il en est de même pour le produit fibré et la somme amalgamée. + +\item[Flèches au-dessus d'un objet:] +%% +Les morphismes étant les éléments de première importance dans les catégories, de +nombreuses situations amènent à considérer comment les flèches sont relier les +unes aux autres. Il existe plusieurs moyens de formalisation les relations entre +flèches avec l'élaboration de $2$-catégories qui ajoute un niveau supplémentaire +d'éléments (des flèches entre flèches), les transformations naturelles, etc. + +Nous nous intéressons, dans notre cas, à une construction spécifique où les +flèches qu'il nous intéresse d'étudier possèdent toutes le même domaine ou +le même codomaine. On parlera alors de catégories de flèches au-dessus ou +au-dessous d'un objet. Pour ces catégories, il est nécessaire de fournir une +notion de morphisme, ce que propose la définition suivante. +%% +\begin{mpo-definition}[Flèche au-dessus/au-dessous d'un objet]\label{def:slice} + Soit $\cat{C}$ une catégorie et $X$ un $\obj{C}$. La \emph{catégorie des + $\mrphs{C}$ au-dessus de $X$}, noté $\cat{C} \downarrow X$, est la catégorie + dont + \begin{itemize} + + \item les objets sont les $\mrphs{C}$ de la forme $f:Y \rightarrow X$, et dont + + \item les morphismes entre $f_1:Y_1 \rightarrow X$ et $f_2:Y_2 \rightarrow + X$ sont les $\mrphs{C}$ $g: Y_1 \rightarrow Y_2$ tels que $f_1 = f_2 + \circ_\cat{C} g$, c'est-à-dire tels que le diagramme suivant commute: + \begin{center} + \includegraphics[page=10]{model-categories} + \end{center} + + \end{itemize} + L'identité et la composition sont naturellement héritées de $\cat{C}$. + + La construction duale est la \emph{catégorie des $\mrphs{C}$ au-dessous de + $X$}, notée $X \downarrow \cat{C}$. +\end{mpo-definition} + +\end{description} + + +\FloatBarrier +\subsection{Catégorie des modèles} + +Nous présentons maintenant les bases d'une construction catégorique pour +la modélisation multi-niveau. Nous commençons par définir la catégorie +$\cat{Abs}_S$ des modèles d'un système $S$. Nous proposons ensuite d'en analyser +certaines propriétés fortement liées aux techniques de modélisation que nous +avons présentées section~\ref{sec:multiniveau}. + +\subsubsection{Définition de la catégorie des modèles} + +Dans la suite, nous supposons l'existence d'un système $S$ que l'on cherche +à modéliser. Notre objectif est de définir une catégorie $\cat{Abs}_S$ dont +les objets sont les modèles de $S$ et les flèches représentent les liens +d'abstraction entre ces modèles. En suivant l'idée générale que nous avons +décrite dans l'introduction de cette section, nous supposons un ensemble +particulier noté $E_{\model{M}{S}}$ représentant les faits du système $S$ +auxquels tout modèle de $S$ doit se référer. D'une certaine façon, l'ensemble +$E_{\model{M}{S}}$ représente le vocabulaire qu'on souhaite pouvoir utiliser +pour décrire $S$. Rappelons que le but d'un modèle de $S$ est d'expliquer le +système $S$ en faisant appel à ce vocabulaire. Dans le contexte des sciences +expérimentales présenté section~\ref{sec:scexp}, ce vocabulaire consistait en +toutes les expériences réalisées/réalisables sur le système étudié. + +\begin{mpo-definition}[Catégorie des modèles]\label{def:abscat} +Soit $S$ un système représenté par un ensemble de faits de référence +$E_{\model{M}{S}}$. La catégorie $\cat{Abs}_S$ des modèles de $S$ est définie +par: +$$ +\cat{Abs}_S := (E_{\model{M}{S}} \downarrow \cat{Set})^\mathbf{co} +$$ +à savoir, l'\emph{opposée de la catégorie des flèches de $\cat{Set}$} au-dessous +de $E_{\model{M}{S}}$. +\end{mpo-definition} +% +Cette définition mérite quelques éléments de clarification. + +\paragraph{Objets de $\cat{Abs}_S$.} +%% +Les objets de $\cat{Abs}_S$ représentent les modèles de $S$ en accord avec +les faits de référence de $E_{\model{M}{S}}$. Par définition, un modèle +$\modelM$ est construit à partir d'une flèche de $\cat{Set}$ de domaine +$E_{\model{M}{S}}$. En notant cette flèche $\sigma_\modelM: E_{\model{M}{S}} +\rightarrow E_\modelM$, on retrouve ici la définition informelle de la +sémantique des modèles que nous avons présentée: une fonction des faits de +référence vers les faits du modèle. + +On peut remarquer qu'un même ensemble de faits peut être utilisé par deux +sémantiques différentes. De façon générale, tout ensemble $E$ de $\cat{Set}$ +(hormis l'ensemble vide) peut être atteint à partir de $E_{\model{M}{S}}$. De +plus, il apparaîtra dans $\cat{Abs}_S$ autant de fois qu'il existe de fonctions +dans $\khom_\cat{Set}(E_{\model{M}{S}},E)$, donnant lieu à autant de modèles +différents de $S$ pour ce seul ensemble de faits. La catégorie $\cat{Abs}_S$ est +donc extrêmement riche en modèles. + +\paragraph{Morphismes de $\cat{Abs}_S$.} +%% +Si l'on constate que les objets de $\cat{Abs}_S$ formalisent la notion de sémantique des modèles que nous cherchions à mettre en place, ses flèches permettent quant à elles de formaliser la notion d'abstraction. +En effet, la définition~\ref{def:abscat} amène à considérer une flèche $\absA:\model{M}{+} \rightarrow \model{M}{-}$, signifiant que le modèle $\model{M}{+}$ est une abstraction du modèle $\model{M}{-}$, pour chaque fonction $f_\absA$ de $E_{\model{M}{-}}$ dans $E_{\model{M}{+}}$ telle que le diagramme suivant commute: +\begin{center} + \includegraphics[page=13]{model-categories} +\end{center} +Nous retrouvons à nouveau la situation décrite informellement en début de +section. On remarquera en particulier la correspondance entre ce diagramme et +celui illustré \textsc{Fig.}~\ref{fig:model-abstraction}. + +Nous finirons en rappelant que par construction la composition et l'identité +sont bien définies dans $\cat{Abs}_S$. La composition correspond à la +transitivité de l'abstraction qui revient à dire informellement que si +$\model{M}{1}$ est une abstraction de $\model{M}{2}$ et que $\model{M}{2}$ est +une abstraction de $\model{M}{3}$, alors $\model{M}{1}$ est une abstraction de +$\model{M}{3}$ par composition des deux fonctions d'abstraction. Pour ce qui est +de l'identité, elle signifie que tout modèle est une abstraction de lui-même. +Dans ce cas, la fonction d'abstraction correspond à la fonction identité de +l'ensemble des faits du modèle concerné. + +\paragraph{Objets extrémaux de $\cat{Abs}_S$.} +%% +Toute catégorie de flèches d'une catégorie $\cat{C}$ arbitraire au-dessous d'un +$\obj{C}$ $X$ vérifie les deux propriétés suivantes: +\begin{enumerate} + + \item $\kid_X$ (qui est bien un $\mrph{C}$ au-dessous de $X$) est un objet + initial de $X \downarrow \cat{C}$; + + \item si $\cat{C}$ présente un objet terminal $F$, l'unique $\mrph{C}$ de $X$ + vers $F$ est un objet terminal de $X \downarrow \cat{C}$. + +\end{enumerate} +En considérant que la définition~\ref{def:abscat} considère l'opposée d'une +telle catégorie et que les notions d'objets initiaux et finaux sont duales, on +déduit aisément que la catégorie $\cat{Abs}_S$ possède des objets initiaux et +des objets finaux. + +Les objet initiaux sont les fonctions constantes de $E_{\model{M}{S}}$ vers les +singletons, c'est-à-dire les objets terminaux de $\cat{Set}$. Par exemple, on +associe au singleton $\{\bot\}$, le modèle $\model{M}{\bot}$ correspondant au +modèle le plus abstrait possible, celui qui offre le moins d'explication de $S$ +en identifiant tout les faits de $E_{\model{M}{S}}$ en un seul, $\bot$. +%% +En revanche, l'objet final, à savoir la fonction identité +$\kid_{E_{\model{M}{S}}}$, constitue le modèle $\model{M}{S}$ le plus concret +qu'il est possible de construire étant donné le vocabulaire proposé dans +$E_{\model{M}{S}}$. +%% +Ainsi, $\cat{Abs}_S$ se présente comme une \emph{hiérarchie d'abstraction} +entre les modèles de $S$ dont les objets initiaux et finaux forment les deux +extrémités. On remarquera que, dans le cas particulier où le vocabulaire +que l'on s'autorise pour parler de $S$ est vide (c'est-à-dire lorsque +$E_{\model{M}{S}} = \emptyset$), la hiérarchie «s'écrase» en un unique objet. + + +\subsubsection{Transformation de modèles} + +L'opération essentielle que notre cadre formel met en avant est +l'abstraction entre modèles. Elle provient des concepts développés +dans le cadre des transformations de modèles que nous avons présentées +section~\ref{sec:modeltrans} au sein de laquelle référence était faite à deux +propriétés des transformations qu'il est bon de confronter à notre proposition. + + +\paragraph{Transformation endogène et foncteur d'oubli.} +%% +Se restreindre à la simple définition ensembliste de $\cat{Abs}_S$ n'apporte +aux modèles aucun pouvoir explicatif. Ce fut d'ailleurs l'objet de la +section~\ref{sec:consmodel} que de montrer qu'il est nécessaire de rajouter de +la structure sur les ensembles de faits pour en tirer plus d'informations. +%% +On peut d'ailleurs remarquer qu'en tant que objet terminal, les faits de +référence constituent certes le modèle le plus concret mais, privés de +structure, n'apportent aucune description supplémentaire du système. + +Pour palier à cette absence de structure, notre proposition consiste +à considérer toute catégorie $\cat{C}$ munie d'un foncteur d'oubli +$\ftr{U}_\cat{C}$ vers $\cat{Set}$ comme la description d'un formalisme. Par +exemple, les modèles dont les ensembles de faits sont des images d'actions de +monoïde par le foncteur $\ftr{U}_\cat{AMon}$, correspondent à la classe des +modèles dynamiques explicitée définition~\ref{def:moddyna}. + +%Il est possible d'aller plus loin dans cette proposition. En effet, en tant que +%foncteur il est intéressant de considérer les abstractions images de morphismes +%par $\ftr{U}_\cat{C}$: ces cas correspondent exactement aux transformations de +%modèles endogènes au formalisme décrit par $\cat{C}$. +Il est possible d'aller plus loin dans cette proposition. Nous pouvons +considérer les abstractions issues des images de morphismes par \emph{le même} +foncteur d'oubli $\ftr{U}_\cat{C}$: ces cas correspondent exactement aux +transformations de modèles endogènes au formalisme décrit par $\cat{C}$. +%% +Illustrons cela pour les modèles dynamiques. Considérons dans $\cat{AMon}$, +$\Phi_-$ et $\Phi_+$ deux actions de monoïde, et $h: \Phi_- \rightarrow +\Phi_+$ un morphisme entre elles. Le cas qui nous intéresse suppose que +$\ftr{U}_\cat{AMon}$ envoie $\Phi_-$ (respectivement $\Phi_+$) sur l'ensemble +des faits $E_{\model{M}{-}}$ (respectivement $E_{\model{M}{+}}$) d'un modèle +$\model{M}{-}$ (respectivement $\model{M}{+}$) de $\cat{Abs}_S$, de telle sorte +que l'image de $\ftr{U}_\cat{AMon}(h) = f_\absA$ pour une flèche d'abstraction +$\absA: \model{M}{+} \rightarrow \model{M}{-}$: +\begin{center} + \includegraphics[page=14]{model-categories} +\end{center} +Cette situation décrit bien une abstraction de modèles dynamiques: passer +du modèle $\model{M}{+}$ au modèle $\model{M}{-}$ par $\absA$ est une +transformation endogène de $\model{M}{+}$ en $\model{M}{-}$ respectant l'action +du temps. + +Évidemment, les transformations exogènes sont également à l'honneur. Elles +correspondent aux abstractions $\absA: \model{M}{+} \rightarrow \model{M}{-}$ +dont les domaines et codomaines sont dans l'image de foncteurs d'oubli +\emph{différents}. + + +\paragraph{Transformation horizontale et isomorphisme.} +%% +Considérons parmi les transformations de modèles, les transformations verticales +et les transformations horizontale. Les premières correspondent à une notion de +raffinement entre le modèle initial et le modèle transformé de telle sorte que +le premier soit en général plus abstrait que le second. La notion d'abstraction +que nous avons formalisée correspond à cette verticalité. + +Les transformations horizontales correspondent à des équivalences entre des +modèles ayant au final le même pouvoir d'explication tout en étant décrits +de façons différentes, par exemple lorsqu'ils reposent sur des formalismes +différents (ce qui est représentable dans notre cadre par l'utilisation +de foncteurs d'oubli différents comme nous venons de le voir). Les deux +modèles sont donc interchangeables. Comme nous l'avons vu, cette propriété +se traduit en termes catégoriques par un isomorphisme entre objets. Soient +$\model{M}{1}$ et $\model{M}{2}$, deux modèles de $\cat{Abs}_S$. Par définition, +l'isomorphisme entre $\model{M}{1}$ et $\model{M}{2}$ se traduit par la +présence de deux abstractions $\absA_{12}: \model{M}{1}\rightarrow\model{M}{2}$ +et $\absA_{21}: \model{M}{2}\rightarrow\model{M}{1}$ telles que $\absA_{12} +\circ \absA_{21}$ et $\absA_{21} \circ \absA_{12}$ donnent respectivement les +identités de $\model{M}{1}$ et de $\model{M}{2}$. En dépliant la définition de +$\cat{Abs}_S$, cela revient à dire que les ensembles de faits de $\model{M}{1}$ +et de $\model{M}{2}$ sont isomorphes dans $\cat{Set}$. Attention, l'inverse est +faux: deux modèles dont les ensembles de faits sont en bijection ne sont pas +nécessairement isomorphes car il peut ne pas exister de bijection respectant les +sémantiques deux modèles simultanément. + + +\subsubsection{Couplage de modèles} + +L'opération importante de la modélisation multi-modèle est le couplage de +modèles. Nous montrons dans cette dernière section comment les constructions de +(co)limites permettent ce couplage. + +\paragraph{Le couplage simple.} +% +Le couplage de deux modèles peut être décrit en terme d'abstraction: le couplage +entre un modèle $\modelM_1$ et un modèle $\modelM_2$ revient à construire +le «meilleur» modèle $\modelM_{12}$ dont $\modelM_1$ et $\modelM_2$ sont +des abstractions. En effet, on cherche à retrouver dans $\modelM_{12}$ les +contributions de $\modelM_{1}$ et $\modelM_{2}$. En cela, $\modelM_{12}$ est +plus complet, et donc plus concret, que ses parents. De plus, on entend par +«meilleur» modèle, le fait que la définition de $\modelM_{12}$ se limite +uniquement aux contributions de $\modelM_1$ et $\modelM_2$. En d'autres termes, +tout autre modèle $\modelM'$ établissant un rapport entre $\modelM_1$ et +$\modelM_2$ serait une spécialisation de $\modelM_{12}$. Sous la forme d'un +diagramme, cette définition informelle se décrit de la façon suivante: +\begin{center} + \includegraphics[page=15]{model-categories} +\end{center} +On reconnaît ici le diagramme d'un coproduit qui invite à poser la définition +du couplage dans $\cat{Abs}_S$ à travers cette construction. Il faut cependant +s'assurer de son existence et, le cas échéant, de sa définition: quels ensemble +de faits et sémantique peut-on lui associer ? Pour ce faire, il suffit de +considérer l'équivalent du diagramme précédent dans $\cat{Set}$. +\begin{center} + \includegraphics[page=16]{model-categories} +\end{center} +Le coproduit de $\cat{Abs}_S$ dérive ici du produit de $\cat{Set}$ dont il +hérite les propriétés. Nous en déduisons qu'il est toujours possible de coupler +deux modèles; il suffit pour cela de faire le produit cartésien des ensembles de +faits des modèles à coupler. Les fonctions d'abstraction correspondent alors aux +fonctions de projection. +%% +Nous avons également fait figurer sur le diagramme l'ensemble des +faits de référence $E_{\model{M}{S}}$ et les sémantiques des modèles, +$\sigma_{\model{M}{1}}$ et $\sigma_{\model{M}{2}}$. L'universalité du coproduit +implique alors qu'il existe un unique morphisme de $E_{\model{M}{S}}$ vers +$E_{\model{M}{12}}$, que nous identifions aisément à la sémantique de +$\model{M}{12}$. Celle-ci consiste à retourner pour chaque fait de référence, le +n-uplet des faits associés par chaque modèle: +$$ +\begin{array}{llcl} +\sigma_{\model{M}{12}}: & +E_{\model{M}{S}} & \longrightarrow & E_{\model{M}{12}} = E_{\model{M}{1}} \times E_{\model{M}{2}} \\ +& r & \longmapsto & (\sigma_{\model{M}{1}}(r), \sigma_{\model{M}{2}}(r)) +\end{array} +$$ + +\paragraph{Somme amalgamée de modèles.} +% +Remarquons qu'en considérant toutes les paires de faits possibles, le produit +cartésien construit beaucoup plus de couples que nécessaire. La sémantique joue +un rôle de filtre puisque seule l'image de $\sigma_{\model{M}{12}}$ n'est au +final prise en compte dans la définition des flèches de $\cat{Abs}_S$. Cela +fait jouer un rôle important aux faits de référence qu'il n'est pas toujours +possible de tenir. En effet, si l'on reprend le cas des sciences expérimentales +par exemple, la référence est donnée par l'expérience et la réalisation de +\emph{toutes} les expériences est en réalité impraticable. Le couplage simple +reste théorique lorsque le choix de l'ensemble $E_{\model{M}{S}}$ est une +hypothèse de travail. + +Néanmoins, nous avons vu que le produit fibré correspondait pour les ensembles à +un produit cartésien suivi d'une sélection permettant de se ramener à l'ensemble +de couples qui nous intéresse. Tout comme le produit de $\cat{Set}$ donne +naissance à un coproduit dans $\cat{Abs}_S$, le produit fibré de $\cat{Set}$ +devient une somme amalgamée dans $\cat{Abs}_S$: +\begin{center} + \includegraphics[page=17]{model-categories} +\end{center} +Pour cette construction, on suppose, en plus des deux modèles qui nous +intéressent, un troisième modèle $\modelM_0$ plus abstrait que $\modelM_1$ +et $\modelM_2$ (par les abstractions $\absA^0_1$ et $\absA^0_2$). La somme +amalgamée de ce diagramme revient à calculer le produit fibré dans $\cat{Set}$. +Celui-ci correspond, comme attendu, à un produit cartésien entre les faits +de $\modelM_1$ et $\modelM_2$ restreint aux couples envoyés vers un fait +identique par $f_{\absA^0_1}$ et $f_{\absA^0_2}$. Les deux abstractions +$\absA_1$ et $\absA_2$ correspondent toujours aux projecteurs. La sémantique +$\sigma_{\model{M}{12}^0}$ est donnée, comme pour le couplage simple, par +universalité. Elle est donc unique et correspond à la restriction de la +sémantique $\sigma_{\model{M}{12}}$ du couplage simple au sous-ensemble du +produit cartésien imposé par $\modelM_0$. +%% +Plus $\modelM_0$ sera proche (en terme d'abstraction) de $\modelM_1$ et +$\modelM_2$, plus la restriction sera fine\footnote{La meilleure restriction +sera d'ailleurs obtenue lorsque $\modelM_0$ correspond au produit de $\modelM_2$ +et de $\modelM_2$. Cependant, comme nous le verrons dans le paragraphe suivant +ce calcul dépend fortement d'une connaissance explicite de $E_{\model{M}{S}}$.}. +On remarquera d'ailleurs que lorsque le modèle $\modelM_0 = \modelM_\bot$, le +modèle initial (le plus abstrait), la construction se ramène au couplage simple. + +Pour conclure, la somme amalgamée permet de coupler deux modèles en se +restreignant à une partie commune identifiée par un troisième modèle. + + + + % E_M1 <-------- E_MS + % / ^ + % v \ + % E_MO E_M12 <-------- E_MS + % ^ / + % \ v + % E_M2 <-------- E_MS + % + + +\paragraph{Construction duale.} +% +Si le coproduit permet de spécifier le couplage de modèles, il est naturel de +considérer la composition de modèles induite par le produit de $\cat{Abs}_S$. +Nous procédons comme pour le produit en analysant les diagrammes: +\begin{center} + \includegraphics[page=11]{model-categories} +\end{center} +Dans ce cas, et comme on pouvait l'attendre d'une construction duale, le +produit dans $\cat{Abs}_S$ construit le dénominateur commun aux deux modèles le +plus concret possible. Cependant, d'un point de vue catégorique, les calculs +sont différents. Le produit de $\cat{Abs}_S$ ne résulte pas du coproduit +de $\cat{Set}$ mais de la somme amalgamée, avec les faits de référence et +les sémantiques pour sommet du diagramme. Ainsi, le modèle $\model{M}{12}$ +correspond à l'union disjointe des faits de $\model{M}{1}$ et de $\model{M}{2}$ +quotientés par la relation d'équivalence regroupant au sein d'une même classe +les faits images d'un même fait de référence. +%% +D'un point de vue constructif moins intéressant que le coproduit, le produit +trouvera un intérêt dans un contexte d'analyse (de code par exemple) afin +d'extraire de deux modèles d'un même système la «meilleure» partie commune. + +À nouveau, cette construction dépend d'une connaissance approfondie des faits de +référence et n'est donc pas applicable dans un certain nombre de cas. On peut +envisager de faire endosser ce rôle à un autre modèle à travers un produit fibré +dans $\cat{Abs}_S$, ce qui revient à considérer le diagramme suivant: +\begin{center} + \includegraphics[page=12]{model-categories} +\end{center} +Au final, on obtient un dénominateur commun $\model{M}{12}^0$ qui n'est pas +le plus concret possible en général, mais qui est le plus concret possible +vérifiant la composition induite par la construction de $\modelM_0$ à partir de +$\modelM_1$ et $\modelM_2$. + + +% Tout comme pour le coproduit, on peut se demander de comment faire quand les +% faits de référence ne sont pas accessible. En gros, est-ce qu'on peut avoir +% une cohérence globale sans pour autant avoir le référentiel ? La réponse est +% oui grace à un produit fibré dans Abs, c'est à dire une somme amalgamée dans +% Set... Au final, on obtient un ensemble qui n'est pas le plus concret possible +% sauf sur la partie requise... ENFIN A VERIFIER + + + + + + +%\FloatBarrier +%\subsection{Application à la modélisation proie-prédateur} + + + + +\FloatBarrier +\section{Conclusion et perspectives} +Cette courte section vise à rappeler les principaux résultats obtenus suite à +notre approche théorique du multi-niveau ainsi que nos futures pistes de travail +sur le sujet. + +\subsection{Conclusion} +% Résumé des épisodes précédents +Dans ce chapitre nous avons posé les fondements d'une description +formelle et trans-formalisme pour la description et pour une meilleure +compréhension de la modélisation multi-niveau. Nous avons commencé dans la +section~\ref{sec:multiniveau} par la définition du terme multi-niveau en +présentant différent types de modélisation multi-niveau: couplage de modèle, +transformation de modèle et complexification. Nous avons déterminé que la +modélisation multi-niveau était un cas particulier du multi-modèle, pratique +dans laquelle plusieurs modèles sont assemblés afin de construire des modèles +plus conséquents. Dans la modélisation multi-niveau s'ajoute une contrainte sur +la représentation de cet assemblage, où les modèles sont rassemblés par niveaux +et où nous pouvons décrire via des méthodes génériques comment assembler ces +modèles selon leur niveau de représentation. Comme nous n'avons pas trouvé +de cadre général suffisamment expressif pour parler de ces assemblages, +nous avons décidé d'élaborer, section~\ref{sec:consmodel}, une définition +générale de modèle qui puisse englober tous ces cas d'usage. S'intéresser à +la notion de modèle nous a amené à différencier les termes de modèle, système +et formalisme. Un modèle est, au final, un ensemble de faits, ce que nous +décrivons ensuite formellement par un foncteur d'oubli. Le système n'est pas +accessible et constitue l'inspiration d'un modèle expérimental, décrit par +extension par le biais de mesures sur ce système. Le formalisme est quant à +lui le principe organisateur des faits du modèle. Nous avons ensuite défini +quelques types de modèles classiques (dynamiques, probabilistes, …). Enfin, dans +la section~\ref{sec:compmodel}, nous nous penchons sur la description de la +composition de plusieurs modèles, d'après les différentes méthodes d'assemblage +que nous avons présenté plus tôt. Cette présentation nous amène à introduire +quelques notions de théorie des catégorie, une théorie s'intéressant à la +composition d'éléments opaques appelés objets et morphismes, afin d'introduire +la catégorie des modèles. Dans ce cadre, nous avons pu exprimer clairement le +rôle du modèle de référence comme garant de la sémantique commune à plusieurs +modèles à assembler. + +Ce chapitre représente une toute première étape de défrichage qui a permis de +mettre en lumière les résultats suivants: +\begin{itemize} + \item une définition de modèle, système et formalisme; + \item la mise en évidence d'un rapport de chaque modèle avec sa sémantique, + identifiée comme son lien avec un modèle de référence; + \item la clarification de la flèche d'abstraction comme un morphisme de + \cat{Abs}; + \item l'éclaircissement des transformations de modèles à la lumière de + \cat{Abs}: transformation verticale (abstraction) et horizontale (changement + de point de vue); + \item la présentation des différentes manières de composer plusieurs modèles + au sein de \cat{Abs}: couplage simple, somme amalgamée de modèles + (correspondant à un produit cartésien des faits de chacun des modèles + restreint par la sémantique) et sa construction duale (correspondant au + «dénominateur commun» entre les deux modèles considérés). +\end{itemize} + +\subsection{Perspectives} + +Malgré la présentation de nombreux nouveaux concepts, il reste encore beaucoup +à accomplir pour parfaire un cadre théorique pour l'intégration des niveaux +d'organisation dans les modèles. + +% Trop abstrait, plus d'exemples concrets différents +Le premier point est le manque d'applications pratiques décrites avec cet +outil. Nous comptons, à court terme, écrire une section sur l'application +à la modélisation proie/prédateur, système présenté en milieu de chapitre. +De manière générale, nous avons manqué d'exemples à la fois concrets et +suffisamment simples. Ainsi une perspective de travail à plus long terme +est la présentation, dans le cadre que nous avons introduit, de nombreux +autres exemples pouvant ainsi aider à affiner les constructions présentées +section~\ref{sec:compmodel}. Parmi ces exemples, la question de la modélisation +de l'activité du chapitre~\ref{chap:partie-activite} et la composition des trois +modèles support de \otb du chapitre~\ref{chap:partie-otb} ont tout à fait leur +place. À terme, nous comptons décrire au moins un cas d'application par type de +transformation/couplage: +\begin{itemize} + \item isomorphisme (transformation horizontale), + \item abstraction/raffinement (transformation verticale), + \item couplage simple, + \item somme de modèles, + \item produit de modèles, +\end{itemize} +tout en mettant en évidence la classe de modèle utilisée: modèles dynamiques, +modèles à champs, modèles probabilistes, etc. + +Le second point que nous souhaitons explorer est bien plus prospectif. Une +fois quelques exemples traité dans notre formalisme, quels nouveaux outils +peut-on développer pour analyser et automatiser la construction de modèles +multi-niveau. Avec le recul, nous devrions être capable d'identifier des +structures récurrentes dans l'établissement des modèles, suivant les objets +d'études ou suivant les disciplines. + +Finalement, nous pourrons aborder notre objectif de recherche à long terme: +notre outil est-il un cadre suffisant pour exprimer clairement le fonctionnement +des systèmes complexes par le biais de mécanismes de complexification. Nous +commencerons par décrire les exemples donnés section~\ref{sec:complexification} +avec nos propres outils: le raffinement d'un modèle complexe de F. Polack et S. +Stepney peut-il être décrit plus simplement dans notre cadre, peut-on pointer +spécifiquement ce qui diffère d'un raffinement classique? La complexification +dans les CNN et la complexification structurelle de A. Ehresmann et J.-P. +Vanbermeersch peuvent-ils simplement s'exprimer dans notre cadre? +% Autre définition pour la catégorie des modèles que \cat{Abs}? + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +% \FloatBarrier +% \subsection{Présentation informelle} + +% Considérons un exemple simplifié, le modèle expérimental $M_0$ réuni +% toutes les mesures que nous avons pu faire pour le couple d'observable +% $(\obsn{Traction},\obsn{Volume})$ d'un ballon immergé dans de l'eau à +% \SI{20}{\celsius} rempli d'azote $N$, attaché à un point fixe $P$. L'observable +% \obsn{Traction} représente la force exercée par le ballon au point $P$, dirigée +% vers le haut et l'observable \obsn{Volume} représente le volume du ballon. + +% Après avoir longuement considéré les données récoltées, les deux modèles +% suivants sont proposés. + +% \[ +% M_1 = \big( \{ \obsn{Traction},\obsn{Volume} \}, \{ (F_A,V) \mid F_A = c_0 V \} +% \big) +% \] +% \[ +% \cfg(\obsn{Traction}) = \mathbb{R}_+ \qquad +% \cfg(\obsn{Volume}) = \left[ \SI{0,0}{} ; \SI{1,0}{} \right] +% \] +% Dans ce modèle le rapport entre observables découle de la loi décrivant la +% poussée d'Archimède où $c_0 = \rho_E g$ est la constante pour laquelle $\rho_E$ +% est la masse volumique de l'eau valant \SI{1,0}{\kilogram\per\metre\cubed} et +% $g$ est l'accélération de la pesanteur, valant \SI{9,81}{\newton\per\kilogram}. +% $F_A$ est la force verticale exprimée en \si{\newton} exercée par le ballon à +% son point d'attache $P$ dirigée vers le haut et $V$ en \si{\metre\cubed} est le +% volume de fluide déplacé, en l'occurence le volume du ballon. + +% \[ +% M_2 = \big( \{ \obsn{Traction},\obsn{Volume} \}, +% \{ (\mathit{faible},\mathit{petit}), +% (\mathit{faible},\mathit{moyen}), +% (\mathit{forte},\mathit{moyen}) , +% (\mathit{forte},\mathit{gros}) \} +% \big) +% \] +% \[ +% \cfg(\obsn{Traction}) = \{ \mathit{faible}, \mathit{forte} \} \qquad +% \cfg(\obsn{Volume}) = \{ \mathit{petit}, \mathit{moyen}, \mathit{gros}\} +% \] +% Dans ce second modèle, les observables sont décrites empiriquement par des +% valeurs discrètes symboliques. Ce modèle permet de comprendre le fonctionnement +% du système de manière qualitative. + +% Pour les besoins de l'exemple, nous considérerons que la relation entre les deux +% observables pour le modèle de référence $M_0$ est décrite par +% \[ +% M_0 = \big( +% \{ \obsn{Traction},\obsn{Volume} \}, \{ (F,V) \mid F = F_A - F_B \} +% \big) +% \] +% \[ +% \cfg(\obsn{Traction}) = \mathbb{R}_+ \qquad +% \cfg(\obsn{Volume}) = \left[ \SI{0,0}{} ; \SI{1,0}{} \right] +% \] +% $F_B = (m_B + m_G) g$ est le poids du ballon en \si{\newton} où $g$ est +% l'accélération de la pesanteur, +% \begin{itemize} +% \item $m_G = \rho_G V$ est la masse de gaz contenue dans le ballon où $\rho_G$ +% est la masse volumique de l'azote valant \SI{1,25}{\gram\per\liter} et +% \item $m_B = \SI{10}{\gram}$ est la masse du ballon vide. +% \end{itemize} +% Il est possible de réécrire $F_B$ en fonction de $V$, $F_B(V) = c_1 + c_2 V$ en +% prenant $c_1 = m_B g$ et $c_2 = \rho_G g$. Remarquons que $M_1$ est incomplet +% car il omet de prendre en compte le poids du ballon pour calculer la force au +% point $P$, ceci découle du fait que nous ayons choisi $M_0$ pour modèle de +% référence. + +% \bigskip +% Donnons ensuite les deux flèches de validation $v_{10} : \bhv_1 \rightarrow +% \bhv_0$ et $v_{20} : \bhv_2 \rightarrow \bhv_0$. Dans ce cas concret, les +% flèches de validation sont des \emph{fonctions} allant du comportement d'un +% modèle vers le comportement de notre modèle de référence. Elles peuvent être +% vues comme définissant une sémantique au modèle de départ dans le modèle de +% destination. Voici leurs définitions: +% \[ +% v_{10} = +% \begin{array}{rcl} +% \bhv_1 & \longrightarrow & \bhv_0\\ +% (f,v) & \longmapsto & (f - F_B(v),v) +% \end{array} +% \qquad +% v_{20} = +% \begin{array}{rcl} +% \bhv_2 & \longrightarrow & \bhv_0\\ +% (\mathit{faible},\mathit{petit}) & \longmapsto & (\SI{0,881}{} \mathop{,} \SI{0.10}{}) \\ +% (\mathit{faible},\mathit{moyen}) & \longmapsto & (\SI{4,309}{} \mathop{,} \SI{0.45}{}) \\ +% (\mathit{forte}, \mathit{moyen}) & \longmapsto & (\SI{5,289}{} \mathop{,} \SI{0.55}{}) \\ +% (\mathit{forte}, \mathit{gros}) & \longmapsto & (\SI{8,717}{} \mathop{,} \SI{0.90}{}) \\ +% \end{array} +% \] +% % f(v) = ((1 * g) - (rhoN * g) ) * v - .01 * g +% % g = 9.80665 N/kg +% % rhoN = 0.00124982 kg/L + +% De nombreux autres modèles existent et possèdent eux aussi une flèche de +% validation. Dans certaines conditions, il paraîtrait naturel que deux modèles +% soient reliés par une flèche d'\emph{abstraction}, indiquant que le modèle +% pointé est «plus détaillé» que le modèle d'origine. Dans le cas où on +% considérerait le modèle ultimement détaillé comme étant $M_\Omega$, une +% succession infinie de modèles liés par une flèche d'abstraction devrait aboutir +% à $M_\Omega$ à terme. Il est important de noter que, comme les modèles $M_1$ et +% $M_2$, les flèches de validation $v_{10}$ et $v_{20}$ sont arbitraires car elles +% proviennent de choix de modélisation. + +% \begin{figure}[ht] +% \centering +% \includegraphics[page=2,width=.45\textwidth]{model-relations} +% \caption{Représentation schématique de la relation d'abstraction entre trois +% modèles $M_1$, $M_2$ et $M_3$ assujettis à leur validation par rapport au +% modèle de référence $M_0$. $M_2$ est une abstraction de $M_1$ et il n'y a +% pas de relation connue entre $M_3$ et $M_2$} +% \label{fig:model-abstraction} +% \end{figure} + +% L'opération inverse de la flèche d'abstraction est la concrétisation. Cette +% flèche d'abstraction (en gras dans la \textsc{Fig.}~\ref{fig:model-abstraction}) +% est en lien étroit avec la flèche de validation. Il n'est toujours pas +% intéressant de considérer l'abstraction entre modèle indépendamment du système +% car cela revient à comparer des ensembles (cardinalité, sous-ensembles communs) +% dénués de sens. Comme nous l'avons présenté précédemment un modèle n'a de sens +% que par rapport au système qu'il modélise, dans notre cas par rapport à un autre +% modèle choisi comme référent. De ce fait un modèle \emph{complet} n'est pas +% seulement un comportement $\bhv$ muni d'observables mais un couple $(\bhv,v)$ +% comprenant le comportement et sa flèche de validation. Autrement dit un modèle +% complet vient avec sa sémantique. Nous verrons plus tard dans la construction +% formelle des flèches d'abstraction le sens de cette présentation. Nous allons +% donc considérer la flèche d'abstraction comme dépendante de la flèche de +% validation. + +% Considérons la construction d'une flèche abstraction sur l'exemple précédent, +% quelles fonctions nous permettraient de passer de $M_1$ à $M_2$ en respectant +% leurs liens à $M_0$ ? Une propriété intéressante est qu'il soit possible de +% parcourir le schéma de $M_1$ vers $M_0$ de deux manières équivalentes: +% \begin{itemize} +% \item Directement, en passant par $v_{20}$ ou +% \item Indirectement, en concrétisant d'abord $M_2$ en $M_1$ puis, en empruntant +% $v_{10}$. +% \end{itemize} +% Cette propriété ressemble beaucoup à la composition des fonctions. La fonction +% suivante respecte cette contrainte +% \[ +% a_{21} = +% \begin{array}{rcl} +% \bhv_2 & \longrightarrow & \bhv_1\\ +% (\mathit{faible},\mathit{petit}) & \longmapsto & (\SI{0,981}{} \mathop{,} \SI{0.10}{}) \\ +% (\mathit{faible},\mathit{moyen}) & \longmapsto & (\SI{4,413}{} \mathop{,} \SI{0.45}{}) \\ +% (\mathit{forte}, \mathit{moyen}) & \longmapsto & (\SI{5,394}{} \mathop{,} \SI{0.55}{}) \\ +% (\mathit{forte}, \mathit{gros}) & \longmapsto & (\SI{8,826}{} \mathop{,} \SI{0.90}{}) \\ +% \end{array} +% \] +% % g = 9.80665 N/kg +% % rhoE = 1kg / L + +% Définit de cette manière, on a bien la propriété $v_{20} = v_{10} \circ a_{21}$, +% où $\circ$ est l'opérateur de composition de fonction. $a_{21}$ est bien +% l'expression concrète d'une flèche d'abstraction. Plusieurs remarques: +% \begin{itemize} +% \item $a_{21}$ dépend de la définition de $v_{20}$ et $v_{10}$, changer l'une +% des deux change la définition de $a_{21}$; +% \item Pour deux flèches de validation données, il existe \emph{potentiellement} +% plusieurs flèches d'abstraction; +% \item Pour deux flèches de validation données, il n'existe \emph{pas +% nécessairement} une flèche d'abstraction. +% \end{itemize} +% Dans l'exemple que nous avons construit, $a_{21}$ est \emph{l'unique} flèche +% d'abstraction que l'on peut construire. + +% % \begin{figure}[ht] +% % \centering +% % \includegraphics[page=3,width=\textwidth]{model-relations} +% % \caption{Vue schématique d'une composition de modèles $M_1$ et $M_2$ +% % assujettis à leur validation par rapport au modèle référent $M_0$} +% % \label{fig:model-composition} +% % \end{figure} + + + + + + + + +% \subsection{Présentation catégorielle} + +% La théorie des catégories est une construction généraliste englobant la théorie des ensembles et permettant de représenter les structures des objets étudiés sous forme de diagramme. Ce cadre offre un fondement formel aux schémas que nous avons +% présentés ci-avant. + + +% % Faire une note sur classe vs ensemble +% \paragraph{Classe ou Ensemble.} +% Dans la section \ref{sec:model-system}, nous avons introduit les définitions de +% système et de modèle et nous avons présenté dans les sections suivantes +% différents modèles en plaçant le modèle même au centre de notre discours. Nous +% nous intéressons maintenant à différentes relations entre modèles comme la +% validation, l'abstraction ou la composition en leur donnant un sens concret, +% dans le cadre précédemment définit. + + +% \begin{mpo-exemple}[Catégorie \catOne] +% La catégorie $\catOne = (\{*\},\kid_*)$ est la catégorie dont l'unique objet +% est noté $*$ et son unique morphisme est noté $\kid_*$. +% \end{mpo-exemple} + + +% \subsection{Flèche de validation} +% La flèche de validation (\textsc{Fig.}~\ref{fig:model-validation}) représente la +% conservation du rapport entre le modèle et le système étudié par le biais d'un +% modèle particulier que nous appellerons modèle expérimental, noté $\wld$. C'est +% l'approche habituelle des sciences expérimentales: des mesures du système sont +% effectuées et notées puis un modèle explicatif est formulé pour retrouver ces +% données. Il est possible de comprendre cette flèche comme le \emph{sens} que +% l'on souhaite donner à un modèle, elle fourni dans ce cas une information +% sémantique. + +% \begin{mpo-definition}[Validation] +% Soit la catégorie $\cat{V} = (\setModel, \khom_\cat{V}, \kid_\cat{V}, +% \circ_\cat{V})$ où: +% \begin{enumerate} +% \item $\setModel$ est la classe des modèles; +% \item $\khom_\cat{V}(A,B): \bhv_A \rightarrow \bhv_B$, pour deux \objs{V} $A +% = (\sig_A,\bhv_A)$, $B = (\sig_B,\bhv_B)$, est l'ensemble des +% \emph{fonctions} (sur les ensembles) du \emph{comportement} de $A$ vers le +% \emph{comportement} de $B$; +% \item $\kid_\cat{V}$ est la \emph{fonction identité} habituelle et +% \item $\circ_\cat{V}$ est \emph{l'opérateur de composition de fonction} +% habituel. +% \end{enumerate} + +% Quand le contexte le permet, on n'indiquera pas nécessairement l'indice +% \cat{V}. + +% Soit $M_0 \in \setModel$ un modèle appelé \emph{modèle référent}, l'ensemble +% $\{ r \in \khom_V \mid \kcod(r) = m \}$ est appelé l'ensemble des +% \emph{flèches de validation}. + +% Remarque: il est possible de définir un foncteur d'oubli trivial $F : \cat{V} +% \rightarrow \cat{Set}$ qui retire la signature de chaque objet de \cat{V}. +% \end{mpo-definition} + +% De part la définition précédente, tout modèle peut-être un modèle référent et le +% choix est laissé libre au modélisateur en fonction des besoins. Néammoins, nous +% supposerons que le plus souvent un \emph{modèle expérimental} est de la forme +% $\wld = (\sig,\bhv)$ dans le cadre des sciences expérimentales. + + + + + + +% \subsection{Flèche d'abstraction} +% % Abstraction dépend de validation +% Pour décrire le rapport existant entre deux modèles d'un \emph{même système} +% nous utilisons les flèches de validation précédemment définies pour maintenir le +% rapport au système via le modèle référent. + + +% \begin{mpo-definition}[Comma-catégorie] +% Soit les trois catégories \cat{A}, \cat{B}, \cat{C} et les deux foncteurs $S$ +% et $T$ de sorte que: +% \begin{center} +% %\includegraphics[page=1,width=.45\textwidth]{model-categories} +% \includegraphics[page=1]{model-categories} +% \end{center} + +% La \emph{comma-catégorie}, notée $(S \downarrow T)$, est obtenue de la façon +% suivante: +% \begin{itemize} +% \item Les objets sont des triplets $(\alpha,\beta,f)$ où $\alpha \in \cat{A}$, +% $\beta \in \cat{B}$ et $f : S(\alpha) \rightarrow T(\beta)$ est un \mrph{C}; +% \item Les morphismes de $(\alpha,\beta,f)$ vers $(\alpha',\beta',f')$ sont +% toutes les paires $(g,h)$ où $g : \alpha \rightarrow \alpha'$ et $h : \beta +% \rightarrow \beta'$ sont des morphismes de \cat{A} et \cat{B}, +% respectivement de sorte que le diagramme suivant commute: +% \begin{center} +% \includegraphics[page=2]{model-categories} +% \end{center} +% \end{itemize} +% Les morphismes sont composés en transformant $(g,h) \circ (g',h')$ en $(g +% \circ g', h \circ h')$ pour tous les cas où cette expression est définie. Le +% morphisme identité d'un objet $(\alpha,\beta,f)$ est $(id_\alpha,id_\beta)$. +% \end{mpo-definition} + +% \begin{mpo-definition}[Catégorie des abstractions entre modèles] +% La \emph{catégorie des abstractions entre modèles}, notée \cat{Abs}, est la +% comma-catégorie obtenue sur la catégorie \cat{V}. En reprenant les trois +% catégories \cat{A}, \cat{B} et \cat{C} et les deux foncteurs $S$ et $T$ de la +% définition de comma-catégorie précédente, \cat{Abs} se construit en prenant: +% \begin{itemize} +% \item $\cat{A} = \cat{C} = \cat{V}$; +% \item $\cat{B} = \catOne$; +% \item $S$ comme foncteur identité; +% \item $T$ comme foncteur envoyant $*$ sur $M_0$, le modèle référent et +% $\kid_*$ sur le \mrph{V} identité de $M_0$. +% \end{itemize} +% Ainsi, les objets de \cat{Abs} sont les couples $(M,v)$, où $M \in \setModel$ +% et $v : M \rightarrow M_0$, pouvant aussi être notée $v_M$, est une flèche de +% validation. Un morphisme de \cat{Abs}, appelé \emph{flèche d'abtraction}, est +% une fonction $a : (M,v_M) \rightarrow (M',v_{M'})$ tel que le diagramme +% suivant commute: +% \begin{center} +% \includegraphics[page=3]{model-categories} +% \end{center} + +% Remarque: ce cas particulier de comma-catégorie est appelée \emph{slice +% category} que l'on note $(\cat{V} \downarrow M_0)$. +% \end{mpo-definition} + +% À l'instar de \cat{Set}, il existe un unique \obj{V} initial $M_I = +% (\sig_I,\emptyset)$. Ceci découle du fait que les morphismes de \cat{V} vont de +% comportement à comportement. + +% \begin{mpo-proposition}[Conservation des objets initiaux] +% Soient la catégorie \cat{V}, $M_R$, $M_I$, des \objs{V}, $i : M_I \rightarrow +% M_R$ un \mrph{V}. Si $M_I$ est un \obj{V} initial, alors $(M_I,i)$ est un +% objet initial de $(\cat{V} \downarrow M_R)$. +% \end{mpo-proposition} + +% \begin{proof} +% Soit $M = (\sig,\bhv)$ un \obj{V}. % +% L'objet de référence $M_R$ se note $(\sig_R,\bhv_R)$. % +% Par définition de l'objet initial, les \mrphs{V} $i : \emptyset \rightarrow +% \bhv_R$ et $j : \emptyset \rightarrow \bhv$ existent, sont uniques et sont +% deux applications vides. % +% Comme dans la catégorie des ensembles il existe au moins une fonction entre un +% ensemble quelconque et un ensemble non-vide, le morphisme $k : M \rightarrow +% M_R$ existe et $(M,k)$ est un objet de $(\cat{V} \downarrow M_R)$. % +% De par le fait que $i$ et $j$ soient deux applications vides, $i = k \circ j$ +% et le diagramme commute. % +% Ainsi, comme $(i,k) : (M_I,i) \rightarrow (M,k)$ est unique, $(M_I,i)$ est +% bien un objet initial de $(\cat{V} \downarrow M_R)$. +% \end{proof} + +% En revanche, cette propriété ne tient plus nécessairement en ce qui concerne la +% conservation des objets finaux. + +% \begin{mpo-proposition}[Non conservation d'un objet final dans \cat{Abs}] +% Soient la catégorie \cat{V}, $M_R$, $M_F$, des \objs{V}, $f : M_R \rightarrow +% M_F$ un \mrph{V}. Si $M_F$ est un \obj{V} final, alors $(M_F,f)$ n'est pas +% nécessairement un objet final de $(\cat{V} \downarrow M_R)$. +% \end{mpo-proposition} + +% \begin{proof} +% Construisons un contre exemple. % +% Soit $M_F = (\sig,\{ 1 \})$ un \obj{V}. % +% Comme dans la catégorie des ensembles il existe au moins une fonction entre un +% ensemble quelconque et un ensemble non-vide, le morphisme $h : M \rightarrow +% M_F$ existe, et comme le comportement de $M_F$ est un singleton, alors $h$ est +% unique, donc $M_F$ est bien un objet final de \cat{V}. % +% Soient +% \[ +% M_R = (\sig_{M_R}, \{ a , b \}) +% \qquad \text{et} \qquad +% M = (\sig_{M}, \{ \heartsuit, \spadesuit \}) +% \] +% deux \obj{V}. % +% Les deux morphismes $g : M \rightarrow M_R$ et $f : M_F \rightarrow M_R$ +% existent. % +% Fixons +% \[ +% f = +% \begin{array}{rcl} +% 1 & \longmapsto & a \\ +% \end{array} +% \qquad \text{et} \qquad +% g = +% \begin{array}{rcl} +% (\heartsuit,\spadesuit) & \longmapsto & b \\ +% \end{array} +% \] +% Dans ce cas, il n'existe pas de \mrph{V} $h$ tel que $g = f \circ h$ et il n'y +% a pas de morphisme entre les objets $(M,g)$ et $(M_F,f)$ dans la comma +% catégorie $(\cat{V} \downarrow M_R)$. $(M_F,f)$ n'est pas un objet final dans +% cette comma catégorie. +% \end{proof} + + +% \noindent +% En revanche, il existe un objet particulier de \cat{V} à l'origine d'un objet +% final dans \cat{Abs}. + +% \begin{mpo-proposition}[Objet final d'une slice category] +% Soient \cat{K} une catégorie, $O$ un \obj{K} et $\kid_O$, le \mrph{K} identité +% de $O$. $(O,\kid_{O})$ est un objet final de $(\cat{K} \downarrow O)$. +% \end{mpo-proposition} + +% \begin{proof} +% Soient $\cat{K} = (\mathcal{K},\khom,\kid,\circ)$ une +% catégorie, $O$ un \obj{K} et $\cat{L} = (\cat{K} \downarrow O)$ la +% comma-catégorie construite sur l'objet $O$. % +% Pour tout \mrph{K} $f : K \rightarrow O$, $(K,f)$ est un \obj{L}. % +% En particulier, $(O, id_O)$ est un \obj{L}. % +% Comme $f \circ \kid_O = f$, alors il existe un unique \mrph{L} +% \[ +% (f,\kid_O) : (K,\kid_O) \rightarrow (O,\kid_O). +% \] % +% Donc, $(O,\kid_O)$ est un objet final de \cat{L}. % +% \end{proof} + +% \begin{mpo-corollaire} +% Pour la catégorie \cat{V}, le modèle de référence $M_R$ et son \mrph{V} +% identité, $(M_R,\kid_{M_R})$ est un objet final de $(\cat{V} \downarrow M_R)$. +% \end{mpo-corollaire} + + + +% L'objet final de \cat{Abs} est \emph{essentiellement unique}, c'est-à-dire que +% s'il existait d'autres objets finaux dans \cat{Abs}, alors ils lui seraient +% isomorphes~\cite{adamek_abstract_2004}. + +% Nous remarquons que dans \cat{Abs}, ces objets initial et final forment les deux +% extrémités d'une \emph{hiérarchie} d'abstraction entre modèles où le modèle le +% plus abstrait est l'objet initial dont le comportement est vide et le modèle le +% moins abstrait est l'objet final, qui se trouve être le modèle de référence. De +% plus, par construction, il n'existe pas d'objet moins abstrait que le modèle de +% référence. + +% Enfin, si le modèle de référence est vide, il est à la fois objet initial et +% final et la hiérarchie «s'écrase». Le modèle de référence devient, dans ce cas, +% le seul objet de \cat{Abs}. + +% %Une seule proposition +% %Si sous-catégorie Abs, alors objet initial reste. +% %Si sous-catégorie Abs, alors objet final reste. + +% \subsection{Composition} +% %FILLME: M1->M12; M2->M12 => Composition de deux modèles d'un même système +% Pour la composition de modèle, nous faisons appel à la construction d'un +% pushout. Dans \cat{Set}, en prenant trois ensembles $X, Y, Z$, le pushout de +% deux fonctions $f : Z \rightarrow X$ et $g : Z \rightarrow Y$ correspond à +% l'union disjointe de $X$ et $Y$. + +% \begin{mpo-definition}[Pushout] +% Soit les trois objets $X, Y, Z$ et les morphismes $f : Z \rightarrow X$ et $g +% : Z \rightarrow Y$, le \emph{pushout} des morphismes $f, g$ consiste en un +% objet $P$ et deux morphismes $i_1 : X \rightarrow P$ et $i_2 : Y \rightarrow +% P$ tel que le diagramme suivant commute +% \begin{center} +% %\includegraphics[page=1,width=.45\textwidth]{model-categories} +% \includegraphics[page=4]{model-categories} +% \end{center} +% et soit \emph{universel}, c'est-à-dire que pour tout autre objet $Q$ et +% morphismes $i'_1 : X \rightarrow Q$ et $i'_2 : Y \rightarrow Q$ alors il +% existe un unique morphisme $u : P \rightarrow Q$ +% \begin{center} +% \includegraphics[page=5]{model-categories} +% \end{center} +% \end{mpo-definition} + + diff --git a/partie-otb.tex b/partie-otb.tex new file mode 100644 index 0000000..f4b37f2 --- /dev/null +++ b/partie-otb.tex @@ -0,0 +1,2712 @@ +\chapter{Travelling Bacteria}\label{chap:partie-otb} +\minitoc +%DONE: (WONTFIX) Rendre la figure plus claire +\begin{figure}[h] + \centerline{% + \includegraphics[width=19cm]{figures/otb2-display}} + \caption{Fenêtre de rendu du logiciel \tb{} lors d'une simulation comportant + un grand nombre de bactéries. Les cadres jaunes indiquent l'espace + actuellement occupé par les bactéries et leur support} + \label{fig:otb2-display} +\end{figure} + +\clearpage +\section*{Préliminaires} +Voici quelques notations utilisées dans ce chapitre: +\begin{itemize} +\item $(G,+)$ est le groupe engendré par l'ensemble $G$ et la loi $+ : G \times + G \rightarrow G$. +\item $\langle G \rangle$ est le groupe libre engendré par l'ensemble des + générateurs $G$. +\item $\mathbb{N}_+$ est l'ensemble des entiers naturels privé de $0$. +\item $\lfloor x \rfloor = \text{max} \{ m \in \mathbb{Z} \,|\, m \leq x \}$ est + la fonction partie entière de $x \in \mathbb{R}$. +\item $\orr{u}$ est un vecteur, +\item $\|\orr{u}\|$ est la norme euclidienne du vecteur $\orr{u}$, +\item $k \cdot\orr{u}$ est le produit scalaire entre un scalaire $k$ et un + vecteur \orr{u}, +\item $\orr{u}\cdot\orr{v}$ est le produit scalaire entre deux vecteurs \orr{u} + et \orr{v}, +\item $\orr{u}\wedge\orr{v}$ est le produit vectoriel entre deux vecteurs + \orr{u} et \orr{v}. +\item $\left[ x \right]^{x_{\mathit{max}}}_{x_{\mathit{min}}} + = \left\{ \begin{array}{ll} + x_{\mathit{max}} & \text{si}\; x > \mathit{max}\\ + x_{\mathit{min}} & \text{si}\; x < \mathit{min}\\ + x & \text{sinon} + \end{array} + \right.$ est la fonction \emph{clamp}. +\end{itemize} + +\section{Simuler la morphogenèse des populations} +En tant que science expérimentale, la recherche en biologie cellulaire et +moléculaire nécessite d'important moyens matériels afin de tester \emph{in +vivo} les hypothèses formulées par les chercheurs. Notamment, la préparation +et l'exécution d'une expérience est… +\begin{itemize} +\item consommatrice en temps. Il faut parfois attendre que les cultures d'un + organisme particulier atteignent l'état désiré\footnote{cf. le projet + \synbiotic}; +\item consommatrice en ressources. Maintenir les conditions de pression, + d'humidité, de température, d'acidité, d'oxygénation, etc. nécessite du + matériel onéreux; +\end{itemize} + +D'un côté, de par les moyens engagés, il est difficile d'envisager de tester des +hypothèses très prospectives ou bien de se faire une idée du résultat probable +d'une expérience quand beaucoup d'entités interagissent. D'un autre, un plan +d'expérience comprend idéalement un nombre minimum nécessaire d'expérimentations +pour valider ou infirmer une hypothèse du modèle, ce nombre pouvant néanmoins +rester élevé au regard des moyens à disposition. La simulation informatique +permet, à partir d'un modèle donné, de confirmer ou de rejeter rapidement une +hypothèse, ce qui peut aider à choisir quelles expérimentations effectuer. Dans +ce cas c'est un outil d'aide à la décision. Si la simulation est suffisamment +précise, comme dans la cas de la simulation de la motilité de quelques bactéries +\Ecoli{} \cite{bray_chemotactic_2007}, elle pourrait même se substituer en +partie à l'expérimentation \emph{in vivo}; on parlera dans ce cas +d'expérimentation \emph{in silico}. + +Nous nous intéressons au problème de la \emph{morphogénèse} c'est à dire à +l'ensemble des lois qui déterminent les étapes de la forme, de la structure des +tissus, des organes et des organismes. Les organismes multicellulaires sont le +fruit d'un grand nombre de divisions cellulaires successives et qui donnent lieu +à l'apparition d'une forme et de fonctionnalités caractéristiques et +reproductibles. Comprendre la morphogénèse est un enjeu fondamental pour la +biologie synthétique (voir à ce propos la section~\ref{sec:synbiotic}). + +Pour répondre à ce problème et dans le cadre du projet \synbiotic, nous avons +développé \tb{}, un simulateur des interactions d'une population de bactéries +\ecoli{} au cours de sa croissance. \tb{} permet de suivre une cellule ou une +sous partie de cette population au cours du temps de manière similaire aux +conditions expérimentales et ainsi de tester des hypothèses à l'échelle de la +population dans le domaine de la biologie synthétique. + +\subsection{Propriétés attendues} +Dans le but de fournir aux biologistes le moyen d'expérimenter \emph{in silico} +la validité d'un modèle concernant l'évolution d'une population de bactéries +\ecoli{}, nous avons dressé une liste de propriétés nécessaires. +\begin{description} +\item[Sorties] Le simulateur permet de recueillir des résultats qualitatifs via + un affichage graphique, reprenant la métaphore de la boîte de Petri qui + permettra d'identifier la forme de la population en croissance. Il est + possible de marquer une sous-partie de la population pour la suivre plus + facilement. Le simulateur permet de recueillir des résultats quantitatifs, tel + que le nombre et la position des bactéries dans un fichier texte pour + traitement ultérieur, par exemple pour la reconnaissance automatique de forme, + ou des calculs statistiques; +\item[Entrées] Les conditions initiales de la simulation sont décrites par un + fichier de configuration dans un langage dédié; au delà des conditions + initiales de l'expérience, il permettra au moins de fixer quelques paramètres + du rendu graphique ou textuel, comme la couleur de représentation des + morphogènes et des bactéries, et de sélectionner quelles informations + quantitatives seront écrites pendant la simulation; +\item[Précision] Le simulateur reprend aussi fidèlement que possible les + connaissances actuelles sur l'aspect mécanique (croissance et collision des + bactéries) et sur l'aspect chimique (réaction et diffusion de morphogènes). + Une étape de calibrage sera donc nécessaire par rapport à des comptes rendus + d'expériences \emph{in vivo}; +\item[Efficacité] Le simulateur est suffisamment efficace pour être utilisable + sans matériel spécifique; par exemple, passer d'une bactérie à une population + de l'ordre de $10^4$ bactéries, soit un temps réel d'environ de + \SI{4}{\hour}\SI{30}{\minute}, nécessitera un temps de simulation + correspondant de l'ordre de l'heure sur un ordinateur portable contemporain, + moins encore sur une machine spécialisée; +\item[Autonomie] Les résultats sont accessibles sans la nécessité de faire + fonctionner le simulateur sur une grille de calcul, un tel matériel ne servira + qu'à réduire le temps de simulation afin d'effectuer un plan d'expérience plus + rapidement; +\item[Scalabilité] Malgré les points précédents, \tb{} passe à l'échelle et peut + s'adapter à une machine de calcul dédiée ou à une grille de calcul distribuée; + plusieurs instances du simulateur peuvent être lancées de manière concurrente; +\item[Adaptabilité] Il est possible d'ajouter à \tb{} de nouvelles + fonctionnalités avec peu d'effort: l'architecture du simulateur est modulaire + et vient avec une documentation claire; +\item[Stabilité] Comme une simulation complexe peut prendre plusieurs heures, il + est important que le simulateur ne produise pas d'erreur en cours de + fonctionnement, autrement dit \tb{} est stable; d'une part le langage utilisé + apportera des garanties de part des vérifications du système de type, d'autre + part des tests fonctionnels permettront de valider le fonctionnement correct + de chaque partie du simulateur; +\item[Ouverture] Le simulateur est un programme informatique ouvert, son code + source peut-être téléchargé en ligne, compilé, amélioré et redistribué, + modifié ou non; +\end{description} + +% \subsection{GRO} % Pourquoi pas GRO +% À l'instar de \gro~\cite{jang_specification_2012}, … + +\subsection{\ocaml} % Adaptabilité, stabilité +Pour répondre aux critères \emph{d'adaptabilité} et de \emph{stabilité}, +nous avons choisi d'implémenter \otb avec le langage \ocaml, un langage de +programmation fonctionnel, statiquement typé, modulaire et interfaçable avec +le langage C. \ocaml est à la fois un projet académique avec de solides +bases théoriques, notamment utilisé comme langage d'implémentation de +l'assistant de preuve Coq\footnote{cf. la page «à propos» du projet Coq +\url{https://coq.inria.fr/about-coq}}, et aussi un langage industriel ayant à +son actif de belles réussites comme l'analyseur statique \textsc{Astrée} en +usage chez Airbus. + +%DONE: Repasser sur ça avec Antoine (WONTFIX) +\paragraph{Langage de programmation fonctionnel} +La programmation fonctionnelle est issue du $\lambda$-calcul, un modèle de +calcul mathématique reposant sur des variables, des applications et des +abstractions regroupées sous le nom de \emph{$\lambda$-termes}. +% \begin{mpo-definition}[Ensemble des $\lambda$-termes] +% Un $\lambda$-terme est composé: +% \begin{itemize} +% \item de variables, notées $v_1,v_2,\ldots,\v_n,\ldots$; +% \item des symboles d'abstraction $\lambda$ et $.$; +% \item des parenthèses ouvrante et fermante. +% \end{itemize} +% L'ensemble des $\lambda$-termes, $\Lambda$ peut être définit par induction: +% \begin{enumerate} +% \item Si $x$ est une variable, alors $x \in \Lambda$ +% \item Si $x$ est une variable et $M\in \Lambda$, alors $(\lambda x.M)\in +% \Lambda$ +% \item Si $M, N \in \Lambda$, alors $(M\ N)\in \Lambda$ +% \end{enumerate} +% Les $\lambda$-termes issus de la règle 2 sont appelés \emph{abstractions} et +% ceux issus de la règle 3 sont appelés \emph{applications}. +% \end{mpo-definition} +Dans le modèle du $\lambda$-calcul, la règle centrale pour le calcul des +$\lambda$-termes est la \emph{substitution} dont les deux principaux +représentants sont l'$\alpha$-conversion et la $\beta$-réduction. Le calcul de +nouveaux $\lambda$-termes s'effectue par un système de réécriture. C'est ce +modèle de calcul qui a donné lieu au paradigme de la programmation +fonctionnelle. Par extension, les langages de programmation fonctionnelle purs +ont la particularité de considérer la programmation d'un algorithme comme une +composition de fonctions s'appelant les unes les autres plutôt que comme une +suite d'instructions qui agissent par effet de bord, c'est-à-dire en modifiant +l'état de la mémoire. Ils se dissocient de la vision de la machine à état comme +support de programmation en adoptant un style plus mathématique dans leur +écriture, proche de la réécriture des $\lambda$-termes. \ocaml dispose ainsi +\begin{itemize} +\item de structures de contrôle comme le filtrage par motif, +\item de clôtures, qui sont des définitions de fonction accompagnées de leur + environnement lexical, analogues des $\lambda$-termes et +\item permet de définir des fonctions d'ordre supérieur, c'est-à-dire aux + fonctions pouvant avoir des fonctions en argument et pouvant retourner des + fonctions comme résultat. +\end{itemize} +Un paradigme de programmation influe sur la syntaxe et la sémantique du langage, +et comme \ocaml est un langage multiparadigme, empruntant aux paradigmes +de la programmation fonctionnelle, de la programmation impérative et de la +programmation orientée objet, il hérite de leurs aspects. \ocaml dispose d'un +ramasse-miette efficace qui gère la désallocation de la mémoire quand celle-ci +n'est plus utilisée sans l'intervention de l'utilisateur. Ceci fait de \ocaml +un langage de programmation de haut niveau. Comme nous le présentons ci-après, +\ocaml est de plus un langage fonctionnel fortement et statiquement typé. + +\paragraph{Typage fort et typage statique} +Les types ont d'abord été introduit en logique combinatoire et dans le +$\lambda$-calcul dans les années 1930. Ils ont depuis eu un fort impact en +informatique: ils sont utilisés comme une abstraction d'un programme et +permettent d'en vérifier certaines propriétés, comme par exemple garantir que le +résultat d'une fonction appartient à un ensemble d'éléments connus. Dans le +langage C, un langage bas niveau proche de l'expression d'un processeur, les +types décrivent la taille de la représentation machine et les règles de +conversion d'une valeur du langage. En \ocaml, les types sont plutôt utilisés +pour modéliser les données du programme. \ocaml permet de déclarer des types +algébriques récursifs permettant par exemple de décrire la structure de listes +\begin{OCAMLcode} +type 'a list = + Nil + | Cons of 'a * 'a list +\end{OCAMLcode} +ou d'arbres binaires +\begin{OCAMLcode} +type 'a tree = + Leaf of 'a + | Node of 'a tree * 'a tree +\end{OCAMLcode} + +\ocaml présente un typage fort. On distingue un typage fort d'un typage faible +par la manière dont s'effectue la transformation d'un type en un autre: plus +elle est explicite plus c'est un typage fort, moins elle explicite moins c'est +un typage faible. Autrement dit, plus un langage est fortement typé, plus il est +difficile de transformer un type en un autre. Dans le langage C, un opérateur +appelé \emph{cast} permet aisément de transformer presque n'importe quel type en +un autre. En \ocaml, cette transformation n'est pas possible dans le cadre de +fonctionnement normal du langage, donc \ocaml est plus fortement typé que C et +le système de type d'\ocaml est par conséquent plus riche. Le code source d'un +programme \ocaml est typé statiquement, c'est à dire que toutes les +annotations de type sont connues avant la compilation. À l'opposé, dans le cas +d'un typage dynamique, certaines informations de type peuvent ne pas être +connues avant la compilation, peuvent rester après la compilation et peuvent +évoluer durant l'exécution du programme. + +\ocaml utilise un typage statique et fort et les annotations de type sont +utilisées à la compilation pour permettre au compilateur de détecter les erreurs +de types avant l'exécution du programme, ce qui apporte quelques garanties +concernant le comportement. Par exemple, les types nous permettent d'apporter +des informations supplémentaires que le compilateur peut prendre en compte. +Déclarer les types +\begin{OCAMLcode} + type nom = Nom of string + type prenom = Prenom of string +\end{OCAMLcode} +permet au compilateur de distinguer deux chaînes de caractères identiques, mais +dont le sens est différent, ce qui est représenté par deux types différents. + +%modulaire +\paragraph{Modularité native} +Lors de la rédaction d'un programme, il est vite nécessaire de «compartimenter» +le code source, d'abord parce que certaines fonctionnalité sont génériques et +peuvent être utilisées plusieurs fois dans des contextes différents, mais aussi +pour des raisons de relecture et de segmentation de l'espace de noms. La +\emph{modularité} consiste à rassembler les fonctionnalités d'un programme dans +des modules \emph{indépendants} et \emph{interchangeables}. En \ocaml, la +modularité est une caractéristique native du langage dans la gestion du code +source et repose sur trois constructions syntaxiques: les \emph{structures}, les +\emph{interfaces} et les \emph{modules}. Les structures contiennent +l'implémentation des modules, les interfaces décrivent les valeurs qui en sont +accessibles — les valeurs dont l'implémentation n'est pas exposée sont des +valeurs abstraites, et celles qui n'apparaissent pas du tout dans +l'implémentation du module sont inaccessibles. Un module peut avoir plusieurs +interfaces — du moment qu'elles sont toutes compatibles avec les types de +l'implémentation — et plusieurs modules peuvent vérifier une même interface. +Enfin, \ocaml dispose de modules paramétriques nommés \emph{foncteurs} qui +sont des structures paramétrées par d'autres structures. +% Quand ils sont répartis dans des fichiers séparés, chaque fichier source +% terminant en \texttt{.ml} est un module dont le nom est celui du fichier, +% auquel on peut adjoindre un fichier interface dont le nom termine en +% \texttt{.mli}. + +%interfaçable avec C +% http://caml.inria.fr/pub/docs/manual-ocaml/intfc.html +\paragraph{Interface avec le langage C} +Un aspect important pour les besoins du cahier des charges (voir +\ref{ss:req-parallel}) est de pouvoir communiquer avec des objets compilés C via +une interface dédiée, typiquement des bibliothèques écrites et compilés dans ce +langage. \ocaml propose une interface claire avec des bibliothèques +logicielles écrites en C, permettant d'empaqueter des valeurs dans des types +\ocaml conservant les avantages d'un typage fort, de dépaqueter des valeurs +typées de \ocaml vers un type C arbitraire et surtout de profiter de la +gestion automatique de la mémoire par le ramasse-miette de \ocaml. + +\subsection{Calcul parallèle} % Efficacité et Autonomie +\label{ss:req-parallel} +Notre simulateur calcule l'évolution d'un grand nombre d'objet de même nature +simultanément. Pour répondre aux critères \emph{d'efficacité} et +\emph{d'autonomie} nous avons le choix d'utiliser un GPU, le processeur dédié +des cartes graphiques, ou bien d'utiliser un cluster: une grappe de serveurs +interconnectés sur le réseau local. En prenant le nombre d'opérations en virgule +flottante par seconde, notée \si{FLOPS}, comme référence de la vitesse d'un +ordinateur, utiliser le parallélisme embarqué dans les GPU semble être la bonne +manière d'atteindre des vitesses de calcul élevées. Nous nous appuyons sur le +fait que plus de la moitié des 500 supercalculateurs les plus rapides au monde +sont construit sur NVidia +Kepler\footnote{\url{https://www.top500.org/statistics/list/}}, un GPU. Les GPU +grand public sont accessibles en terme de prix, leur consommation est +suffisamment faible pour fonctionner sur batterie dans un PC portable et les +plus puissants atteignent les \SI{10000}{\giga FLOPS}\footnote{% + \url{https://www.nvidia.com/en-us/geforce/products/10series/titan-x-pascal}\\ + Par exemple, la carte graphique NVidia Titan X possède \num{3584} cœurs + de calculs, cadencés à \SI{1417}{\mega\hertz} pour un prix avoisinant les +\num{1200} euros}.Enfin, +le parallélisme des GPU semble être plus efficace énergétiquement par rapport +aux CPU en comparant leur \si{\giga FLOPS} par Watt~\cite{dong_step_2014}. + +%parallélisme SIMD OpenCL +\paragraph{SIMD} +La taxinomie de Flynn~\cite{flynn_computer_1972} classifie différentes +architectures d'ordinateur et comporte quatre catégories selon le type +d'organisation du flux de données et du flux d'instructions. Le modèle de +programmation le plus répandu repose sur l'architecture de Von Neumann, ce qui +correspond à la catégorie \emph{Single Instruction Single Data} (SISD). Les +ordinateurs de cette catégorie n'exploitent aucun parallélisme et sont purement +séquentiels, tant au niveau des instructions qu'au niveau de la mémoire. Ce +modèle de programmation ne correspond pas à la réalité des processeurs +contemporains qui exploitent le parallélisme des données (plusieurs banques de +mémoire RAM) ou d'instructions grâce à plusieurs processeurs à plusieurs cœurs. +À l'extrême opposé de la classification se trouvent les architectures +\emph{Multiple Instruction on Multiple Data} (MIMD), puis les architectures +\emph{Multiple Instructions on Single Data} (MISD). Dans le cas des MISD, des +problèmes de concurrence à la lecture−écriture apparaissent et il est d'usage +d'avoir recours à des barrières de synchronisation, des sémaphores ou des Mutex. +SPMD, \emph{Single Program on Multiple Data}, est la technique la plus courante +pour utiliser le parallélisme des ordinateurs multiprocesseurs contemporain, où +chaque processeur exécute un programme distinct et possède sa propre mémoire, en +plus de partager une mémoire globale, la RAM. Finalement, dans les ordinateurs +contemporains, il existe, en complément d'un CPU et d'une mémoire partagée, des +cartes de calcul dédiées, comme des cartes graphiques, spécialisées dans le +calcul vectoriel, capable d'effectuer des opérations rapides sur des grandes +matrices. L'architecture d'une carte graphique, munie d'un GPU et d'une mémoire +RAM entre dans la catégorie \emph{Single Instruction on Multiple Data} (SIMD). +Ces processeurs sont spécialisés dans le traitement en parallèle d'un grand +nombre de données. Depuis la taxinomie de Flynn, d'autres types de Nous avons +choisi de tirer parti du parallélisme disponible sur l'ordinateur où est exécuté +\tb{}, qu'il provienne de plusieurs CPU ou d'une carte graphique. + +\paragraph{\opencl} +Afin d'accéder aux périphériques présent sur la plateforme de simulation et de +les programmer, nous utilisons \opencl (Open Computing Language), un framework +pour l'écriture de programmes s'exécutant sur des plateformes hétérogènes: +microprocesseurs (CPU), processeurs graphique (GPU), processeurs de signal +numérique (DSP), réseau de portes programmables in situ (FPGA) ou autre carte +accélératrice. \opencl spécifie un langage de programmation, inspiré de C99, +pour la programmation de ces périphériques ainsi que des interfaces de +programmation (API) pour le contrôle de la plateforme et l'exécution des +programmes sur les périphériques. \opencl fournit une interface standard pour +la programmation parallèle utilisant le parallélisme de tâche et le parallélisme +de données. Il existe d'autres framework pour la programmation des GPU, comme +CUDA\footnote{\url{http://www.nvidia.com/object/cuda_home_new.html}}, cependant +l'avantage de \opencl est qu'il est le seul langage pour le GPGPU (General +Purpose computing on Graphics Processing Unit) à ne pas être restreint à une +seule plateforme. En effet, il fonctionne sur une large gamme de matériel et, au +contraire de CUDA, ne se limite pas à un seul constructeur, ni à un seul type de +périphérique. \opencl est un standard ouvert maintenu par Khronos +Group\footnote{\url{https://www.khronos.org/about}}, un consortium technologique +à but non lucratif. De nombreux constructeurs fournissent une implémentation +officielle, comme AMD, Intel et Nvidia les principaux constructeurs de CPU et de +cartes graphiques grand public. + +\paragraph{\opengl} % Sorties +Pour répondre au point «Sortie», nous avons choisi d'utiliser \opengl (Open +Graphics Library), une API multiplateforme, multilangage utilisée pour +programmer un GPU spécifiquement pour un rendu graphique. Dans le modèle de +programmation de \opengl, un ensemble de vecteurs dans l'espace en trois +dimensions sont successivement transformés pour obtenir une projection en deux +dimension rastérisée. Le programmeur écrit des programme de traitement, des +shader, qui viennent se brancher à différents points de la chaîne de traitement +graphique. À l'inverse de \opencl, \opengl est optimisé pour le calcul vectoriel +et n'est pas approprié pour effectuer des calculs généraux sur les GPU. Cette +bibliothèque logicielle nous permet de proposer une ou plusieurs fenêtre +de rendu en temps réel pour présenter des informations qualitatives sur la +progression d'une simulation. + +% Scalabilité +%détection dynamique de la configuration de l'utilisateur + +% Ouverture +%licence libre +\subsection{Modélisation d'une cellule} +\begin{figure}[t] + \centering + \includegraphics[height=6cm]{figures/EscherichiaColi}\hfill + \includegraphics[page=1,height=6cm]{figures/bacteria} + \caption{Une image d'une microscopie électronique à balayage d'une culture de + \ecoli\ (à gauche) et une représentation simplifiée en deux dimensions d'une + bactérie \ecoli\ (à droite)} + \label{fig:ecoli} +\end{figure} + +% \caption{Longueur totale d'une bactérie : $L = 2 \cdot{} (r + l)$ +%Surface totale : $S = 2 \cdot{} r \cdot{} 2 \cdot{} l + \pi \cdot r^2 +% = 4 \cdot{} r \cdot{} l + \pi \cdot r^2$} + +\Ecoli\ est une bactérie bacillaire, c'est à dire en forme de bâtonnet, du genre +\emph{Escherichia}. C'est une bactérie vivant habituellement dans l'intestin des +animaux à sang chaud, dont elle constitue 0,1\% de la flore intestinale. +Découverte en 1885 par Theodor Escherich et étudiée intensivement depuis 60 ans, +c'est un organisme très utilisé dans le domaine de l'ingénierie biologique et de +la microbiologie industrielle, notamment pour sa disponibilité et sa facilité de +culture. La souche K-12, adaptée à l'étude en laboratoire, est également un des +premiers organisme dont le génome a été séquencé \cite{blattner_complete_1997}. + +%Usages de ecoli +Elle est à l'origine du domaine de la biotechnologie en étant choisie comme +premier organisme génétiquement modifié contenant de l'ADN recombiné, c'est à +dire de l'ADN dont la séquence des nucléotides à été altérée pour modifier +l'expression des gènes de la bactérie. Elle est ensuite utilisée comme hôte pour +la production de protéines hétérologues (provenant d'un autre organisme), +notamment pour la production industrielle d'insuline humaine +\cite{goeddel_expression_1979} mais aussi de vaccins. \ecoli{} est utilisée en +bioremédiation pour la neutralisation de déchets toxique ou la dépollution des +sites contaminés et pour la production d'enzymes. Les efforts de recherche se +concentrent actuellement sur la synthèse par \ecoli{} de protéines plus +complexes comprenant par exemple des ponts bisulfure ou nécessitant une +modification post-traductionnelle pour être stables ou bien juste +fonctionnelles~\cite{han_escherichia_2006}. + +\begin{table}[hb] + \centering + \begin{tabular}{llll} + \hline + \textbf{Paramètre} & \textbf{Symbole} & \textbf{Valeur} & \textbf{Unité}\\ + \hline + Longueur & $L = 2 (l+r)$ & \num{2.5+-0.6} & \si{\micro\meter} \\ + Largeur ou Diamètre & $d = 2r$ & \num{0.88+-0.09} & \si{\micro\meter} \\ +% Masse & $m$ & 0 & g \\ + Volume & $V$ & \num{1.4} & \si{\femto\liter} \\ + Vitesse rectiligne & $v$ & \num{29+-6} & \si{\micro\meter\per\second} \\ +% Vitesse angulaire & $\omega$ & \num{29+-6} & \si{\micro\meter\per\second} \\ + Temps de génération & $G$ & 20 — 30 & \si{\minute} \\ + \hline + \end{tabular} + \caption{Quelques ordres de grandeur associés aux bactéries \Ecoli{} + \cite{bremer_modulation_1996,darnton_torque_2007}% + \cite{britanica_online_encyclopedia_bacteria_2016}} + \label{tab:ecoli-odg} +\end{table} + +\paragraph{La chimiotaxie de \Ecoli} +Comme la plupart des bactéries bacillaires, \ecoli{} possède une ciliature +péritriche: elle est assortie de longs flagelles elliptiques, quatre en moyenne, +recouvrant sa surface qui sont utilisés comme moteur de son déplacement. Ces +flagelles sont fixés à leur base à un moteur rotatif réversible entraîné par un +flux de protons et tournent sur eux-mêmes à une fréquence de l'ordre de +\SI{100}{\hertz}. Suivant le sens de leur rotation, sens direct (CCW pour +Counter ClockWise) et sens indirect (CW pour ClockWise), ils sont à l'origine de +deux modes de déplacement: +\begin{itemize} +\item le mode «run», les moteurs tournent dans le sens direct et les flagelles + se regroupent pour propulser la bactérie dans une direction rectiligne. Il + dure en moyenne \SI{1}{\second}; +\item le mode «tumble», au moins un des moteurs tourne dans le sens indirect. + Les flagelles se désolidarisent ce qui a pour effet moyen de faire tourner la + bactérie sur elle-même dans le sens horaire \cite{diluzio_escherichia_2005}. + Ce mode dure en moyenne \SI{0,1}{\second}. +\end{itemize} +Ces deux modes de déplacement alternent successivement et, en fonction de +l'environnement de la bactérie, les amènent à migrer vers des environnements +favorables, riches en nutriments et à fuir les environnements toxiques et +délétères \cite{berg_chemotaxis_1972}. +Ce phénomène s'appelle la \emph{chimiotaxie}. Il résulte de la transmission +de signaux extracellulaires, détectés par les récepteurs de la membrane, aux +moteurs des flagelles qui contrôlent le comportement de la cellule. + +% Modèle discret entre concentration d'un morphogène et temps de tumble et run +D'un point de vue macroscopique, \ecoli{} effectue une marche aléatoire +biaisée vers une direction particulière. Elle détecte la variation +\emph{dans le temps} de la concentration d'un chimioeffecteur. Ainsi, lorsque +la bactérie se dirige vers un milieu plus favorable, les réorientations par +tumble deviennent plus rares et la bactérie peut remonter le gradient de la +concentration d'une molécule qui se diffuse dans l'environnement. Entre deux +run, \ecoli{} peut complètement changer de direction, avec un angle allant +jusqu'à 180°, le plus souvent entre 0° et 90° \cite{turner_real-time_2000}. +D'un point de vue microscopique, \ecoli{} peut détecter différents acides +aminés, sucres et dipeptides ainsi que l'acidité, la température et l'état +d'oxydoréduction. + +Les récepteurs principaux, comme ceux de l'aspartate (Tar) +et de la sérine (Tsr), sont très nombreux et sont aux nombre de quelques +milliers par cellule. Les récepteurs secondaires, comme ceux spécifiques aux +dipeptides (Tap), ribose et galactose (Trg), et au potentiel d'oxydoréduction +(Aer), sont bien moins nombreux avec seulement une centaine de copies par +cellule. Ces récepteurs se regroupent en amas, ce qui induit des dynamiques +complexes dans la détection de chimioeffecteurs \cite{sourjik_receptor_2004}, +impliquant soit une plus grande sensibilité ou au contraire une plus grande +diversité de détection. + +Dans le réseau de régulation génétique, parmi les voies de signalisation +de la cellule, la voie de réponse chimiotaxique consiste donc en un ensemble +de protéines réceptrices transmembranaires sus-citées et les produits de six +gènes chimiotaxiques: CheR, CheB, CheW, CheA, CheY et CheZ. L'information sur +la liaison de ligants bénéfiques ou nocifs aux récepteurs est transportée +jusqu'au moteur des flagelles ce qui leur permet de changer le sens de rotation +du moteur. Il existe plusieurs modèles stochastiques capables de simuler +en détail la cascade d'évènements entre la liaison d'un chimioeffecteur +à un récepteur jusqu'au biais des moteurs \cite{shimizu_spatially_2003, +mello_quantitative_2003}. + + + +\paragraph{Modèle de croissance} +\ecoli\ suit un modèle de croissance linéaire +\cite{zaritsky_growth_1982,kubitschek_cell_1990} par élongation et bien que son +diamètre décroisse avec l'élongation, cette variation reste négligeable quand +$L$ est suffisamment grande \cite{trueba_changes_1980,skarstad_cell_1983}. Nous +considérerons donc que seule sa longueur $L$ (voir \textsc{Fig.}~\ref{tab:ecoli-odg}) +varie lors de la croissance d'une bactérie. Comme toutes les cellules +procaryotes, \ecoli{} se reproduit par scissiparité. Ce cycle de division +implique: +\begin{enumerate} +\item La réplication de la molécule d'ADN circulaire au sein de la cellule; +\item La migration après duplication des deux brins d'ADN à chacun des pôles de + la cellule; +\item La croissance de la cellule pour laisser la place à un matériel génétique + plus volumineux; +\item Le plan équatorial de la cellule se resserre et fini par scinder la + membrane en deux, de sorte que chaque nouvelle cellule fille ait le même + matériel génétique. +\end{enumerate} + +L'équation \ref{eq:generation-time} présente le calcul du temps de génération +pour une population de bactéries dont la croissance s'effectue par division +binaire, où $t$ est le temps en minutes, $n$ est le nombre de générations, $B$ +est le nombre de bactéries au début de la période de temps mesurée et $b$ est le +nombre de bactéries à la fin de la période de temps mesurée. Cela permet aux +biologistes de retrouver le temps moyen d'un cycle cellulaire pour la population +observée. + +\begin{equation} + \displaystyle + G = \frac{t}{n} = \frac{t}{3,3 \times ln (b / B)} + \label{eq:generation-time} +\end{equation} + +\paragraph{Vieillissement et mort cellulaire} +Il semble que les bactéries se scindant en deux bactéries filles en tout point +identiques atteignent une sorte d'immortalité, au moins fonctionnelle. Néanmoins +quand elle n'est pas tuée par des antibiotiques, par manque de nutriments ou par +le système immunitaire d'organisme multicellulaires, même dans des conditions +idéales \ecoli{} vieillit~\cite{stewart_aging_2005}. Ce vieillissement résulte +d'une asymétrie entre les parois membranaires des pôles de la cellule. En effet, +un de ces pôle est celui de la cellule mère, alors que le second provient du +plan équatorial de scission de la cellule mère et a été fraîchement créé. En +partant d'une unique cellule mère, à chaque génération deux cellules possèdent +les parois membranaires des pôles de la cellule mère susmentionnée. Avec les +générations, le matériel cellulaire diffusant peu et ayant une longue demi-vie +s'accumule dans ces «vieux» pôles. Les cellules aux pôles plus âgés produisent +moins de cellules filles et ont une probabilité de décès spontané plus élevée. +On peut ainsi donner un âge à chaque pôle prenant en compte le nombre de +divisions qu'il a subit. Cela permet d'attribuer un âge à chaque cellule, qui +est définit comme l'âge du pôle le plus âgé. En conséquence, \otb inclus un +modèle de vieillissement des bactéries pouvant causer le décès spontané (nommé +apoptose) d'une cellule si sa lignée dépasse une certaine valeur, paramétrable +en début de simulation. + +\subsection{Organisation logicielle du simulateur} +Pour décrire l'organisation logicielle du simulateur, il nous faut parler des +architectures de \opencl et de \opengl avant de présenter l'architecture de +\otb afin de comprendre comment ces différents composants communiquent pour +simuler l'évolution d'une population de bactéries. + +\subsubsection{Architecture \opencl}\label{sec:archi-cl} +Nous présentons ici une version simplifiée de l'architecture de \opencl% +\footnote{\url{http://www.khronos.org/registry/cl/specs/opencl-1.1.pdf}}. Un +programme \opencl est construit en deux parties: le programme hôte et les +\emph{kernel}. Le programme hôte s'exécute normalement sur CPU. Dans notre cas, +c'est la partie du simulateur gérée par \ocaml. Les kernels sont des fonctions +écrites en C99 destinées à être exécutées sur les périphériques gérés par +\opencl, comme une carte graphique. Le modèle d'exécution d'\opencl définit +comment ces kernels sont instanciés sur les différentes unités de calcul +disponibles. + +Lorsque l'hôte soumet un kernel à exécuter à \opencl, un espace d'indices est +définit et, pour chaque indice de cet espace, une instance du kernel est +exécutée. Cette instance est appelée un \emph{work-item}. Les work-items sont +regroupés en \emph{work-group}, une division par blocs de l'espace d'indices. +Les work-items ont accès à quatre types de mémoire: la mémoire globale, la +mémoire constante, la mémoire locale et la mémoire privée. Chacune de ces +mémoires est manipulable soit par l'hôte, soit par un work-item, soit par les +deux. Par exemple, la mémoire privée est réservée à un work-item, la mémoire +local est accessible à tous les work-items du même work-group, les mémoires +constantes et globales sont accessibles à l'hôte comme aux work-items. + +L'hôte peut également demander des transferts de données entre sa mémoire +principale, la RAM, et les mémoires du device, dans les deux sens, afin de +fournir des données initiales aux work-items et de récupérer leur travail. + +\subsubsection{Architecture \opengl} +Le framework \opengl définit une architecture client-serveur: le client +fonctionnant sur l'hôte, côté CPU, et le serveur s'exécutant sur la carte +graphique, côté GPU. La pièce maîtresse du serveur est le \emph{rendering + pipeline} (chaîne de traitement du rendu), une succession de tâches permettant +de transformer par étapes un ensemble de vertex, définis dans un espace en trois +dimensions, en un tableau de pixels en deux dimensions. + +\begin{figure}[ht] + \centering + \includegraphics[width=\textwidth]{figures/openGLPipeline} + \caption{Vue de haut niveau de la chaîne de traitement de \opengl. Les + shaders en gras peuvent être définis par l'utilisateur, les shaders en + pointillé sont optionnels. } + \label{fig:openGLPipeline} +\end{figure} + +Ces étapes peuvent peuvent pour certaines être programmées à l'aide d'un langage +appelé \emph{GLSL} (OpenGL Shading Language), une variante de C, et sont +appelées des \emph{shaders} (voir \textsc{Fig.}~\ref{fig:openGLPipeline}). Voici une +description succinte des shaders programmable utilisés dans \otb, avec leurs +entrées, leurs sorties et une description de leur rôle: +\begin{description} +\item{\bfseries Vertex Shader} + \begin{itemize} + \item Entrée: un vertex; + \item Sortie: un vertex; + \item Description: ce shader modifie un vertex, par exemple ses attributs de + position \ç{vec4 gl_Position} ou de taille de point \ç{float gl_PointSize}. + \end{itemize} +\item{\bfseries Geometry Shader} + \begin{itemize} + \item Entrée: un vertex, une ligne, des triangles; + \item Sortie: zéro, un ou plusieurs vertex, ligne ou triangles; + \item Description: ce shader permet d'effectuer des calculs géométriques sur + les primitives qui lui sont données, soit pour modifier leur attributs, soit + pour générer de nouveaux points, de nouvelles lignes ou de nouveaux + triangles. Par exemple, dans \otb, ce shader est utilisé pour construire les + vertex nécessaire à la représentation d'une bactérie, à partir de trois + vertex donnés en entrée. + \end{itemize} +\item{\bfseries Fragment Shader} + \begin{itemize} + \item Entrée: un fragment; + \item Sortie: une couleur; + \item Description: ce shader permet d'attribuer une couleur à un pixel sur + l'écran à partir des informations calculées par le shader de Rasterization. + C'est ici par exemple que la représentation de chaque bactérie obtient ses + couleurs. + \end{itemize} +\end{description} + +\subsubsection{Architecture de \otb} +% Extracted with: +% $ $grep ^module * 2> /dev/null | sed -e 's/^.*\.ml.\?://' | sort -u | copy +L'architecture de \tb{} est organisée en modules \ocaml. L'usage de modules a +été une méthode intuitive pour rapidement prototyper le fonctionnement du +simulateur. Les modules de \tb{} peuvent être découpés en deux catégories: les +modules haut niveau, utilisés dans la programmation de la logique du simulateur +et les modules bas niveau utilisés pour fournir des outils concrets aux modules +de haut niveau, comme par exemple communiquer avec les périphériques +d'entrée/sortie via des binding vers des bibliothèques externes. Les modules +sont écrits avec \ocaml, mais l'accès à \opengl et \opencl ne peut se faire +que via le langage C, ainsi les modules de bas niveau \texttt{Viewer} et +\texttt{OpenCL} sont en partie dédiés à la traduction entre l'interface C et +\ocaml. + +%% Représentation schématique des modules +\begin{figure}[ht] + \centering + \includegraphics[width=\textwidth]{figures/otbModules} + \caption{Organisation des dépendances entre les modules de \tb{}. Les modules + de bas niveau sont organisés sur le rang inférieur, les modules de haut + niveau sont sur le rang supérieur.} + \label{fig:tbModules} +\end{figure} + +\paragraph{Entrée} Le point d'entrée par défaut du programme, à savoir la +fonction d'entrée dans le programme, se trouve dans le module \texttt{Main}. Ce +dernier fait appel aux autres modules pour construire une simulation et +l'exécuter. + +\paragraph{Modules de haut niveau} +Les modules de haut niveau regroupent les définitions des fonctions dédié au +travail des modèles: d'une bactérie et d'une population de bactéries, d'un +environnement de morphogènes, d'une zone délimitant les bords physiques de +l'environnement de simulation et enfin de l'assemblage des trois modèles +précédents. Comme indiqué par les flèches de la \textsc{Fig.}~\ref{fig:tbModules}, un +module de haut dépend d'un ou plusieurs modules bas niveau. Le module +\texttt{Bacterium} décrit le modèle d'une bactérie ainsi que l'automate +cellulaire support d'une population de bactéries. Sa fonction la plus notable, +\texttt{Bacterium.run}, prépare et lance le calcul d'un pas de simulation d'une +population de bactéries sur le GPU. Le module \texttt{Morphogen}, assez +symétrique au module \texttt{Bacterium}, décrit l'automate cellulaire modélisant +la réaction-diffusion des morphogènes. Sa fonction principale, +\texttt{Morphogen.run} initialise et lance le calcul d'un pas de simulation +d'une grille de morphogènes sur le GPU. Ces deux modules font appel à quatre +autres modules de bas niveau qui sont décrits dans le paragraphe suivant. +\texttt{Zone} est un module de haut niveau modélisant une boîte de Petri de +taille dynamique en fonction de la répartition des individus qu'elle contient. +Ses bords sont représentées par un cadre jaune dans la +\textsc{Fig.}~\ref{fig:otb2-display}. Finalement, le module \texttt{Coupling} décrit le +modèle complet obtenu par l'interaction entre les bactéries et leur +environnement. C'est ce modèle qui permet aux bactéries de déposer des +morphogènes dans leur environnement et de consommer les morphogènes qui y sont +présent. + +%% 3 vues du simulateur +\begin{figure}[h] + \centering + \includegraphics[width=\textwidth]{otb-multi-view}% + \caption[Présentation des zones dynamiques]{Trois vues d'une même simulation + avec \num{1174} bactéries présentant, à gauche, une vue globale montrant + les zones dynamiques (délimitées en rouge, la zone intérieure est celle + des bactérie, la zone extérieure est celle des morphogènes). À droite sont + présentés des vues agrandies de la simulation mettant en évidence, en + haut, le comportement physique des bactéries et, en bas, la diffusion des + morphogènes.} + \label{fig:tbModules} +\end{figure} + +\paragraph{Modules de bas niveau} +Le module \texttt{Packfile} regroupe les fonctions de sérialisation nécessaire à +la sauvegarde dans un fichier de l'état d'une simulation. Le module +\texttt{BoundingBox} contient les types et les fonctions permettant de définir +et d'effectuer des calculs courants sur des boîtes encadrantes, une +représentation rectangulaire d'une zone géométrique. + +Les modules \texttt{OpenCL} et \texttt{Viewer} sont des modules permettant +d'accéder à des bibliothèques externes. En effet, \tb{} communique avec la +carte graphique \emph{via} le langage et framework \opencl pour les calculs +généraux. Dans un premier temps, nous avons fait appel à un module \ocaml, +appelé SPOC~\cite{bourgoin_spoc:_2012}, fournissant un binding \opencl et une +gestion automatique de la mémoire de la carte graphique. Au delà d'une simple +interface entre \ocaml et \opencl, SPOC abstrait la programmation GPGPU et donne +un accès transparent à d'autres framework. Cependant, SPOC posant des problèmes +de stabilité et possédant bien plus de fonctionnalités que nous avions besoin, +nous avons finalement écrit notre propre interface bas niveau pour \opencl, car +nous souhaitons manipuler explicitement le transfert entre l'hôte et la carte. +Cette interface a pour intérêt d'être simple, stable et de donner une grande +latitude au développeur \ocaml quant à la gestion de la mémoire entre l'hôte et +la carte graphique. Ce binding est contenu dans le module \texttt{OpenCL}. \tb{} +communique aussi avec la carte graphique \emph{via} \opengl. De la même manière, +il existe plusieurs bindings \opengl pour \ocaml. Toutefois, nous n'utilisons +qu'un faible sous-ensemble des fonctions de l'\api{} d'\opengl et nous avons +écrit notre propre interface bas niveau, minimale et spécifique à l'utilisation +de \tb{}. \texttt{Viewer} contient le binding vers \opengl, glew et glfw, trois +bibliothèques utilisées dans la création de l'interface graphique du simulateur. + +\subsection{Le langage \sbgp{}} +Pour répondre au point «Entrée» du cahier des charges, nous avons développé +notre propre langage afin de faciliter le paramétrage d'une +simulation \cite{pascalie_developmental_2016} avec \tb{}. \sbgp{} (Synthetic +Biology Genetic Programming) est un langage déclaratif décrivant les options de +configuration d'une simulation \otb. Un fichier de configuration de la +simulation écrit avec \sbgp{} donne une représentation abstraite du génome de la +bactérie sous la forme d'une machine à états finis et inclus des informations +supplémentaires pour paramétrer la simulation, comme les couleurs de rendu. + +\paragraph{Syntaxe} +Un fichier \sbgp{} est formaté en JSON~\cite{bray_javascript_2014}. Un génome +\sbgp{} est un objet JSON contenant les blocs suivants: +\begin{itemize} + \item \texttt{signals}: la liste des signaux en usage dans la simulation, + chaque signal est définit par un triplet: nom du signal, coefficient de + diffusion et coefficient de dégradation; + \item \texttt{reactions}: la liste des réactions, si elles existent. Chaque + réaction est définit par un triplet: $(r,p,\tau)$ où $r$ est une liste des + réactants, $p$ une liste des produits et $\tau$ le taux de réaction; + \item \texttt{type}: la liste des types identifiés par une étiquette unique; + \item \texttt{behavior}: le comportement, un objet donnant pour chaque type la + liste des actions à exécuter à chaque pas de temps; + \item \texttt{transition}: une matrice de taille + $card(\text{\texttt{type}}) \times card(\text{\texttt{type}})$ + qui représente la table de transition d'état entre chaque types. La matrice + donne l'identifiant de la transition si il existe. + \item \texttt{cond\_transition}: la transition conditionnelle identifiée par + son étiquette; chaque étiquette dans la table de transition d'état doit + être défini dans ce bloc +\end{itemize} + +Le type de chaque bloc est le suivant: +\begin{SBGPcode} +{ + "signals" : [[Sid_i, Deg_rate_i, Diff_rate_i], [...]], + "reactions" : [[[Pid_i, Pid_j], [Rid_i], Rate_i], [...]], + "type" : [T0, ..., Tn], + "behavior" : {T0 : [{InstructionID : [Pid_1, ..., Pid_n]}]} + "transition" : [type x type] of Condition_name, + "cond_transition" : [{Condition_name_i : ConditionID}, ..., {...}] +} +\end{SBGPcode} + +\paragraph{Déclaration des signaux} +Les signaux sont déclarés dans une liste. Chaque signal est un triplet contenant +le nom du signal sous forme de chaîne de caractères, et les coefficients de +diffusion et de dégradation sous forme de nombres réels. +\begin{SBGPcode} + "signals" : [ + ["alpha", 0.05, 0.01], + ["beta", 1.5, 1] + ] +\end{SBGPcode} +% Par exemple, l'extrait de code précédent est compilé vers l'en-tête C suivante: +% \begin{Ccode} +% alpha := signal(0.050000,0.010000) ; +% beta := signal(1.500000,1.2) ; +% \end{Ccode} + +\paragraph{Déclaration des réactions} +Les réactions sont déclarés dans une liste. Chaque réaction consiste en un +triplet: la liste des réactants, la liste des produits et la constante cinétique +de la réaction. Par exemple, le bloc \sbgp{} suivant est utilisé pour décrire la +réaction $2\alpha + \beta \xrightarrow{0.15} \gamma$: +\begin{SBGPcode} + "reactions" : [ + [ + ["alpha", "alpha", "beta"], + ["gamma"], + 0.15 + ] + ] +\end{SBGPcode} +% Il se compile vers l'en-tête C suivante: +% \begin{Ccode} +% reaction({alpha,alpha,beta},{gamma},0.15) ; +% \end{Ccode} + +\paragraph{Déclaration des types} +% The bacterial types are declared in a list of IDs, the following block +% indicates the list of types involved in the genome: +Les types de bactéries légaux sont déclarés dans une liste d'identifiants. Le +bloc suivant donne la liste des types impliqués dans le génome: +\begin{SBGPcode} + "type" : [ + "QUIESCENT", + "LEADER", + "FLESH", + "SKIN", + "DEAD" + ] +\end{SBGPcode} +% All types in the \sbgp{} file are declared as integer variables in Gro. These +% types are indexed starting from 0 (type of the initial bacterium). The +% following SBGPcode shows the Gro code produced by the \sbgp{} compiler: +% Tous les types déclarés dans le fichier \sbgp{} sont transformés en nombre entier +% dans \tb{}. Ces types sont indexés à partir de 0 — le type de la bactérie initiale. +% L'extrait \sbgp{} précédent est compilé comme suit: +% \begin{Ccode} +% QUIESCENT := 0 ; +% LEADER := 1 ; +% FLESH := 2 ; +% SKIN := 3 ; +% DEAD := 4 ; +% \end{Ccode} + +\paragraph{Déclaration du comportement} +% Type-specific behaviors are declared in an associative list: for each label +% declared in the type block, a list of instructions is given. As an example the +% following code gives the behavior of the \texttt{LEADER} type: +Les comportements spécifiques aux types sont déclarés dans une liste +associative; une liste d'instructions est donnée pour chaque étiquette +déclaré dans le bloc type. Par exemple, le code suivant donne le comportement +d'une bactérie de type \texttt{LEADER}: +\begin{SBGPcode} + "behavior" : { + "LEADER" : [ { "EmitSignal" : ["alpha", "150"] }, + { "StopDivide" : [] }, + { "Accumulate" : ["lambda","1"] } + ] + } +\end{SBGPcode} +Une instruction est décrite conformément à la structure suivante: +\begin{SBGPcode} +{ "InstructionID" : ["param1", ... ,"paramN"] } +\end{SBGPcode} +% The \texttt{InstructionID} must be a member of the \sbgp{} instruction set. +% These instructions and their Gro equivalent are given in the following table: +La valeur du champ \texttt{InstructionID} doit être pris parmi l'ensemble des +instructions \sbgp{} suivantes: +\begin{itemize} +\item \texttt{EmitSignal(s,q)}: dépose une quantité \ç|q| du morphogène \ç|s| à + la position courante de la bactérie dans l'environnement; + % & emit\_signal(s,q) \\ +\item \texttt{AbsorbSignal(s,q)}: consomme une quantité \ç|q| du morphogène + \ç|s| à la position courante de la bactérie dans l'environnement; + % & absorb\_signal(s,q) \\ +\item \texttt{Differentiate(A)}: force un changement de type de la bactérie vers + le type \ç|A| (il doit exister dans la liste des types); + % & mem.type := A \\ +\item \texttt{Die()}: détruit la bactérie. Elle est en pratique marquée comme + inactive et réinitialisée; + % & die() \\ +\item \texttt{Freeze()}: place le marqueur \ç|immobile| sur une bactérie. Dans cet + état une bactérie est immobile et ne croît pas; + % & freeze() \\ +\item \texttt{Unfreeze()}: retire le marqueur \ç|immobile|; + % & unfreeze() \\ +\item \texttt{Divide(r)}: définit le taux de croissance de la bactérie à la + valeur particulière \ç|r|; + % & set("ecoli\_growth\_rate",0.1) \\ +\item \texttt{StopDivide()}: définit le taux de croissance de la bactérie comme + nul, l'empêchant ainsi de se diviser; + % & set("ecoli\_growth\_rate",0) \\ +\item \texttt{Accumulate(p,q)}: incrémente le compteur de morphogènes \ç|p| avec + la valeur \ç|q|; + % & p := p + q \\ +\item \texttt{Deplete(p,q)}: décrémente le compteur de morphogènes \ç|p| avec la + valeur \ç|q|. + % & p := p - q \\ +\end{itemize} + +\paragraph{Déclaration des transitions} +% The transition block is a matrix that encapsulates the differentiation graph +% of the genome. The size of the matrix is dependent on the number of types. +% When a link exists between two types, a label is set in the corresponding +% element the matrix, if not, the keyword \texttt{NA} is specified. The +% following SBGPcode shows how is the differentiation graph of the 2-layered +% homeostatic core: +Le bloc transition est une matrice encodant le graphe de différentiation du +génome. La taille de la matrice dépend du nombre de types. Lorsque qu'une +transition existe entre deux types, une étiquette est définie dans la case de la +matrice correspondante, sinon, le mot-clé \texttt{NA} est spécifié. Le code +\sbgp{} suivant présente le graphe de différenciation d'un cœur homéostatique à +deux couches: la population croît autour d'une bactérie mère en formant deux +anneaux concentriques constitués d'une quantité invariante de bactéries. +\begin{SBGPcode} +"transition" : [ + ["NA","CL","C1" ,"C2" ,"NA" ,"NA" ], + ["NA","NA","NA" ,"NA" ,"NA" ,"NA" ], + ["NA","NA","NA" ,"C12","NA" ,"NA" ], + ["NA","NA","C21","NA" ,"C23","NA" ], + ["NA","NA","NA" ,"NA" ,"NA" ,"C3D"], + ["NA","NA","NA" ,"NA" ,"NA" ,"NA" ] +], +\end{SBGPcode} + +\paragraph{Déclaration des conditions de transition} +Une condition est une expression booléenne renvoyant \ç|true| ou \ç|false|. La +valeur du champ \texttt{ConditionID} doit être prise parmi l'ensemble des +instructions \sbgp{} suivantes: +\begin{itemize} +\item \texttt{AND(Cid1,Cid2)}, \texttt{OR(Cid1,Cid2)}: \ç{AND} et \ç{OR} sont les + opérations classiques de la logique booléenne; +\item \texttt{EqThreshold(s,q)}: ce prédicat n'est vérifié que si la + concentration du morphogène \ç|s| est égale à \ç|q|; + % & get\_signal(s) $=$ q \\ +\item \texttt{LessThreshold(s,q)}: ce prédicat n'est vérifié que si la + concentration du morphogène \ç|s| est inférieure à \ç|q|; + % & get\_signal(s) $<$ q \\ +\item \texttt{GreaterThreshold(s,q)}: ce prédicat n'est vérifié que si la + concentration du morphogène \ç|s| est supérieure à \ç|q|; + % & get\_signal(s) $>$ q \\ +\item \texttt{LessEqThreshold(s,q)}: ce prédicat n'est vérifié que si la + concentration du morphogène \ç|s| est inférieure ou égale à \ç|q|; + % & get\_signal(s) $>=$ q \\ +\item \texttt{GreaterEqThreshold(s,q)}: ce prédicat n'est vérifié que si la + concentration du morphogène \ç|s| est supérieure ou égale à \ç|q|; + % & get\_signal(s) $<=$ q \\ +\item \texttt{BetweenThreshold(s,q1,q2)}: ce prédicat n'est vérifié que si la + concentration du morphogène \ç|s| est comprise strictement entre \ç|q1| et + \ç|q2|; +\item \texttt{InternalProtEqCond(p,q)}: ce prédicat n'est vérifié que si le + compteur de morphogènes \ç|p| est égal à la valeur \ç|q|; + % & p $=$ q \\ +\item \texttt{InternalProtLessCond(p,q)}: ce prédicat n'est vérifié que si le + compteur de morphogènes \ç|p| est inférieur strictement à la valeur \ç|q|; + % & p $<$ q \\ +\item \texttt{InternalProtGreatCond(p,q)}: ce prédicat n'est vérifié que si le + compteur de morphogènes \ç|p| est supérieur strictement à la valeur \ç|q|; + % & p $>$ q \\ +\item \texttt{InternalProtLessEqCond(p,q)}: ce prédicat n'est vérifié que si le + compteur de morphogènes \ç|p| est inférieur ou égal à la valeur \ç|q|; + % & p $<=$ q \\ +\item \texttt{InternalProtGreatEqCond(p,q)}: ce prédicat n'est vérifié que si le + compteur de morphogènes \ç|p| est supérieur ou égal à la valeur \ç|q|; + % & p $>=$ q \\ +\item \texttt{MidPlane(a,b,t)}: ce prédicat n'est vérifié que si la valeur de la + concentration du morphogène \ç|a| moins la concentration du morphogène \ç|b| + est comprise entre \ç|-t| et \ç|t|. + % & (get\_signal(a) $-$ get\_signal(b)) $>$ $-$t \\ + % & \& (get\_signal(a) $-$ get\_signal(b)) $<$ t\\ +%\item \texttt{OscillHigh(a,b,t)} +% % & cos(a $*$ mem.time) $>$ t \\ +%\item \texttt{OscillLow(a,b,t)} +% % & cos(a $*$ mem.time) $<$ t \\ + % & get\_signal(s) $>$ q1 \& get\_signal(s) $<$ q2 \\ +%\item \texttt{EqThresholdRefracted(s,q)} +% % & get\_signal(s) $=$ q \& mem.tn > tr\\ +%\item \texttt{LessThresholdRefracted(s,q,tr)} +% % & get\_signal(s) $<$ q \& mem.tn > tr\\ +%\item \texttt{GreaterThresholdRefracted(s,q,tr)} +% % & get\_signal(s) $>$ q \& mem.tn > tr\\ +%\item \texttt{LessEqThresholdRefracted(s,q,tr)} +% % & get\_signal(s) $>=$ q \& mem.tn > tr\\ +%\item \texttt{GreaterEqThresholdRefracted(s,q,tr)} +% % & get\_signal(s) $<=$ q \& mem.tn > tr\\ +%\item \texttt{BetweenThresholdRefracted(s,q1,q2,tr)} +% % & get\_signal(s) $>$ q1 \& get\_signal(s) $<$ q2 \& mem.tn > tr\\ +%\item \texttt{Rate(p)} +% % & rate(p) \\ +\end{itemize} + + + +\section{Propagation Parallèle à la Margolus}\label{sec:ppm} +Nous avons présenté l'architecture de haut niveau de \otb, ainsi que son langage +de configuration, cette section présente l'algorithme de Propagation Parallèle à +la Margolus (\ppm). Cette algorithme forme le socle théorique que nous +implémentons dans les kernels \opencl. Nous commençons par un rappel sur les +automates cellulaires, les automates à blocs, puis nous présentons l'algorithme +de bounding-box dynamique et enfin \ppm. + +\subsection{Automates cellulaires et voisinage de Margolus} +% Voir peut-être aussi CML (https://en.wikipedia.org/wiki/Coupled_map_lattice) +Notre travail se situe dans le contexte des automates cellulaires. Un automate +cellulaire est un modèle de calcul discret, introduit par John Von Neumann et +Stanislaw Ulam dans les années 1960~\cite{neumann_theory_1966}. C'est un modèle +de calcul Turing complet qui a d'abord été objet de recherche académique sur les +processus d'auto réplication, ensuite popularisé par le «Game of Life» de John +Conway\footnote{lors de sa publication dans les pages du Scientific American en + octobre 1970} où il est devenu un modèle pour les processus biologiques. Les +automates cellulaires sont un outil des paradigmes de programmation non +conventionnels, d'un côté permettant de formaliser les processus biologiques +observés, et de l'autre de les modéliser et de les simuler. +% Ce n'est néammoins qu'à partir des années 1980 et avec le physicien Stephen +% Wolfram que la recherche scientifique dans ce domaine s'est vraiment étendue. +% Son travail de classification des automates cellulaires a abouti à la +% publication en 2002 d'un livre intitulé «A New Kind of Science» désormais +% considéré comme une référence du domaine. + +\begin{mpo-definition}[Configuration] + Soit $\oQ$ un ensemble d'états, $G$ un groupe, $c_\oQ : G \rightarrow \oQ$ est + une \emph{configuration} et $C_\oQ := \{ c \,|\, c:G \rightarrow \oQ \}$ est + \emph{l'ensemble de toutes les configurations} $c_\oQ$. Quand le contexte lève + tout ambigüité, on pourra omettre l'indice $\oQ$. +\end{mpo-definition} + + +\begin{mpo-definition}[Automate cellulaire]\label{def:ca} + Un automate cellulaire est un tuple $\oA = (M, \oQ, N, f)$ dont: + \begin{itemize} + \item $(M,+)$ est un groupe abélien libre appelé \emph{maillage des cellules}; + \item $\oQ$ est \emph{l'ensemble des états}, aussi parfois appelé alphabet, + \item $N \in M^k$, $k \in \mathbb{N}$ est \emph{l'indice de + voisinage}, dont les éléments sont uniques deux à deux et $N = + (n_1,n_2,\ldots,n_k)$; + \item $f: \oQ^k \rightarrow \oQ$ est la \emph{fonction de transition locale} + \end{itemize} + $f$ induit une fonction de transition globale $F$, $\forall c \in C_\oQ$ et $m + \in M$: + \[ F(c)(m) := f(c(m+n_1),c(m+n_2),\ldots,c(m+n_k)) \] +\end{mpo-definition} + +La mise à jour d'une configuration se fait de manière locale, par l'application +de $f$ sur chaque cellule en fonction du voisinage, et \emph{synchrone} avec +des pas de temps discrets. Dans le cas d'un voisinage classique ou de Von +Neumann, à gauche dans la \textsc{Fig.}~\ref{fig:voisinage-2D}, les voisins directs +sont pris en compte pour le calcul du nouvel état de chaque cellule. Du point de +vue de \mgs{}, un automate cellulaire est constitué d'un ensemble $C$ de +collections topologiques et d'une transformation $T$ jouant le rôle de la +fonction de transition globale de l'automate. Quelques restrictions s'appliquent +sur chaque $c_i \in C$ et $T$: $c_i$ doit être une collection newtonienne de +type \gbf{} et $T$ doit utiliser la stratégie de réécriture +\texttt{maximal-parallel}, afin que la mise à jour soit synchrone. + +\begin{figure}[ht] + \centering + \includegraphics[page=1,width=.3\textwidth]{figures/ca-neighborhood-2D} + \includegraphics[page=2,width=.3\textwidth]{figures/ca-neighborhood-2D} + \includegraphics[page=3,width=.3\textwidth]{figures/ca-neighborhood-2D} + \caption{Trois exemples de voisinages sur un grille carrée en 2D, à gauche un + voisinage de Von Neumann, au centre un voisinage hexagonal et à droite un + voisinage de Moore.} + \label{fig:voisinage-2D} +\end{figure} + +En tant que modèle de calcul, un automate cellulaire fonctionne de manière +fortement parallèle: la même fonction est appliquée sur chaque cellule de la +grille, ou autrement dit le même algorithme est appliqué à de multiples données +ce qui est la définition d'une architecture SIMD. On pourrait donc tirer parti +d'une architecture fortement parallèle pour implémenter un automate cellulaire. +Néanmoins, la dépendance entre les données par la relation de voisinage entre +les cellules pose encore problème. Une solution classique revient à utiliser une +mémoire intermédiaire (un buffer) depuis lequel on va lire les données et écrire +les résultat dans un second buffer, cassant ainsi la dépendance en écriture sur +les cellules concernées. Cependant, il reste une \emph{dépendance en lecture} +sur les cellules voisines causant des collisions de lecture et pouvant encore +porter atteinte à l'efficacité d'une implémentation parallèle. Pour résoudre ces +problèmes, nous nous sommes tournés vers le voisinage de Margolus et de manière +plus générale, le modèle de calcul des automates à blocs. + +S'intéressant au développement d'ordinateurs simulant des systèmes physiques, +Toffoli et Margolus introduisent +dans~\cite{toffoli_cellular_1987,margolus_physics-like_1984} les automates +cellulaire à blocs (\emph{block cellular automata}), ou automate à partitions +(\emph{partitioning automata}), pour modéliser le comportement dynamique de +l'écoulement d'un fluide en respectant le principe de \emph{réversibilité} des +lois physiques. En thermodynamique, durant un processus réversible l'entropie +n'augmente pas et le système est en état d'équilibre thermodynamique. On appelle +\emph{automate cellulaire réversible} les automates cellulaire dont on retrouve +la configuration d'origine en «inversant» la flèche du temps. Un automate +cellulaire dont chaque cellule est mise à jour en inversant sa valeur précédente +et en ignorant son voisinage est trivialement réversible. Cependant, au delà +d'une dimension, la réversibilité d'un automate cellulaire est +indécidable~\cite{kari_reversibility_1994}. L'automate gaz sur réseau (lattice +gas automaton)~\cite{hardy_time_1973}, la règle +«Tron»~\cite{toffoli_cellular_1987}, l'ordinateur à boules de billard +(billiard-ball computer)~\cite{fredkin_conservative_1982} sont des exemples +d'automates cellulaires réversibles. Toffoli et Margolus montrent également que +la classe des automates à partitions est équivalente à celles des automates +cellulaires, et que ces deux modèles peuvent se simuler l'un l'autre. + +%\begin{mpo-definition}[Division entière] $\text{div}_k$ est la division entière +% par $k$, une fonction retournant la partie entière de la division euclidienne +% par $k$. Pour $k \in \mathbb{N}_+$ et $x \in \mathbb{R}$ : +% \[ +% \text{div}_k(x) = \left\lfloor \frac{x}{k} \right\rfloor +% \] +% avec la fonction partie entière $\lfloor x \rfloor = \text{max} \{ m \in +% \mathbb{Z} \,|\, m \leq x \}$. +%\end{mpo-definition} + +%\begin{mpo-definition}[Rang] Le rang d'un groupe $G$, noté $\text{rank}(G)$ +% donne la plus petite cardinalité d'un ensemble de générateurs de $G$ : +% \[ +% \text{rank}(G) = min \{ |X| : X \subseteq G, \langle X \rangle = G \}. +% \] +%\end{mpo-definition} + +\begin{mpo-definition}[Automate cellulaire à blocs] Un automate cellulaire à + blocs, aussi appelé automate à partitions, est un tuple + $B=(M,\oQ,p,\text{\em shift},f)$ avec: + \begin{itemize} + % Lattice (order) != Lattice (groups) | Treilli != Réseau + \item $(M,+)$ le maillage des cellules. C'est le groupe abélien \emph{libre} + engendré par l'ensemble fini $A = \{g_1,...,g_n\}$; + \item $\oQ$ un ensemble d'états; + \item $p : M \rightarrow M$ la fonction de pavage qui pour $\{c_1,...,c_n\} + \subset \mathbb{Z}^n$ et $\{k_1,...,k_n\} \subset \mathbb{N}_{+}^n$ associe à + chaque point de $M$ un \emph{bloc}: + \[ + p(\sum\limits_{i=1}^{n}{c_i\ g_i}) + = \sum\limits_{i=1}^{n}{\left\lfloor \frac{c_i}{k_i} \right\rfloor g_i} + \] + La fonction inverse $p^{-1}(m) = \{ m \in M\, |\, p(m) \in M \}$ permet + d'obtenir l'ensemble des éléments du bloc indicé par $m$. + \item $\text{\em shift}$ est la liste d'éléments $(m_1,...,m_n)$ de $M$ . + \item $f : Q^k \rightarrow Q^k$ est la fonction de transition locale, avec $k + = \prod_{i=1}^{n}{k_i}$. + \end{itemize} + La fonction de transition locale $f$ induit une fonction de transition + globale, dont la définition est décrite par l'algorithme + %\[ + % F(c)(m) = \left[ f (c (T^s \beta(m))) \right]_m + %\] + \begin{algorithm} + \ForAll {$s \in \text{shift}$} + { \ForAll {$m \in M$} { + $M \gets f (c_1 (T^s \beta(m)))$ \; + } + } + \end{algorithm} + en posant: + \begin{itemize} + \item $T^s$ l'opérateur de décalage sur les groupes Abéliens, $T^s f(g) = + f(g+s)$ en prenant un groupe Abélien $G$, $g \in G$ et $f : G \rightarrow + G$; + \item $\beta(m) = (p^{-1} \circ p) (m)$ l'ensemble des éléments appartenant au + bloc de la cellule $m$ et + \item $c_1(B) : M \rightarrow Q^k $ la configuration d'un ensemble de cellules + \emph{indexées par leur élément correspondant} dans le groupe. Nous + n'expliciterons pas la version formelle ici pour ne pas alourdir la + définition inutilement. + \end{itemize} +\end{mpo-definition} + +Nous avons choisi d'utiliser la structure de groupe abélien libre pour +représenter un maillage de cellule. C'est également le point de vue utilisé dans +la définition des \gbf{} à la différence que nous nous restreignons aux groupes +libres, afin de pouvoir définir un pavage naturel. De ce point du vue, il +semblerait qu'un automate cellulaire à bloc ne puisse pas avoir de maillage +hexagonal, avec la présentation de groupe $H = \langle a,b,c \:|\: a + b = c +\rangle$, car ce n'est pas un groupe libre. Néanmoins, nous pourrons considérer +qu'un maillage hexagonal est un maillage carré, de présentation $H = \langle a,b +\rangle$ sur lequel le voisinage entre cellules est spécifique comme présenté +sur la \textsc{Fig.}~\ref{fig:voisinage-2D} au centre. Par conséquent, c'est la +fonction de transition locale qui déterminera quel voisinage est utilisé. + +La fonction $\lfloor x/k \rfloor$ se comporte « naturellement » autour de $0$: +chaque image par cette fonction possède exactement $k$ préimages. Cette +caractéristique permet, par exemple, de partitionner $\mathbb{Z}$ en +sous-ensembles de cardinalité $k$, d'où son usage dans la définition de $p$. + +Pour la définition de la fonction de pavage, nous avons choisi une approche +similaire à la définition d'une partition de l'espace passant par les +$\mathbb{Z}$-modules comme introduit dans~\cite{michel_representations_1996} à +la section VI.1.1. Notre approche correspond mieux à l'idée intuitive d'une +sous division de l'espace: à chaque cellule du maillage on fait correspondre une +cellule du même maillage, ce qui expose immédiatement la structure et la +régularité du pavage. + +% def générale + +Le voisinage de Margolus est la règle de partitionnement du maillage d'un +automate à blocs en une grille composée de blocs de $2$ cellules (ou en carrés +de $2\times 2$ cellules en deux dimensions, en cubes de $2\times 2\times 2$ +cellules en trois dimension, …) avec un décalage d'une «case» dans toutes les +directions. C'est donc un cas particulier d'automate cellulaire à blocs, avec +les restrictions suivantes (en reprenant le contexte de la définition des +automates à blocs): +\begin{itemize} +\item $p : M \rightarrow M$ la fonction de pavage qui pour $\{c_1,...,c_n\} + \subset \mathbb{Z}^n$ associe à chaque point de $M$ un bloc de côté 2: + \[ + p(\sum\limits_{i=1}^{n}{c_i\ g_i}) + = \sum\limits_{i=1}^{n}{\left\lfloor \frac{c_i}{2} \right\rfloor g_i} + \] et +\item shift est l'élément $\sum\limits_{i=1}^{n}{1\ g_i} \in M$. +\end{itemize} +%restrictions + +\begin{figure}[ht] + \centering + \includegraphics[page=1,width=.4\textwidth]{figures/ca-neighborhood} + \hspace{1cm} + \includegraphics[page=2,width=.4\textwidth]{figures/ca-neighborhood} + \caption{Voisinage classique (à gauche) d'un automate cellulaire à une + dimension et voisinage de Margolus (à droite). Pour le voisinage classique, + chaque ligne correspond à un pas dans la simulation de l'automate, de haut + en bas. Pour le voisinage de Margolus, un seul pas de simulation est + présenté, la ligne du milieu est présentée afin de montrer la correspondance + entre les deux automates.} + \label{fig:ac-nh} +\end{figure} + + +\subsection{Bounding box et activité}\label{sec:boundingbox} +Dans OTB, l'environnement dans lequel évoluent les bactérie n'a pas \emph{a + priori} de taille fixe et subit une expansion ou une contraction en fonction +de l'espace occupé par les bactéries, ou par leur support. Nous appelons +\emph{bounding box} la boîte englobante dont l'intérieur forme l'environnement +dans lequel évoluent les bactéries, ou leur support. Cette bounding box a une +taille rectangulaire libre. La bounding box est construite \emph{a posteriori}: +elle est déterminée par la taille de la grille d'automate qu'elle représente. De +cette manière, il est possible d'accéder rapidement à la taille d'une population +de bactéries et d'effectuer des calculs de collision entre bounding box et des +opérations de séparation et de fusion. Ces opérations, bien que planifiées, ne +sont que partiellement implémentées à l'heure de l'écriture de ce mémoire. + +\begin{figure}[ht] + \centering + \includegraphics[page=1,width=.8\textwidth]{figures/bb-activity} + \caption{Grille d'un automate cellulaire, ses indicateurs vertical et + horizontal et sa Bounding Box (en gras)} + \label{fig:bb-activity} +\end{figure} + +Nous utilisons une mesure d'activité spatiale pour déterminer s'il est +nécessaire d'agrandir ou de diminuer la taille de l'environnement. Chaque +cellule de l'automate contenant une bactérie est considérée comme active. Si une +cellule active se trouve à une distance inférieure à $d_c$ d'un des bords, alors +l'environnement est agrandi. À l'inverse, si la distance la cellule active la +plus proche d'un bord à ce bord est supérieure à $d_f$ alors, l'environnement +est rétréci. + +En pratique, une bounding box est définie par un triplet $(p,w,h)$ où $p=(x,y)$ +est un point dans le plan représentant le coin inférieur gauche de la boîte, $w$ +est sa largeur et $h$ est sa hauteur (Fig.~\ref{fig:bb-activity}). Nous mesurons +l'occupation pour chaque ligne et chaque colonne avec deux tableaux appelés +\emph{indicateur}: un pour l'occupation horizontale, l'autre pour l'occupation +verticale. Ces deux tableaux sont suffisant pour déterminer s'il est nécessaire +d'agrandir ou de rétrécir l'environnement. L'algorithme suivant est utilisé par +\otb pour déterminer une nouvelle bounding box optimale, $w,h$ sont la largeur +et la hauteur respectives de la bounding box de départ, $c_w,c_h$ sont les +tableaux indicateurs sur la largeur et la hauteur respectivement. + +La première partie de cet algorithme détermine la position de coupe par rapport à +chacun des quatre bords nord, sud, est et ouest de la bounding box. Il suffit +pour cela de déterminer la position du premier élément non nul pour chaque +extrémité de chaque indicateur, ce qui nous fournit le quadruplet $(\text{posN}, +\text{posS}, \text{posE}, \text{posW})$ de positions de coupe au nord, au sud à +l'est et à l'ouest respectivement. + +%#trivial? +%\begin{algorithm}[h] +% \SetKwInOut{Input}{input}\SetKwInOut{Output}{output} +% \SetKwData{PosN}{posN} +% \SetKwData{PosS}{posS} +% \SetKwData{PosE}{posE} +% \SetKwData{PosW}{posW} +% +% \Input{Une bounding box de dimension $w \times h$ et deux indicateurs $c_w,c_h$} +% \Output{Un quadruplet de positions de découpe} +% $\PosN \gets \infty$, +% $\PosS \gets \infty$, +% $\PosE \gets \infty$, +% $\PosW \gets \infty$\; +% +% $i \gets 0$ \tcp*{Coupe ouest} +% \While{$i < w$}{ +% \If{$c_h[i] = 1$}{ +% $\PosW \gets i$\; +% break\; +% } +% $i \gets i + 1$\; +% } +% \tcp{...} +%\end{algorithm} +%\begin{algorithm}[h] +% \setcounter{AlgoLine}{12} +% \SetKwData{PosN}{posN} +% \SetKwData{PosS}{posS} +% \SetKwData{PosE}{posE} +% \SetKwData{PosW}{posW} +% +% \tcp{...} +% +% $i \gets w - 1$ \tcp*{Coupe est} +% \While{$i \ge 0$} { +% \If{$c_h[i] = 1$}{ +% $\PosE \gets i$\; +% break\; +% } +% $i \gets i - 1$\; +% } +% +% $j \gets 0$ \tcp*{Coupe sud} +% \While{$j < h$}{ +% \If{$c_w[j] = 1$}{ +% $\PosS \gets j$\; +% break\; +% } +% $j \gets j + 1$\; +% } +% +% $j \gets h - 1$ \tcp*{Coupe nord} +% \While{$j \ge 0$}{ +% \If{$c_w[j] = 1$}{ +% $\PosN \gets j$\; +% break\; +% } +% $j \gets j - 1$\; +% } +% +% \Return (\PosN,\PosS,\PosE,\PosW) +% \caption{Détermination des indicateurs de coupe} +%\end{algorithm} +%L'instruction \textbf{break} sert à terminer la boucle courante immédiatement +%indiquant que la recherche termine au plus tôt. + +La seconde partie de cet algorithme détermine la nouvelle dimension de la +bounding box, en prenant en compte les deux marges notée $d_c$ et $d_f$ et en +fonction des positions de coupe déterminées auparavant. La fonction +\texttt{CropBoundingBox()} est chargée de la mise en œuvre du découpage de +l'ancienne bounding box et en retourne une nouvelle en fonction du quadruplet +$(\text{n}, \text{s}, \text{e}, \text{w})$ indiquant les corrections de marge à +chacune des extrémité. Par exemple, $\text{n}=2$ agrandi de 2 unités la taille +de la bounding box au nord, alors que $\text{e}=-4$ rétrécie de 4 unités la +taille de la bounding box à l'est. Cette fonction est implémenté dans le module +de bas niveau \ç|BoundingBox|. + +\begin{algorithm}[H] + \SetKwInOut{Input}{input}\SetKwInOut{Output}{output} + \SetKwData{PosN}{posN}\SetKwData{PosS}{posS} + \SetKwData{PosE}{posE}\SetKwData{PosW}{posW} + \SetKwData{OldBB}{oldBB} + \SetKwFunction{CBB}{cropBoundingBox} + + \Input{Bounding box actuelle \OldBB et \PosN, \PosS, \PosE, \PosW}% + \Output{Une nouvelle bounding box ajustée} + \eIf(\tcp*[f]{Marge nord}){$\PosN < d_c$}{ + $n \gets d_c - \PosN$\; + }{ + \If{$\PosN > d_f$} { + $n \gets d_c - \PosN$\;} + \Else{ + $n \gets 0$\; + } + } + + \tcp{Exactement la même opération pour sud, est et ouest} + + \Return{\CBB{\OldBB, $n$, $s$, $e$, $w$}} + \caption{Création d'un nouvelle bounding box aux \emph{bonnes} dimensions} +\end{algorithm} + + + +\subsection{Propagation Parallèle à la Margolus} +L'algorithme \ppm est inspiré du voisinage de Margolus, à droite dans la +\textsc{Fig.}~\ref{fig:ac-nh}, en deux dimensions et l'utilise comme structure de +données. Il effectue la simulation d'un automate cellulaire à blocs sur une +machine parallèle d'architecture SIMD, nous l'avons implémenté sous forme d'un +kernel \opencl. Pour faciliter sa lisibilité, en voici une description un peu +plus haut niveau que notre implémentation. + + +\paragraph{Cellule}% +Chaque cellule est constituée de quatre emplacements: son propre état et l'état +de trois de ses voisines comme présenté dans la \textsc{Fig.}~\ref{fig:margolus-grid}. +Ces quatre emplacements seront notés dans l'algorithme suivant par abus +de la notation classique de tableau, avec les indices spéciaux 1, 2, 3 et +4. Ainsi, $m[a1]$ désigne le premier emplacement de la cellule $A$. La +\textsc{Fig.}~\ref{fig:margolus-grid} (a) donne une représentation visuelle de la +position des cellules et de leurs emplacements en accord avec l'algorithme. + +\begin{figure}[ht] + \centering + \includegraphics[page=1,width=.24\textwidth]{figures/margolus}\hfill% + \includegraphics[page=2,width=.24\textwidth]{figures/margolus}\hfill% + \includegraphics[page=3,width=.24\textwidth]{figures/margolus}\hfill% + \includegraphics[page=4,width=.24\textwidth]{figures/margolus} + + \hspace{.11\textwidth}(a)\hfill(b)\hfill(c)\hfill(d)\hspace{.11\textwidth} + \caption[Quatre configuration successives d'un automate cellulaire en deux + dimensions.]{\textit{Général.} Quatre configurations successives d'un + automate cellulaire en deux dimensions dont les cellules sont en gris.% + \textit{\hspace{1em}(a).} Les coordonnées utilisées dans l'algorithme pour + une cellule de Margolus.% + \textit{\hspace{1em}(b).} Les cellules A,B,C et D font partie d'une cellule + du voisinage de Margolus (en noir, en gras).% + \textit{\hspace{1em}(c).} Chacune des cellules stocke quatre états: la copie + de l'état de trois de ses voisines et le sien (en blanc sur fond noir). + Le positionnement de ces états est présenté par rapport au voisinage de + Margolus courant.% + \textit{\hspace{1em}(d).} Après une étape de calcul, les états de A, B, C + et D sont mis à jour en A', B', C' et D' et le voisinage de Margolus est + décalé.} + \label{fig:margolus-grid} +\end{figure} + +\paragraph{Algorithme}% +\ppm prend en entrée un tableau de cellules \ç|cellSpace[w][h]| en deux +dimensions de largeur \ç|w| et de hauteur \ç|h| et un indicateur \ç|shift| +déterminant le décalage du voisinage. La fonction d'évolution locale +\ç|evol(c,n1,n2,n3,n4,n5,n6,n7,n8)| prend en argument l'état courant \ç|c| ainsi +que l'état des 8 cellules voisines \ç|n1,...,n8|. + +La fonction de mise à jour est appelée en parallèle sur \emph{le même tableau} +de cellules et doit donc être paramétrée pour indiquer sur quelle cellule elle +travaille: c'est le rôle des deux variables spéciales $gc_x$ et $gc_y$ indiquant +la position globale en abscisse et en ordonnée du bloc courant. C'est donc la +coordonnée d'une cellule du voisinage de Margolus qui est fournie. Ces deux +variables sont les paramètres propres à un work-item \opencl, qui permet à +chaque instance du kernel d'avoir un comportement différent. + +\begin{algorithm} + \SetKwInOut{Input}{input}\SetKwInOut{Output}{output} + \SetKwData{CellSpace}{cellSpace}\SetKwData{Shift}{shift} + \SetKwData{Slot}{.slot}\SetKwData{Evol}{evol} + + \Input{Une configuration \CellSpace d'un automate cellulaire en deux + dimension, un indice de décalage \Shift valant 0 ou 1 et les coordonnées + globales $(gc_x,gc_y)$ du bloc actuel}% + \Output{Aucune (le changement est effectué par effet de bord)} + + $p_x \gets 2 * gc_x + \texttt{shift}$ \tcp*{Coordonnées de la cellule} + $p_y \gets 2 * gc_y + \texttt{shift}$\; + $i_x \gets p_x + 1$\; + $i_y \gets p_y + 1$\; + + Nouveau tableau local de 2×2 cellules: $m[2][2]$\; + $m[0][1] \gets \texttt{cellSpace}[N*iy+px]$\; + $m[1][1] \gets \texttt{cellSpace}[N*iy+ix]$\; + $m[0][0] \gets \texttt{cellSpace}[N*py+px]$\; + $m[1][0] \gets \texttt{cellSpace}[N*py+ix]$\; + + Nouvelle cellule locale: $n$\; + $n[1] \gets \Evol(m[a3],$\tcp*[f]{Cellule courante $A$}\\ + $\qquad m[a1],m[a2],m[b1],m[b4],m[c1],m[d2],m[d1],m[a4])$ + \; + + $n[2] \gets \Evol(m[b4],$\tcp*[f]{Cellule courante $B$}\\ + $\qquad m[a2],m[b1],m[b2],m[b3],m[c2],m[c1],m[d2],m[a3])$ + \; + + $n[3] \gets \Evol(m[c1],$\tcp*[f]{Cellule courante $C$}\\ + $\qquad m[a3],m[b4],m[b3],m[c2],m[c3],m[c4],m[d3],m[d2])$ + \; + + $n[4] \gets \Evol(m[d2],$\tcp*[f]{Cellule courante $D$}\\ + $\qquad m[a4],m[a3],m[b4],m[c1],m[c4],m[d3],m[d4],m[d1])$ + \; + + $\CellSpace[N*iy+px] \gets n$\; + $\CellSpace[N*iy+ix] \gets n$\; + $\CellSpace[N*py+px] \gets n$\; + $\CellSpace[N*py+ix] \gets n$\; + \caption{\ppm} +\end{algorithm} + +La cellule localement créée $n$ est au cœur du fonctionnement de \ppm. +Il pourrait paraître en premier lieu étrange qu'elle soit recopiée à +l'identique dans les quatre cellules de \ç|cellSpace| constituant l'unique +cellule de Margolus en cours de mise à jour. Néanmoins, en s'aidant de la +\textsc{Fig.}~\ref{fig:margolus-grid} et en prenant en compte que le prochain +décalage de la grille de Margolus se fait sur une cellule en diagonale, une +symétrie apparaît. + +La création d'un tableau local $m$ de $2 \times 2$ est en revanche moins +importante, cependant elle reste utile pour deux raisons: elle améliore sa +lisibilité de l'algorithme et l'utilisation de variables locales en général nous +permet de limiter le nombre d'accès à la mémoire globale en faisant un usage +plus intensif de la mémoire privée (voir le paragraphe Architecture \opencl +page~\pageref{sec:archi-cl}). + +L'algorithme \ppm travaille sur un bloc et, dans le voisinage de Margolus, +chaque bloc est indépendant, ainsi il n'y a pas de problème de concurrence ni à +l'accès au données ni à l'écriture. Chaque cellule embarque un quart de son +voisinage et comme un bloc est constitué de quatre cellules, ce bloc contient +toutes les informations nécessaires pour effectuer une mise à jour localement. +Ainsi, alors que les algorithmes usuels de simulation d'automates cellulaires +utilisent deux copies de la configuration actuelle pour éviter les collisions de +lecture, \ppm n'en a pas besoin. + + + + + + + +% #IloveFloatBarrier +\FloatBarrier +\section{Implémentation de \tb{}}\label{sec:implementation} +Dans cette section nous décrivons les trois modèles (appelés moteurs) qui +gouvernent le fonctionnement du simulateur: le moteur chimique, le moteur +physique et le moteur de décision. + +\subsection{Moteur chimique: réaction et diffusion} +Dans cette section nous présentons la fonction de transition de l'automate +cellulaire en charge de la simulation chimique du milieu dans lequel évolueront +les bactéries. Ce milieu a comme propriété de diffuser plusieurs morphogènes et +de les faire réagir. L'équation de réaction-diffusion est un modèle mathématique +qui permet, entre autres, de modéliser l'évolution de la concentration dans +le temps et dans l'espace d'espèces chimiques diffusant et réagissant entre +elles. Il a notamment été utilisée par A. Turing~\cite{turing_chemical_1952} +a qui nous empruntons le terme de \emph{morphogène} pour décrire une espèce +chimique dans notre automate. Exprimée pour un seul morphogène dans une +dimension d'espace, l'équation de réaction-diffusion est appelé l'équation de +Kolmogorov-Petrovsky-Piskounov (KPP)~\cite{kolmogorov_etude_1937}. + +Nous partirons d'une version généralisée de l'équation KPP en deux dimensions +d'espace, avec un nombre $n \in \mathbb{R}_+$ de morphogènes: +\begin{equation} + \frac{\partial\orr\varphi}{\partial t} = + \orr{\text{X}}(\orr\varphi) + + \orr{\text{D}}^{\text{T}} \cdot \left( \frac{\partial^2\orr\varphi}{\partial x^2} + + \frac{\partial^2\orr\varphi}{\partial y^2} \right) + \label{eq:reaction-diffusion-2D} +\end{equation} +L'équation~\ref{eq:reaction-diffusion-2D} donne la variation des concentrations +de plusieurs espèces chimiques, ou morphogènes, dénotée $\orr\varphi = +(\varphi_1,\ldots,\varphi_n)$, au cours du temps et dans un espace à deux +dimensions où $\orr{\text{D}}^{\text{T}} = (\text{D}_1,\ldots,\text{D}_n)$ sont +les coefficients de diffusion et $\orr{\text{X}}^{\text{T}} = +(\text{X}_2,\ldots,\text{X}_n)$ est un champ de vecteur décrivant la cinétique +locale du système, autrement dit les réactions entre morphogènes. + +\paragraph{Discrétisation} +Lors d'une simulation numérique, le temps et l'espace sont discrétisés et il +existe différentes méthodes pour approcher par des méthodes discrètes la +solution de l'équation~\ref{eq:reaction-diffusion-2D}. L'implémentation actuelle +du simulateur utilise la méthode d'Euler, la méthode d'intégration numérique la +plus simple: +%\begin{align*} +% \displaystyle +% \varphi^{t + \Delta t}_{1,i,j} &= \Delta t\,\text{X}_1(\varphi^t_{1,i,j}, \varphi^t_{2,i,j}) +% + \frac{\text{D}_1\Delta t}{(\Delta x)^2} +% (\varphi^t_{1,i-1,j} + \varphi^t_{1,i+1,j} + \varphi^t_{1,i,j-1} + \varphi^t_{1,i,j+1} +% - 4\varphi^t_{1,i,j})\\ +% \displaystyle +% \varphi^{t + \Delta t}_{2,i,j} &= \Delta t\,\text{X}_2(\varphi^t_{1,i,j}, \varphi^t_{2,i,j}) +% + \frac{\text{D}_2\Delta t}{(\Delta x)^2} +% (\varphi^t_{2,i-1,j} + \varphi^t_{2,i+1,j} + \varphi^t_{2,i,j-1} + \varphi^t_{2,i,j+1} +% - 4\varphi^t_{2,i,j}) +%\end{align*} +\begin{align}\label{eq:num-int} + \displaystyle + \varphi^{t + \Delta t}_{k,i,j} &= \Delta t\,\text{X}_1(\varphi^t_{1,i,j}, \ldots, \varphi^t_{k,i,j}) + + \frac{\text{D}_k\Delta t}{(\Delta x)^2} + (\varphi^t_{k,i-1,j} + \varphi^t_{k,i+1,j} + \varphi^t_{k,i,j-1} + \varphi^t_{k,i,j+1} + - 4\varphi^t_{k,i,j}) +\end{align} +où les indices $(i,j)$ dénotent la position sur une grille carrée en 2D. +Dans~\cite{dilao_validation_1998}, les auteurs fournissent une classe +de méthodes pour l'intégration numérique d'équations de diffusion et de +réaction-diffusion approchant la solution exacte de l'équation de diffusion +continue. En l'absence d'une validation plus poussée de notre outil, nous ne +pouvons pas encore nous prononcer sur l'impact de l'erreur introduite par la +discrétisation sur automate. Cependant, d'un point de vue qualitatif, le moteur +chimique s'est suffisamment bien comporté pour les quelques tests que nous avons +menés. En choisissant un $\Delta t$ suffisamment petit, en l'occurrence $\Delta +t = \num{0.01}$, nous avons pu reproduire des réactions chimiques classiques, +dont une réaction BZ (voir section~\ref{sec:bz}). + +% However, cellular automata models cannot be calibrated and validated from real +% parameters (kinetic reaction rates and diffusion coefficients), as the +% physical and chemical mechanisms that characterize the observed phenomena are +% generally continuous models — +% https://taf.menf.in/_media/bibliographie/reaction-diffusion-calibration.pdf + +\paragraph{Fonction de transition} +\newcommand{\RTable}{\ensuremath{\mathit{RTable}}} +\newcommand{\RRate}{\ensuremath{\mathit{RRate}}} +Chaque cellule de l'automate a pour état la concentration de chacun des $n$ +morphogènes de la simulation: +\[ + (conc_1,conc_2,\ldots,conc_n) +\] +Une table des réactions $\RTable[i][j]$ est définie comme un tableau en deux +dimensions avec selon $i$ les $n$ morphogènes et selon $j$ les $r$ réactions. +Une liste des taux de réaction $\RRate[j]$ donne le coefficient de vitesse pour +la réaction $j$. Ces deux valeurs sont définies avant la simulation et sont donc +accessibles à la fonction de transition locale du moteur chimique. Par exemple, +dans le cas d'une simulation à trois morphogènes $a,b,c$ où deux réactions $r,s$ +sont possibles +\[ + \RTable = \left[ + \begin{array}{rrr} + -1 & -2 & 2 \\ + 0 & 2 & -1 + \end{array} \right] + \qquad + \RRate = (\alpha, \beta) +\] +désigne les réactions +\[ + a + 2b \xrightarrow{\alpha} 2c + \qquad\text{et}\qquad + c \xrightarrow{\beta} 2b +\] + +\begin{algorithm} + \SetKwData{Evol}{evol} + \SetKw{KwFrom}{from} + \SetKw{And}{and} + \SetKwData{NBPC}{$\mathit{nbpc}$} + \SetKwProg{Fn}{Fonction}{ as} + + \Fn{\Evol(c: cell, $n_1$: cell, $\ldots$, $n_8$: cell): cell}{ + \For(\tcp*[f]{Diffusion de chacun des morphogènes}){$i$ \KwFrom $0$ \KwTo + $n-1$}{% + $ c'[i] \gets c[i] + \Delta t * D[i] * \frac{1}{(\Delta x)^2} * ( n_2[i] + + n_4[i] + n_6[i] + n_8[i] - 4 c[i] )$\;% + \For(\tcp*[f]{Résultat des réactions entre morphogènes}){$j$ \KwFrom $0$ + \KwTo $r-1$}{ $c'[i] \gets c'[i] + \Delta t * \RTable[i][j] * \RRate[j]$\; + } } \Return{$c'$}\; } + \caption{Fonction de transition locale du moteur chimique} +\end{algorithm} + +Dans le cas de la diffusion sans réaction, la diffusion sur +automate à bloc à voisinage de Margolus a été traité dans la +littérature~\cite{medvedev_multi-particle_2010} et montre que le processus +de diffusion est exactement simulé par un automate cellulaire booléen +bloc synchrone sur voisinage de Margolus. + + +\subsection{Moteur physique: collisions} +Dans cette section, nous présentons la construction de la fonction de transition +de l'automate cellulaire en charge de la simulation physique des bactéries. Le +moteur physique représente certains aspects de la mécanique du solide, notamment +les translations sur le plan, la rotation et la collision entre objets. Nous +utilisons un modèle de mécanique newtonien avec des simplifications spécifiques +à l'échelle à laquelle les bactéries évoluent. Le modèle suivant est décrit dans +un plan vectoriel en deux dimensions. + +\paragraph{Modèle physique au repos} +Une bactérie est modélisée par une masse $m$, un centre de masse $p = +(p_x,p_y)$, une longueur $l$ et un rayon $r$ donnant son épaisseur (voir +Fig.~\ref{fig:ecoli} droite). Son orientation est représentée de manière +équivalente, soit par un angle $t$, soit par un vecteur directeur $d = +(d_x,d_y)$ en prenant $d_x = \mathit{cos}(t)$ et $d_y = \mathit{sin}(t)$. La +longueur totale d'une bactérie est notée $L$ et sa surface $S$. +%\[ +% L = 2 \times (r + l) +%\] +%et sa surface est obtenue comme suit +%\begin{align*} +% S &= 2 r \times 2 l + \pi r^2\\ +% &= 4 r l + \pi r^2 +%\end{align*} +Nous ajoutons deux points $f=(f_x,f_y)$ et $b=(b_x,b_y)$ représentant respectivement l'avant et +l'arrière de la bactérie +\begin{align*} + f_x &= p_x + l \times \mathit{cos}(t) & b_x &= p_x - l \times \mathit{cos}(t)\\ + f_y &= p_y + l \times \mathit{sin}(t) & b_y &= p_y - l \times \mathit{sin}(t) +\end{align*} +% +% Forces +Du point de vue cinétique, une bactérie possède une vitesse de déplacement de +norme $v_b$ colinéaire à $\orr{d}$ et une vitesse de rotation de norme +$\omega_b$ autour de $p$. Elle a également un taux de croissance $g$ faisant +varier sa masse, sa longueur et sa largeur. + +La quantité de mouvement, aussi appelé moment linéaire, d'une bactérie est +$\orr{p} = m \orr{v}_b$ et son moment angulaire, aussi appelé moment cinétique, +autour de son centre d'inertie est $\orr{L} = I \orr{\omega}_b$ où le moment +d'inertie $I$ est similaire au moment d'inertie d'une tige de densité de masse +uniforme, tournant autour de son centre de masse, de la même longueur que la +bactérie, à savoir: +\[ + I = \displaystyle\frac{1}{12} \times m(2r+2l)^2 = + \displaystyle\frac{1}{6} \times m(r+l)^2 +\] + +Du point de vue dynamique, nous considérons que les bactéries évoluent dans un +milieu dont la viscosité est très élevée. Au centre de masse de chaque bactérie +s'applique la somme des forces extérieures d'accélération linéaire $F$ et +accélération angulaire $T$ transmises lors de collisions avec d'autres objets. + +% Calcul d'une collision (schéma) +\begin{figure}[ht] + \centering + \includegraphics[page=2,width=.49\textwidth]{figures/collision}\hfill + \includegraphics[page=3,width=.49\textwidth]{figures/collision} + \caption{La détection d'une collision a lieu lorsque l'un des pôles d'une + bactérie est proche du corps d'une autre bactérie (à gauche). Quelques + vecteurs utilisés dans le calcul de l'impulsion (à droite)} + \label{fig:collision} +\end{figure} + +% Qu'est-ce-qu'une collision +\paragraph{Collision entre deux bactéries} +En général, déterminer si deux objets sont en collision, c'est à dire déterminer +si l'intersection des deux objets est non vide, n'est pas trivial, et ce pour +deux raisons: les objets ont une forme potentiellement complexe et il peut +y avoir un grand nombre d'objets. Pour les ceux qui ont une forme complexe, +un objet de forme proche et plus simple, comme un disque ou un rectangle, +appelé \emph{bounding box}\footnote{différent de la bounding box que nous avons +présenté avant, celle-ci est autour d'une unique bactérie, notre bounding +box est autour d'une population de bactérie. Leurs fonctions sont toutefois +similaires.} est utilisée pour faciliter le calcul d'intersection. Dans le cas +où un grand nombre d'objet peuvent entrer en collision, l'espace est divisé en +petites sections afin que le test de collision n'ait lieu que pour un faible +nombre d'objets. + +% Collision de deux bactéries +Commençons par déterminer la fonction de collision pour deux bactéries. Cette +fonction prend en entrée deux bactéries et retourne vrai s'il y a collision, +avec la distance de collision la plus courte, les vecteurs de collision, les +positions des collisions, ou faux s'il n'y a pas collision. Chaque bactérie est +déterminée par un quadruplet comprenant le vecteur position du centre de masse, +le vecteur directeur (unitaire), la longueur et le rayon respectivement $b_1 = +(\orr{p_1},\orr{d_1},l_1,r_1)$ et $b_2 = (\orr{p_2},\orr{d_2},l_2,r_2)$. À +partir de ces informations, nous pouvons obtenir les coordonnées des extrémités +\begin{align*} + \orr{f_1} &= \orr{p_1} + l_1 \cdot \orr{d_1} & \orr{f_2} &= \orr{p_2} + l_2 \cdot \orr{d_2}\\ + \orr{b_1} &= \orr{p_1} - l_1 \cdot \orr{d_1} & \orr{b_2} &= \orr{p_2} - l_2 \cdot \orr{d_2} +\end{align*} +Le critère de collision est simple. Grâce à la forme de la bactérie, il nous +faut juste vérifier qu'aucun point du segment $[f_1,b_1]$ n'est à une distance +inférieure ou égale à $d_\mathrm{min} = r_1+r_2$ d'un point du segment +$[f_2,b_2]$. Aussi, nous commencerons par construire les projections +orthogonales restreintes à un segment des pôles $\orr{f}^j_i, \orr{b}^j_i$ d'une +bactérie $i$ sur le corps d'une bactérie $j$. +\begin{align*} + \orr{f}^2_1 &= \orr{p_2} + + \big[ \orr{d_2} + (\orr{f_1} - \orr{p_2}) \big]^{l_2}_{-l_2} + \cdot{} \orr{d_2} & + \orr{f}^1_2 &= \orr{p_1} + + \big[ \orr{d_1} + (\orr{f_2} - \orr{p_1}) \big]^{l_1}_{-l_1} + \cdot{} \orr{d_1} \\ + \orr{b}^2_1 &= \orr{p_2} + + \big[ \orr{d_2} + (\orr{b_1} - \orr{p_2}) \big]^{l_2}_{-l_2} + \cdot{} \orr{d_2} & + \orr{b}^1_2 &= \orr{p_1} + + \big[ \orr{d_1} + (\orr{b_2} - \orr{p_1}) \big]^{l_1}_{-l_1} + \cdot{} \orr{d_1} +\end{align*} +Restreindre la projection a un segment reflète le fait qu'une bactérie a une +longueur \emph{limitée}. Si on omet cette restriction, on obtient les +projections de la \textsc{Fig.}~\ref{fig:collision}, où la distance la plus courte +n'est pas nécessairement indicatrice d'une collision. Il nous reste à obtenir +les 4 vecteurs de collisions +\begin{align*} + \orr{n}_{f_{12}} &= \orr{f}^2_1 - \orr{f}_1 & \orr{n}_{f_{21}} &= \orr{f}^1_2 - \orr{f}_2 \\ + \orr{n}_{b_{12}} &= \orr{b}^2_1 - \orr{b}_1 & \orr{n}_{b_{21}} &= \orr{b}^1_2 - \orr{b}_2 +\end{align*} +dont les normes nous donnent bien la distance entre les corps des bactéries. Si +$\| \orr{n}_{f_{12}} \| \le d_\mathrm{min}$ ou $\| \orr{n}_{b_{12}} \| \le +d_\mathrm{min}$ ou $\| \orr{n}_{f_{21}} \| \le d_\mathrm{min}$ ou $\| +\orr{n}_{b_{21}} \| \le d_\mathrm{min}$, alors il existe au moins une collision +entre les deux bactéries. Le point d'impact se trouve sur le segment entre +le pôle de la première bactérie et son projeté sur le corps de la seconde. +Supposons que la collision ait lieu lorsque les corps des deux bactéries sont au +contact, alors les points de collisions peuvent être les suivants +\begin{align*} + \orr{c}_{f_{12}} &= \displaystyle\frac{r_1 \cdot\orr{f}_1 + r_2 \cdot\orr{f}^2_1}{r_1 + r_2} & \orr{c}_{f_{21}} &= \displaystyle\frac{r_2 \cdot\orr{f}_2 + r_1 \cdot\orr{f}^1_2}{r_1 + r_2} \\ + \orr{c}_{b_{12}} &= \displaystyle\frac{r_1 \cdot\orr{b}_1 + r_2 \cdot\orr{b}^2_1}{r_1 + r_2} & \orr{c}_{b_{21}} &= \displaystyle\frac{r_2 \cdot\orr{b}_2 + r_1 \cdot\orr{b}^1_2}{r_1 + r_2} +\end{align*} + + + +\paragraph{Modèle physique post-collision} +Pour calculer le résultat des échanges de forces lors d'un impact entre une +bactérie $i$ et une bactérie $j$, il est nécessaire de déterminer le type +d'impact que nous souhaitons représenter. Dans le cas d'un impact parfaitement +élastique, toute l'énergie transmise à la bactérie est restituée et l'énergie +cinétique du système est conservée. Dans le cas d'un impact inélastique, une +partie de l'énergie est dissipée et seule une partie de l'énergie totale est +restituée. En une dimension, les vitesses post-collision de deux objets $a$ et +$b$ sont données par les deux équations suivantes +\[ + v_a = \displaystyle\frac{Cr\ m_b (u_b - u_a) + m_a u_a + m_b u_b}{m_a + m_b} + \qquad + v_b = \displaystyle\frac{Cr\ m_a (u_a - u_b) + m_a u_a + m_b u_b}{m_a + m_b} +\] +où +\begin{itemize} +\item $Cr \in [0,1]$ est le \emph{coefficient de restitution}, $0$ pour une + collision parfaitement inélastique et $1$ pour une collision parfaitement + élastique; +\item $u_a, u_b$ sont les vitesses avant collision des objets $a, b$ + respectivement; +\item $m_a, m_b$ sont les masses des objets $a, b$ respectivement. +\end{itemize} + +Dans le cas d'une collision en 2D, nous pourrions appliquer ces deux équations +sur chacune des deux composantes des vecteurs vitesse, mais il nous manquerait +les informations sur le moment angulaire de chaque bactérie. Nous utilisons un +modèle un peu différent, ajusté à la collision de corps en 2D dont voici la +description. + +\noindent +Les vecteurs vitesse \emph{au point de collision} pré-collision sont +\[ + \orr{v}_{ac1} = \orr{v}_1 + \orr{\omega}_1 \wedge \orr{r}_1 + \qquad + \orr{v}_{ac2} = \orr{v}_2 + \orr{\omega}_2 \wedge \orr{r}_2 +\] +Notre objectif est de trouver les nouvelles valeurs $\orr{v}'_i$ et +$\orr{\omega}'_i$ des deux bactéries après la collision. Écrivons d'abord les +vecteurs vitesse au point de collision post-collision +\[ + \orr{v}_{pc1} = \orr{v}'_1 + \orr{\omega}'_1 \wedge \orr{r}_1 + \qquad + \orr{v}_{pc2} = \orr{v}'_2 + \orr{\omega}'_2 \wedge \orr{r}_2 +\] +Les vitesses relatives au point d'impact $\orr{v}_{ac12}, \orr{v}_{pc12}$ +pré-collision et post-collision respectivement sont données par +\[ + \orr{v}_{ac12} = \orr{v}_{ac1} - \orr{v}_{ac2} + \qquad + \orr{v}_{pc12} = \orr{v}_{pc1} - \orr{v}_{pc2} +\] +Dans notre modèle, nous faisons l'hypothèse que la vitesse à laquelle les deux +bactéries se séparent est proportionnelle à la vitesse à laquelle les deux +bactéries se rapprochent. +\begin{equation*} + \orr{v}_{pc12} \cdot{} \orr{n} = -\mathit{Cr}\ \orr{v}_{ac12} \cdot{} \orr{n} +\end{equation*} +Nous retrouvons ici le coefficient de restitution $\mathit{Cr} \in [0,1]$ et +\orr{n} est le \emph{vecteur normal unitaire} ($\|\orr{n}\| = 1$) au point de +collision pointant vers l'extérieur de la seconde bactérie. + +La collision en elle-même est modélisée par une \emph{impulsion}. Pour une +bactérie quelconque, rencontrer un obstacle équivaut à se voir appliquer une +force au point de collision, dont la durée d'application est suffisamment courte +pour qu'elle soit considérée \emph{constante}. Cette application s'effectue +\emph{sans frottements} ce qui implique qu'elle soit dirigée selon \orr{n}, la +normale de collision. Une impulsion $\orr{J} = j \cdot \orr{n}$ est +l'intégration de cette force sur $\Delta_t = t' - t$ le temps d'application +\[ + \orr{J} = \int^{t'}_t \orr{F} dt +\] +Comme d'après la seconde loi de Newton, une force est la dérivée temporelle +d'une quantité de mouvement et que l'on suppose $\Delta_t$ suffisamment court +pour que \orr{F} ne varie pas, une impulsion est une variation entre les +quantités de mouvement entre les temps $t$ et $t'$ et a donc la dimension d'une +quantité de mouvement. La collision modifie les vitesses des deux bactéries +selon \orr{n} avec l'intensité $j$. En divisant le tout par la masse, on +retrouve la dimension d'une vitesse. L'impulsion s'applique selon \orr{n} pour +la première bactérie et selon $-\orr{n}$ pour la seconde. +\begin{equation*} + \orr{v}'_{1} = \orr{v}_{ac1} + j \orr{n} / m_1 + \qquad + \orr{v}'_{2} = \orr{v}_{ac2} - j \orr{n} / m_2 +\end{equation*} +Les vitesses angulaires sont aussi modifiées de manière symétrique en prenant en +compte la distance au centre de rotation des bactéries — si cette distance est +nulle, la vitesse angulaire est nulle — et en divisant cette fois +par le moment d'inertie de chacune des bactéries +\begin{equation*} + \orr{\omega}'_{1} = \orr{\omega}_{ac1} + (\orr{r}_1 \wedge j \orr{n}) / I_1 + \qquad + \orr{\omega}'_{2} = \orr{\omega}_{ac2} - (\orr{r}_2 \wedge j \orr{n}) / I_2 +\end{equation*} + +%http://www.myphysicslab.com/collision.html#resting_contact + +\noindent +Après résolution des équations précédentes pour $j$, on obtient +\begin{equation*} + j = \displaystyle\frac{-(1 + Cr)\ \orr{v}_{ac12} \cdot{} \orr{n}} { 1/m_1 + + 1/m_2 + (\orr{r}_1 \wedge \orr{n})^2 / I_1 + (\orr{r}_2 \wedge \orr{n})^2 + / I_2} +\end{equation*} +et il est possible de déterminer le quadruplet $(\orr{v}'_1, \orr{\omega}'_1, +\orr{v}'_2, \orr{\omega}'_2)$ post-collision. Plus généralement, l'impulsion +résultant d'une collision entre une bactérie $a$ et une bactérie $b$ se notera +$j_{ab}$. + +Dans le cas de plusieurs collisions simultanées de la bactérie $1$ avec les +bactéries $(2,\ldots,N)$, dans la mesure ou chaque bactérie est indépendante, +les vitesses linéaires et angulaires post-collision de la bactérie $1$ sont +\begin{equation*} + \orr{v}'_1 = \orr{v}_{ac1} + \sum^N_{k=2} \frac{j_{1k}\orr{n}}{m_1} + \qquad + \orr{\omega}'_1 = \orr{\omega}_{ac1} + \sum^N_{k=2} \frac{\orr{r}_1 \wedge j_{1k}\orr{n}}{I_1} +\end{equation*} +l'impulsion étant le seul terme dépendant de la collision, il est différent pour +chacune des collisions. + + +% Les places sont limitées +\paragraph{Fonction de transition locale} +La méthode naïve pour détecter les collisions entre un nombre arbitraire de +bactéries est d'effectuer un test de collision pour chaque paire de bactéries, +c'est à dire $\binom{n}{2}$ combinaisons, ce qui n'est pas atteignable pour une +population de l'ordre de \num{E4} individus avec les contraintes que nous nous +sommes fixées. Pour résoudre ce problème, nous utiliserons le fait que, comme +nous effectuons une simulation physique, nous partons du principe que tout ce +qui cause un changement d'état du système a un \emph{effet local} et se +\emph{propage} de proche en proche. C'est bien le chemin que nous avons emprunté +en choisissant les automates cellulaires comme support de la simulation. Nous +devons déterminer comment effectuer notre recherche de collision localement pour +qu'elle soit correcte à l'échelle de la population. Nous allons donc restreindre +la recherche de collision à un petit groupe de bactéries, contenu dans une +cellule de l'automate. Le nombre de bactéries par cellule $\mathit{nbpc}$ dépend +de plusieurs paramètres: +\begin{itemize} +\item l'aire minimum d'une bactérie $S_\mathit{min}$ (dépendant de + $l_{\mathit{min}}$ et $r_{\mathit{min}}$); +\item l'aire d'une cellule $C_p$ de diffusion du moteur physique. +\end{itemize} +Nous donnons une dimension physique concrète aux cellules car nous allons devoir +superposer les deux automates cellulaires des moteurs physique et chimiques pour +savoir où les bactéries déposent et consomment des morphogènes. De plus, nous +gardons un rapport entier entre les aires des cellules $C_p$ du moteur physique +et $C_c$ du moteur chimique afin que les deux grilles soient toujours alignées. +\[ + \mathit{nbpc} = \left\lfloor + \displaystyle\frac{C_p}{S_\mathit{min}} + \right\rfloor + \qquad \text{et} \qquad + C_p = n_r \times C_c +\] +Le rapport entre $C_p$ et $C_c$, noté $n_r$, est un entier. + +L'espace ainsi segmenté en cellules est une \emph{configuration}. Afin que notre +automate cellulaire soit complet, il nous reste à spécifier la fonction de +transition locale à utiliser pour mettre à jour cette configuration. + + % $n\Slot[0][0] \gets \Evol($\\ + % $0011,$\tcp*[f]{Cellule courante $A$}\\ + % $0000,0001,0100,0110,$\\ + % $1100,1001,1000,0010)$ + % \; + +\begin{algorithm} + \SetKwData{Evol}{evol} + \SetKwData{GCol}{getCollisions} + \SetKwData{UpBact}{updateBacteria} + \SetKw{KwFrom}{from} + \SetKw{And}{and} + \SetKwData{NBPC}{$\mathit{nbpc}$} + \SetKwProg{Fn}{Fonction}{ as} + + \Fn{\Evol(c: cell, $n_1$: cell, $\ldots$, $n_8$: cell): cell}{ + \For{$i$ \KwFrom $0$ \KwTo $\NBPC - 1$}{ + \tcp{Calcul de collision} + $v \gets 0$, + $\omega \gets 0$\; + \ForAll{$c_n \in \{c,n_1,\ldots,n_8\}$}{ + \For{$j$ \KwFrom $0$ \KwTo $\NBPC - 1$}{ + \If{$c[i] \ne c_n[j]$ \And $\GCol (c[i],c_n[j],\orr{c},\orr{n},\orr{j})$}{ + $v \gets v + \frac{\orr{j}}{c[i].m}$, + $\omega \gets \omega + \frac{(\orr{c} - c[i].\orr{p}) \wedge \orr{j}}{c[i].I}$\; + } + } + } + + \tcp{Mise à jour de position} + $\UpBact (v,\omega)$\; + } + \Return{$c'$}\; + } + \caption{Fonction de transition locale du moteur physique} +\end{algorithm} + +La fonction \ç|getCollisions| effectue les calculs de collision présentés +ci-dessus et retourne \ç|true| si une collision est détectée et \ç|false| sinon. +Les variables \orr{c}, \orr{n} et \orr{j} sont passées par adresse et sont +définies seulement dans le cas d'un collision. + +\FloatBarrier +\subsection{Moteur de décision: bactéries et morphogènes réunis} +La coordination entre moteur chimique et moteur physique est le dernier problème +à résoudre. En effet, pour être complet, les deux parties du simulateur doivent +communiquer: +\begin{itemize} +\item les bactéries peuvent \emph{lire} des valeurs des concentrations en + morphogène \emph{à leur position} et +\item les bactéries peuvent \emph{consommer} ou \emph{déposer} des + morphogènes à leur position. +\end{itemize} +Lire, consommer et déposer des morphogène implique que la fonction d'évolution +des bactéries doit avoir connaissance de la configuration de l'automate chimique +et doit pouvoir la modifier. Il n'est pas souhaitable que les bactéries écrivent +directement dans les cellules de la configuration de l'automate chimique car ces +valeurs dépendent du temps et sont intégrées numériquement. Une meilleure +solution est de faire déposer par les bactéries une contribution $\epsilon$ qui +sera ajoutée lors de l'intégration numérique pendant la mise à jour de +l'automate chimique. Nous reprenons l'équation \ref{eq:num-int} auquel nous +ajoutons un nouveau terme: +\begin{align*} + \displaystyle + \varphi^{t + \Delta t}_{k,i,j} &= \Delta t\,\text{X}_1(\varphi^t_{1,i,j}, \ldots, \varphi^t_{k,i,j}) + + \frac{\text{D}_k\Delta t}{(\Delta x)^2} + (\varphi^t_{k,i-1,j} + \varphi^t_{k,i+1,j} + \varphi^t_{k,i,j-1} + \varphi^t_{k,i,j+1} + - 4\varphi^t_{k,i,j}) + \Delta t\,\epsilon_{\varphi_k,i,j} +\end{align*} + +Ensuite, les deux configurations des automates physique et chimique doivent se +superposer dans l'espace afin de lier la position d'une bactérie à la +concentration en morphogènes à cette position. À la position du centre d'une +bactérie $(p_x,p_y)$ correspond une cellule de la configuration de l'automate +cellulaire du moteur chimique +\begin{equation*} + \left(\frac{p_x}{\Delta x},\frac{p_y}{\Delta x}\right) +\end{equation*} +où $\Delta x$ est la taille du côté d'une cellule de cet automate et à condition +qu'à la position $(0,0)$ corresponde la cellule de coordonnées $(0,0)$. + +La contrainte suivante concerne la taille des configurations. Nous avons indiqué +dans la section~\ref{sec:boundingbox} que les dimensions des configurations +variaient en fonction de leur contenu. Comme une bactérie doit toujours pouvoir +lire, écrire ou consommer des morphogènes, cela implique que la partie de +l'espace $S_c$ couvert par la configuration du moteur chimique doit inclure la +partie de l'espace $S_p$ couvert par la configuration du moteur physique, soit +$S_p \subset S_c$. + + +Finalement, lorsque les bactéries ont accès aux concentrations de morphogènes, +elles peuvent s'en servir pour modifier leur comportement ce qui est l'objet du +moteur de décision. Chaque bactérie a un état prédéfini en début de simulation +qui regroupe les différents variables normales et booléennes (dont la valeur par +défaut est donnée entre parenthèses) suivants +\begin{itemize} +\item Division (vrai): si vrai, la bactérie croît et se divise quand sa masse a + doublé; +\item Décès (faux): si vrai, la bactérie décide d'entrer en apoptose et + disparaît de la simulation; +\item TumbleRun (vrai): si vrai, la bactérie tourne sur elle-même, sinon la + bactérie se déplace selon une trajectoire rectiligne uniforme vers l'avant; +\item Production/Consommation du morphogène $\varphi_i$: la bactérie dépose une + certaine quantité de morphogènes à sa position dans l'environnement. Cette + quantité est déterminée par le modélisateur en début de simulation. +\end{itemize} +Les transitions entre les états sont également donnés en début de simulation +dans un fichier de description de simulation \sbgp. + +Le fonctionnement du moteur de décision est donné par la fonction de transition +décrite dans l'algorithme~\ref{algo:decision}. Cette dernière est appelée sur +chaque cellule de la configuration de l'automate du moteur physique directement, +sans passer par \ppm car il n'y a pas conflit en lecture ou en écriture et +peut être parallélisée naïvement. Cette fonction a de plus à sa disposition +la configuration de l'automate du moteur chimique $\mathit{H}$ ainsi qu'une +configuration $\mathit{E}$ des contributions aux concentrations des morphogènes +de la même taille que $\mathit{H}$. Nous considérerons une simulation où il y +a $N$ morphogènes. Dans l'algorithme~\ref{algo:decision}, toutes les valeurs +précédées de \ç|init| sont issues de l'initialisation de la simulation. + + +\begin{algorithm} + \SetKwData{Evol}{evol} + \SetKw{KwFrom}{from}\SetKw{KwIn}{in}\SetKw{And}{and}\SetKw{KwBreak}{break} + \SetKwData{NBPC}{$\mathit{nbpc}$} + \SetKwProg{Fn}{Fonction}{ as} + + \Fn{\Evol(c: cell, H: configuration, E: configuration): cell}{ + \For{$i$ \KwFrom $0$ \KwTo $\NBPC - 1$}{ + %(c[i].px - $H_0$.x)/$\Delta$ x + (c[i].py - $H_0$.y)/$\Delta$ x * + \tcp{Indice de la cellule de $H$ correspondant à la bactérie courante} + $j \gets projection(H,(c[i].px,c[i].py))$\; + + \tcp{Mise à jour de la bactérie pour chaque morphogène} + \For{$k$ \KwFrom $0$ \KwTo $N - 1$}{ + E[i][k] <- E[i][k] + \ç|init.behavior.(c[i].type).EmitSignal[k].value| + } + + \tcp{Transition vers un nouveau type} + \For{$t$ \KwIn \ç|init.transisition.(c[i].type)|}{ + \If{\ç|init.cond_transition.t|}{ + $c[i].type \gets t$\; + \KwBreak\; + } + } + } + \Return{$c'$}\; + } + \caption{\label{algo:decision}Fonction de transition locale du moteur de + décision} +\end{algorithm} + + +\noindent +En prenant en compte toutes les contraintes précédentes, l'exécution d'un pas de +simulation s'effectue de la façon suivante: +\begin{enumerate} +\item un pas du moteur physique, +\item un pas du moteur chimique, +\item redimensionnement des configurations et +\item un pas du moteur de décision. +\end{enumerate} + + +%Diffusion multi-échelle sur automate~\cite{hoekstra_complex_2010} + + + +%\subsection{Validation qualitative} +%Nous présentons dans cette section quelques validations qualitatives effectuées +%avec la version courante du simulateur. Pour chacune des simulations nous +%donnons son fichier de configuration \sbgp{} ainsi que des rendus graphique à +%différents moments de la simulation.l + +\FloatBarrier +\section{Mise en œuvre}\label{sec:mise-en-oeuvre} +Dans cette section nous présentons trois exemples de simulation avec \otb. Pour +chacun de ces exemple nous fournissons le rendu de l'interface graphique et +le fichier SBGP qui l'a engendré. Ces trois exemples mettent en évidence le +fonctionnement de chacun des moteurs (chimique, physique et de décision). + +% Chimique BZ +\subsection{Une réaction de Belooussov-Jabotinski} +\label{sec:bz} +\newcommand{\gfp}{\ensuremath{\mathit{bleu}}}% +\newcommand{\rfp}{\ensuremath{\mathit{vert}}}% +Les réactions de Belooussov-Jabotinski (BZ) sont une classe de réactions +chimiques dans laquelle les concentrations de plusieurs réactants oscillent +périodiquement jusqu'à épuisement de l'un d'entre eux. Leur importance réside +dans le fait que l'état d'équilibre n'est pas atteint immédiatement mais après +une série d'oscillations pouvant prendre plusieurs minutes. Quand elle est +effectuée dans une boîte de Petri, il est possible d'observer des vagues de +réactions. + +Dans le cas de notre moteur chimique, nous pouvons facilement spécifier les +réactions et les couleurs associés à chacun des morphogènes. Nous construisons +donc cette réaction avec le minimum de réactifs et de réactions nécessaires, +soit deux réactifs \gfp{} et \rfp{} et les trois réactions suivantes: +\begin{align*} + \gfp + \rfp &\xrightarrow{0.05} 2 \rfp\\ + \gfp &\xrightarrow{0.05} 2 \gfp\\ + \rfp &\xrightarrow{0.05} .\\ +\end{align*} + +\noindent +La configuration de la simulation décrite en \sbgp{} est la suivante +\begin{SBGPcode} +{ + "signals" : [ ["bleu", 0.0, 1.0], ["vert", 0.0, 1.0] ], + "reactions" : [ [["bleu","vert"], ["vert","vert"], 0.05], + [["bleu"], ["bleu","bleu"], 0.05], + [["vert"], [], 0.05] ], + "type" : [], + "behavior" : {}, + "transition" : [], + "cond_transition" : [] +} +\end{SBGPcode} +où les quatre derniers champs sont vides car il n'y a pas de bactéries à +simuler. Durant la simulation, il est possible d'observer une alternance entre +les concentrations des deux morphogènes (en vert et en bleu) au cours du temps. +Comme les morphogènes diffusent, ne s'évaporent pas et que l'environnement +est ouvert, les concentrations locales baissent et il devient de plus en +plus difficile de distinguer les deux morphogènes au centre. Par contre, des +vagues de concentrations alternant bleu puis vert se forment à la périphérie +conformément aux réactions BZ effectuées en boîte de Petri. + +% Réaction BZ +\begin{figure}[ht] + \centering + \includegraphics[width=.245\textwidth]{figures/BZ-reaction1} + \includegraphics[width=.245\textwidth]{figures/BZ-reaction2} + \includegraphics[width=.245\textwidth]{figures/BZ-reaction3} + \includegraphics[width=.245\textwidth]{figures/BZ-reaction4} + \caption{Quatre états d'une simulation de réaction BZ ordonnés en fonction du + temps de gauche à droite. Il est possible de noter l'alternance entre le + vert et le bleu au cours du temps} + \label{fig:reaction-BZ} +\end{figure} +%DONE: (WONTFIX) rapport temps réel/temps simulé + +% Physique sectorisation! +\subsection{Sectorisation d'une population de \ecoli{}} +Pour la validation du moteur physique, nous avons reproduit une expérience de la +littérature~\cite{hallatschek_genetic_2007}. Dans cet article, les auteurs +étudient la ségrégation génomique à la frontière entre deux populations de +bactéries en croissance. + +\paragraph{Protocole expérimental} Les auteurs utilisent deux souches de +bactéries \Ecoli{} de génotypes exactement identique, à l'exception d'une unique +mutation du même gène promoteur induisant +\begin{itemize} +\item la première souche à produire une protéine fluorescente cyan (CFP) et +\item la seconde souche à produire une protéine fluorescente jaune (YFP). +\end{itemize} +On répartit de façon homogène ces deux souches pour obtenir des cultures de +différentes proportions. Une gouttelette de cette culture est posée au centre +d'une gélose pour dénombrement dans un milieu contenant un médium de croissance +enrichi afin d'obtenir une croissance rapide des deux populations. Comme les +bactéries utilisées sont immobiles, le développement de la population s'effectue +aux bords. Dans le cas d'un mélange équilibré contenant 50\% de chaque souche, +il est possible d'observer des secteurs monochromes dans la zone d'expansion de +la population. + +D'après les auteurs de~\cite{hallatschek_genetic_2007}, la +\textsc{Fig.}~\ref{fig:sectorisation} à gauche: « […] is a visible manifestation of +random genetic drift acting at the leading edge of a range expansion ». La +dérive génétique (genetic drift) est l'évolution d'une population ou d'une +espèce causée par des phénomènes aléatoires, impossible à prévoir. Du point de +vue génétique, c'est la modification de la fréquence d'un allèle, ou d'un +génotype, au sein d'une population, indépendamment des mutations, de la +sélection naturelle et des migrations. + +\paragraph{Simulation avec \otb} Dans notre simulation de cette expérience, nous +avons utilisé deux états différents ayant le même comportement pour les deux +souches de bactéries afin de pouvoir colorer les deux sous populations a +posteriori. Voici le protocole que nous avons suivi: +\begin{enumerate} +\item nous avons initialement laissé croître une population initiale issue d'une + unique bactérie jusqu'à \num{1054} individus, pour obtenir une goutte de + l'ordre du dixième de millimètre; +\item nous avons marqué chaque individu par l'état $A$ avec une probabilité de + 50\%, les autres ont été marqué par l'état $B$; +\item Nous avons repris la croissance de cette population jusqu'à atteindre une + population de \num{271958} individus (voir Fig.~\ref{fig:sectorisation}) après + vingt minutes de calcul sur un serveur muni d'une carte de calcul + Tesla\footnote{NVidia Tesla est une carte de calcul dédié munie de plusieurs + GPU}; +\item nous avons fait émettre aux individus de type $A$ un morphogène de couleur + verte et aux individus type $B$ un morphogène de couleur rouge, afin de + pouvoir observer qualitativement la répartition des bactéries. +\end{enumerate} + +Bien qu'idéalement il nous faudrait une population de l'ordre de \num{E6} +individus pour être dans les mêmes conditions que le protocole expérimental, +nous avons obtenu un résultat qualitativement très proche des photos présentées +dans l'article original. Étonnamment, nos bactéries rudimentaires, par les seules +contraintes mécaniques du moteur physique, se répartissent en secteurs lors de +la croissance de la population. + +% Sectorisation +\begin{figure}[ht] + \centering + \includegraphics[height=.4\textwidth]{figures/sectors-original}\hspace{1cm} + \includegraphics[height=.4\textwidth]{figures/sectors} + \caption[Deux population de bactéries \ecoli{} croissant librement: + comparaison avec un résultat de la littérature.] {Deux population de + bactéries \ecoli{} croissant librement dans un milieu riche en nutriment. + La figure de droite est issue de la fenêtre de rendu du simulateur \otb. + La figure de gauche est issue de~\cite{hallatschek_genetic_2007} pour + comparaison} + \label{fig:sectorisation} +\end{figure} + + + + + +\FloatBarrier +% Ensemble Cercles concentriques +\subsection{Une population stable ?} +Les bactéries croissent, se divisent et entrent en apoptose. Nous avons tenté +dans cette simulation d'obtenir une population stable ou au moins croissant +linéairement. Intuitivement, l'idée que avons suivie est de faire en sorte que +les bactéries croissent en cercles concentriques autour de la bactérie mère +initiale. Cette dernière dépose un morphogène, appelé «Vert» dans le modèle, +et se divise en deux bactéries: une nouvelle bactérie mère et une bactérie +fille qui change d'état immédiatement. Cette nouvelle bactérie fille dépose +un morphogène «Rouge» dans l'environnement. L'ensemble des bactéries filles +forme alors un premier anneau autour de la bactérie mère. Si ces dernières ne +perçoivent pas un taux de morphogène «Vert» suffisamment grand, signifiant +qu'elles sont trop éloignées, alors elles changent à nouveau d'état. + +Voici le comportement que nous avons spécifié en SBGP: +\begin{SBGPcode} +{ + "signals" : [ ["Vert", 0.01, 2.5], + ["Rouge", 0.001, 1.5], + ["Bleu", 0.001, 1.5] ], + "reactions" : [], + "type" : [ "LEADER", + "CDAUGHTER", + "FDAUGHTER", + "DEAD" ], + "behavior" : { + "LEADER" : [ { "Divide" : [] }, + { "Tumble" : [] }, + { "EmitSignal" : [ "Vert", 50 ] } ], + "CDAUGHTER" : [ { "Divide" : 0.005 }, + { "Tumble" : [] }, + { "EmitSignal" : [ "Rouge", 50 ] } ], + "FDAUGHTER" : [ { "Divide" : 0.005 }, + { "Tumble" : [] }, + { "EmitSignal" : [ "Bleu", 50 ] } ], + "DEAD" : [ { "Die" : [] } ] + }, + "transition" : [ + ["NA","NA","NA","NA"], + ["CD","NA","NA","NA"], + ["NA","CF","NA","NA"], + ["NA","NA","CA","NA"] + ], + "cond_transition" : [ + {"CD" : "IsDaughter()"}, + {"CF" : "LessThreshold(Vert,0.1)"}, + {"CA" : "And(LessThreshold(Rouge,0.1),LessThreshold(Bleu,10.0))"} + ] +} +\end{SBGPcode} + +\noindent +Les bactéries peuvent être de quatre types: +\begin{enumerate} +\item \ç|LEADER| est la première bactérie de la simulation. Elle dépose le + morphogène vert dans l'environnement; +\item \ç|CDAUGHTER| sont les bactéries filles directes de la bactérie de type + \ç|LEADER|. Elles déposent le morphogène \ç|Rouge| dans l'environnement; +\item \ç|FDAUGHTER| sont les bactéries filles qui sont assez éloignées de la + bactérie de type \ç|LEADER| d'après la concentration en morphogène \ç|Vert|. + Elles déposent le morphogène \ç|Bleu| dans l'environnement; +\item \ç|DEAD| sont les bactéries filles qui se sont trop éloignées de la + bactérie de type \ç|LEADER| et qui meurent quand les concentrations en + morphogènes \ç|Vert| et \ç|Bleu| sont trop faibles. +\end{enumerate} + +\begin{figure}[ht] + \centering + \includegraphics{figures/stablePopulation} + \caption{Graphique de la simulation « Une population stable? » présentant le + nombre de bactérie en fonction du temps de simulation. Après une phase de + croissance linéaire, la population se stabilise autour de \num{6000} + individus} + \label{graph:stablePopulation} +\end{figure} + +\begin{figure}[ht] + \centering + \includegraphics[width=.45\textwidth]{figures/ftl01}\hspace{1em} + \includegraphics[width=.45\textwidth]{figures/ftl02}\vspace{1em} + \includegraphics[width=.45\textwidth]{figures/ftl03}\hspace{1em} + \includegraphics[width=.45\textwidth]{figures/ftl05} + \caption[Différentes étapes de la simulation «Une population + stable?».]{Différentes étapes de la simulation « Une population stable? ». + La bactérie mère (en haut à gauche) se divise une première fois et sa fille + change d'état (en haut à droite). Après un certain nombre de divisions, + une des bactérie est suffisamment éloignée de la bactérie mère et change + d'état (en bas à gauche). Plus tard dans la simulation, les bactéries « + bleues » trop éloignées de la bactérie mère meurent à la périphérie.} + \label{fig:stablePopulation} +\end{figure} + + + + + + + + + + + + + +\FloatBarrier +\section{Conclusion et perspectives} +Cette courte section vise à rappeler les principaux résultats obtenus suite à +nos travaux sur le simulateur de bactéries \otb ainsi que nos futures pistes de +travail sur le sujet. + +\subsection{Conclusion} +% Résumé des épisodes précédents +Dans ce chapitre nous présentons \otb, un simulateur d'une population de +bactéries \Ecoli{}. Nous débutons ce chapitre en présentant nos motivations +pour le développement d'\otb ainsi que les choix techniques que nous avons +fait: l'utilisation de \ocaml, de \opencl et \opengl. Nous avons ainsi décidé +de tirer partie du parallélisme présent dans les ordinateurs grand public, +ce qui nous a amené à développer \ppm, un algorithme inspiré des travaux des +chapitres précédents (section~\ref{sec:ppm}). \ppm est conçu de sorte que le +contexte nécessaire à l'exécution de chaque kernel leur soit immédiatement +disponible. Ainsi le travail de chaque kernel est effectué de manière autonome +et en parallèle sans accès concurrent à la mémoire. \ppm est utilisé à la fois +pour l'exécution du moteur chimique et pour l'exécution du moteur physique. Ces +deux moteurs étant indépendants, la conception de \otb repose sur un dernier +moteur de décision permettant aux bactéries et à leur support de communiquer par +le couplage des moteurs chimique et physique. Ces trois moteurs sont présentés +dans la section~\ref{sec:implementation}. Nous clôturons le chapitre par +trois simulations permettant de rendre compte du fonctionnement du simulateur +(section~\ref{sec:mise-en-oeuvre}), montrant le fonctionnement des moteurs +chimique, physique et de décision. + +% Résultats importants +\noindent +De nos travaux sur \otb nous tirons deux résultats: +\begin{itemize} + \item un résultat théorique: l'algorithme \ppm est générique et peut-être + adapté à d'autres outils travaillant sur les automates cellulaires; + \item un résultat pratique: le simulateur \otb est un exécutable utilisable + librement sur différentes plateformes, principalement pour l'étude de la + morphogénèse dans les populations de \ecoli. Il est modulaire et extensible + et pourrait donc aisément être adapté à d'autres types de population. +\end{itemize} + +% Retour critique + + +\subsection{Perspectives} +Nos travaux futurs s'articulent autour des grands axes suivants, dont +l'objectif principal est la pérennisation d'\otb comme outil de simulation: + +\begin{description} + +% Effectuer des test de précision pour valider l'écart par rapport à une +% expérience in vivo. +% Implémenter plus de modèles (reprendre les exemples de jonathan) +% Collaborer avec des équipes de chercheurs dans les sciences du vivant +% s'intéressant à la morphogénèse. + \item[Calibration] + Nous projetons de comparer les résultats de simulation avec des résultats + d'expériences \emph{in vivo} connus afin d'étalonner au mieux les moteurs + physique et chimique. Si cela s'avère nécessaire, nous changerons + l'algorithme d'intégration numérique pour une version plus précise, au prix + de la performance. Nous envisageons d'implémenter bien plus d'exemples de + modèles qu'actuellement. Nous considérons dans ce but l'établissement d'une + collaboration avec des scientifiques des sciences du vivant s'intéressant + à la morphogénèse ou plus largement aux dynamiques d'une population de + bactéries. + +% Effectuer des test de performance pour valider l'efficacité de l'algorithme +% par rapport à GRO + \item[Performance] + La performance actuelle du simulateur \otb provient principalement d'une + planification en amont de sa conception. Il est encore possible d'améliorer + la vitesse d'exécution du simulateur. Pour cela, il sera nécessaire + d'effectuer des mesures quantitatives afin d'identifier les parties du + programme les plus coûteuses en temps de calcul et les optimiser au mieux, + par rapport à l'environnement dans lequel le simulateur est utilisé et + en fonction des ressources en espace disponible sur le périphérique de + calcul. Il pourra ensuite être envisageable de comparer les performances de + \otb par rapport à d'autres simulateurs de population de bactéries comme + \gro~\cite{jang_specification_2012}. + +% Retravailler le GUI + \item[Interface de sortie] + L'interface utilisateur de \otb est à ce jour rudimentaire. Pour qu'un plus + grand nombre d'utilisateurs puissent utiliser le simulateur au quotidien + il est impératif de lui ajouter quelques fonctionnalités: un meilleur + contrôle à la souris, l'ajout d'obstacles et de flux dans l'environnement + afin de tester l'influence de contraintes mécaniques sur une population + en croissance ou encore présenter plusieurs vues en simultané de la même + population. Il est envisageable d'ajouter d'autres modes de sortie, comme + des mesures quantitatives agrégées sous forme de graphes en fonction du + temps de la simulation comme, par exemple, l'orientation moyenne des + bactéries, leur nombre, leur taille moyenne, leur volume moyen, etc. +% Refaire l'interface d'entrée + \item[Interface d'entrée] + La description d'une simulation par un fichier \sbgp{} peut encore être + améliorée. Il est d'abord nécessaire d'optimiser le contenu de ce fichier + en fonction des informations réellement nécessaire à une simulation \otb + ce qui sera possible une fois le point «Calibration» effectué et après + discussion avec les futurs utilisateurs d'\otb. Il est aussi envisageable + de contrôler \otb à partir d'un programme externe, par exemple une + interface graphique regroupant les interfaces d'entrée et de sortie pour un + usage plus intuitif. + +% Étendre les types de bactéries supportées, déjà d'autres types du genre +% bacillus (en testant diplobacilli, streptobacilli, …) voir d'autres formes +% (Cocci) +% https://upload.wikimedia.org/wikipedia/commons/6/69/Bacterial_morphology_diagram.svg + \item[Formes de bactérie] + De part sa conception, \otb est modulaire et extensible. Une piste + de travail futur est l'exploration de la simulation d'autre formes de + bactéries du genre bacillus (comme \ecoli), diplobacillus (des couples de + bâtonnets), streptobacillus (des chaînes de bacillus), coccus (des sphères), + coccobacillus (des ovales), etc. Changer de forme de bactérie implique de + mettre à jour l'algorithme de collision qui a été développé spécifiquement + pour les bactéries bacillaires. Ces développements se feront également en + lien avec le point «Calibration» en fonction des besoins. + +% Passer à l'hexagonal + \item[Grille hexagonale] + Une propriété des grilles hexagonales est que toutes les cellules ont un + bord en commun et leur centres sont équidistants (ce qui n'est pas le cas + sur une grille carrée, les centres des cellules en diagonale sont plus + éloignés). Nous souhaitons explorer le fonctionnement de \ppm sur ce support + afin de déterminer s'il est possible d'obtenir une diminution des erreurs + de la méthode d'intégration actuelle du moteur chimique et du calcul de + collision du moteur physique. + +% Collection topologique OTB + \item[\mgs] + Dans le point «Interface d'entrée» nous avons indiqué qu'il était + envisageable qu'un programme externe serve d'interface de contrôle pour + \otb. \mgs est un bon candidat pour cette tâche. En effet, nous pouvons + considérer que \otb définit une collection topologique dont les éléments + sont les bactéries. Cette collection est paramétrée par les réactions + entre les morphogènes. Chaque élément de cette collection a pour valeur + la spécification d'un réseau de régulation génétique sous la forme d'un + automate avec nombre fini d'états. + +\end{description} + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +%TODO: maybe? Citer Dugovson + +% Fakesection \section{Simulation physique} +%%Première partie physique moteur de collision etc +%L'efficacité de \tb\ repose sur sa simulation en parallèle sur plusieurs +%cœurs de calcul. Deux niveaux de description sont identifiables : le niveau +%dynamique dans lequel les bactéries se déplacent, entrent en collision, +%se repoussent et tournent sur elles-même ; le niveau chimique duquel les +%bactéries consomment des morphogènes, dans lequel elles déposent des +%morphogènes et dans lequel les morphogènes se diffusent et réagissent. +%Afin que la simulation soit la plus efficace possible, des techniques de +%programmation sur GPU ont été employées et un algorithme sur mesure de calcul +%parallèle a été développé. +% +% +% +% +% +% +% +% +% +%%Comment calculer en parallèle une simulation physique ? +%\subsection{Automates réversibles et voisinage de Margolus} +%Notre algorithme a été développé à partir des constats suivants : pour +%simuler l'évolution d'objets soumis à des lois physiques (collisions, +%forces) il nous faut un modèle de calcul proche de la physique et dans le +%même temps, pour que la simulation soit rapide, il nous faut un modèle de +%calcul parallélisable, c'est à dire qui partitionne l'espace de calcul en +%«briques» indépendante en terme de données pour être envoyée sur un +%périphérique de calcul comprenant du nombreuses unités de calcul (GPU, CPU +%multi-cœur, …). +% +%Le modèle de calcul des automates cellulaires (\ac), en plus du fait d'être +%naturellement parallèle, semble particulièrement bien adapté à la +%simulation physique. Les concepts de temps et d'espace y sont naturellement +%présents et les \ac\ respectent quelques propriétés attendues des lois +%physiques comme l'\emph{uniformité} et la \emph{localité}. La plupart +%des lois physiques sont \emph{réversibles}, cependant, en général un +%\ca\ ne l'est pas ; ce sujet a été largement abordé dans la litérature +%\cite{margolus_physics-like_1984,truc,bidule}. +%%Voisinage de margolus +%Margolus établit à partir d'un voisinage particulier les conditions sur les +%fonctions de transition dans lequel les automates cellulaires sont réversibles, +%appelé voisinage de Margolus (voir figure \ref{fig:margolus-neighborgood}). +%Au delà de la motivation principale de l'auteur, le voisinage de Margolus +%présente la particularité de pouvoir être utilisé pour simuler n'importe +%quel automate sans avoir recours à une technique de double-buffering. +% +%\begin{figure}[t] +% \centering +% \includegraphics[page=1,width=.4\textwidth]{figures/ca-neighborhood}\hspace{1cm} +% \includegraphics[page=2,width=.4\textwidth]{figures/ca-neighborhood} +% \caption{Voisinage classique (à gauche) et voisinage de Margolus (à droite) +% d'un automate cellulaire 1D. Chaque ligne correspond à un pas dans la +% simulation de l'automate, de haut en bas.} +% \label{fig:margolus-neighborgood} +%\end{figure} +% +%\subsection{Voisinage de Moore et moteur physique} +%\begin{figure}[t] +% \centering +% \includegraphics[page=2,width=.4\textwidth]{figures/margolus}\hspace{1cm}% +% \includegraphics[page=3,width=.4\textwidth]{figures/margolus} +% \caption{Voisinage de Margolus (au centre, en noir) d'un automate cellulaire +% en deux dimensions dont les cellules sont en gris. Division de l'état des +% cellules en quatre sous-partie (à droite), dont trois contiennent une copie +% du contenu des cellules voisines. La sous-partie principale est en blanc sur +% fond noir et contient l'état de la cellule. Les états de quatre cellules +% sont donnés} +% \label{fig:margolus-grid} +%\end{figure} +% +%Cet algorithme fonctionne de la manière suivante : à chaque pas, la grille +%de l'automate est découpée en blocs de $2 \times 2$ cellules qui sont +%ensuite calculés indépendamment les uns des autres, voir les figures +%\ref{fig:margolus-grid} ; au pas suivant, un nouveau découpage de blocs de $2 +%\times 2$ cellules, décalé de $(1,1)$ par rapport au découpage précédent, +%est effectué et l'opération recommence. Cette manière de découper une grille +%d'automate est introduite par Margolus dans \cite{margolus_physics-like_1984} et +%\cite{toffoli_cellular_1987}, où il présente un automate découpé en blocs +%obéissant à la loi de conservation locale où chaque transition conserve les +%proportions d'états, ce voisinage est communément connu comme « voisinage de +%Margolus ». +% +%Les automates cellulaires sont un modèle de calcul intrinsèquement parallèle, +%néammoins, mettre à jour une cellule requiert d'aller lire les cellules +%voisines, ce qui cause en pratique des collision de lecture, des lectures +%multiples et oblige finalement à accompagner chaque cellule de son voisinage +%pour le calcul. Afin de pouvoir rendre autonome le calcul de chaque bloc +%dans un voisinage de Margolus, les valeurs des douze cellules voisines sont +%copiées (voir figure \ref{fig:margolus-grid}) au sein de chaque état de +%chaque cellule d'un bloc de Margolus. Une technique similaire est employée par +%\cite{morita_computation_1989} ; cependant, leur but n'est pas tant d'améliorer +%la localité des données, mais de montrer l'universalité d'un automate +%cellulaire unidimensionnel réversible en réponse à une conjecture de Toffoli. +% +%\begin{figure}[t] +% \centering +% \centerline{% +% \includegraphics[page=4,width=.4\linewidth]{figures/margolus} +% \includegraphics[page=5,width=.4\linewidth]{figures/margolus} +% \includegraphics[page=6,width=.4\linewidth]{figures/margolus}} +% \caption{Détail des tâches effectuées avant un décalage de grille} +% \label{fig:margolus-inter} +%\end{figure} +% +%Le reste de la procédure est, à notre connaissance, complètement originale. +%Avant le décalage de la grille suivant, les états des cellules sont mis à +%jour avec les « bonnes » valeurs pour pouvoir poursuivre le calcul. Pour +%commencer, la sous-partie principale des quatre cellules du bloc est mis à jour +%indépendamment des autres blocs grâce à la recopie précédente des états +%des voisins (figure \ref{fig:margolus-inter} gauche). Ensuite, chaque cadran +%est rempli de la manière suivante : l'état à jour de la cellule est recopié +%dans le coin extérieur qui et les trois autres reçoivent une copie des états +%des nouvelles voisines (figure \ref{fig:margolus-inter} centre). Après cette +%mise à jour, on constate que les quatre nouveaux blocs sont identiques (figure +%\ref{fig:margolus-inter} droite), à ceci près que la sous-partie principale de +%la cellule est différente suivant la cellule ; il suffit donc de calculer les +%mises à jour de chaque cellule puis de recopier quatre fois la même cellule +%pour obtenir le bloc mis à jour. +% +%\subsection{Voisinage de Von Neuman et moteur de réaction-diffusion} +% +% +%% Publication de OTB, test de charge, cahier des charges… +%% +%% Modélisation discrète, continue. +%% +%% Le modèle est continu, implémentation discrète +%% +%% Partie associée : modélisation MGS qui montre comment les deux modèles +%% communiquent. +%% +%% Montrer qu'on est coincé car le couplage est important : problématique de +%% multi-modèle. +%% +%% Valoriser les algos développés +%% +%% Montrer +%% +%% Corps +%% +%% Margolus, bench (on y gagne) +%% +%% Rapport avec techniques d'optimisation noir/rouge +%% +%% Approche particulière par rapport au multi-agent : On aurait tendance à faire +%% un tableau de bactérie qui se met à jour (problème de voisinage, problème de +%% création de bact). Optim, oc-tree, AABB, etc. mais pas facile sur GPU. Du +%% coup on utilise des collections à la margolus. +%% +%% 50% d'encadrement Romain dans lequel a été développé l'algo de collision. +%% +%% +%\section{Organisation logicielle du simulateur} +%% Organisation logicielle : valoriser l'architecture, interfacement MGS, collection TB +%Présentation des différentes briques logicielles de TB. On utilise \ocaml +%car langage haut niveau, bien typé et facilement interfaçable en C. +% +%Interfaces bas niveau vers OpenCL et OpenGL +% +%Schéma de l'architecture haut niveau, liens entre les modules +%% +%\section{Collection topologique et OTB} +%% Collection TB, présentation formelle des deux collections et comment on les +%% fait marcher ensemble. +%% +%% Reprendre le rapport de stage de GRO et faire pareil dans un chapitre. +%% +%% Lien avec symbiotique +%% +%% Lien avec multi-niveau +%% +%% Conclusion et perspectives +%% +%% Passer à l'hexagonal +% diff --git a/potier.these.2015.pdf b/potier.these.2015.pdf new file mode 100644 index 0000000..e5215f7 Binary files /dev/null and b/potier.these.2015.pdf differ diff --git a/remerciements.tex b/remerciements.tex new file mode 100644 index 0000000..c012ab4 --- /dev/null +++ b/remerciements.tex @@ -0,0 +1,57 @@ +\makeway\thispagestyle{empty} +\section*{Remerciements} + +Ce travail de thèse n'aurait sans doute pas pu aboutir sans le support et +parfois même l'aide précieuse de toutes les personnes que j'ai rencontré, avec +qui j'ai partagé mon lieu de travail ou bien qui m'ont juste pointé dans la +bonne direction. + +\newcommand{\tu}{$\lambda$} + +Sans ordre particulier, je souhaite remercier les personnes suivantes: +\begin{itemize} +\item[\tu] Antoine et Olivier pour m'avoir encadré durant la thèse et m'avoir proposé + un sujet original et motivant, ainsi que pour m'avoir permi de le mener à bien; +\item[\tu] Elisabeth pour m'avoir gentiment rappelé qu'écrire une section de remerciements était + une partie importante d'un manuscrit de thèse; +\item[\tu] Daniele pour m'avoir permi de le remplacer pendant un de ses cours et + qui s'est montré très enthousiaste devant mon usage de Sozi; +\item[\tu] Flore, Clara, Nicolas, pour avoir été présent pour régler des détails + administratifs parfois pesant et pour les longues discussions que cela a pu + entraîner; +\item[\tu] Toute l'équipe de l'IUT de Fontainebleau \verb+\o/+ (Régis, tu gères + archlinux comme pas deux); +\item[\tu] Mes co-doctorants de l'époque: Louis, Thomas, Nghi, Quentin, Yoann, + Victor, Rodica, et tous les autres… +\item[\tu] Olivier (Hermant, pas l'autre) et Olivia qui, les premiers, m'ont orienté + vers le monde de la recherche et m'ont permi de passer au delà de mon angoisse + d'ingénieur à trouver un travail, parce que, il le faut, mais de continuer + dans la voie qui me plaît, jusqu'à aujourd'hui; +\item[\tu] Olivia (la même que juste au dessus) pour son soutien inconditionnel et + pour avoir réussi l'exploit de me déconstruire et me reconstruire sans que je + tombe en panne, ce qui lui vaut le statut de vache en furie à vie; +\item[\tu] Au commité de l'ombre, gérant des serveurs dans les salles obscures, communicant + entre eux comme des hakerz, et parlant un langage que les simples mortels + ne peuvent comprendre, David, Grégoire et… +\item[\tu] Sergiu (камарад!) parce que, soyons honnêtes, ce type n'est vraiment pas + comme les autres; +\item[\tu] Tous ceux qui sont venu voir le match, en particulier Thomas, Samuel, + (Claire-Alice), que je n'avais pas revu depuis trop longtemps; +\item[\tu] Mes parents et de manière plus générale ma famille pour m'avoir toujours + soutenu dans mes choix tout en sachant me laisser la place nécessaire pour + construire ma propre voie; +\item[\tu] Les auteurs et contributeurs de tous les logiciels libres utilisés + pendant l'écriture de ce mémoire\footnote{ + Pour vous faire une idée de la grande quantité des projets libres qui existent + et de l'écosystème qu'ils forment, je vous conseille de jeter un œil à la + clôture nix des dépendances de l'environnement de compilation pour ce document + rédigé avec \LaTeX, en voici quelques uns des plus importants: linux, xmonad, + texlive et vim.}; +\item[\tu] Toi qui lit ces remerciements, merci d'avoir lu jusqu'ici; +\item[\tu] Et enfin, tous ceux qui ne sont pas cités ici mais que le méritent + amplement, car à mon avis, il serait présomptueux de penser que ce qu'on n'est + ne tient qu'à soit même. +\end{itemize} + +Et là, il est grand temps que je m'arrête, car pour être honnête, il me reste +bien une moitié de l'internet à remercier. diff --git a/resume.tex b/resume.tex new file mode 100644 index 0000000..c6c8563 --- /dev/null +++ b/resume.tex @@ -0,0 +1,154 @@ +\pagestyle{empty} +\begin{center} + \huge\textsc{Résumé} +\end{center} +{\small % Mots-clef pawa +La description et la compréhension d'un système passe souvent par la +construction d'un modèle mathématique. Ce dernier constitue un point de vue +particulier sur le système (structurel, dynamique, etc.). Constituer des modèles +plus complets, c'est-à-dire multi-point-de-vue, atteint rapidement les limites +des formalismes qui les supportent. Une solution alternative passe par le +couplage de plusieurs modèles «simples». Dans le cas où chaque modèle correspond +à un niveau de description du système, comme le niveau de la molécule, le niveau +de la cellule, le niveau de l'organe, pour un système biologique, nous parlerons +de modélisation multi-niveau. Ces niveaux sont organisés et interagissent. Nous +pensons que la modélisation multi-niveau ouvre une voie prometteuse pour l'étude +des systèmes complexes, traditionnellement durs à modéliser. +% +Nous explorons trois voies pour la compréhension du fonctionnement de ces +modèles en nous restreignant à la question de la relation entre global et +local, c'est à dire entre l'individu et la population. La première voie est +formelle et passe par la définition mathématique de «modèle» indépendamment du +formalisme qui le supporte, par la présentation des différents types de modèles +que l'on peut construire et par la définition explicite des relations qu'ils +entretiennent. +% +La seconde voie est portée par l'activité, définie dans le cadre de \mgs, un +langage de programmation spatiale, dont le modèle de calcul est fondé sur la +réécriture des collections topologiques au moyen de transformations. +Nous fournissons une méthode constructive pour l'obtention d'une description +de plus haut niveau (une abstraction) des systèmes étudiés en déterminant +automatiquement quelle est la sous-collection active sans la nécessité de faire +référence à la sous-collection quiescente. +% +La dernière voie est pratique, elle passe par la programmation de \otb, un outil +de simulation parallèle pour l'étude de la morphogénèse dans une population +de bactéries \ecoli. Pour \otb, nous avons conçu un algorithme générique de +calcul parallèle d'un automate cellulaire en deux dimensions, adapté aux cartes +graphiques grand public. Le modèle embarqué dans \otb correspond au couplage +de trois modèles correspondant chacun à un niveau de description du système: +le modèle physique, qui décrit la dynamique des collisions entre bactéries, le +modèle chimique, qui décrit la réaction et la diffusion des morphogènes, et le +modèle de prise de décision, qui décrit l'interaction entre les bactéries et +leur support. +} +% Abstraction +% Activité spatiale +% Automate cellulaire +% Collection topologique +% Complexe +% Comportement +% Composition +% E. Coli +% Formalisme +% MGS +% Modèle +% Modéliser +% Multi-niveau +% PPM +% Parallèle +% Point de vue +% Programmation spatiale +% Relation +% Simulation +% Système +% Transformation +% Validation +% +\begin{center} + \huge\textsc{Abstract} +\end{center} +\begin{english} +\small +%La description et la compréhension d'un système passe souvent par la +%construction d'un modèle mathématique. +We often build mathematical models to describe and understand what a system +does. +%Ce dernier constitue un point de vue +%particulier sur le système (structurel, dynamique, etc.). +Each model gives a specific point of view on the system (structure, dynamics, +etc.). +%Constituer des modèles plus complets, c'est-à-dire multi-point-de-vue atteint +%rapidement les limites des formalismes qui les supportent. +Building more comprehensive models that encompass many different points of view +is limited by the formalism they are written in. +%Une solution alternative passe par le couplage de plusieurs modèles «simples». +Coupling “simple” models to form a bigger one is an alternative. +%Dans le cas où chaque modèle correspond à un niveau de description du système, +%comme le niveau de la molécule, le niveau de la cellule, le niveau de l'organe, +%pour un système biologique, nous parlerons de modélisation multi-niveau. +If each model corresponds to a level of description of the system, e.g., the +molecular level, the cellular level, the organ level in biology, then we call +this technique multi-level modelling. +%Ces niveaux sont organisés et interagissent. +Levels of description are organized and interact with each other. +%Nous pensons que la modélisation multi-niveau ouvre une voie satisfaisante pour +%l'étude des systèmes complexes, traditionnellement durs à modéliser. +We think that multi-level modelling is a promising technique to model complex +systems, which are known to be difficult to model. +%% +%Nous explorons trois voies pour la compréhension du fonctionnement de ces +%modèles en nous restreignant à la question de la relation entre global et +%local, c'est à dire entre l'individu et la population. +%To investigate the link between local and global properties, for instance +%an entity and its population, which is a case of classical complex systems' +%problems, we have opened three distinct research tracks. +We have opened three distinct research tracks to investigate the link between +local and global properties, for instance between those of an entity and its +population — a classical opposition in complex systems. +%La première voie est formelle et passe par la définition mathématique de +%«modèle» indépendamment du formalisme qui le supporte, par la présentation +%des différents types de modèles que l'on peut construire et par la définition +%explicite des relations qu'ils entretiennent. +On the first track, we give precise definitions of a model — independently +of its underlying formalism, of a system and of some of the relations models +have (validation, abstraction, composition). +%We also introduce different kinds of models and how they relate to their +%classical definition (dynamic models, spatial models, and so on). +We also introduce different classes of models and show how they relate to some +classical definitions (dynamic models, spatial models, etc.) +%% +%La seconde voie est portée par l'activité, définie dans le cadre de \mgs, un +%langage de programmation spatiale, dont le modèle de calcul est fondé sur la +%réécriture topologique des collections topologiques au moyen de transformations. +On the second track, we look at \mgs, a spatial programming language based on +the rewriting of topological collections by means of transformation functions. +%Nous fournissons une méthode constructive pour l'obtention d'une description +%de plus haut niveau (une abstraction) des systèmes étudiés en déterminant +%automatiquement quelle est la sous-collection active sans la nécessité de faire +%référence à la sous-collection quiescente. +We present a constructive method giving us access to a higher level of +description of the system (an abstraction). This method automatically computes +the active sub-collection of a model, without any knowledge about the quiescent +sub-collection, and follows it for each time step. +%% +%La dernière voie est pratique, elle passe par programmation de \otb, un outil +%de simulation parallèle pour l'étude de la morphogénèse dans une population +%de bactéries \ecoli, pour lequel nous avons conçu un algorithme générique de +%calcul parallèle, adapté aux cartes graphiques grand public. +Finally, on the third track, we present \otb, a parallel simulator for the +study of morphogenesis in a population of \ecoli bacteria. We provide a generic +algorithm for the parallel simulation of two-dimensional cellular automata +on general-purpose graphics cards. +%Le modèle embarqué dans \otb est correspond au couplage de trois modèles +%correspondant chacun à un niveau de description du système: le modèle physique, +%qui décrit la dynamique des collisions entre bactéries, le modèle chimique, qui +%décrit la réaction et la diffusion des morphogènes, et le modèle de prise de +%décision, qui décrit l'interaction entre les bactéries et leur support. +\otb itself is built around a multi-level model for the population of bacteria. +This model is the result of the coupling of three “simple” (base) models: a +physical model, describing how bacteria collide, a chemical model, describing +how morphogenes react and diffuse, and a decision model, describing how bacteria +and their environment interact. +\end{english} + diff --git a/sigles.tex b/sigles.tex new file mode 100644 index 0000000..825185c --- /dev/null +++ b/sigles.tex @@ -0,0 +1,96 @@ +\newcommand\defeq{\mathrel{\smash{\stackrel{\mbox{{\tiny\rm df}}}{=}}}} +\newcommand{\AC}{\ac} +\newcommand{\Cl}{\ensuremath{\mathrm{Cl}}} +\newcommand{\Dim}{\ccad} +\newcommand{\EDO}{\textsf{EDO}\xspace} +\newcommand{\EDP}{\textsf{EDP}\xspace} +\newcommand{\Ecoli}{\emph{Escherichia Coli}\xspace} +\newcommand{\GBF}[1]{\textbf{#1}\xspace} +\newcommand{\ISC}{\textsf{ISC}\xspace} +\newcommand{\K}{\ccaK} +\newcommand{\Lk}{\ensuremath{\mathrm{Lk}}} +\newcommand{\MGS}{\mgs} +\newcommand{\N}{\ensuremath{\mathbb{N}}} +\newcommand{\PQpath}[2]{{$(#1,#2)$}-path} +\newcommand{\SpaceTime}{\ensuremath{\mathbb{L}}} +\newcommand{\Space}{\ensuremath{\mathbb{S}}} +\newcommand{\St}{\ensuremath{\mathrm{St}}} +\newcommand{\Time}{\ensuremath{\mathbb{T}}} +\newcommand{\ac}{\textsf{AC}\xspace} +\newcommand{\ald}{\textsf{ALD}\xspace} +\newcommand{\anabaena}{\emph{Anabaena}} +\newcommand{\api}{API} +\newcommand{\bhvpo}{\ensuremath{\mathfrak{B}_p}} +\newcommand{\bhvxp}{\ensuremath{\mathfrak{B}_e}} +\newcommand{\bhv}{\ensuremath{\mathfrak{B}}} +\newcommand{\catOne}{\ensuremath{\mathbf{1}}} +\newcommand{\cat}[1]{\ensuremath{\mathbf{#1}}} +\newcommand{\catop}[1]{\ensuremath{\mathbf{#1}^\mathbf{op}}} +\newcommand{\ca}{\ac} +\newcommand{\ccaK}{\ensuremath{\mathcal{K}}} +\newcommand{\ccad}{\ensuremath{\text{dim}}} +\newcommand{\cca}{\textsf{CCA}\xspace} +\newcommand{\cells}[1]{$#1$-cellules} +\newcommand{\cell}[1]{$#1$-cellule} +\newcommand{\cfg}{\ensuremath{\omega}} +\newcommand{\chains}[1]{$#1$-chaînes} +\newcommand{\chain}[1]{$#1$-chaîne} +\newcommand{\cnn}{\textsf{CNN}\xspace} +\newcommand{\dobs}{\ensuremath{\mathcal{O}}} +\newcommand{\domaine}{\mathcal{D}} +\newcommand{\dom}{\ensuremath{\mathbb{D}}} +\newcommand{\dsds}{(\textsf{DS})$^2$\xspace} +\newcommand{\ds}{\dsds} +\newcommand{\eC}{\ensuremath{\mathsf{C}}} +\newcommand{\ecoli}{\emph{E. Coli}\xspace} +\newcommand{\edp}{\EDP} +\newcommand{\etc}{etc.} +\newcommand{\etoile}[1]{\ensuremath{\text{St}\,{#1}}} +\newcommand{\fermeture}[1]{\ensuremath{\overline{#1}}} +\newcommand{\ftr}[1]{\ensuremath{#1}} +\newcommand{\gbf}{\textsf{GBF}} +\newcommand{\gro}{\textsf{GRO}\xspace} +\newcommand{\ie}{\emph{i.e.},\xspace} +\newcommand{\kcod}{\ensuremath{\mbox{cod}}} +\newcommand{\kdom}{\ensuremath{\mbox{dom}}} +\newcommand{\khom}{\ensuremath{\mathit{hom}}} +\newcommand{\kid}{\ensuremath{\mathit{id}}} +\newcommand{\krel}{\ensuremath{\mathit{abs}}} +\newcommand{\laplacien}{\Delta} +\newcommand{\latin}[1]{\emph{#1}} +\newcommand{\liaison}[1]{\ensuremath{\text{Lk}\,{#1}}} +\newcommand{\mens}{\textsf{MENS}\xspace} +\newcommand{\mgs}{\textsf{MGS}\xspace} +\newcommand{\modelLotka}{\ensuremath{\mathfrak{M}_{L}} } +\newcommand{\absA}{\ensuremath{\mathfrak{a}}} +\newcommand{\modelM}{\ensuremath{\mathfrak{M}}} +\newcommand{\modelSLotka}{\ensuremath{\mathfrak{M}_{SL}}} +\newcommand{\modelSVolterra}{\ensuremath{\mathfrak{M}_{SV}}} +\newcommand{\modelVolterra}{\ensuremath{\mathfrak{M}_{V}} } +\newcommand{\model}[2]{\ensuremath{\mathfrak{#1}_{#2}}} +\newcommand{\morphism}[3]{$#2 \overset{#1}{\longrightarrow} #3$} +\newcommand{\mref}[1]{\ensuremath{\bar{#1}}} +\newcommand{\mrphs}[1]{\mrph{#1}s} +\newcommand{\mrph}[1]{$\cat{#1}$-morphisme} +\newcommand{\neighbors}[2]{{$(#1,#2)$}-neighbors} +\newcommand{\neighbor}[2]{{$(#1,#2)$}-neighbor} +\newcommand{\oA}{\ensuremath{\mathcal{A}}} +\newcommand{\oQ}{\ensuremath{\mathcal{Q}}} +\newcommand{\objs}[1]{\obj{#1}s} +\newcommand{\obj}[1]{$\cat{#1}$-objet} +\newcommand{\obsn}[1]{\ensuremath{\text{\tt #1}}} +\newcommand{\obs}{\ensuremath{\mathbb{O}}} +\newcommand{\ocaml}{OCaml\xspace} +\newcommand{\ola}[1]{\ensuremath{\overset{\leftarrow}{#1}}} +\newcommand{\opencl}{OpenCL\xspace} +\newcommand{\opengl}{OpenGL\xspace} +\newcommand{\ora}[1]{\ensuremath{\overset{\rightarrow}{#1}}} +\newcommand{\orr}[1]{\ensuremath{\vec{#1}}} +\newcommand{\otb}{\tb} +\newcommand{\ppm}{\textsf{PPM}\xspace} +\newcommand{\sbgp}{\textsf{SBGP}\xspace} +\newcommand{\setModel}{\ensuremath{\mathcal{M}}} +\newcommand{\sig}{\ensuremath{\Sigma}} +\newcommand{\synbiotic}{\textsc{Synbiotic}\xspace} +\newcommand{\tb}{\textsf{OTB}\xspace} +\newcommand{\wld}{\ensuremath{\mathbb{W}}}