an environment for virtual experimentation with ...lvalencia/research/phd/thesis_luis...luis...

University of SevilleDpt. of Computer Scienceand Artificial Intelligence

An environment for virtual experimentation

with computational models

based on P systems

Report submitted byLuis Valencia Cabrerato obtain the PhD degreeby the University of Seville

Luis Valencia Cabrera

Approval of the Thesis Supervisors

PhD. Mario de Jesus Perez Jimenez PhD. Agustın Riscos Nunez

October 9, 2014

A los que ya no estan,cuyo vacıo no se puede llenar

A mis padresA mi hermana Ana, Rosalıa, Niko y Tilman

A Manolito, Mati, Fidel y familiasA Marimeri, Antonito, Pepi y Joaquın

A toda mi familiaA mis leales amigos

iii

Prologue

Learn from the seniors, value the expertise...

Learn and get enriched from the experiences of past times, in Science andLife, learn which other people transmitted us, grow on a solid foundationhardened by time, collaborate with our grain of sand, our energy and efforts,our abilities, help with our breath and encouragement, evidence and thoughtsto those who will succeed us, transmitting what we learnt from our ancestorsjoint with our own vision...

Study which others could provide, get to understand which others gaveus, observe the world with our own eyes and integrate our ideas with thecontributions of the others, combine thoughts, knowledge and efforts with thepast and the present and lay the foundations for the future, building bridgeslinking the paths of Science and Universe, the society and the individual,through the deepening in the understanding of what surrounds us and try tohelp improving it...

Provide integral mechanisms bringing fields together, helping communicat-ing different languages, sharing the knowledge of scientists in different areas inorder to understand each other, communicate, get enriched together, in a jointeffort to reach a higher knowledge about the phenomena, taking into accountthe holistic premise than the whole is greater than the sum of its parts.

The work presented in this dissertation intends to collaborate with thisintegrative process, proposing a sort of glue in the form of a methodologyand tools supporting it, in order to bring paths together trying to reduce thegap from the study of a problem to the provision of automated tools helpingus to deepen in the knowledge about the phenomena through solutions andmodels, abstractions able to capture a relevant part of reality inherently hold-ing as much as possible that holistic vision also adopted by Systems Biology,understanding the study of the phenomena in the most possible global form,not only focusing on individual elements but trying to understand the prob-lems and processes as a whole through the interaction of multiple elements atdifferent levels of organization. All this path is aimed to help increasing theknowledge about phenomena, serving as a help assisting us to a better man-agement and decision making of the underlying real systems through the useof models as practical tools.

As initially introduced, learn from our ancestors that explain who we aretoday, which things are known today, because no result we can reach everyday deserves a Nobel Prize or a Fields Medal if we do not consider it is ashared prize, starting from the support of so many people that led us to theneeded echelon to permit us moving the next step forward, so many knownand unknown that along the History where providing each part of what hasfinally arrived to us, such a way that we could start from all the theoreticaland practical tools, conceptual and technological, in so many areas of Life andKnowledge, so powerful and thorough, developed along centuries.

Serve this prologue as a general thought and acknowledgement, prelude ofthe particular ones to the predecessors and contemporaries which I have hadthe huge fortune to enjoy with and learn from.

Acknowledgements

Nothing of what I did would have been possible without the support of thosewho provided me with their experience and wisdom every day I have the fortuneto share with them. In particular, without the one we are so lucky to haveamong us as a reference at a professional and a moral level, for the valuesthat silently transmits each day with his example, through his work, respect,passion, responsibility and empathy for those who come to him looking foradvice or help, which is unable to deny his selfless collaboration, even whenfeeling overtaken at a physical and mental level for so much constant effort.Many thanks Mario, having this example so close is very difficult for us to gettempted to hold on to any excuse of any nature to lower the arms, even if thatone is the uneasiness caused by life.

My sincerest thanks also to Ignacio, to whom I owe so much since I beganworking with at the beginning of 2010, in the development of MeCoSim fromhis previous developments within the area of the simulation of the populationdynamics of real ecosystems. And also I have to thank him for encouraging meto contact Mario to check if some possibility arose to follow my vocation forresearch, thus leaving the company I worked for to join the Research Groupon Natural Computing.

I would also like to thank Agustın, for his gentle company, constant supportand wise guidance despite his youth. And also thank him and Carmen forsustaining part of my teaching backpack to make it possible for me to finishthe work developed in this dissertation. I can not forget the human supportand technological help provided by my colleague and friend Luis Felipe, helpalso provided by Manu in the development of simulators, or Miguel Angel, inthis case always combined with good amounts of humor, and that was wellaccompanied the last year by Francis, another great team and coffee mate.A special mention also to Alvaro, for his constant help and support in manyteaching, administrative and management tasks. I would also like to thankFran, with whom I have had a less close collaboration but was also a goodinspiration, doing a great scientific and teaching work I have been followingfor years.

Thank the whole Research Group on Natural Computing and the Depart-ment of Computer Science and Artificial Intelligence for the support, companyand respect shown from my incorporation in 2010 and 2011, respectively. Ifeel very honored for the opportunities I have been given from the beginningand fills me with responsibility, keeping the strong desire and dedication trying

to respond the trust placed in me, aiming to contribute with the value at ascientific and teaching level corresponding to the challenge we face every day,to respond to those that trusted on us, to the scientific community, and theStudent body that finally receives (along with the society) the fruit of our ef-forts. My acknowledge is also directed to the members of the different researchgroups I could collaborate with along these years, mainly from the universitiesof Sheffield, Bucarest, Pitesti, Wuhan and Chengdu. I would like to includea special thank to Marian Gheorghe, who cared so much to make me have apleasant stay at a personal level and a fruitful time from a scientific point ofview during the three months I stayed in Sheffield, and also to Gexiang Zhang,with whom I had the pleasure to share so many lunches, coffee times and hoursof joint work this last summer during his one month stay in Sevilla.

I was lucky to learn since I was very young from my elderly in the mostdiverse aspects of life, sharing so many unforgettable moments and conver-sations with who were so important to help forming, along with my parents,rest of the family and friends, the personality I have developed so far. Thankyou so much, wherever you are, to Rafael, Lita, Candi, Primi, Fidel, Ana,Manuel, Carmela, Mariquita, Zaida, I I am so sorry not to have been able tohave more time with you my little cousin... An many thanks tıa Antonia, ouraunt... They taught me so many important things as the honesty, kindness,perseverance, responsibility, respect, family, generosity, brotherhood, and alsothe happiness, excitement, sense of humor, gets up with a smile every day...and of course, humility (ah yes, you get the highest score? What an impoooor-tant thing!, seem to keep reminding us sarcastically my aunt Antonia everytime some of us forgets there is no person more important than another, andwe must walk through life remaining as humble as a child). Thanks to all ofthem for the invaluable value of the time I spent with everyone, as well as forthe permanent remainder that they are part of me, they follow every step Itake and lead me to the correct direction, while I try to get the path I amwalking makes them feel proud and peaceful cause the ones succeeding themtry to leave the flag up high in life, guided for the principles they instillingon us. The same way we must remember those who bringed us where I havein Life, we must also honor in Science those who left their mark and laid thefoundation for those who succeeded them...

And remembering with huge affect those who were there in the past doesnot imply belittling thanks and appreciation to those who remain with us, asin case of parents, those who are always there whenever we need them, whoenjoy our successes, help us to overcome our failures and receive the prodigal

son that has been somehow absent, those who always forgive, who learnt ushow to live, and had the maturity to avoid getting carried away by their owncircumstances in difficult times and always prioritized the education of theirchildren over their particular interests. To those who raised us not to be likethem, or to be the person they would have liked to be, but to grow withthe necessary freedom to be different from them and walk with responsibilitythrough life, cause there is no responsibility without freedom and trust, causeonly when we are free to choose we can exercise our responsibility and choosethe right path. We may be wrong, but not falling into the easiest option,but walking the path given by our principles, and when in doubt, the fairestand most difficult path leading us to help the weakest, not being able to offernothing in return.

Just to end up with this acknowledgement and thought, I would like toreinforce my belief that we should be always opened to learn, in every aspectand level, from our mentors but also from our students, from our mistakes,from the ones more similar to us, but also from the virtues of the ones we findless things in common with. I hope to keep learning from all, from the closestand from the ones who can make me get inspired in this global world, puttingmy efforts and abilities at the disposal of research, teaching and dissemination,in order to eventually get reflected within our possibilities in the benefit forour society, helping to irrigate a little plot of land constituted by the humanknowledge of what surrounds us and the tools we built to help us deepeningon it.

Contents

Introduction 1

I Preliminaries 11

1 Bio-inspired Computing 131.1 Natural Computing . . . . . . . . . . . . . . . . . . . . . . . . . 141.2 Cellular Computing with Membranes . . . . . . . . . . . . . . . 151.3 P Systems variants . . . . . . . . . . . . . . . . . . . . . . . . . 171.4 Solving decision problems by means of cell systems . . . . . . . 231.5 P systems simulators . . . . . . . . . . . . . . . . . . . . . . . . 33

2 Models in real life 392.1 The need for model designing . . . . . . . . . . . . . . . . . . . 392.2 Formal models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.3 Computational modeling . . . . . . . . . . . . . . . . . . . . . . 422.4 Different approaches to formal models . . . . . . . . . . . . . . . 432.5 Stochastic versus probabilistic models . . . . . . . . . . . . . . . 46

3 Computational modeling based on Membrane Computing 493.1 Multienvironment P systems . . . . . . . . . . . . . . . . . . . . 503.2 Types of multienvironment P systems . . . . . . . . . . . . . . . 533.3 Simulation algorithms for multienvironment P systems . . . . . 56

II Body 65

4 MeCoSim: A visual general purpose simulation environmentfor Membrane Computing 674.1 Introduction and main goals . . . . . . . . . . . . . . . . . . . . 67

ix

4.2 MeCoSim software . . . . . . . . . . . . . . . . . . . . . . . . . 734.3 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

5 Simple Kernel P systems 1035.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035.2 Simple Kernel P Systems . . . . . . . . . . . . . . . . . . . . . . 1045.3 Software tools for modeling and simulation . . . . . . . . . . . . 1085.4 A solution for 3-COL problem based on simple kernel P systems 113

6 Case study 1: Modeling of a real ecosystem 1176.1 Computational modeling of real ecosystems based on PDP . . . 1176.2 Zebra Mussel in the reservoir of Ribarroja . . . . . . . . . . . . 1196.3 Approach and modeling framework . . . . . . . . . . . . . . . . 1236.4 Design of the model . . . . . . . . . . . . . . . . . . . . . . . . . 128

7 Case study 2: Solving NP-complete problems 1637.1 The 3-COL problem in MeCoSim . . . . . . . . . . . . . . . . . . 164

III Conclusions and future work 179

8 Conclusions and future work 1818.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1818.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

A The Neverending Storyof software 189

Bibliography 195

List of Figures

1.1 An eukaryotic cell . . . . . . . . . . . . . . . . . . . . . . . . . . 151.2 A membrane structure . . . . . . . . . . . . . . . . . . . . . . . 161.3 Solving a decision problem by means of cell systems . . . . . . . 261.4 Common elements in P systems simulators . . . . . . . . . . . . 34

4.1 Roles and uses of MeCoSim . . . . . . . . . . . . . . . . . . . . . 734.2 Outputs - Initial data . . . . . . . . . . . . . . . . . . . . . . . . 754.3 MeCoSim internal database logic design . . . . . . . . . . . . . . 764.4 App definition - Parameters generation . . . . . . . . . . . . . . 794.5 Parameters language grammar definition . . . . . . . . . . . . . 824.6 Simulation registers format in the database. . . . . . . . . . . . 864.7 Simulation criteria for results definition. . . . . . . . . . . . . . 874.8 Selection criteria for a simulation result. . . . . . . . . . . . . . 874.9 Filtering criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . 884.10 Group criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894.11 Line chart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894.12 Bar chart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904.13 Stacked bar chart. . . . . . . . . . . . . . . . . . . . . . . . . . . 904.14 MultiLineChart - Line charts list . . . . . . . . . . . . . . . . . 904.15 Chart definition - Roles assignment . . . . . . . . . . . . . . . . 914.16 Daikon - Output data - TableConfig . . . . . . . . . . . . . . . . 924.17 Daikon - Extraction - DaikonConfig . . . . . . . . . . . . . . . . 934.18 Available simulators for a loaded P systems variant . . . . . . . 964.19 Model debugging . . . . . . . . . . . . . . . . . . . . . . . . . . 974.20 Alphabet (left) and structure (right) viewers . . . . . . . . . . . 984.21 Multisets viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . 984.22 Graphs visualization plugin . . . . . . . . . . . . . . . . . . . . 994.23 GraphsPlugin - Parameters . . . . . . . . . . . . . . . . . . . . . 994.24 GraphsPlugin - Generation options . . . . . . . . . . . . . . . . 1004.25 GraphsPlugin - Trees of graphs . . . . . . . . . . . . . . . . . . 100

xi

4.26 Custom output for later Daikon extraction . . . . . . . . . . . . 1004.27 Extracted trace selection . . . . . . . . . . . . . . . . . . . . . . 1014.28 Invariants detection based on Daikon . . . . . . . . . . . . . . . 1024.29 Plugin for generation of Promela code and verification by means

of Spin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

5.1 Specification, analysis and verification of simple kernel P sys-tems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

6.1 Zebra Mussel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1206.2 Ebro river basin . . . . . . . . . . . . . . . . . . . . . . . . . . 1226.3 Division in zones in the reservoir . . . . . . . . . . . . . . . . . 1236.4 Processes and interactions . . . . . . . . . . . . . . . . . . . . . 1266.5 Model blocks sequencing . . . . . . . . . . . . . . . . . . . . . . 1276.6 Main edges of the environments graph of the PDP system . . . 1366.7 Execution trace red: to remove, green: new, orange: modified 1476.8 MeCoSim app settings - Visual structure . . . . . . . . . . . . . . 1526.9 MeCoSim app - Tabs tree structure . . . . . . . . . . . . . . . . . 1536.10 MeCoSim app settings - Tables . . . . . . . . . . . . . . . . . . . 1536.11 MeCoSim app settings - Table definition . . . . . . . . . . . . . . 1536.12 MeCoSim app settings - Parameters . . . . . . . . . . . . . . . . 1546.13 MeCoSim app - Average temperatures per week . . . . . . . . . . 1546.14 MeCoSim app settings - Advanced parameters . . . . . . . . . . . 1556.15 MeCoSim app settings - Auxiliary result . . . . . . . . . . . . . . 1556.16 MeCoSim app settings - Result to show . . . . . . . . . . . . . . 1566.17 MeCoSim app - Debugging - Parsing . . . . . . . . . . . . . . . . 1566.18 MeCoSim app - Debugging - Messages . . . . . . . . . . . . . . . 1576.19 MeCoSim app - Simulation step by step . . . . . . . . . . . . . . 1586.22 MeCoSim app - Multisets viewer . . . . . . . . . . . . . . . . . . 1586.20 MeCoSim app - Alphabet viewer . . . . . . . . . . . . . . . . . . 1596.21 MeCoSim app - Membrane structure viewer . . . . . . . . . . . . 1596.23 MeCoSim app - Initial population . . . . . . . . . . . . . . . . . . 1606.24 MeCoSim app - Area properties . . . . . . . . . . . . . . . . . . . 1616.25 MeCoSim app - Adults output . . . . . . . . . . . . . . . . . . . 1616.26 MeCoSim app - Larvae evolution chart . . . . . . . . . . . . . . . 162

7.1 Colorings - Definition and input visualization . . . . . . . . . . 1667.2 Colorings - Debug . . . . . . . . . . . . . . . . . . . . . . . . . . 1677.3 Colorings - Output settings . . . . . . . . . . . . . . . . . . . . 1677.4 Colorings - Output . . . . . . . . . . . . . . . . . . . . . . . . . 168

7.5 Colorings - Extraction settings . . . . . . . . . . . . . . . . . . . 1697.6 3-COL - MeCoSim app . . . . . . . . . . . . . . . . . . . . . . . 1727.7 3-COL - Initial graph . . . . . . . . . . . . . . . . . . . . . . . . 1737.8 3-COL - Tree of graphs . . . . . . . . . . . . . . . . . . . . . . . 1747.9 3-COL - A custom solution graph . . . . . . . . . . . . . . . . . 175

A.1 MeCoSim web site - Installation . . . . . . . . . . . . . . . . . . 193A.2 MeCoSim web site - Features . . . . . . . . . . . . . . . . . . . 194A.3 MeCoSim web site - Documentation . . . . . . . . . . . . . . . . 194A.4 MeCoSim web site - Case studies . . . . . . . . . . . . . . . . . 195

List of Tables

6.1 % of mussels starting reproduction per week, given the thermalconditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

6.2 % of terrain of each type of soil per zone: type I bedrock, typeII shingle, type III gravels, type IV small gravels, sands, silts,and capacity to hold mussels per zone . . . . . . . . . . . . . . . 124

6.3 Average water temperature each week, on each compartment . . 130

7.1 Some invariants detected . . . . . . . . . . . . . . . . . . . . . . 170

xv

Introduction

Since the beginning of time, mankind has been committed to solve problems.Very specific problems, as running away from imminent danger, looking forfood at any given time (to provide the energy needed for survival), or shelteringfrom the cold (to keep body temperature high enough for vital functions to goon).

Within the need of human beings to know more and better the world theyinhabit, at every level, man has being facing problems that can be solved in amechanical way; that is, by means of a systematic procedure not requiring adeep knowledge about the problem to solve, but the basic ability to performsome elementary tasks. In that sense, any entity or machine, alive or not, beingable to perform each task or sentence given by the systematic procedure, willtherefore be able to execute the solution of the problem solved mechanically.

The irruption of electronic computers meant a qualitative leap forward interms of the resolution of specific problems being previously intractable froma practical point of view, thus having a huge impact in the twentieth centuryand extending to the present day. Since 1983 it is known, thanks to a resultgiven by R. Churchhouse, that the speed of electronic computers is boundedby a limit that can never be surpassed. As a consequence of this limitation,certain problems that are very relevant in real life are practically impossibleto solve by electronic computers. The need of providing successful solutions tothese kind of problems has led to the search for alternative ways in a headlongrush.

Given such circumstances, the observation that many phenomena occur-ring in Nature may be interpreted as computational procedures, provides thebasis for Natural Computing, scientific discipline including a variety of compu-tational paradigms whose design is inspired by processes present in Nature.

Over the last years, from its creation by Gheorghe Paun in 1998, Mem-brane Computing has emerged as one of the paradigms within Natural Com-

1

2

puting that has attracted more attention from the scientific community. Thisparadigm provides a computational framework inspired by the structure andfunctioning of living cells, accounting for the ability of cells to perform a greatnumber of processes simultaneously at a biochemical level, at the level of eachcompartment inside the cell, each cell of a tissue, etc.

These new models try to give successful ways to solve problems affectinghuman beings, specifically the resolution of abstract problems by mechanicalmethods, but trying to overcome the limitations inherent in electronic technol-ogy. Membrane Computing provides machine oriented models of computation ,described by the syntax of the devices or machines whose execution (accordingto a very special semantics) provides, from a theoretical point of view, all thecomputable functions of the model. To summarize, solving a problem in thesemodels of computation implies the description of the corresponding machines.

Membrane Computing theoretical devices (its machines) are genericallycalled P systems. Depending on the idea behind their inspiration, there existcell-like P systems, tissue-like P systems or spiking neural P systems. Be-sides, there exist different variants of these systems, most of them proved tobe universal (in the sense of having the same computational power than Turingmachines). Thus, according to Church-Turing thesis, they will be able to solve,from a theoretical point of view, any problem that can be solved mechanically.In addition, many of these machines have been proved to have the ability tosolve in an efficient way (in the sense of the non deterministic maximal parallelsemantics) computationally hard problems; in particular, NP–complete prob-lems. Obviously, the resolution in polynomial time of these problems does notimply a negative proof of the P 6= NP conjecture, given that the polynomialsolution is reached in exchange for using an exponential amount of space.

From the emergence of Membrane Computing, a number of solutions havebeen provided for different problems within the scope of the so called real lifeproblems, as well as for problems that are apparently a bit farther from real life,having an inherent great complexity but, at the same time, may also represent(model) interesting specific problems.

The solution to this kind of real life problems and high complexity onesprovided in the framework of a model of computation must be followed by thedevelopment of ad hoc simulators to solve in a practical way specific instancesof these problems usually appearing in everyday life. These ad hoc simulatorsact as assistants for the designer of solutions to materialize specific answers tospecific problems modeled by the abstract problem.

Introduction 3

In order to avoid the need of developing ad hoc simulators for each problem,a crucial step in finding the most general possible solution of the problems inthe field of simulation of P systems was provided by P-Lingua. This softwareplatform provides a standard language for the specification of these compu-tational devices, along with a set of tools for the parsing and debugging ofthe solutions written in the language, and simulators able to reproduce thedynamics of the real P systems if its full materialization was already a reality.

Thus, some questions emerge. For instance, if a designer of P systems pro-vides a computational model solving a problem related with a real ecosystem,would this model alone be enough for helping the expert ecologist make betterdecisions? Similarly, let us consider a P system representing, in an amazinglyaccurate way, a protein signaling pathway related to apoptosis (programmedcell death). Would this P system, just by itself, provide an interesting toolfor the molecular biologist? The answer could not be an emphatic no, but ifwe carefully read the wording of these questions we might agree that beforebecoming useful tools for the experts, these systems should be well understoodby the ecologist or molecular biologist or, if we are dealing with NP-completeproblems, by the Logician, Mathematician or the expert in the specific problemunder study.

This way, the P systems designer, has succeeded to solve a general problemand provide a computational framework solving the abstract problem. Thisdesigner has even codified this solution in P-Lingua, worked with the parserof the language, debug it and “reproduced” the behavior of the system bymeans of the general purpose simulator, available in the field of P systems.However, some difficulties appear when the purpose of the model is to be usedas a useful tool to improve the knowledge and for the practical managementof the phenomena by the experts dealing with the problem under study.

The main goal of the work presented in this dissertation is to move a stepforward in the path started by P-Lingua for solving problems by means ofcomputational models under the framework of Membrane Computing. Theaim is to bring these tools to the experts in the phenomena, processes orcomplex systems under study, such a way that the leap can be shortened fromthe theoretical model or the solution at the designer level, to the release of apractical solution at the end user level.

The simulation environment presented in this work is called MeCoSim

(Membrane Computing Simulator) and intends to meet that need, solve thatproblem. That is, the main focus is on providing a general mechanism to makeit possible for end users to have available general purpose applications able to

4

be customized for each particular problem, abstracting them from the internaldetails of P systems and models based on them. Thus, MeCoSim provides enduser applications abstracting them from the details of the P system solutionsbehind them,the same way that P-Lingua provides P systems designers toolsabstracting them from the details of the parsers and simulators. This way, itis intended for these real problems (that were searched for an alternative wayof solving, a matter of headlong rush to solve them in a practical way, over-coming the limitation of conventional paradigms) move from the scope of Psystems designers to the zone of end users, to become useful tools for the prac-tical resolution of tractable instances of these problems, specifically for thosespecially interested in increasing their knowledge about the phenomena, tak-ing advantage of these powerful assistants for a better decision-making processregarding the management of the phenomena under study.

Contents of the document

The present dissertation is structured in three main parts including eight chap-ters whose contents are described below.

Part I: Preliminaries

The first part is organized through a series of preliminary chapters laying thefoundations for the body of the dissertation.

In Chapter 1 the appearance of the discipline of Natural Computing is jus-tified and the paradigm of Membrane Computing is presented in a deeper way.This paradigm is inspired in the structure and functioning of cells in livingorganisms. A series of variants being used along this work are described: tran-sition P systems, P systems with active membranes and tissue-like P systems.In addition, some basic concepts concerning the computational complexity inMembrane Computing are introduced. The last part of the chapter is devotedto explain the role played by P systems simulators, the features that should beincluded in a good simulation platform, and finally a general review of parallelsimulators for P systems developed so far is presented.

Chapter 2 focuses on the general issue when studying dynamic complexsystems, using the formal modeling as a methodology to address relevant phe-nomena of real life. Several approaches are briefly analyzed, including both

Introduction 5

computational and non computational ones. Finally, the inherent randomnessin processes occurring in real life is analyzed, along with the soundness of cap-turing certain aspects by means of mathematical, stochastic or probabilisticmodels.

Chapter 3 is centered on the paradigm of Membrane Computing, mainlyfrom the point of view of formal modeling of complex systems. A uniformformal framework is presented, multienvironment P systems, for representingsuch systems, and two approaches are described: multicompartmental P sys-tems, for molecular and cellular phenomena of an essentially stochastic nature,and population dynamics P systems, a probabilistic approach mainly used onprocesses related to the evolution of real ecosystems. Finally, some algorithmsare presented, capturing the corresponding dynamics of these two types ofmultienvironment systems.

Part II: Body

The body of this document presents the core of the work performed. Firstof all, conceptual, methodological and practical tools developed are described.Secondly, the application of these tools to different problems of interest isillustrated.

Chapter 4 is devoted to MeCoSim simulation environment, general purposesoftware for the experimental validation and virtual experimentation of themodels analyzed in the previous chapters. The software tools, their origin andthe internal structure of the environment are introduced, along with the mainfunctionalities provided. This chapter ends by presenting a methodology tothe resolution of problems within the framework of P systems, from the initialstudy of the phenomena themselves to the use of software tools adapted tothe user needs, being used for performing virtual experiments and assisting indecision making.

Chapter 5 focuses in the introduction of simple kernel P systems, a variantof cellular systems acting as an integrative model. Simple kernel P systems pro-vide a formalism that makes them able to simulate the action of most variantsof P systems previously existing within the scope of Membrane Computing.

Chapter 6 is devoted to present a first case study, consisting in the de-sign of a control plan for an exotic invasive species (Zebra Mussel) in thereservoir of Ribarroja, placed in the northeast of Spain, in the area of Ebroriver. In addition, in this chapter the application of P-Lingua and MeCoSim

6

for this problem is detailed, acting as a connecting backbone for the proposedmethodology, supporting the tasks involved in its different stages.

In Chapter 7 a second case study is presented, related to the use of theprovided platform to assist in solving well known NP-complete problems. Inorder to carry this out, the process starts by analyzing solutions of this kindof problems by means of P systems, including their translation to P-Lingua

language, their parsing, debugging, and the simulation step by step along withthe introspection of the corresponding internal structures. Finally, a high levelvisual application based on MeCoSim is provided.

Part III: Results

In the third part of this dissertation the main conclusions extracted from thework performed are presented, along with the main contributions made by theauthor. Then, some research lines for future work are proposed, some of themwhere we have just started working.

At the end of the document, some additional appendices are presented,meeting two goals complementing the core contents of the work presented. Onthe one hand, it tries to be fair with the numberour software packages usedduring the development of this work. On the other hand, it presents the website developed to illustrate the main functionalities of MeCoSim.

Contributions

Among the main contributions performed during the development of the presentwork, it is worth to highlight the ones that follow.

• Design of a methodology for working with solutions based on P systemsas tools able to assist in the search for further knowledge and the man-agement of the problems under study. To achieve this, the necessarystages are involved, from the initial study of the problem to the provi-sion of a software application adapted to the custom needs derived fromeach problem.

• Development of a simulation environment to provide sound mechanismssupporting the goals raised by the methodology above, both for designers

Introduction 7

of solutions based on P systems and for the end users of the correspondingapplications.

• Design and implementation of a mechanism for the extensibility ofMeCoSim to permit adding new functionalities to the general environ-ment. This can be performed by means of a plugins architecture whichpermits including in MeCoSim programs, both based on Java technologyintegrated in MeCoSim, or completely external, being able to be connectedto MeCoSim by configuring a simple text file.

• Development and integration of plugins for solving specific requirementsin response to different problems: introduction of propositional formula,graphs visualization, invariants extraction or external simulation by Spin

software, among others.

• Design of a language for simple kernel P systems as part of P-Lingua,capturing the essential elements of the framework and extending P-Linguato incorporate the needed ingredients.

• Development of tools for the parsing of the designed language and a simu-lator inside P-Lingua framework, with the aim of recognizing, debuggingand simulating solutions based on simple kernel P systems.

• Application of the methodology and the developed tools to real life prob-lems (scavenger birds, Pyrenean Chamois, plant alliances, newts, am-phibians, fishes, Zebra Mussel, pandemics, gene networks and animalproduction, specifically pigs), along with a set of NP-complete problems(such as SAT, 3-COL, Subset Sum, Partition and Vertex Cover).

• Development of a web site for the download and installation of MeCoSim,along with the dissemination of documentary and audiovisual informa-tion for illustrating the use of the basic functionalities provided by theenvironment and showing the study of a number of applications usingthe software.

8

Publications

Some of the more relevant results of the work presented in this dissertationhave been published in journals, book chapters and conference proceedings, asenumerated below.

Indexed journals

1. L. Valencia-Cabrera, M. Garcıa-Quismondo, M.J. Perez-Jimenez, Y. Su,H. Yu, L. Pan. Modeling Logic Gene Networks by Means of ProbabilisticDynamic P Systems. International Journal of Unconventional Comput-ing , 9, 5-6 (2013), 445-464. Impact factor: 0.684

2. M. Gheorghe, F. Ipate, R. Lefticaru, M.J. Perez-Jimenez, A. Turcanu,L. Valencia-Cabrera, M. Garcıa-Quismondo, L. Mierla. 3-COL prob-lem modelling using simple Kernel P systems. International Journal ofComputer Mathematics , 90, 4 (2013), 816-830. Impact factor: 0.542

3. M. Garcıa-Quismondo, L.F. Macıas-Ramos, M.A. Martınez-del-Amor, I.Perez-Hurtado, L. Valencia-Cabrera. Open Problems on Simulation ofMembrane Computing Models. International Journal of Foundations ofComputer Science, 24, 5 (2013), 619–622. Impact factor: 0.554

4. I. Perez-Hurtado, L. Valencia-Cabrera, J.M. Chacon, A. Riscos-Nunez,M.J. Perez-Jimenez. A P-Lingua based simulator for tissue P systemswith cell separation. Romanian Journal of Information Science andTechnology , 17, 1 (2014), 89-102. Impact factor: 0.453

5. D. Orellana-Martın, C. Graciani, L.F. Macıas-Ramos, M.A. Martınez-del-Amor, A. Riscos-Nunez, A. Romero-Jimenez, L. Valencia-Cabrera.Sevilla Carpets Revisited: Enriching the Membrane Computing Toolbox.Fundamenta Informaticae, 134 (2014), 153-166. Impact factor: 0.479

6. M.A. Colomer, A. Margalida, L. Valencia-Cabrera, A. Palau. Applica-tion of a computational model for complex fluvial ecosystems: the pop-ulation dynamics of zebra mussel Dreissena polymorpha as a case study.Ecological Complexity . Accepted. In press Impact factor: 2.000

Introduction 9

Non-indexed journals

1. M.A. Colomer, S. Lavın, I. Marco, A. Margalida, I. Perez-Hurtado, M.J.Perez-Jimenez, D. Sanuy, E. Serrano, L. Valencia-Cabrera. Modelingpopulation growth of Pyrenean Chamois (Rupicapra p. pyrenaica) byusing P systems. Lecture Notes in Computer Science, 6501 (2011), 144-159.

2. L.F. Macıas-Ramos, I. Perez-Hurtado, M. Garcıa-Quismondo, L. Valencia-Cabrera, M.J. Perez-Jimenez, A. Riscos-Nunez. A P-Lingua based simu-lator for Spiking Neural P systems. Lecture Notes in Computer Science,7184 (2012), 257-281.

3. M.A. Martınez-del-Amor, I. Perez-Hurtado, M. Garcıa-Quismondo, L.F.Macıas-Ramos, L. Valencia-Cabrera, A. Romero-Jimenez, C. Graciani,A. Riscos-Nunez, M.A. Colomer, M.J. Perez-Jimenez. DCBA: Simulat-ing population dynamics P systems with proportional objects distribu-tion. Lecture Notes in Computer Science, 7762 (2013), 257-276.

4. L.F. Macıas-Ramos, M.J. Perez-Jimenez, A. Riscos-Nunez, M. Rius. Theefficiency of tissue P systems with cell separation relies on the environ-ment. Lecture Notes in Computer Science, 7762 (2013), 243-256.

5. F. Ipate, R. Lefticaru, L. Mierla, L. Valencia-Cabrera, H. Hang, G.Zhang, C. Dragomir, M.J. Perez-Jimenez, M. Gheorghe. Kernel P sys-tems: Applications and Implementations. Advances in Intelligent Sys-tems and Computing , 212 (2013), 1081-1089.

6. M.J. Perez-Jimenez, A. Riscos-Nunez, M. Rius, L. Valencia-Cabrera.The relevance of the environment on the efficiency of tissue P systems.Lecture Notes in Computer Science, 8340 (2014), 308-321.

7. L.F. Macıas-Ramos, M.A. Martınez-del-Amor, M.J. Perez-Jimenez, A.Riscos-Nunez, L. Valencia-Cabrera. The Role of the Direction in TissueP Systems with Cell Separation. Journal of Automata, Languages andCombinatorics , 19, 1-4 (2014), 185-199.

Book chapters

1. M. A. Colomer, M. Garcıa-Quismondo, L. F. Macıas, M. A. Martınez-del-Amor, I. Perez-Hurtado, M.J. Perez-Jimenez, A. Riscos-Nunez, L.

10

Valencia-Cabrera. Membrane System-Based Models for Specifying Dy-namical Population Systems. In P. Frisco, M. Gheorghe, M. J. Perez-Jimenez (eds.) Applications of Membrane Computing in Systems andSynthetic Biology. Springer, Series: Emergence, Complexity and Com-putation, Vol. 7, 2014, Chapter 4, pp. 97-132.

Conference proceedings

1. I. Perez-Hurtado, L. Valencia-Cabrera, M.J. Perez-Jimenez, M.A. Colomer,A. Riscos-Nunez. MeCoSim: A general purpose software tool for simu-lating biological phenomena by means of P Systems. In K. Li, Z. Tang,R. Li, A.K. Nagar, R. Thamburaj (eds.) Proceedings 2010 IEEE Fifth In-ternational Conference on Bio-inpired Computing: Theories and Appli-cations (BIC-TA 2010), IEEE Press, Volume 1, September 23-26, 2010,Changsha, China, pp. 637-643.

2. M. Angels Colomer, C. Fondevilla, L. Valencia-Cabrera (2011). A New PSystem to Model the Subalpine and Alpine Plant Communities. Proceed-ings of the Ninth Brainstorming Week on Membrane Computing, Seville,Spain, January 31- February 4, 2011, Report RGNC 01/2010, Fenix Ed-itora, 2011, pp. 91-112.

3. R. Lefticaru, F. Ipate, L. Valencia-Cabrera, A. Turcanu, C. Tudose, M.Gheorghe, M.J. Perez-Jimenez, I.M. Niculescu, C. Dragomir. Towardsan integrated approach for model simulation, property extraction andverification P systems. Proceedings of the Tenth Brainstorming Week onMembrane Computing, Volume I, Seville, Spain, January 30- February3, 2012, Report RGNC 01/2012, Fenix Editora, 2012, pp. 291-318.

4. M. Gheorghe, F. Ipate, C. Dragomir, L. Mierla, L. Valencia-Cabrera, M.Garcıa-Quismondo, M.J. Perez-Jimenez. Kernel P systems - Version I.Proceedings of the Eleventh Brainstorming Week on Membrane Comput-ing, Seville, Spain, February 4-8, 2013, Report RGNC 01/2013, FenixEditora, 2013, pp. 97-124.

5. L. Valencia-Cabrera, M. Garcıa-Quismondo, M.J. Perez-Jimenez, Y. Su,H. Yu, L. Pan. Analising gene networks with PDP systems. Arabidopsisthailiana, a case study. Proceedings of the Eleventh Brainstorming Weekon Membrane Computing, Seville, Spain, February 4-8, 2013, ReportRGNC 01/2013, Fenix Editora, 2013, pp. 257-272.

Part I

Preliminaries

11

1Bio-inspired Computing

The need to solve concrete real life problems has made man to look for sys-tematic procedures allowing him to obtain solutions by means of methods thatwe can denominate as mechanical. Such procedures consist in, basically, per-forming a set of adequately sequenced “elemental” tasks. In this way, anyentity able to execute such tasks in an autonomous way, can implement suchprocedures.

The coming of (general purpose) electronic computers in the middle 40’sof the past century implied a quantitative improvement in the solving of con-crete problems. Nevertheless, in 1983, R. Churchhouse proved the existenceof a boundary for the computing speed and size that electronic devices couldreach. And the worst part about that boundary was its insufficiency to im-plement mechanical solutions of really relevant real life problems in electroniccomputers.

The Natural Computing is a scientific discipline which main goal is theanalysis, design and simulation of dynamic processes taking place in the livingNature and that are susceptible to be interpreted as calculation procedures.

In this chapter the formal framework in which the present work is devel-oped, concretely Membrane Computing is presented. This document is struc-tured as follows. In the first place, some paradigms and models of NaturalComputing are briefly described. In Section 1.2 the first ideas and concepts of

13

Chapter 1. Bio-inspired Computing 14

Membrane Computing are introduced. Section 1.3 is devoted to present somevariants that are going to play a relevant role in this document. In Section1.4 the required ingredients to develop a Computational Complexity Theoryin Membrane Computing will be introduced. Also we will present solutions tothe SAT and 3-COL problems within the aforementioned variants. Such solu-tions will let us study the different functionalities that the MeCoSim platform,in conjunction with P-Lingua offers. The last section deals with the analysisof different aspects related to software applications that enable simulating thebehaviour of the cellular computing devices.

1.1 Natural Computing

Natural Computing emerges as an alternative to conventional computing inthe search of novel ways to overcome the limitations associated to the conven-tional models. Natural Computing is a discipline characterized by simulatingthe way in which nature operates on matter. Among the branches of Nat-ural Computing, we highlight genetic algorithms (or in general evolutionarycomputation), artificial neural networks, molecular computing and membranecomputing.

Genetic algorithms,introduced by J. Holland [54] in 1975, take inspirationfrom the genetic process making living beings evolve. They are based on theprinciple of natural selection, which allows finding a good solution from a hugeset of possible candidate solutions.

Artificial neural networks were introduced by W.S. McCulloch and W. Pitts[69] in 1943 and take inspiration from the interconnections and the functioningof neurons in the brain.

Molecular computing aims to use organic molecules (DNA, RNA, proteins,etc.) as biological hardware allowing to perform computations. This branchof Natural Computing was born at the end of 1994 with the laboratory ex-periment of L. Adleman [13] which allowed to solve a concrete instance of anNP-complete problem by means of the manipulation of DNA molecules.

Membrane computing was introduced by Gh. Paun [80] at the end of 1998and takes inspiration from the structure and the functioning of cells in theliving organisms as well as their interactions in tissues or biological structuresof superior order. In October 2003, the Institute for Scientific Information(ISI, USA) designated membrane computing as Fast Emerging Research Front

1.2. Cellular Computing with Membranes 15

in the area of Computer Science.

Genetic algorithms and artificial neural networks have been implementedon electronic conventional computers in order to improve the efficiency of pro-grams executed on such machines. DNA computing has been implemented onbiochemical subtracts while membrane computing has not been implementedyet on any subtract.

1.2 Cellular Computing with Membranes

The cell is the fundamental unit of any living organism. It has a complex as wellas a deeply organised structure allowing the simultaneous execution of a hugenumber of chemical reactions. There exist two kind of cells: prokaryotic cells(conforming certain unicellular organisms) and eukaryotic cells (conforminganimals and plants). Both of them perform a set of basic processes for life:a) DNA replication; (b) energy production; (c) proteins synthesis; and (d)metabolic processes.

Three parts can be identified in a cell: a somewhat very thin layer (cy-toplasmic membrane) that delimits the cell from its environment, a centralcorpuscle (nucleus), that contains and stores the genetic information, and the(cytoplasm), that is the part situated between the nucleus and the cytoplasmicmembrane.

Figure 1.1: An eukaryotic cell


Membrane Computing is a paradigm which devices are known as P sys-tems in general. Their syntactic ingredients are: (a) a membrane structureformalised through a rooted tree, which root is named skin and which leavesare named elemental membranes; (b) a finite multisets of objects (abstractingchemical compounds) placed in the different compartments that delimit themembranes; and (c) finite set of rewriting rules (abstracting chemical reac-tions) that allow objects evolution. The skin membrane provides the systemwith a differentiated entity and allows identifying the inside from the outside.This external part is called the environment of the system.

'

&

$

%

'

&

$

%

#

"

!#" !

'&

$%

membranes

elementary membrane

environment environment

regions

skin

1 2

3

45

6

7

8

9

@@@@@@R

HHHHj

PPPPPPPPPPq

9

+

/

SSw

Figure 1.2: A membrane structure

The semantic ingredients of the membrane computing models are based onthe maximal parallelism and the non-determinism. The maximality conditionmeans that when performing a computation step, a multiset of rules will beselected in such a way that after its application there is no object left that canevolve.

With respect to non-determinism, when evaluating the system differentobjects and rules may be used: objects and rules will be non-deterministicallyselected.

1.3. P Systems variants 17

1.3 P Systems variants

In this section some membrane computing models will be presented. Suchmodels will be used through this piece of work.

1.3.1 Transition P Systems

In the first place, some preliminaries are introduced. An alphabet, Γ, is anon-empty multiset which elements are called symbols. A finite sequence of Γsymbols is a string of Γ. The set of all strings on the Γ alphabet is noted Γ∗.A language on Γ is a subset of Γ∗.

A multiset m on an alphabet Γ is a pair (Γ, f) where f is a function from Γto the set IN of natural numbers. If m = (Γ, f) is a multiset, then the supportof m is supp(m) = x ∈ Γ | f(x) > 0. If x ∈ supp(m), then we will say that xbelongs to the multiset m and we will write x ∈ m. We will say that a multisetm = (Γ, f) is finite if its support is finite (supp(m) = a1, . . . , ak). In suchcase we will say that f(a1) + · · · + f(ak) is the cardinal of m, noted by |m|.The empty multiset (all elements have 0 multiplicity) is noted by ∅ or λ. Wewill note by Mf (Γ) the set of all finite multisets on Γ.

If m1 = (Γ, f1), m2 = (Γ, f2) are multisets on Γ, then the union of m1

and m2 is defined as m1 + m2 = (Γ, g), where g = f1 + f2; that is, g(x) =f1(x) + f2(x), for each x ∈ Γ. We will say that m1 is contained in m2, and wewill write m1 ⊆ m2, if m1(x) ≤ m2(x), for each x ∈ Γ is verified. From herewe can naturally extend binary relations of the set Rel = ≤,≥,=, 6=, >,<to binary relations between multisets of an alphabet (for instance, m1 ≤ m2 ifand only if m1 ⊆ m2).

Definition 1.1. A transition P system of degree q ≥ 1 is a tuple

Π =(Γ, µ

Π,M1, . . . ,Mq, (R1, ρ1), . . . , (Rq, ρq), iout

)where:

• Γ is a finite alphabet named working alphabet.

• µΠ

is a membrane structure (a rooted tree) that consists in q membranesunequivocally labelled from 1 to q.

• Mi, 1 ≤ i ≤ q, are finite multisets of objects (symbols) over Γ associatedwith the membrane i, representing the initial contents;


• Ri, 1 ≤ i ≤ q, are finite sets of evolution rules over Γ associated with themembrane i. An evolution rule is of the form u → v, where u ∈ Mf (Γ)and v = v′ or v = v′δ, being v′ ∈Mf (Γ×

(here, out∪inj : 1 ≤ j ≤ q

)and δ /∈ Γ is a special symbol.

• ρi, 1 ≤ i ≤ q, is a strict partial order over Ri.

• iout, 1 ≤ iout ≤ q, represents the output membrane of the system.

A configuration of a transition P system in an instant t consist of a mem-brane structure and a family of multisets of objects associated to each ex-isting membrane in that instant. In the description of Π, the configuration(µ

Π,M1, . . . ,Mq) is named initial configuration.

We will say that a rule r ≡ u → v ∈ Ri i is applicable to a configurationC of Π at a instant t it the following is verified: (a) the membrane i appearsin the membrane structure associated to C; (b) the multiset u is contained inthe membrane i of C; (c) if (v1, inj) ∈ v, then the membrane j must be a childmembrane of i; (d) if v = v′δ, then the membrane i cannot be the tree root orthe output membrane iout; and (e) there not exists any rule r′ ∈ Ri applicableto that configuration and with higher priority.

Execution of r ∈ Ri to a configuration C is performed as follows: (a) themultiset u is removed from the membrane i; (b) for each (a, out) ∈ v, an objecta ∈ Γ is included in the parent membrane i (if i is the skin membrane, object ais sent to the environment); (c) for each (a, here) ∈ v, an object a ∈ Γ is addedto membrane i; (d) for each (a, inj) ∈ v, an object a ∈ Γ is introduced into thechild membrane labelled by j; and (e) if δ ∈ v, the membrane i is dissolvedand its content goes to the first not dissolved predecessor in that step.

Rules of the system are applied in a non-deterministic, parallel and maximalway; that is, rules to be executed and involved objects in such rules will beselected in such a way that in each computation step and after the applicationof these rules, no objects that can evolve by the application of some rule areleft.

The existing priority relationships on rules are interpreted in a strong sense,as follows: if the rule r1 has higher priority than rule r2 and r1 can be appliedto a certain configuration, then r2 cannot be applied to that configurationalthough it is applicable.

We will say that a configuration C is a halting configuration if there noexists any applicable rule in the system to such configuration. Given two


configurations C and C ′ of system Π, we will say that C ′ is obtained from Cafter the execution of a computation step or transition step, and we will noteC ⇒

ΠC ′, if the configuration C ′ is obtained from C after applying a maximal

set of rules.

A computation of a P system is a (finite or infinite) sequence of configura-tions such that: (a) the first term of the sequence is an initial configuration ofthe system; (b) for each n ≥ 2, the n-th term of the sequence is obtained fromthe previous one by means of the execution of a computation step; and (c)if the sequence is finite (in which case it will be named halting computation),then the last term of the sequence is a halting configuration. Only a haltingcomputation provides a result, which is codified in the output membrane.

Notation: If C = Ctt≤r (r ∈ IN) is a halting computation of Π, then we willsay that the length of C is r and we will note it by |C|.

In the P systems with external output [81] it was considered the possibilityfor the output of the system to be provided through the environment content.

We will admit that any computation executes a synchronized process; thatis, it is assumed the existence of some kind of universal clock that marks theactivities of all the elements present in the system.

1.3.2 P systems with active membranes

In what follows, a variant which allows the construction of an exponentialamount of space (expressed in terms of number or objects and number ofmembranes) in polynomial time is introduced.

The differentiator ingredient consist in an specific rule of cell division in-spired from the process of mitosis.

Definition 1.2. A P system with active membranes of degree q ≥ 1 is a tupleΠ = (Γ, H, µΠ,M1, . . . ,Mq,R, iout), where:

• Γ is a finite alphabet, named working alphabet.

• H is a finite set, named labels alphabet, such thatΓ ∩H = ∅.

• µΠ is a rooted tree which nodes (membranes) are labelled with elementsfrom H×0,+,−. If a membranes is labelled by (h, α) ∈ H×0,+,−,we will note [ ]αh and we will say that it has label h and electric charge α.


Initially all membranes have associated neutral charge (0) and differentlabels.

• M1, . . . ,Mq are finite multisets on Γ.

• R is a finite set of rules of the following kinds:

(a) [ a→ v ]αh, where a ∈ Γ, v ∈Mf (Γ), α ∈ 0,+,−, h ∈ H (evolutionrule).

(b) [ a]αh → b [ ]βh, where a, b ∈ Γ, α, β ∈ 0,+,−, h ∈ H (send-outcommunication rule).

(c) a [ ]αh → [ b ]βh, where a, b ∈ Γ, α, β ∈ 0,+,−, h ∈ H, h is not thelabel of the tree root (send-in communication rule).

(d) [ a ]αh → b, where a, b ∈ Γ, α ∈ 0,+,−, h ∈ H \ iout, h is notthe label of the tree root (dissolution rule).

(e) [ a ]αh → [ b ]βh [ c ]γh, where a, b, c ∈ Γ, α, β, γ ∈ 0,+,−, h ∈ H \iout, h is not the label of the tree root (division rule).

• iout ∈ H ∪ env, where env /∈ H ∪Γ is a symbol that labels the environ-ment of the system.

In what follows we specify how the rules of such systems are applied.

(a) Evolution rules : the rule [ a→ v ]αh , will be applicable to any membraneh with electric charge α and containing the object a. Its execution doesnot change neither the label nor the charge and produces the substitutionof an object a with a multiset of objects v.

(b) Send-out communication rules : the rule [ a ]αh → b [ ]βh will be applicableto any membrane h with charge α and containing the object a. Itsapplication does not change the label but, to the contrary, the chargechanges to β. Its execution produces the elimination of an object a ofthe membrane h while an object b appears in the parent membrane of h(if h is the skin membrane, object b goes to the system environment).

(c) Send-in communication rules : the rule a [ ]αh → [ b ]βh will be applicableto any membrane f , different from the skin membrane, with charge αin such a way that the object a appears in the parent membrane of h.Its execution does not change the label but, to the contrary, the chargechanges to β and, in addition, it produces the removal of an object a


of the parent membrane of h and the appearance of an object b in theparent membrane of h.

(d) Dissolution rules : the rule [ a ]αh → b, will be applicable to any mem-brane h, different from the either the skin or the output membrane withcharge α and containing object a. Its application produces the elimina-tion of that membrane while its content goes to the its first not dissolvedpredecessor membrane.

(e) Division rules : the rule [ a ]αh → [ b ]βh [ c ]γl will be applicable to any ele-mental membrane h with charge α containing the object a. Its executionproduces the creation of two membranes with the same label, the firstone with charge β and the second one with charge γ. Object a disap-pears and, two different objects b and c appears in its place, b in thefirst created membrane and c in the second one. The other objects arereplicated in the both newly created membranes.

System rules are applied in such a way that: (1) in each computation step, amembrane can be applied at most a rule from those that are not of the ,(a)kind; and (2) an evolution rule can be executed on a membrane simultaneouslyand in a maximal way with rules of the kind (b), (c), (d) or (e).

The concepts configuration, computation (or transition) step from one con-figuration to other one and computation are defined in the framework of Psystems with active membranes in a similar way to transition P systems.

1.3.3 Tissue-like P systems

This variant of P systems aims to describe the way in which tissues functionwithin the framework of Membrane Computing.

In this new context, the basic components are called cells and there existsa singular external element to the system named environment. Cells will beidentified by means of labels and can communicate between each other and theenvironment by means of communication rules of the kind symport/antiport.Besides, these systems may contain rules allowing the creation of two newcells from an initial one. These rules implement, on the one hand, cell division(division rules) and, on the other hand, cell fission (separation rules).

Definition 1.3. A tissue-like P system with cell division of degree q ≥ 1 is atuple Π = (Γ, E ,M1, . . . ,Mq,R, iout), such that:


1. Γ is a finite alphabet.

2. E ⊆ Γ.

3. M1, . . . ,Mq are mutisets on Γ.

4. R is a finite set of rules of the following kinds:

(a) Communication Rules: (i, u/v, j), for i, j ∈ 0, 1, 2, . . . , q,i 6= j, u, v ∈Mf (Γ), |u+ v| 6= 0;

(b) Division Rules: [ a ]i → [ b ]i [ c ]i, where i ∈ 1, 2, . . . , q, i 6= iout ya, b, c ∈ Γ.

Definition 1.4. A tissue-like P system with cell separation of degree q ≥ 1 isa tuple Π = (Γ,Γ1,Γ2, E ,M1, . . . ,Mq,R, iout), such that:

1. Γ is a finite alphabet.

2. E ⊆ Γ.

3. M1, . . . ,Mq are multisets on Γ.

4. Γ1,Γ2 is a partition of Γ.

5. R is a finite set of rules of the following kinds:

(a) Communication Rules: (i, u/v, j), for i, j ∈ 0, 1, 2, . . . , q, i 6= j,u, v ∈Mf (Γ), |u+ v| 6= 0;

(b) Separation Rules: [ a ]i → [ Γ1 ]i [ Γ2 ]i, where i ∈ 1, 2, . . . , q, i 6=iout y a ∈ Γ.

A tissue-like system Π = (Γ, E ,M1, . . . ,Mq,R, iout) of degree q ≥ 1, canbe considered as a set of q cells, labelled from 1 to q, with an environment(labelled by 0) in such a way that: (a) M1, . . . ,Mq are finite multisets on Γrepresenting the objects initially placed in the q cells; (b) E is a set of objectsinitially placed in the environment (we will admit that all of them appear withan arbitrary number of copies); and (c) iout ∈ 0, 1, 2, . . . , q representing adistinguished region that codifies the system output. We will use the termregion i (0 ≤ i ≤ q) to refer to cell i, in the case 1 ≤ i ≤ q, or to theenvironment, in the case i = 0. If the output region is a cell, then such cellcan be neither “divided” nor “separated”.

1.4. Solving decision problems by means of cell systems 23

A communication rule (i, u/v, j), for i, j ∈ 0, 1, 2, . . . , q, i 6= j, u, v ∈Mf (Γ), is applicable to any pair of regions i, j such that the region i con-tains the multiset u and region j contains the multiset v. The application ofsuch rule produces that the multiset u goes from region i to region j while,simultaneously, multiset v goes from region j to region i.

A division rule [ a ]i → [ b ]i[ c ]i is applicable to a cell i containing object aas long as it is not an output cell. The rule execution produces the creation oftwo new cells with the same label, in such a way that, in the first one object ais replaced by object b, while in the second one object a is replaced by objectc. The rest of the objects are replicated in the two newly created cells.

A separation rule [ a ]i → [ Γ1 ]i[ Γ2 ]i is applicable to a cell i containingobject a as long as it is not an output cell. Its execution creates two new cellswith the same label, in such a way that object a is consumed and the rest ofthe objects are distributed among the newly created cells: objects from Γ1

go to the first created cell while objects from Γ2 go to the second one.

Rules of a tissue-like system are executed in parallel, in a non-deterministicand maximal way but with one constraint: if at a certain step a division (orseparation) rule is being applied to a cell, then in that step only such rule willbe applied to the cell. A configuration of a tissue-like P system in a certaininstant is described by the multisets of object on Γ associated to the cellspresent in the system, as well as the multiset of objects on Γ \ E associatedto the environment in that moment. The initial configuration of the systemΠ = (Γ, E ,M1, . . . ,Mq,R, iout) is (M1, · · · ,Mq; ∅). In a similar way to howit has been done in previous sections, the concept of computation is introducedand the same notation described in Section 1.2 is used.

1.4 Solving decision problems by means of cell

systems

In this section we are going to use the term cell system to refer indistinctlya transition P system, a P system with active membranes or a tissue-like Psystem with cell division. The aim of this section is to introduce the conceptof efficient resolution of decision problems through a family of cell systems.

A decision problem, X, is an ordered pair (IX , θX), where IX is a languageon a finite alphabet (which elements are named instances of the problem) andθX is a total boolean function on IX . Any decision problem X has associated a


language LX composed by all those instances a ∈ IX such that θX(a) = 1 and,reciprocally, given a language L on a finite alphabet Γ, there exists a decisionproblem XL such that the language associated to XL is, precisely, the initiallanguage L.

The recognizer cell systems will be used as a formal framework to tacklecomputationally hard decision problems in an efficient way.

Definition 1.5. We will say that a cell system Π is a recognizer system if itverifies the following:

• The working alphabet Γ of the system contains two distinguished objectsyes and no. Besides, in tissue-like P systems at least a copy of each oneof these objects has to be present in some of the initial multisets of thesystem.

• There exists an (input) alphabet Σ strictly contained in Γ. In tissue-likeP systems we have Σ ∩ E = ∅, being E the environment alphabet.

• Initial multisets of the system M1, . . . ,Mq are multisets on alphabet Γ \Σ.

• There exists an input membrane (cell–like systems) or an input cell(tissue–like systems) that we will note by iin.

• The output region will be the environment.

• All the computations halt.

• If C is a computation of Π, then at least one of the objects yes or no,but not both, has to be sent to the output region and, precisely, only inthe last computation step.

For each multiset m on Σ, the configuration of P system Π with input m isobtained from the initial configuration of the system by adding to the multisetMiin the multiset m. Miin +m.

If Π is a recognizer P system and C is a computation of Π, then we will saythat the result is yes (respectively, no) if this object appears in the environmentassociated to the corresponding halting configuration and, to the contrary,neither object yes nor object no appear in the environment associated to anyprevious configuration. We will say that a configuration C is an accepting one


(respectively, rejecting one) if the answer is yes, affirmative (respectively, no,negative).

We will note AM (respectively, TDC) the class of all recognizer P systemswith active membranes (respectively, recognizer tissue-like P systems with celldivision).

1.4.1 Polynomial complexity classes in cell systems

Cell systems provide non-deterministic devices and, consequently, when study-ing solvability of decision problems in this new framework, it would be ad-visable to set “distances” from the classical concept of solvability by non-deterministic Turing machines.

Definition 1.6. A decision problem X = (IX , θX) is solvable in polynomialtime by a family Π = Π(n) | n ∈ IN of recognizer cell systems if the followingproperties are verified:

• The family Π is polynomially uniform by Turing machines; that is, thereexists a deterministic Turing machine working in polynomial time suchthat it builds the system Π(n) from n ∈ IN.

• There exists a pair of functions (cod, s) on IX that are computable inpolynomial time, in such a way that they satisfy the following:

− For each instance w ∈ IX , s(w) is a natural number and cod(w) isan input multiset to the system Π(s(w)).

− For each n ∈ IN, the set s−1(n) is finite.

− The family Π is polynomially bounded with respect to (X, cod, s);that is, there exist a polynomial function p(n), such that for eachinstance w ∈ IX , any computation from Π(s(w)) with input cod(w)is a halting one and takes, at most, p(|w|) steps.

− The family Π is sound with respect to (X, cod, s); that is, for eachinstance w ∈ IX , if there exists an accepting computation of Π(s(w))with input cod(w), then θX(w) = 1.

− The family Π is complete with respect to (X, cod, s); that is, foreach w ∈ IX , if θX(w) = 1, then any computation of Π(s(w)) withinput cod(w) is an accepting one.


From the soundness and completeness it is implied that any system of thefamily is confluent, in the following sense: any computation of such systemwith the same input multiset always yields the same answer.

Figure 1.3: Solving a decision problem by means of cell systems

If R is a class of recognizer cell systems, we will note PMCR the set ofdecision problems that can be solved in polynomial time by families of systemsfrom R.

1.4.2 A solution to SAT by means of P systems withactive membranes

In what follows we are going to present an efficient solution tott SAT problem from the satisfiability of the propositional logic, by means offamily of recognizer P systems with active membranes.

Let us start having a look at the function f of IN × IN in IN defined byf(m,n) = (m+n)·(m+n+1)

2+ m that is a computable bijective function between

the cited sets. Usually, we will note f(m,n) = 〈m,n〉.For each m,n ∈ IN it is considered a recognizer P system with active mem-

branes Π(〈m,n〉) = (Γ,Σ, µ,M1,M2,R, iin) of degree 2, defined as follows:

• The input alphabet is Σ = xi,j, xi,j : 1 ≤ i ≤ m, 1 ≤ j ≤ n.

• The working alphabet is

Γ = Σ ∪ ck : 1 ≤ k ≤ m+ 2 ∪ dk : 1 ≤ k ≤ 3n+ 2m+ 3 ∪∪ ri,k : 0 ≤ i ≤ m, 1 ≤ k ≤ 2n ∪ e, t ∪ Y es,No


• The labels set is 1, 2.

• The initial membrane structure is µ = [ [ ]2 ]1.

• The initial multisets are M1 = ∅ and M2 = d1.

• The input membrane is the one labelled by 2.

• The set R consists of the following rules:

(a) [dk]02 → [dk]+2 [dk]

−2 : 1 ≤ k ≤ n.

(b) [xi,1 → ri,1]+2 , [ xi,1 → ri,1]−2 : 1 ≤ i ≤ m;[xi,1 → λ]−2 , [xi,1 → λ]+2 : 1 ≤ i ≤ m.

(c) [xi,j → xi,j−1]+2 , [xi,j → xi,j−1]−2 : 1 ≤ i ≤ m, 2 ≤ j ≤ n;[ xi,j → xi,j−1]+2 , [ xi,j → xi,j−1]−2 : 1 ≤ i ≤ m, 2 ≤ j ≤ n.

(d) [dk]+2 → [ ]02dk, , [dk]−2 → [ ]02dk : 1 ≤ k ≤ n;

dk[ ]02 → [dk+1]02 : 1 ≤ k ≤ n− 1.

(e) [ri,k → ri,k+1]02 : 1 ≤ i ≤ m, 1 ≤ k ≤ 2n− 1.

(f) [dk → dk+1]01 : n ≤ k ≤ 3n− 3;[d3n−2 → d3n−1e]

01.

(g) e[ ]02 → [c1]+2 ; [d3n−1 → d3n]01.

(h) [dk → dk+1]01 : 3n ≤ k ≤ 3n+ 2m+ 2.

(i) [r1,2n]+2 → [ ]−2 r1,2n.

(j) [ri,2n → ri−1,2n]−2 : 1 ≤ i ≤ m.

(k) r1,2n[ ]−2 → [r0,2n]+2 .

(l) [ck → ck+1]−2 : 1 ≤ k ≤ m.

(m) [cm+1]+2 → [ ]+2 cm+1.

(n) [cm+1 → cm+2t]01.

(o) [t ]01 → [ ]+1 t.

(p) [cm+2]+1 → [ ]−1 Y es.

(q) [d3n+2m+3]01 → [ ]+1 No.

• iin = 2; that is, the input membrane is the one labelled by 2.


Let ϕ = C1 ∧ · · · ∧ Cm be a propositional formula in normal conjunctiveform such that V ar(ϕ) = x1, . . . , xn y Ci = yi,1 ∨ · · · ∨ yi,ki , 1 ≤ i ≤ m,where yi,i′ ∈ xj,¬xj : 1 ≤ j ≤ n are the literals od ϕ. Let us consider thefunctions

cod(ϕ) =⋃mi=1xi,j : xj ∈ Ci ∪ xi,j : ¬xj ∈ Ci

s(ϕ) = 〈m,n〉 = (m+n)·(m+n+1)2

+m

The formula ϕ will be processed by the system Π(s(ϕ)) with input multisetcod(ϕ), which execution tries to implement a brute force algorithm.

The details of the proof showing that the family Π = Π(t) : t ∈ INsolves the SAT problem in polynomial time can be found at [85].

1.4.3 A solution to 3-COL by means of tissue-like Psystems with cell division

In what follows, it is presented a solution to the 3-COL problem by means of afamily of recognizer tissue-like P systems with cell division.

We will use the elements of the set R,G,B to name the three colours1, 2, 3 (R for “red”, G for “green” and B for “blue”).

For each m,n ∈ IN, the following recognizer tissue-like P system with celldivision is considered: Π(〈n,m〉) = (Γ, E ,Σ,M1,M2,R, iin) defined as follows:

• The working alphabet Γ is the set

Ai, Ri, Gi, Bi, Ti, Ri, Gi, Bi : 1 ≤ i ≤ n ∪ai : 1 ≤ i ≤ 2n+m+ dlogme+ 11 ∪ ci : 1 ≤ i ≤ 2n+ 1 ∪di : 1 ≤ i ≤ dlogme+ 1 ∪ zi : 2 ≤ i ≤ m+ dlogme+ 6 ∪Aij, Pij, P ij, Rij, Gij, Bij : 1 ≤ i < j ≤ n ∪ b,D,D, e, T, S,N, [, yes, no

• The environment alphabet is E = Γ \ (yes ∪ Σ)

• The input alphabet Σ is the set Aij : 1 ≤ i < j ≤ n

• The initial multisets contained in the cells are: M1 = a1, b, c1, yes, noy M2(n) = D,A1, . . . , An

• The set R consists of the following rules:


(a) [Ai]2 → [Ri]2[Ti]2, [Ti]2 → [Gi]2[Bi]2 : 1 ≤ i ≤ n(b) (1, ai/ai+1, 0) : 1 ≤ i ≤ 2n+m+ dlogme+ 10(c) (1, ci/c2

i+1, 0) : 1 ≤ i ≤ 2n(d) (1, c2n+1/D, 2)

(e) (2, c2n+1/d1D, 0)

(f) (2, di/d2i+1, 0) : 1 ≤ i ≤ dlogme

(g) (2, D/e z2, 0)

(h) (2, zi/zi+1, 0) : 1 ≤ i ≤ m+ dlogme+ 5(i) (2, ddlogme+1Aij/Pij, 0) : 1 ≤ i < j ≤ n(j) (2, Pij/RijP ij, 0) : 1 ≤ i < j ≤ n(k) (2, P ij/BijGij, 0) : 1 ≤ i < j ≤ n(l) (2, RiRij/RiRj, 0) : 1 ≤ i < j ≤ n

(m) (2, BiBij/BiBj, 0) : 1 ≤ i < j ≤ n(n) (2, GiGij/GiGj, 0) : 1 ≤ i < j ≤ n(o) (2, RjRj/[, 0) : 1 ≤ j ≤ n(p) (2, BjBj/[, 0) : 1 ≤ j ≤ n(q) (2, GjGj/[, 0) : 1 ≤ j ≤ n(r) (2, e [/λ, 0)

(s) (2, e zm+dlogme+6/T, 0)

(t) (2, T/λ, 1)

(u) (1, b T/S, 0)

(v) (1, S yes/λ, 0)

(x) (1, b a2n+m+dlogme+11/N, 0)

(y) (1, N no/λ, 0)

• iin = 2; that is, the input set is labelled by 2.

Let G = (V,E) be a non-directed graph with n vertices (V = 1, . . . , n)and m edges. Let us consider the functions cod(G) = Aij : i, j ∈ E ∧ 1 ≤i < j ≤ n y s(G) = 〈m,n〉. The graph G will be processed by the systemΠ(s(G)) with input cod(G).

The details of the proof showing that the family Π = Π(t) : t ∈ INsolves the 3-COL problem in polynomial time can be found at [32].


1.4.4 A solution to 3-COL by means of tissue-like Psystems with cell separation

In what follows, it is presented an efficient solution to SAT problem by meansof a family fo recognizer tissue-like P systems with separation rules.

For each m,n ∈ IN, it is considered the recognizer tissue-like P system, ofdegree 3, with cell separation and using communication rules at most of length3, Π(〈m,n〉) = (Γ,Γ1,Γ2,Σ, E ,M1,M2,M3,R, iin, iout) defined as follows:

• The input alphabet is: Σ = xi,j, xi,j : 1 ≤ i ≤ n , 1 ≤ j ≤ m.• The working alphabet is: Γ = Σ ∪ Γ1 ∪ Γ2, where:

Γ1 = Ai, Bi : 1 ≤ i ≤ n+ 1 ∪ ai, bi, Ti, Fi, yi, vi, wi : 1 ≤ i ≤ n ∪ci, ti, fi, si, zi : 1 ≤ i ≤ n− 1 ∪ Ej : 1 ≤ j ≤ m+ 1 ∪αi : 0 ≤ i ≤ 3n+ 2m+ 1 ∪ βi : 0 ≤ i ≤ 3n+ 2m+ 2 ∪qi,j, ri,j, ui,j : 1 ≤ i, j ≤ n− 1 ∪xi,j, xi,j, ei,j, ei,j : 1 ≤ i ≤ n , 1 ≤ j ≤ m ∪di,j,k, di,j,k : 1 ≤ i ≤ n , 1 ≤ j ≤ m, 1 ≤ k ≤ n ∪ q0, S, yes, no

Γ2 = A′i, B′i : 1 ≤ i ≤ n+ 1 ∪ a′i, b′i, T ′i , F ′i : 1 ≤ i ≤ n

• The environment alphabet is:

E = S ∪ Ai, Bi, A′i, B

′i : 2 ≤ i ≤ n+ 1 ∪ Ej : 1 ≤ j ≤ m+ 1 ∪

ai, a′i, bi, b′i, vi : 2 ≤ i ≤ n ∪ T ′i , ci, ti, fi, si, zi : 1 ≤ i ≤ n− 1 ∪Ti, Fi, F ′i , yi, wi : 1 ≤ i ≤ n ∪ αi : 1 ≤ i ≤ 3n+ 2m+ 1 ∪βi : 1 ≤ i ≤ 3n+ 2m+ 2 ∪ qi,j, ri,j, ui,j : 1 ≤ i, j ≤ n− 1 ∪ei,j, ei,j : 1 ≤ i ≤ n , 1 ≤ j ≤ m ∪di,j,k, di,j,k : 1 ≤ i, k ≤ n , 1 ≤ j ≤ m

• The initial multisets are:

M1 = A1B1

M2 = a1 a′1 b1 b

′1 v1 q1,1 α0 yes no

M3 = β0

• The set R of rules consists in the following:


(1) (1 , Ai / ai a′i , 2), for 1 ≤ i ≤ n, and (1 , An+1 /E1 , 2).

(2) (1 , A′i / ai a′i , 2), for 1 ≤ i ≤ n, and (1 , A′n+1 /E1 , 2).

(3) (1 , Bi / bi b′i , 2), for 1 ≤ i ≤ n.

(4) (1 , B′i / bi b′i , 2), for 1 ≤ i ≤ n.

(5) (1 , Ti / ti , 2), for 1 ≤ i ≤ n− 1.

(6) (1 , T ′i / ti , 2), for 1 ≤ i ≤ n− 1.

(7) (1 , Fi / fi , 2), for 1 ≤ i ≤ n− 1.

(8) (1 , F ′i / fi , 2), for 1 ≤ i ≤ n− 1.

(9) (1 , ti / Ti T′i , 0), for 1 ≤ i ≤ n− 1.

(10) (1 , fi /Fi F′i , 0), for 1 ≤ i ≤ n− 1.

(11) (1 , bi /Bi+1 S , 0), for 1 ≤ i ≤ n.

(12) (1 , b′i /B′i+1 , 0), for 1 ≤ i ≤ n.

(13) (1 , ai / TiAi+1 , 0), for 1 ≤ i ≤ n.

(14) (1 , a′i /F′i A′i+1 , 0), for 1 ≤ i ≤ n.

(15) (2 , Ai / ci , 0), for 1 ≤ i ≤ n−1, and (2 , Ai / λ , 0), for n ≤ i ≤ n+1.

(16) (2 , A′i / ci , 0), for 1 ≤ i ≤ n−1, and (2 , A′i / λ , 0), for n ≤ i ≤ n+1.

(17) (2 , Bi / ci , 0), for 1 ≤ i ≤ n− 1, and (2 , Bn / λ , 0).

(18) (2 , B′i / ci , 0), for 1 ≤ i ≤ n− 1, and (2 , B′n / λ , 0).

(19) (2 , ci / bi+1 b′i+1 , 0), for 1 ≤ i ≤ n− 1.

(20) (2 , vi / y2i , 0), for 1 ≤ i ≤ n.

(21) (2 , yi / ziwi , 0), for 1 ≤ i ≤ n− 1, and (2 , yn /wn , 0).

(22) (2 , zi / vi+1 , 0), for 1 ≤ i ≤ n− 1.

(23) (2 , wi / ai+1 a′i+1 , 0), for 1 ≤ i ≤ n− 1, and (2 , wn /E1 , 0).

(24) (2 , q1,1 / r1,1 , 0).


(25) (2 , qi,j / r2i,j , 0), for 1 ≤ i ≤ n− 1, 2 ≤ j ≤ n− 1.

(26) (2 , ri,j / si ui,j , 0), for 1 ≤ i, j ≤ n− 1.

(27) (2 , si / ti fi , 0), for 1 ≤ i ≤ n− 1.

(28) (2 , u1,j / q1,j+1 q2,j+1 , 0), for 1 ≤ j ≤ n− 2.

(29) (2 , ui,j / qi+1,j+1 , 0), for 2 ≤ i, j ≤ n− 2.

(30) (2 , ui,n−1 / λ , 0), for 1 ≤ i ≤ n− 1.

(31) (2 , Ti / λ , 0), for 1 ≤ i ≤ n− 1.

(32) (2 , T ′i / λ , 0), for 1 ≤ i ≤ n− 1.

(33) (2 , Fi / λ , 0), for 1 ≤ i ≤ n− 1.

(34) (2 , F ′i / λ , 0), for 1 ≤ i ≤ n− 1.

(35) [S ]1 −→ [ Γ1 ]1 [ Γ2 ]1

(36) (2 , αi / αi+1 , 0), for 0 ≤ i ≤ 3n+ 2m.

(37) (3 , βi / βi+1 , 0), for 0 ≤ i ≤ 3n+ 2m+ 1.

(38) (3 , xi,j / d2i,j,1 , 0), (3 , xi,j / d

2i,j,1 , 0), for 1 ≤ i ≤ n, 1 ≤ j ≤ m

(39) (3 , di,j,k / d2i,j,k+1 , 0), (3 , di,j,k / d

2i,j,k+1 , 0), for 1 ≤ i ≤ n, 1 ≤ j ≤

m, 1 ≤ k ≤ n− 1.

(40) (3 , di,j,n / ei,j, 0), (3 , di,j,n / ei,j , 0), for 1 ≤ i ≤ n, 1 ≤ j ≤ m.

(41) (1 , TiEj / ei,j , 3), (1 , FiEj / ei,j , 3), (1 , T ′iEj / ei,j , 3), (1 , F ′iEj / ei,j , 3),for 1 ≤ i ≤ n, 1 ≤ j ≤ m.

(42) (1 , ei,j / TiEj+1 , 0), (1 , ei,j /FiEj+1 , 0), for 1 ≤ i ≤ n, 1 ≤ j ≤m− 1.

(43) (1 , ei,m /Em+1 , 0), (1 , ei,m /Em+1 , 0), for 1 ≤ i ≤ n.

(44) (3, Ti / λ , 0), (3 , Fi / λ , 0), (3 , T ′i / λ , 0), (3 , F ′i / λ , 0), for 1 ≤i ≤ n.

(45) (3 , Ej / λ , 0), for 1 ≤ j ≤ m.

1.5. P systems simulators 33

(46) (1 , Em+1 / yes α3n+1+2m , 2).

(47) (1 , yes / β3n+1+2m+1 , 3).

(48) (2 , α3n+1+2m / β3n+1+2m+1 , 3).

(49) (2 , no β3n+1+2m+1 / λ , 0).

(50) (3 , yes / λ , 0).

• The input cell is iin = 3.

• The output region is the environment, iout = 0.

Let ϕ = C1 ∧ · · · ∧ Cm be a propositional formula in normal conjunctionform V ar(ϕ) = x1, . . . , xn and Ci = yi,1 ∨ · · · ∨ yi,ki , 1 ≤ i ≤ m, whereyi,i′ ∈ xj,¬xj : 1 ≤ j ≤ n are the literals of ϕ. Let us consider the functions

cod(ϕ) =⋃mi=1xi,j : xj ∈ Ci ∪ xi,j : ¬xj ∈ Ci

s(ϕ) = 〈m,n〉 = (m+n)·(m+n+1)2

+m

The formula ϕ will be processed by the system Π(s(ϕ)) with input multisetcod(ϕ).

To analyse the details of the proof of that the family Π = Π(t) : t ∈ INsolves the problem SAT in polynomial time, see [86].

1.5 P systems simulators

An implementation of a computational model consist in the design of a realmachine that exactly reproduces the computations taking place in such model;in particular, each computation step taken in the model requires one time unitexecution in the implemented machine. We will use the term simulator of acomputational model to refer to a software and/or hardware application thatdescribes the syntax specification of such model and materialize the semanticsby means of an algorithm susceptible of being implemented in a real machine.

In the last years many software and hardware applications has been pre-sented for Membrane Computing, which has supposed a great step forwardin the development of simulators [30]. The majority of them shows a typicalsoftware architecture, including three main modules: input (the definition of


the cell system model), kernel (the simulator engine), and output (to presentresults).

Figure 1.4: Common elements in P systems simulators

In what respect to the kernel, it is supposed that the input system isconsistent with a given model. The kernel then proceeds to the execution of adetermined algorithm to provide one or many computations of the simulatedcell system, reproducing, step by step, one of the possible computations.

1.5.1 The P-Lingua software project

P-Lingua [91, 83] is a language for describing and defining P systems allowingto standardize definition of the simulator input, in order to assure that thesimulators always process the same format. The P-Lingua project providessoftware tools under the GNU GPL standard [2], to compile, simulate anddebug, which are integrated in a Java library called pLinguaCore.

There exists the possibility of exporting P-Lingua definition files to other(error-free) formats with the aim of providing interoperability between thedifferent software simulation environments. It is advisable to highlight thatP-Lingua is an standard format to define P systems that can be translated toother formats syntactically error-free. On the other hand, the development ofsimulators in pLinguaCore is a relatively easy process and, at the same time,allows implementing new simulation algorithms. Finally, the same P-Linguainput file can be used for the developed simulators as well as for pLinguaCoresimulators.


1.5.2 P systems simulation platforms

A good computation platform to simulate P systems should provide a goodbalance between performance, flexibility, scalability, parallelism and cost [49].

• Performance: it refers to the speed in which the platform is able tosimulate P systems. A good measure to assure it can be the number ofrule applications executed by time unit.

• Flexibility : it signifies the capability of the platform to support the exe-cution of a wide range of P systems. A great degree of flexibility impliessupporting a great diversity of P systems.

• Scalability : it refers to the ability of the platform to simulate P sys-tems with growing size without a negative impact on its functionality orperformance.

It is difficult to assure that any computing platform complies with the threeaforementioned attributes.

In fact, there exists two principal connections between them [75]: flexibilityvs performance and flexibility vs scalability.

1.5.3 Parallel simulation of P systems

This section covers a general overview of P systems parallel simulator devel-oped to date.

• Cluster-based simulators (a set of computers interconnected in a localnetwork [90]):

– Ciobanu and Guo simulator [24]: It simulates a restricted set oftransition P systems using a linux-based cluster, C++ and the MPIlibrary.

– Fernandez et al. simulator [109]: it brings some improvements withrespect to the Ciobanu and Guo simulator in order to partially solvethe problem of the communication process.

– Syropoulos et al. simulator [108]: this simulator works in Java anduses theRMI (Remote Method Invocation) to distribute work.


– Diez Dolinski et al. simulator [35]: it provides a highly scalablesolution to the problem of the exponential space growth created byP systems. It uses the algorithms MapReduce on the distributedenvironments while P-Lingua is extended (distributed P-Lingua) todefine the corresponding inputs.

• FPGA based simulators (reconfigurable chips that the designer has toprogram[68]):

– Petreska and Teuscher simulator[87]: the first FPGAs based sim-ulator that offers total support for transition P systems with celldivision rules. Implemented on VHDL.

– Fernandez et al. simulator in FPGA [38]: it presents the design ofa circuit that can be implemented on FPGAs to select active rulesin a transition P system.

– Nguyen et al. simulator [76, 75, 77]: it consists in an evolution inthe simulation of P systems by means of FPGAs. Its hardware sys-tem, named Reconfig-P, along with P-Builder, provides an elegantapproximation to the balance between performance, flexibility andscalability.

• Micro-controller based simulators (an integrated circuit containing pro-cessor, memory and input/output units):

– Gutierrez et al. simulator [50, 49]: it tries to balance flexibilityand performance at low cost. It uses the PIC (Peripheral InterfaceController) as solution and algorithms and architectures have beendesigned to improve communication [109, 15, 49].

• GPUs based simulator (graphic cards processors, that can be used asspecial highly parallel multiprocessors [78], and programmed with pro-gramming models like CUDA [63, 5] and OpenCL [74, 6]):

– PMCGPU : consists in a series of sub-projects aiming to simulatedifferent variants of P systems:

∗ PCUDA: The first simulator for P systems based onCUDA, consisting in a flexible platform for simulation, but witha compromise with performance and scalability.

∗ PCUDASAT : a PCUDA project branch centred on the efficientsimulation of a family of P systems with active membranessolving SAT.


∗ TSPCUDASAT : a variant of PCUDASAT, dealing with a fam-ily of tissue-like P systems with cell division solving SAT.

∗ ABCD-GPU : it is a recent project involving the simulation ofPDP, that will be described in the Section 3.2.2. It includessimulators based on C++, and multi-core processors platforms(with OpenMP [7]) and GPU (with CUDA).

– Neural P systems with spikes simulation: the first simulator weredeveloped by Cabarle et al. [16, 17]. The implemented algorithmuses a matrix-based representation Zeng et al. [115].

– Simulation of evolution-communication P systems with energy andwithout antiport rules : the initial work was developed by Juayonget al. [61]. The simulator uses a matrix-based representation, wherethe semantics of the model is represented.

– Simulation of enzymatic and numerical P systems : this work isdeveloped by Garcıa-Quismondo et al. [41]. The simulated modelsare used to model robot controllers with possible interesting resultfor Artificial Intelligence.

– Simulators for image processing solutions with tissue-like P systems :Dıaz-Pernil et al [82] they present a new work in the simulation oftissue-like P systems models, but specifically with respect to imageprocessing algorithms (for instance image smoothing).

2Models in real life

In this chapter we deal with the existing general issue when studying complexdynamic systems (phenomena, entities, processes or organisms) appearing inthe real world and that can be of interest for different reasons. We are goingto use a method called modeling consisting in representing the system understudy in a framework (graphical, informal, mathematical, etc.) in order toobtain further information and, if possible, to increase the knowledge aboutit, allowing the formulation of predictive hypothesis in different scenarios.

This chapter is structured as follows. The first section is devoted to justifythe need for using models representing complex dynamic systems.

In the second section some approximations for designing mathematicalmodels are briefly described.

The section 2.3 is devoted to present two kind of algorithms that succinctlydescribe the semantics associated to some computational models and that cap-ture the inherent randomness to the process taking place in nature.

2.1 The need for model designing

In a sense it can be affirmed that the try for miniaturizing some parts of theworld has been an everlasting dream for humanity.

39

Chapter 2. Models in real life 40

In an informal way, a model of a given complex system is a concrete, ab-stract, conceptual, graphical or formal representation, that allows studying,analyzing, describing, explaining and reasoning about such system.

Thanks to a model, we can obtain a simplified image of reality that, con-sequently, will never be can contain all the details of the real system thatdescribes and represents.

There exist a “balance” problem when designing a model since, on the onehand, the model has to incorporate the essential or relevant features of thesystem in the context of the problem that we are trying to solve. On the otherhand, models have to be rich enough in order to provide behaviors that canbe surprising, interesting, helpful and significant.

Using models is intrinsic to any scientific activity and is basic when tack-ling some real-life problems where, besides, the existence of many interactionsbetween other factors operating simultaneously is well-known. Scientists reg-ularly use reality abstractions or simplifications such that diagrams, graphs,laws, relations, etc. in order to better understand some concrete aspects thatthey study, analyze and examine. The development of models usually requiresa multidisciplinary approximation. In this context, Mathematics and Com-puter Science have been used by experts simply as auxiliary tools to the betterquantitative development of these experiments.

The achievements during the past century in Cellular and Molecular Bi-ology, Ecology and Population Dynamics in general, Economics, as well asof course in Computer Science, both from a theoretical and practical pointsof view, have provided the convergence of such disciplines through the use offormal models, with the aim to obtain significant achievements in science.

2.2 Formal models

A formal model is an abstraction of a concrete aspect of the world within amathematical framework trying to highlight some relevant aspects of a systemunder study by means of formal theories.

The formal modeling process consists of some semi-formal stages that guideus in the design task, in the description within a formal language, as well as itsimplementation for the evaluation and analysis. Such process can be structuredas follows:

• Identification and delimitation of the process under study.

2.2. Formal models 41

The first step consists in setting the specific part of the system that canbe modeled detailing the more relevant aspects, the concrete goals thatwe want to achieve, as well as the validation and analysis processes toconsider.

• Formal definition and formulation.

Following this, it is required to specify or translate in the context of aformal theory, the informal description of the components of the systemunder study, as well as the goals and the matters to deal with.

• Implementation or computational simulation.

Besides, it is required to detail how to implement, or in its case, numer-ically approximate or simulate the model by using electronic computers,in order to manipulate and extract reliable information.

• Validation and calibration.

Before performing simulations it will be necessary to calibrate our model,by using a method of parameters estimation and performing a sensitivityanalysis to determine which parameters are really crucial in the model.The calibration process has to be followed by validation process con-trasting the simulation results of the model with reliable data obtainedexperimentally.

• Analysis and checking.

There exist different analysis methods in relation to the formal designedmodels that go from a simple simulation generation in an electronic com-puter to complex statistical analysis, using also model checking tech-niques.

In a formal model of a complex system a we can differentiate some basiccomponents or elements: state variables,control functions or external variables,mathematics expressions, parameters and universal constants if applicable.

It seems clear that in order to avoid creating an unnecessarily complexmodel we have to restrict “as much as it takes” the number of basic compo-nents.


2.3 Computational modeling

It is widely accepted ([97]) that a good model has to satisfy the followingfour properties: relevancy, understandability , extensibility and mathematical-computational tractability.

• A model has to be relevant, in the sense of capturing the basic proper-ties of the phenomena under study, in relation to its structure and itsdynamics.

• A model has to provide a better understandability of the system understudy.

• A model has to be easily extensible and scalable to other levels of or-ganization and easily changeable in order to include new knowledge orremove false hypothesis.

• A model has to be computationally tractable, in the sense that we haveto be able to implement it in order to execute simulations allowing us tostudy the system dynamics in different scenarios.

Models are essential to further and better understand complex systemswhere the direct calculations could take years or even centuries to complete.Models are applicable to micro (for instance molecular chemical reactions,protein signaling pathways, gene expression regulation, etc.) as well as tomacro level (ecosystems, galaxies, etc.).

Similarly to the fact that the interaction between theory and experimenta-tion is the driving force of science, we can affirm that, nowadays, computationalmodeling and simulation are in the core itself of the scientific method that wecould label as modern.

There exist several approaches of the complex systems modeling process.

1. In relation with the scaling in space, we can distinguish between macro-scopic, microscopic and mesoscopic approaches. With respect to the firstone, the system is studied as a whole. With respect to the microscopicapproach, each part of the system is represented with high detail. Themesoscopic approach in centered on the number of individual compo-nents and only takes into account those part of the system consideredparticularly relevant.

2.4. Different approaches to formal models 43

2. Depending of the kind of analysis conducted, a formal model can bequantitative or qualitative. In the same way, according to the kind ofgenerated quantitative data as well as to the specific character of thesystem, a model can be discrete or continuous.

3. With respect to its dynamics or evolution, models can be classified indeterministic and non-deterministic. In the first case, there exists onlyone possible evolution of the model, given an initial situation or param-eters, while in the second one, the exist many possible evolutions of themodel from some given initial parameters.

4. Finally, in relation with the origin of the information used to its design,a formal model can be empirical or heuristic. The first one is constructedfrom direct observations o experimental results, while the second one isdesigned by means of known mechanisms of system under study.

2.4 Different approaches to formal models

In this section we are going to review the different formal modeling frameworksfor complex system in the real world.

Ordinary or partial differential equations (ODEs/PDEs) conformed the firstframework for such modeling. Nevertheless, this approach tended to be ques-tionable in some situations; for instance in cell systems with low number ofmolecules, in slow reactions or in non-homogeneous structures[11, 45].

The complexity of biological processes and population dynamics make nec-essary to use electronic computers to unveil the underlying mechanisms andfunctionalities to such processes and populations. In the past two decades,new well-based formalisms have been proposed to design computational mod-els. In this section we briefly present the most extended computational ap-proaches: agent based systems[53], Petri nets[46], and the processes algebra(π-calculus[97]).

2.4.1 Models based on ODEs/PDEs

Nowadays, systems based on ordinary or partial differential equations (ODEs/PDEs) represent the most widely used approach to model molecular mecha-nisms, cellular functions, population dynamics, in general, and real ecosystems


in particular.

But, it is advisable to highlight the existence of important constraints whenusing ODEs/PDEs as modeling framework; for instance, in the cell systemscase, ODEs/PDEs based models rely on the following basic hypothesis:

• Cells have homogenous volumes and concentrations does not change withrespect to space.

• Chemical concentrations vary continuously along time in a deterministicway.

These conditions do not verify in, for instance, cell systems with smallnumber of molecules or subjected to slow reactions, or in systems made oforganized structures in different compartments. Concretely, ODEs systemshave been widely used to model kinetics of macroscopic chemical reactionswhich goal is the analysis of the average evolution of the concentration ofchemical substances along the whole system.

2.4.2 Agent based approach

Agent based modeling takes each individual component of the system as asimple entity (an agent) that has associated a given set of rules that specifiesits behavior in the system. Agents can represent any component of the systemand have the ability of interact with the environment and other neighbors,according to existing protocols. In this way it is obtained an extensible andmodular modeling framework.

A biochemical model based on agents does not have the constraints presentin ODEs/PDEs based models since any number and distribution of moleculescan be modeled. In the last decade, agents based models have applied tothe study and analysis of different biological systems: insect communities (M.Holcombe et al., 2003 [53], M. Gheorghe et al., 2003 [44], D. Jackson et al.,2004 [59], [58]), epithelial tissue (D. Walker et al., 2004 [112]), signaling path-ways (M. Pogson et al., 2006 [89]), tumor cells migration (L. Dib et al., 2005[34]), etc. The Computational Systems Biology Group of the Computer ScienceDepartment of the University Sheffield (U.K.) has pioneered in this field.

2.4. Different approaches to formal models 45

2.4.3 Petri nets

A biochemical system and a population of individuals can be representedthrough a system of discrete events whose properties may result useful forgetting conclusions regarding the behavior of the structure of the system,aswell as the original population [95].

Petri nets [?] constitute a computational tool for modeling and analysis ofdiscrete events systems with a concurrent behavior. A Petri net consists on agraph formed by two types of nodes called places and transitions, respectively.Places are connected to transitions, and transitions are connected to placesthrough directed arcs with an associated weight.

Recently, the modeling framework of Petri nets has been applied to differ-ent fields of System Engineering and Computer Science. The specific variantplace-transition net (PT-net) has been used to model systems of molecularinteractions [46, 95].

2.4.4 Process algebra, π-calculus

π-calculus was first introduced by R. Milner, J. Parrow and D. Walker as aformal language for describing mobile processes communicating through cer-tain channels [71]. It is considered as a model for systems that interacts andhave a dynamic topology of communication. π-calculus permit the channels topass through others, thus increasing their expressive power. The semantics ofπ-calculus is based on a tractable algebraic theory. The evolution of a processis described in π-calculus by means of a reduction relation between processescontaining those transitionsthat can be inferred from a set of rules.

Different variants have been used to model molecular interactions [96], genenetworks and to integrate molecular and gene networks [88]. Over the last yearsdifferent tries have been produced to establish bridges between π-calculus andP systems.

The same way that in ordinary Petri nets, this new framework is only qual-itative. Therefore, in order to introduce qualitative information, a constantis associated to each communication channel, and then the waiting time toperform a communication is determined by an exponential distribution whoseparameter is calculated using the cited constant and the number of processestrying to communicate through that channel.


2.5 Stochastic versus probabilistic models

The inherent randomness of biological process and population dynamics, ingeneral, is captured in computational models through the use of stochasticstrategies based on Gillespie algorithm, or of probabilistic strategies by ad hocsimulation algorithms.

2.5.1 Stochastic models

Continuous deterministic descriptions are only sound in certain situations. Ata microscopical level, cellular processes follo the n-square law: the level offluctuation of a system is inversely proportional to the square root of thenumber of individuals involved on it.

Let us suppose the system under study occupy a fixed constant volume,V , and is composed of molecules of n types or species s1, . . . , sn such asthey interact to each other by a series of chemical reactions r1, . . . , rq. Theinstantaneous description of a system can be described in an instant t bya vector X(t) = (X1(t), . . . , Xn(t)), where Xi(t) represents the number ofmolecules of species i in that instant. The aim is to study the evolution of thevector X(t) from a known initial state X(t0).

Each molecular interaction rj is characterized by a state change vectorvj = (v1j, . . . , vnj) and a propensity constant pj(X(t)) associated to each statein a certain instant. Components vij(1 ≤ i ≤ j) represent the change producedin species si due to the application of reaction rj. Thus, if in a certain instantthe state of the system is X(t) and a rule rj is executed, then the new statewill be X(t) + vj.

The propensity pj(X(t)) of rj in an instant t verifies that pj(X(t))dt is theprobability for an interaction of type rj to take place in time interval [t, t+dt).To calculate the propensity pj(X(t)), the process starts from a kinetic con-stant kj used in the conventional kinetic theory usually being experimentallycalculated; from this constant, a stochastic constant cj is calculated, and thispermits getting the propensity, through a process based on the law of massaction. This approach is usually called mesoscopic modeling.

Gillespie algorithm is being successfully used to explore the state spaceassociated to a system of differential equations (Chemical Master Equation,CME). Instead of analytically solving the CME, the trajectories of X(t) aregenerated using a Monte Carlo algorithm for the stochastic simulation of molec-

2.5. Stochastic versus probabilistic models 47

ular interactions taking place in a certain volume [45]. Gillespie algorithm hasbeen used in the implementation of stochastic π-calculus [88, 10], as well as inthe application to the modeling of biological processes [92].

Let us suppose that in a bounded medium m (with a certain volume) thereexist chemicals subject to a set of chemical reactions r1, . . . , rq, from which weknow h1, . . . , hq (number of possible combinations of reactants), and k1, . . . , kq(kinetic constants of the reactions). Gillespie algorithm permits selecting thechemical reaction to be executed and its corresponding waiting time to executethat reaction.

Input: An homogeneous volume m containing chemicals subject to q chemical

reactions r1, . . . , rq.

1. Calculate a0 =

q∑j=1

pj, with pj = hj · kj lthe propensities of the rules.

2. Generate two random numbers b1 and b2 uniformly distributed over

the unit interval (0, 1).

3. Choose the index j0, of the next chemical reaction, verifying:

j0−1∑k=1

pk < b1 · a0 ≤j0∑

k=1

pk.

4. Calculate the waiting time of the next reaction: τrj0 =1

a0ln(

1

b2).

Output: the pair (rj0 , τrj0 ) composed of the chemical reaction to execute and

the waiting time consuming its execution.

2.5.2 Probabilistic models

In the syntactic specification of a computational model of probabilistic typea probabilistic function whose variable depends on time is usually assigned tocertain basic elements controlling the dynamics of the system.

The numeric values associated to those elements in the model in a certaininstant represents the probability for each one of them to be used to makethe system evolve in that moment according to that element. Those functionsare experimentally obtained; otherwise, they are estimated by a calibrationprocess. After that, an ad hoc algorithm is designed to describe the seman-tics of the computational model in which the work is being developed. This


semantics must incorporate the treatment of the random nature materializedby probabilistic constants or functions.

The simulation algorithm must be experimentally validated by contrastingthe values produced by the algorithm with those data that were obtained bymeans of experiments or field work. Obviously, this contrast must be performedsimulating the algorithm under the specific scenarios in which the data wereobtained. To do so, it is necessary for the algorithm to be efficient enough tobe able to be executed in a reasonable time, for the different scenarios underinterest. In next chapter two probabilistic simulation algorithms for P systemswill be described.

3Computational modeling based on

Membrane Computing

In the past years, the Membrane Computing discipline is being used as a formalframework for the computational modeling of phenomena and complex systemsin real life, ranging from “micro level” (molecular, cellular, etc) to “macrolevel” (population dynamics, real ecosystems, etc).

The present chapter introduces a uniform formal framework that allows todescribe and represent complex systems of various kinds by means of computa-tional models withing Membrane Computing. It is important to recall that inorder to carry out analysis and make predictions on the systems under study, itis necessary to rely on software tools/applications/platforms which implementor simulate the above mentioned formal models. In this way, handling thecomputational models is an easy task thanks to software programs running onconventional computers.

The chapter is structured in three sections. The first one introduces aformal framework for modelization based on Membrane Computing, namelymultienvironment P systems. The second section is devoted to two approachesraising from this general framework: a stochastic approach (multicompart-mental P systems), and a probabilistic approach (population dynamics

49

Chapter 3. Computational modeling based on Membrane Computing 50

P systems, PDP systems). The last section describes simulation algorithmswhich try to capture the semantics of the computational models with the pre-vious two approaches. More precisely, multicompartmental Gillespie algorithm(stochastic approach) and DNDP (Direct Non-Deterministic distribution withProbabilities) together with DCBA (Direct distribution based on ConsistentBlocks Algorithm) for the probabilistic approach1.

3.1 Multienvironment P systems

Definition 3.1. A multienvironment P system of degree (q,m, n) (q,m, n ≥ 1)and with T ≥ 1 time units is a tuple

(G,Γ,Σ, µ, T,Π1, . . . ,Πn,R, E1, . . . , Em,RE)

where:

• G = (V, S) is a directed graph. Let V = e1, . . . , em.

• Γ and Σ are alphabets such that Σ $ Γ.

• µ is a rooted tree with q nodes (called membranes) injectively labelled byelements from the set 1, . . . , q × 0,+,−. If the label of a membraneis (i, α), then such a membrane will be denoted as [ ]αi and we will saythat the membrane has label i and electrical charge α. The root of thetree has 1 as associated label.

• T is a natural number.

• For each k, 1 ≤ k ≤ n, Πk = (Γ, µ,M1,k, . . . ,Mq,k,R) are P systems ofdegree q such that: (a) all of them have the same membrane structureµ; (b) M1,k, . . . ,Mq,k are finite multisets over Γ (initial multisets); and

(c) R is a finite set of rules of the form r ≡ u[v]αifr−−−→u′[v′]α

′i , where

u, v, u′, v′ ∈ Mf (Γ), u + v 6= ∅, 1 ≤ i ≤ q and α, α′ ∈ 0,+,−. Eachrule r from the P system has an associated computable function fr whosedomain is 1, . . . , T.

• E1, . . . , Em are finite multisets over Σ.

1Only DCBA will be included in this document, see the full version of the thesis fordetails on DNDP.

3.1. Multienvironment P systems 51

• RE is a finite set of rules of the form

(x)ejpr−−−→(y1)ej1 · · · (yh)ejh y (Πk)ej

pr′−−−→ (Πk)ej′

where x, y1, . . . , yh ∈ Σ, (ej, ejl) ∈ S, 1 ≤ l ≤ h, (ej, ej′) ∈ S, 1 ≤ j, j′ ≤m, 1 ≤ k ≤ n and pr, pr′ are computable functions whose domain is1, . . . , T. Moreover:

– If (x)ejpr−−−→(y1)ej1 · · · (yh)ejh is a rule in RE, then there cannot

exist any rule in R whose left-hand side is of the form u[v]α1 withx ∈ u.

A multienvironment P system of degree (q,m, n) and with T time units canbe seen as a set of m environments e1, . . . , em linked by arcs from a directedgraph G and a set of n P systems, Πk, having the same “skeleton” (the sameworking alphabet Γ, the same membrane structure µ, and the same rules).

Each environment ej initially contains a finite multiset Ej of objects fromΣ (which will be referred to as environment objects from ej). Besides, eachsystem Πk must be included within some environment ej. If a system Πk islocated within an environment ej, then its initial multisets M1,k, . . . ,Mq,k

depend on the environment where it resides. Finally, all membranes in any ofthe P systems initially have neutral charge.

Multienvironment P system allow rules of two types: on one hand rulesassociated with the P systems contained in the environments, whose set isdenoted by R; and on the other hand rules for communicating objects amongenvironments, as well as for P systems traveling from an environment to aneighbour one, and this set is denoted by RE. Therefore, the whole set ofrules in the multienvironment P system is

⋃nj=1RΠj

∪ RE. All rules havecomputable functions associated with them (fr, pr, or pr′ , see Definition 3.1),and those functions depend on the environment where the rule is located.These functions can be interpreted as an indication of the affinity of each rule,to be taken into account when several applicable rules compete for the availableobjects.

The natural number T stands for the simulation time.

The semantics of multienvironment P systems is defined as a parallel, nondeterministic, synchronized mode, in the sense that we assume that a globalclock exists, marking the time steps of the system evolution. Let us describenext the semantics of multienvironment P systems.


An instantaneous description or configuration of the system at a giveninstant t is a tuple composed by: (a) the multisets of objects over Σ present inthe m environments; (b) the P systems included on each environment; (c) themultisets of objects over Γ contained on each of the regions of such P systems;and (d) the polarizations of the membranes from each P system.

A rule r ∈ R of the type u[ v ]αifr−−−→u′[ v′ ]α

′i asociated to a system Πk

is applicable to a configuration C at a given instant t if the membrane fromΠk labelled by i has electrical charge α in this configuration, and moreover itcontains the multiset v, and its parent membrane (or the environment, in case iis the root of the tree) contains multiset u. The execution of the rule producesthe following effects: (a) multisets v and u are deleted from membrane i andits parent region, respectively; (b) at the same time, multiset u′ is added tothe parent membrane of i and multiset v′ is added to membrane i; and (c)the new electrical charge of membrane i will now be α′ (which might be thesame as α). It is interesting to note that when applying a given set of rulesto a given membrane, all of the rules must have the same electrical charge ontheir right-hand side; that is, all rules applied simultaneously in one step onthe same membrane should be consistent. The value of function fr at a giveninstant t indicates the affinity which the rule has.

A rule r ∈ RE of the type (x)ejpr−−−→(y1)ej1 . . . (yh)ejh is applicable to a

configuration C of the system at a given instant t if the environment ej con-tains object x in this configuration.The execution of such rule produces thefollowing effects: (a) the object x is eliminated from environment ej; and (b)environments ej1 , . . . , ejh get new objects y1, . . . , yh respectively. Note thatat any instant t, 1 ≤ t ≤ T , for each object x in environment ej, if thereexist communication rules of type (x)ej

pr−−−→(y1)ej1 . . . (yh)ejh , then some ofthem will be applied. In case several of such rules exist having (x)ej as theirleft-hand side, then the rules will be applied according to their correspondingprobabilities associated to this particular instant t. A rule r ∈ RE of type

(Πk)ejpr′−−−→ (Πk)ej′ is applicable in environment ej if this environment con-

tains P system Πk. The execution of such rule makes the system Πk movefrom environment ej into environment ej′ .

From these notions, one can define in a natural way what means that themultienvironment P system goes from a configuration C at a given instantto another configuration C ′ in the next instant, by means of the execution ofa maximal multiset of rules following the previous indications. In this way, acomputation step is obtained; that is, a transition from a configuration to a nextconfiguration of the system. Thus, the concept of computation is introduced

3.2. Types of multienvironment P systems 53

in a natural way, as a sequence of configurations as it was defined in section 2of the first chapter.

3.2 Types of multienvironment P systems

We can highlight two main types of multienvironment P systems, which cor-respond to different frameworks of computational modeling: systems havinga stochastic orientation, called multicompartmental P systems, and those hav-ing a probabilistic orientation, called Population dynamics P systems. Wewill next describe the specific syntax of each one, as well as some simulationalgorithms which allow us to implement the corresponding semantics.

3.2.1 Multicompartmental P systems

Multicompartmental P systems constitute a variant of multienvironment P sys-tems which provides a framework for modelization of processes related withmolecular and cellular mechanisms. In these systems, each environment con-tains a certain number of P systems which are randomly distributed at thebeginning of the computation. besides, on each environment, the P systemsresiding there will get specific initial multisets associated with this environ-ment.

In these systems, the inherent randomness of molecular and cellular pro-cesses is captured by using a semantics designed for rewriting rules that mayor may not be applicable at a given instant, and they also get an associatedpropensity.

Definition 3.2. A multicompartmental P system of degree (q,m, n)(q,m, n ≥ 1) having T ≥ 1 time units is a multienvironment P system ofdegree (q,m, n) and with T time units

(G,Γ,Σ, µ, T,Π1, . . . ,Πn,R, E1, . . . , Em,RE)

which fulfills the following conditions:

• The computable functions associated to the rules of the environment andthe rules of the P systems are the propensities of such rules. Thesefunctions are determined from the values of stochastic constants, by ap-plying the mass action law. The stochastic constants associated to each


rule are calculated, on their turn, from the values of kinetic constantswhich have been experimentally calculated. The propensities are func-tions which depend on time, but on the other hand, they do not dependon the environment ej where the corresponding P system currently is.

• At the initial instant, the n P systems are randomly distributed amongthe m environments of the system.

• For every rule of type (x)ejpr−−−→(y1)ej1 · · · (yh)ejh , we have h = 1; that

is, an object x can just move from an environment to another one, pos-sibly getting transformed into another object y1.

A multicompartmental P system can be graphically described as follows

e1 e2

e3 e4

The semantics of a multicompartmental P system can be simulated througha multicompartmental Gillespie algorithm, which will be introduced in nextsection.

3.2.2 Population Dynamics P Systems

The Population Dynamics P Systems constitute a variant of multienvironmentP systems which provides a framework for modelization of processes related topopulation dynamics, in general. The inherent randomness of such processesis captured by means of a semantics designed for rewriting rules that mayor may not be applicable at a given instant, and they also get an associatedprobability. In these systems, each environment contains a single P system,

3.2. Types of multienvironment P systems 55

and the initial multisets of their membranes are specific for each environment.Moreover, each rule will have a probability function associated with it whichwill also depend on the environment.

Definition 3.3. A Population Dynamics P System (PDP system) of degree(q,m), where (q,m ≥ 1) and having T ≥ 1 time units is a multienvironmentP system of degree (q,m,m) and with T time units

(G,Γ,Σ, µ, T,Π1, . . . ,Πm,R, E1, . . . , Em,RE)

satisfying the following conditions:

• At the initial instant, each environment ej contains exactly one P system,which will be denoted by Πj. Therefore, the number of P systems matchesthe number of environments.

e1 e2

e3 e4

• Functions pr associated to rules from RE of the type

(x)ejpr−−−→(y1)ej1 · · · (yh)ejh

have their range included in [0, 1] and they verify:

– For each ej ∈ V and x ∈ Σ, the sum of the functions associated torules of the above type is the constant function 1.

• Functions pr′ associated to rules fromRE of the type (Πk)ejpr′−−−→ (Πk)ej′

are all constant and equal to 0; that is, one may as well assume thatthis type of rule is forbidden, or equivalently, P systems residing in anenvironment cannot travel to any other environment.


• For each rule r ∈ R of the system Πj located in ej, 1 ≤ j ≤ m, thecomputable function fr also depends on the environment (thus, it will bedenoted as fr,j) and its range is contained within [0, 1]. Moreover, foreach u, v ∈ Mf (Γ), 1 ≤ i ≤ q and α, α′ ∈ 0,+,−, the sum of thefunctions fr,j with r ≡ u[v]αi → u′[v′]α

′i , is the constant function 1.

The semantics of a population dynamics P system can be simulated bymeans of DNDP algorithm (Direct Non-Deterministic distribution with Proba-bilities) or by DCBA algorithm (Direct distribution based on Consistent BlocksAlgorithm).

3.3 Simulation algorithms for multienvironment

P systems

In this section we present algorithms capturing the semantics of the previouslydefined models.

3.3.1 A simulation algorithm for multicompartmental Psystems

In [98], the authors have developed an extension of the Gillespie’s algorithm,(called multicompartmental Gillespie’s algorithm). The pseudocode of suchalgorithm is the following:

Input: A multicompartmental P system Π with simulation time T

• Initialization

Set simulation time to t = 0.

For each compartment i in Π apply the classical Gillespie’s algorithm

which will return a tuple (rji , τrji , i), formed by the pair obtained as

output of the algorithm, (rji , τrji ), together with the label of the compartment.

Build a list formed by all the tuples obtained in the previous step.

Sort the list of tuples (rji , τrji , i) with respect to the waiting time

τ (in increasing order), providing a pile of rules to be applied;

• Iteration

Pick the first tuple of the pile, (rji0 , τrji0, i0).

3.3. Simulation algorithms for multienvironment P systems 57

Set simulation time to t = t+ τji0.

Update the waiting time for the rest of the tuples, by subtracting

the value τji0.

Apply once the rule rji0 into compartment i0, modifying the number of

objects in the involved compartments.

For each compartment i′ affected by the application of rule rji0: (a)

eliminate the corresponding tuple (rji′ , τrji′, i′) from the pile; and

(b) execute again classical Gillespie’s algorithm in the new context,

obtaining a new tuple (rj′i′, τrj′

i′, i′).

Add the tuple (rj′i′, τrj′

i′, i′) to the list and sort it again with respect

to the waiting time, obtaining an updated pile.

Iterate the process.

• Finalization

If simulation time t reaches or exceeds from a maximal time initially

set, then terminate the process.

Output: The configuration of the system Π at instant T

The process is initialized by executing classical Gillespie’s algorithm oneach one of the compartments (membranes/environments) of the system. Inthis way, a list of 3-tuples (rule, waiting time, compartment) is obtained, onefor each compartment, which will be sorted with respect to the waiting time,and then the tuple having the least waiting time will be selected. Such selectedrule will be applied on its compartment, possibly affecting the adjacent ones(if objects are communicated). Then, the Gillespie’s algorithm is executedagain for all affected compartments, so that updated tuples can be obtainedfor them. This process is iterated until reaching a prefixed bound for thesimulation time.

3.3.2 A simulation algorithm for population dynamicsP systems

Let us first introduce some previous concepts which will be used in the de-scription of the algorithm. These concepts refer to an arbitrary PDP system ofdegree (q,m) with T time units (G,Γ,Σ, µ, T,Π1, . . . ,Πn,R, E1, . . . , Em,RE)

Definition 3.4. The left-hand side of the rules is defined as follows:


(a) Given a rule r ∈ R of the form u[v]αi → u′[v′]α′i where 1 ≤ i ≤ q, α, α′ ∈

0,+,− and u, v, u′, v′ ∈Mf (Γ):

• The left-hand side of r is LHS(r) = (i, α, u, v). The charge ofLHS(r) is charge(LHS(r)) = α.

• The right-hand side of r is RHS(r) = (i, α′, u′, v′). The charge ofRHS(r) is charge(RHS(r)) = α′.

The charge of LHS(r) is the second component of the tuple (analogouslyfor RHS(r)).

(b) Given a rule r ∈ RE of the form (x)ejp−−−→ (y1)ej1 · · · (yh)ejh where

ej ∈ V and x, y1, . . . , yh ∈ Σ:

• The left-hand side of r is LHS(r) = (ej, x).

• The right-hand side of r is RHS(r) = (ej1 , y1) · · · (ejh , yh).

Definition 3.5. Given x ∈ Γ, l ∈ H, and r ∈ R such that LHS(r) =(i, α, u, v), we say that (x, l) occurs in LHS(r) with multiplicity k in any ofthe following cases:

• l = i, and the multiplicity of x in the multiset v is k.

• l is the label of the parent membrane of i, and the multiplicity of x in themultiset u is k.

Definition 3.6. A set of rules A from R is said to be consistent if for eachi ∈ 1, . . . , q and each α ∈ 0,+,− there exists α′ ∈ 0,+,− verifying thefollowing condition: for each rule r ∈ A such that its left-hand side is of type(i, α, u, v) we have charge(RHS(r)) = α′.

Definition 3.7. A rule r ∈ R is said to be consistent with a consistent set Aof rules from R if the set A ∪ r is a consistent set of rules.

3.3.3 Direct distribution based on ConsistentBlocks Algorithm (DCBA)

This section describes the Direct distribution based on Consistent Blocks Al-gorithm (DCBA) [29, 28] which performs a uniform distribution of availableresources (objects) among the blocks competing for them.


Definition 3.8. The rules of the system can be classified into blocks as follows:

(a) For each i ∈ 1, . . . , q, α ∈ 0,+,− and u, v ∈ Mf (Γ), the blockassociated to the tuple (i, α, u, v) is defined as:

Bi,α,u,v = r ∈ R : LHS(r) = (i, α, u, v)

(b) For each environment ej and each object x ∈ Σ, the block associated tothe pair (ej, x) is defined as:

Bej ,x = r ∈ RE : LHS(r) = (ej, x)

Definition 3.9. A block Bi,α,u,v is said to be consistent if and only if thereexists α′ such that, for each r ∈ Bi,α,u,v, charge(RHS(r)) = α′.

Definition 3.10. Given a tuple (i, α, α′, u, v), with 1 ≤ i ≤ q, α, α′ ∈ 0,+,−,u, v ∈ Γ∗, the block associated with such tuple is:

Bi,α,α′,u,v = r ∈ R : LHS(r) = (i, α, u, v) ∧ charge(RHS(r)) = α′

Whenever no confusion will be made, we will refer to the left-hand side ofa block B, denoting it as LHS(B), which is actually the left-hand side of anyof the rules in the block.

Definition 3.11. Two blocks Bi1,α1,α′1,u1,v1and Bi2,α2,α′2,u2,v2

are said to bemutually consistent if and only if (i1 = i2 ∧ α1 = α2)⇒ (α′1 = α′2).

Definition 3.12. A set of blocks B = B1, B2, . . . , Bs is mutually consistentif and only if ∀i, j (Bi and Bj are mutually consistent).

3.3.4 Pseudocode of DCBA

Algorithm 3.3.1 describes the main routine of DCBA. Note that the algorithmis structured in three stages: (a) initialization; (b) selection; and (c) execution.


Algorithm 3.3.1 MAIN PROCEDURE DCBA

Input: A PDP system of degree (q,m) where q ≥ 1, m ≥ 1, with T timeunits, T ≥ 1 and A ≥ 1 (Accuracy).

1: C0 ← the initial configuration of the system2: INITIALIZACION . (Algorithm 3.3.2)3: for t ← 1 a T do4: Calculate probability functions fr,j(t) and p(t).5: C ′t ← Ct−1

6: SELECTION of rules:

– STAGE 1 : distribution . (Algorithm 3.3.3)

– STAGE 2 : maximality . (Algorithm 3.3.4)

– STAGE 3 : probabilities . (Algorithm 3.3.5)

7: EXECUTION of rules. . (Algorithm 3.3.6)8: Ct ← C ′t9: end for

In the initialization stage (Algorithm 3.3.2), a static table is constructed,showing blocks (columns) against objects of the alphabet coupled with com-partment labels (rows).

Algorithm 3.3.2 INITIALIZATION

1: Construct a table for static distribution T :

• Labels on the columns: blocks Bi,α,α′,u,v from R.

• Labels on the rows: pairs (x, i), for each object x ∈ Γ, and 0 ≤ i ≤ q.• On each cell of the table, put 1

k if the object corresponding to this rowoccurs with multiplicity k in the LHS of the block corresponding to thiscolumn.

2: for j = 1 to m do . (Construct expanded static tables Tj)3: Tj ← T . . (Initialize the table with original value of T )4: Add a further row for each block Bej ,x from RE , having value 1 in row (x, 0).

5: Initialize the multisets Bjsel ← ∅ and Rjsel ← ∅

6: end for

Observation 3.1. Each column in tables Tj contains the information corre-sponding to the left-hand side of a block.

Observation 3.2. Each row in tables Tj contains the information related to


the competition for objects: given an object, the row indicates which are theblocks making use of it for its application.

In DCBA algorithm, selection stage is structured in three micro stages: (a)stage 1 (distribution); (b) stage 2 (maximality); and (c) stage 3 (probability).In stage 1 the number of times to apply each block is calculated; to do so, adistribution table is used.


Algorithm 3.3.3 STAGE SELECTION 1: DISTRIBUTION

1: for j = 1 a m do . (For each environment ej)2: Apply filters to table Tj , using C ′t and obtaining T tj :

a. T tj ← Tjb. Filter 1 (T tj , C ′t).c. Filter 2 (T tj , C ′t).d. Check the mutual consistency for remaining blocks in T tj . If there exists

at least one inconsistency then report the error, and finish execution(in case of not activating step 3).

e. Filter 3 (T tj , C ′t).3: (OPTIONAL) Generate a set Stj of sub-tables of T tj , formed by the

mutually consistent sets of blocks, in a maximal way inT tj . Replace T tj with a randomly chosen table in Stj .

4: a← 15: repeat6: for each fila X en T tj do7: RowSumX,t,j ← total sum of non null values in row X.8: end for9: T Vtj ← T tj . (A temporary copy)

10: for each non null position (X,Y ) in T tj do11: multX,t,j ← multiplicity in C ′t and ej of the object in row X.

12: T Vtj(X,Y )← bmultX,t,j ·(T t

j (X,Y ))2

RowSumX,t,jc

13: end for14: for each non filtered column, labeled by block B, in T tj do

15: NaB ← minX∈rows(T t

j )(T Vtj(X,B)) . (Minimum in the column)

16: Bjsel ← Bj

sel + BNaB . (Accumulate the value in the total)

17: C ′t ← C ′t − LHS(B) ·NaB . (Remove LHS of the block)

18: end for19: Filter 2 (T tj , C ′t)20: Filter 3 (T tj , C ′t)21: a← a+ 122: until (a > A) ∨ (All the minimums in step 15 are 0)23: end for

Stage 2 (maximality) has the aim of ensuring a maximal multiset of rulesis applied, through the maximal application of the blocks.


Algorithm 3.3.4 STAGE SELECTION 2: MAXIMALITY

1: for j = 1 a m do . (For each environment ej)2: Choose a random order for the remaining blocks in table T tj .3: for each block B, following the stated order do4: NB ← number of possible applications of B in C ′t.5: Bj

sel ← Bjsel + BNB . (Accumulate to the total)

6: C ′t ← C ′t − LHS(B) ·NB . (Remove LHS from block B, NB times.)7: end for8: end for

In stage 3 (probability) the selection of blocks is translated to a selectionof rules by using random numbers with a normal distribution.

Algorithm 3.3.5 STAGE SELECTION 3: PROBABILITY

1: for j = 1 a m do . (For each environment ej)

2: for each block BNB ∈ Bjsel do

3: Calculate n1, . . . , nl, with a multinomial M(NB, g1, . . . , gl) accordingto

the probabilities of the rules r1, . . . , rl in the block.4: for k = 1 a l do5: Rjsel ← Rjsel + rnk

k .6: end for7: end for8: Bj

sel ← ∅. . (Useful for the next iteration)9: end for

Finally, the execution stage is described in the algorithm 3.3.6.

Algorithm 3.3.6 EXECUTION

1: for j = 1 a m do . (For each environment ej)

2: for each rule rn ∈ Rjsel do . (Apply RHS of the rules)3: C ′t ← C ′t + n ·RHS(r)4: Update electrical charges in C ′t with RHS(r).5: end for6: Rjsel ← ∅. . (Useful for the next iteration)7: end for

In the execution stage the current configuration is updated producing thecorresponding objects and updating the charges.

Part II

Body

65

4MeCoSim: A visual general purpose

simulation environment for MembraneComputing

This chapter focuses on the description of MeCoSim simulation environment,general purpose software for Membrane Computing. The first section intro-duces the tool, from its origin and main goals to achieve. In the second section,the overall structure and the main functionalities present in MeCoSim are de-scribed in detail. Finally, the third section states the main stages a methodol-ogy proposed to solve problems under the scope of P systems through modelingand simulation. It is complemented with several additional functionalities forP systems designers and end users of applications based on MeCoSim.

4.1 Introduction and main goals

P systems are the computational devices of the model of computation ofMembrane Computing. They have not been implemented so far, not exist-ing a real machine capturing their essential features. However, this absencedoes not avoid the detailed study of the computational power and efficiency of

67

68

different variants of these devices, nor the verification and formal validation ofproperties of certain models based on P systems.

Besides, the result of a computation “executed” over the theoretical modelcan also be know. This could be performed by following a manual trace ina paper for each possible computation, but this process would be too tediousor even practically unfeasible when dealing with significantly big instances.Therefore, if we are interested on analyzing a variant of P systems or studyingthe properties of a specific solution, or the evolution or result of a computationassociated with an instance of a problem, we should use conventional electroniccomputers for replying the expected behavior of the real machine. Over thesedevices we develop simulators of the real machines to reproduce that behaviorwithout the advantages of the real machine but the same expected computationand result.

However, it is significantly different to face the goal of mimicking a specificcomputation studied with a trace, or the one of looking for a generic designthat can be used for any P system of a certain variant. In this sense, withinthe scope of P systems, two main approaches have been followed:

1. To develop an ad-hoc simulator for a specific solution for a problem, fora single instance or different instances of that problem.

2. To develop a general purpose simulator for a variant of P systems, cap-turing all the ingredients of the theoretical model of computation.

Most of the developments presented so far by different groups were mainlyfocused on the first approach, providing simulators for specific problems, solu-tions or even instances. Other tools were devoted to the analysis or verificationof a specific solution within the scope of P systems.

Research Group on Natural Computing of the University of Seville is moreinterested in the second approach, developing simulators for every variant ofmodel of computation including all their ingredients. Other initiatives in thissense for some types of P systems are Infobiotics or Meta P-Lab.

Our vision goes even a step further, following a third approach: the de-velopment of simulators covering a spectrum of variants of P systems as wideas possible. These variants should include a broad range in terms of struc-ture (hierarchical –Cell-Like–, plain graph –Tissue-Like, Spiking, kernel– orgraph with nodes containing trees –multienvironment, PDP systems–). They

4.1. Introduction and main goals 69

should also include a broad range of ingredients (dissolution, division, mem-brane creation, catalysts, charges, guards, symport/antiport communicationrules, stopping objects, etc.). And finally a wide range in terms of semantics(sequential execution, priorities, non maximal/minimal determinism, proba-bilistic, stochastic, etc.).

Many simulators were developed inside P-Lingua project to achieve thisgoal, along with the specification language and its associated tools for parsingand debugging the different P systems variants listed in [8]. This infrastructureprovides a complete programming environment for Membrane Computing.

Given an abstract problem, for instance SAT problem, the P system de-scribing a solution to the problem by a specific variant will be written in a filewith .pli extension holding its specification. Thus, for a cell-like P system, thefollowing elements must be given:

• Membrane structure.

• Set of rules.

• Initial multiset present inside each region.

This file will specify a family of P systems associated to a solution of theSAT problem for a generic instance of the problem with parameters n for thenumber of variables and m the number of clauses. From this definition, thesimulation of different instances can be performed by providing specific valuesfor the parameters in the P-Lingua file, and running through command line.This specific values determine the set of rules, alphabet, initial mutisets andmembrane structure.

This approach have been proved quite useful for the definition of P systemswhere the designer is also the person who perform the simulations. However,another possible situation would be the need of an end user to solve a problem(for instance SAT, 3-COL or analyzing the population dynamics of an ecosystem)which could be successfully addressed within the scope of P systems by adesigner. The end user might not be know in this framework, but he needsto provide data about the specific instance whose answer is trying to solve (asingle propositional formula, a graph or the data about an initial situation andpopulation for a species and environment). From this data, the parameters forinstantiating a P system of the family to solve the specific instance of theproblem could be internally calculated.

In addition, it could be also desirable for P systems designers to have facil-ities to provide data about specific instances of the problems to the simulators

70

beyond its coding in .pli files, easing the testing and debugging process. Itwould be therefore interesting to have high level simulation environments, in-stead of coding approach for introducing data in .pli file for each differentinstance and running from command line. Besides, it would be also worthhaving mechanisms for the visual analysis of P systems complementing thetext output provided by pLinguaCore.

This double goal, providing a high level integrated environment for mod-eling, editing, debugging, simulating, analyzing and visualizing P systems,along with a simulation environment for end users to introduce different in-stances of the problems, constitutes the starting point for the development ofthe visual general purpose simulator called MeCoSim (Membrane ComputingSimulator).

The previous needs were first detected in the context of ecological modelingand simulation. Several models, as the population dynamics of some scavengerbirds in the Catalan Pyrenees or the evolution of the population of larvae inthe reservoir of Ribarroja in Ebro river basin, were being designed. Besides,the managers of the ecosystem and the ones in the reservoir needed some toolsto study the evolutions of the corresponding systems, by means of softwareapplications to introduce different initial scenarios and visualize specific out-puts, showing certain elements of the ecosystem (internally, certain objectsin some regions for certain configurations of the underlying P systems alongthe computations. This specific purpose applications required a big effort toanalyze, design and develop the software and were needed to solve instancesof the problems being approached by modeling and simulating, both for theP systems designer and for the end user running simulations and analyzingoutputs under different possible initial conditions, scenarios of interest for theproblem under study.

Once designed ecosystem models, a number of common needs were identi-fied. The effort required for developing ad-hoc applications for each problemwas unfeasible, so a new approach was addressed: the development of a soft-ware environment able to provide mechanisms for defining simulation appli-cations (apps) customizable for any ecosystem, with user interfaces adaptedfor each problem. Thus, MeCoSim environment would act as a meta-simulationapp, allowing the definition of a simulation app for each problem. The mainmechanisms required for this environment would be which follows:

1. Input definition to specify the data the user needs to introduce for eachinstance of the problem.

4.1. Introduction and main goals 71

2. Generation of parameters of the P system from the data of the instancejust introduced.

3. Output definition, to show the end user the desired information abouteach target application (output tables, charts, graphs, etc.)

This way, it would be necessary to define for each particular application:

• The desired visual arrangement of the elements in the application.

• Which input data to introduce, in terms of needed visual tables for theuser to introduce information.

• Which parameters of the model to generate from the input data.

• Which outputs to show (defining which data from the computation toextract, which filter to apply, which grouping of the information or whichpost-processing to perform) and which format (output tables, charts,etc.)

In the same way that a P system family can be defined by the designer by a.pli file, a mechanism has been designed to define visual simulation applicationsby an .xls file (spreadsheet format for generating and using in any spreadsheetsoftware). This file will therefore define a MeCoSim based application, withthe desired inputs, outputs and visual arrangement. The execution of thisapplication permits loading the P system specification defined in a .pli file,introducing data for each specific instance visually from input tables (thesedata could be entered and saved in a scenario .ec2 file, or a pre-saved one couldbe loaded). Then, from the loaded specification and data the corresponding Psystem can be generated and simulated. Besides, specification .pli file couldbe edited and debugged through a step by step simulation.

One of the main goals of the underlying philosophy of this approach is theclear separation of the different roles involved in the modeling and simulationprocess, such a way that:

• The end user provides real field data about the problem itself, interactswith the P systems designer and transmits the requirements for inputs(data to provide about the phenomena) and outputs (information toget from the computation). He is also in charge of the corroboration

72

process, contrasting the returned data with the experimental data aboutthe same scenarios, in order for the P systems to be validated. He needsan application to enter data about the scenarios under interest and getresults, so that the application acts as a black box for him, not beinginterested in the internal P systems or software enabling the simulation.

• The P systems designer selects a proper P system variant as his modelof computation and design the model from the abstraction of real lifeprocess. In addition, he will codify the model in a language understand-able for the machine, in this case by a .pli file using P-Lingua. Thisfile should be adapted to allow different instances of the problem to bereceived from the user in the form of input data, that is, should be pa-rameterized. Besides, to make this process effective he should definea MeCoSim based application for simulating the given solution for theproblem under study.

• The developer of simulation applications should provide a software ableto receive inputs (solution and data/parameters for each scenario of in-terest), simulate the P system instantiated from those data and returnthe desired custom output. This process usually implied different ad-hocdevelopments for different problems, as in Ecosim 1.0 family for simu-lation of real ecosystems. This is unfeasible in practice as the numberof applications grows, producing a long time to market from the designof a model to the use of a practical tool for end users to simulate andmanage the underlying systems. So the idea is to avoid the need of a soft-ware developer in the modeling and simulation process, avoiding ad-hocapplications and using a single general customizable environment.

This is the philosophy underlying this dissertation, resulting in its maincontribution in terms of practical application: MeCoSim. This environ-ment acts as a meta-simulator, enabling the generation of applications(apps) for each problem or solution. Thus, it should be flexible enoughto allow P systems designers defining MeCoSim based apps with theirinputs, outputs, etc., as determined by the end user to perform the re-quired simulations of scenarios of interest. In addition, MeCoSim intendsto provide a set of functionalities for every type of P systems, includingmodeling, edition, debugging, simulation, analysis and visualization ofresults. From this core functionalities, the scope can be extended, as infact has been done.

4.2. MeCoSim software 73

Developer

Develop and release

-Fin1

*

-Fin2

*

MeCoSim

MeCoSim Plugins

-Fin1

*

-Fin2

*-Fin1

*-Fin2

*

Designer

Customize and releasesimulation app

-Fin1

*

-Fin2

*MeCoSim

-Fin1

*

-Fin2

*-Fin1

*-Fin2

*Provide the model

or solution Simulation app based on

MeCoSim

-Fin1

* -Fin2

*

Simulation app based on

MeCoSim

End user

-Fin1

*

-Fin2

*

Provide input data,scenarios

Runsimulations

Formulate hypothesis

-Fin1

*

-Fin2

*

Analyze the results

Figure 4.1: Roles and uses of MeCoSim

4.2 MeCoSim software

As commented in the previous section, a clear separation of the roles involvedin modeling and simulation process is stated: (a) software development; (b)P systems designer; y (c) end user of a simulation app. What does MeCoSim

provide within this scope?

As shown in figure 4.1, software developer releases different versions ofMeCoSim and its associated plugins, thus becoming available for any P systemsdesigner and potential users.

P systems designer defines a simulation app based on MeCoSim, customizedfor particular problem. Then, he can debug its solution and analyze the un-derlying P system. No programming knowledge is required for customizingthe app, but only the knowledge about P systems, their computations andsimulations, so only a P system designer is required.

The end user simply uses the custom simulation app based on MeCoSim

provided by the designer and study different scenarios of interest involvingspecific instances of the system previously provided by the designer.

Thus, taking into account these roles, some main functionalities of MeCoSimare listed below:

• General environment for the simulation of solutions based on P systems.It is supported by P-Lingua framework, such a way that the default

74

app, called General, permits selecting a standard P-Lingua .pli file anddebug and simulate it. Besides, that file can be edited, and the membranestructure, multisets and alphabet can be visualized.

• Mechanism for the definition of simulation apps.This applications consist of:

– A visual hierarchical structure determined by the user in an .xlsspreadsheet file.

– A definition of inputs and outputs mainly represented as tables, en-abling the introduction of data by the user and showing the desiredresults of the simulation.

– Output charts for the specified tables, stating the type of chart(lines, bars, stacked columns or pie) and the role of each column inthe table to generate the charts (category, subcategory, series, data).Besides, some charts with the prefix of Multiple can be generated,consisting of a list of values representing categories, displaying a sin-gle chart (lines for MultipleLineChart, bars for MultipleBarChart)for the clicked element of the list.

Along with the visual elements described so far, two essential com-ponents for the app have to be defined, as illustrated in the followingitems.

– Parameters: variable elements of the model or solution based on Psystems depending on the instance of the problem, according to thedata entered by the user from the input tables. It is necessary todefine the way to generate each parameter from the input tables,possibly affected by some processing from these data. To achievethis goal, a new parameters generation language has been defined,as described in section 4.2.1.

– Results: before showing output tables and charts, the correspondingdata to show should be obtained, essentially coming from computa-tion data, getting the desired objects from the stated configurations.The set of data available as part of the simulation is of type givenin figure 4.2.

All configurations data are saved during the simulation to a tablewith that schema in an on-memory database, so that the mech-anism of results definition can take advantage of the flexibility ofdatabases standard structured query language (SQL), including se-lection, filtering, grouping and ordering. Thus, the definition of


Figure 4.2: Outputs - Initial data

results consists in the selection of information from the table juststored, possibly including additional information from parametersor derived data. For instance, a user could be interested in observ-ing the evolution of the amount of larvae of Zebra Mussel, whichcould be obtained from the simulation data getting the objects ofa certain name, with certain multiplicity, along with a parameterassociated to the volume of the compartment where they are placed.This mechanism includes the possibility to define results based onpreviously defined ones, and the main one will result in an SQL queryover the database (transparent to the end user) that will be finallyshown in an output table or chart. The details of the intermediatelayer provided to the designers to abstract from some tedious SQLdetails are described in section 4.2.2.

MeCoSim environment stores every simulation app in a small SQLite databasecontaining the information loaded from the .xls configuration file. This databaseformat is a simple file with .db extension. When running MeCoSim, the list ofsimulation apps is shown, from where we can add, modify, delete or run aspecific one. The type of information stored in the database is given in therelational diagram shown in figure 4.3.

When running any simulation app, MeCoSim looks for the information in thedatabase and generates the corresponding visual application; that is, its tabshierarchy, input tables, outputs, etc. according to its defined configuration.Therefore, each simulation app will be customized as required by the user,defined in the configuration file and stored in the database. This app willthen be ready to load a solution file and the specific data for a scenario.The accepted solution files for loading in the simulation app by the optionModel >Set Model are the ones included in P-Lingua, with .pli extension,and the syntax recognized by 4.0 version of the language and software librarypLinguaCore. Besides, the variant of P system specified in the file must becompatible with the ones included in P-Lingua. pLinguaCore library containsa mapping between variants and simulators by xml files.

For instance, PDP system models are specified in P-Lingua as

76

current_app

id I

NT(

11)

idAp

p IN

T(11

)

last

Load

edCo

nfig

File

VARCH

AR(2

55)

curr

entS

kinC

lass

VAR

CHAR

(255

)

general_data

idAp

p IN

T(11

)

appN

ame

VARCH

AR(2

55)

data

Path

VAR

CHAR

(255

)

mod

elPa

th V

ARCH

AR(2

55)

sim

ulat

edCy

cles

IN

T(11

)

sim

ulat

ions

ByCy

cle

INT(

11)

step

sByC

ycle

IN

T(11

)

mod

e VA

RCH

AR(2

55)

curr

entS

imul

ator

VAR

CH

AR(2

55)

vers

ionT

ype

VARCH

AR(2

55)

save

Para

met

ers

TIN

YIN

T(1)

show

Log

TIN

YIN

T(1)

times

tam

p VA

RCH

AR(2

55)

save

Last

IN

T(1)

plingua_params

appI

d IN

T(11

)

para

mN

ame

VARCH

AR(5

0)

para

mVa

lue

VARCH

AR(2

55)

para

mSe

c IN

T(11

)

para

mO

rder

IN

T(11

)

para

mTy

pe V

ARCH

AR(2

0)

plingua_params_indexes

appI

d IN

T(11

)

para

mN

ame

VARCH

AR(5

0)

para

mIn

dex

VARCH

AR(2

55)

para

mSe

c IN

T(11

)

para

mI

INT(

11)

plugin_daikon_extractions

appI

d IN

T(11

)

tabl

eId

INT(

11)

extr

actio

nId

INT(

11)

extr

actio

nTyp

e IN

T(11

)

obje

ctN

ame

VARCH

AR(5

0)

data

Inde

x IN

T(11

)

plugin_daikon_indexes

appI

d IN

T(11

)

tabl

eId

INT(

11)

extr

actio

nId

INT(

11)

extr

actio

nOrd

er I

NT(

11)

extr

actio

nInd

ex I

NT(

11)

plugin_daikon_table

appI

d IN

T(11

)

tabl

eId

INT(

11)

step

Inde

x IN

T(11

)

enab

led

TIN

YIN

T(1)

repositories

repo

sito

ryPa

th V

ARCH

AR(2

55)

type

VAR

CHAR

(255

)

runs

runI

d IN

T(19

)

appN

ame

VARCH

AR(2

55)

data

File

Nam

e VA

RCH

AR(2

55)

mod

elFi

leN

ame

VARCH

AR(2

55)

time

INT(

19)

sequence

SEQ

_NAM

E VA

RCH

AR(5

0)

SEQ

_CO

UN

T IN

T(19

)

simulation_criteria

appI

d IN

T(11

)

resu

ltTab

leId

IN

T(11

)

crite

riaId

IN

T(11

)

crite

riaTy

pe V

ARCH

AR(5

0)

crite

ria V

ARCH

AR(5

0)

form

ula

VARCH

AR(5

0)

refe

rred

Crite

riaId

IN

T(11

)

argu

men

t VA

RCH

AR(5

0)

qual

ified

Nam

e VA

RCH

AR(5

0)

whe

reCo

nditi

onTy

pe V

ARCH

AR(5

0)

whe

reCo

nditi

on V

ARCH

AR(5

0)

simulation_registers

appI

d IN

T(11

)

sim

ulat

ion

INT(

11)

cycl

e IN

T(11

)

step

IN

T(11

)

mem

bran

eID

IN

T(11

)

envi

ronm

entI

D V

ARCH

AR(5

0)

labe

lID V

ARCH

AR(5

0)

obje

ct V

ARCH

AR(5

0)

mul

tiplic

ity I

NT(

11)

simulation_results

appI

d IN

T(11

)

resu

ltTab

leId

IN

T(11

)

resu

ltTab

leN

ame

VARCH

AR(5

0)

tabl

eId

INT(

11)

refe

rred

Res

ultT

able

Id I

NT(

11)

table_columns

idAp

p IN

T(11

)

idTa

bla

INT(

11)

idCo

l IN

T(11

)

nom

breC

ol V

ARCH

AR(2

55)

defa

ultV

alue

VAR

CHAR

(50)

save

TIN

YIN

T(1)

tool

tip V

ARCH

AR(2

55)

grap

hicR

ole

VARCH

AR(2

55)

table_config

idAp

p IN

T(11

)

idTa

bla

INT(

11)

nom

bre

VARCH

AR(2

55)

idTa

b IN

T(11

)

nrow

s IN

T(11

)

ncol

s IN

T(11

)

save

TIN

YIN

T(1)

outp

ut T

INYI

NT(

1)

grap

hic

VARCH

AR(2

55)

exte

rnal

View

TIN

YIN

T(1)

row

Addi

tionP

erm

itted

TIN

YIN

T(1)

row

Del

etio

nPer

mitt

ed T

INYI

NT(

1)

tabs_hierarchy

idAp

p IN

T(11

)

idTa

b IN

T(11

)

nom

bre

VARCH

AR(2

55)

idTa

bPad

re I

NT(

11)

0..1

1

1..*

1

1..*

1

1..*

1

0..*

0..1

1..*

1

1..*

1

1..*1

1..*

1

1..*

1

0..1

1

1..*

10..*

1

Figure 4.3: MeCoSim internal database logic design


<probabilistic>.

Once loaded in MeCoSim based simulation app, it will be parsed and, if itis a valid model, the file probabilistic.xml will be searched for getting the listof available simulators for that variant.

The format of the information in that file is as follows:

<?xml version="1.0" encoding="utf-8">

<simulators>

<simulator id="binomial" class=

"org.gcn.plinguacore.simulator.celllike.probabilistic.BinomialProbabilisticSimulator">

</simulator>

...

<simulator id="dcba" class=

"org.gcn.plinguacore.simulator.celllike.probabilistic.DCBAProbabilisticSimulator">

</simulator>

</simulators>

In order for the simulation to be performed from the loaded .pli file withthe model or solution based on P systems, the data about a specific scenariomust be given, by entering the data from the visual input tables or loadingthe .ec2 scenario file, so that the corresponding P system can be generated.Then, the simulation can be performed from the initial situation given by theentered data. When simulation starts, the first step is the instantiation of the Psystem corresponding to the given solution and scenario, including membranestructure, initial configuration and set of rules for each compartment. Thisinformation could depend on the specific instance, so some process for addingscenario data to model file will be needed, accounting for the complementaryaspects:

1. .pli solution/model file could present parameterized structures, rules andinitial configuration, depending on values as n, m, pi, etc. This way,different values for this parameters will generate different P systems.

2. The MeCoSim based simulation app will present a custom input withthe information needed for setting a specific scenario. Therefore, somemechanism should be designed to convert user input data in specificvalues for the model or solution, possibly involving some processing toget derived data. This process is explained in section 4.2.1.

Just as an example, let us analyze a part of the solution of 3-COL problemby means of tissue-like P systems [31], focusing on the generation of all possible

78

colorings by using cell division rules, for a graph of n vertices. This part ofthe solution can be described as follows:

Let Π(n) = (Γ(n), w1, w2(n), ε, R(n), i0) family of tissue-like P systems withcell division of degree 2, where:

1. Γ(n) = Ai, Ri, Ti, Bi, Gi : 1 ≤ i ≤ n

2. w1 = ∅, w2(n) = A1, . . . , An

3. R(n) is a set of division rules:

• r1,i ≡ [Ai]2 → [Ri]2[Ti]2 para i = 1, . . . , n

• r2,i ≡ [Ti]2 → [Bi]2[Gi]2 para i = 1, . . . , n

Thus, the solution .pli file representing the corresponding family of P sys-tems presents some instructions of the type:

/* Multiset in region 2 */

@ms(2) += Ai : 1<=i<=n;

/* Division rules: */

/* r1 */ [Ai]’2 --> [Ri]’2 [Ti]’2 : 1<=i<=n;

/* r2 */ [Ti]’2 --> [Bi]’2 [Gi]’2 : 1<=i<=n;

The solution .pli file represents the whole family of P systems solving this ab-stract problem, but the user will be interested in simulating a specific instance ofthe problem; that is, analyzing the P system associated to each different value ofn. To provide an app accepting values for n and generating and simulating thecorresponding P system for that solution for that specific instance, an input tableis defined in the .xls configuration file, with the information shown in figure 4.4 fortabs hierarchy, table and columns, and parameters generation.

As shown in figure 4.4, parameter n is defined, as referenced in P-Lingua file.In this case, n takes its value from the data entered in the first row, first columnof table with Id 5. When running the solution, if value 3 has been entered in thevisual table, MeCoSim based simulation app generates the parameters (n, as definedin SimulationParams tab of the configuration file). Then, the specific P system canbe instantiated from the solution .pli file and start the simulation of a computation.

It is worth noting that MeCoSim provides different simulation modes:


Figure 4.4: App definition - Parameters generation

a) Simulate a number of simulation steps. They are structured on simulations,each one divided in cycles involving a number of steps. Instead of a singlecomputation, several ones can be performed, thus showing in the outputs theaverages or deviations of certain elements along the different simulations.,mainly in probabilistic, stochastic or non deterministic systems where everycomputation can be different. The cycles permit organizing the dynamics ofthe systems in a number of iterations representing years, days, etc. where anumber of processes take place involving a sequence of steps, keeping the evo-lution of the model synchronized. MeCoSim based simulation app will permitthe end user setting the number of simulations or cycles, and designers willalso be able to modify the number of steps by cycle.

b) Simulate until a halting configuration is reached. That is, until no more rulesare applicable in the whole system in the current configuration. Additionalhalting criteria could be included in the future to extend MeCoSim features,based on specific conditions occurring on a configuration.

c) Simulate until a halting object is present in a configuration. Along with theprevious modes, it is possible to include in the solution files some halt objects,whose presence imply the interruption of the simulation.

Along with the general mechanism for simulating, simulation apps based onMeCoSim present a “Debug” tab, that could be hidden for end users, providing thefollowing functionalities:

• Set Model : sets the model or solution to work with, the same way as done byModel >Set Model.

• Init Model : loads the parameters for the current scenario, unfold the ruleswritten in P-Lingua and generates the initial configuration of the P system.Depending on the result of this process, the answer can vary, thus having:

80

a) A model or solution with a valid scenario, ready to simulate step by stepor a number of steps.

b) A non valid solution or scenario, thus showing the detected problems inErrors tab.

Both cases will show, along with the previous information:

– ParsingInfo: shows the parameters being generated, along with the un-folded rules for the P system.

– Warnings: shows warnings related to the parsing of the solution file forthe current scenario, not avoiding the simulation or debugging of thesolution.

• Step: moves the computation a step forward from the current configuration,once the model has been initialized.

• Run steps: takes the specified number of steps from the current configuration.

In both cases the information about each configuration is shown in Simula-tionInfo tab, along with the information about the selected rules for executingevery step. To complement this text output, some plugins (whose architectureis explained in section 4.2.3) show the alphabet, the membrane structure andthe multisets inside each compartment.

The general mechanism for simulation and debugging has been explained, butthe details for parameters generation and results extraction have not been given.They will be described in sections 4.2.1 and 4.2.2, respectively.

4.2.1 Parameters generation

This section details the mechanism for generating parameters from the specific dataabout a particular scenario.

As commented in the previous section, a model/solution file can contain rules,structures and initial multisets depending on parameters whose values depend on thespecific instance of the problem under study. According to the proposed approach,data are provided by input tables, such a way that the end user can define differentscenarios to simulate by simply modifying the input values in the graphical interface.The mechanism set in this section should therefore set the way the parameters aregenerated.

The definition or the parameters is written in .xls configuration file and loadedin the internal database, so that when initializing the model the parameters are gen-erated from the loaded model/solution and scenario. The syntax of the parameters


is the one of P-Lingua identifiers; for example: var, x, i. In addition, the possiblearrays of values (indexed variables) are stated, with at most 4 numeric indexes (thiscould be extended in the future to include a number of indexes as big as possible).Indexes must be specified as integer expressions separated by commas, being placedbetween a pair of braces just to the right of the name of the variable. For example:a3, a7,10, sai,2. These parameters will be generated from the configu-ration stored in the database, containing the following data in SimulationParamstab:

• Param name: name of the parameter, a mandatory valid identifier.

• Param value: numeric valid expression for the value of the parameter.

• Index : valid expression returning an integer or a range, determining the valuesfor an index of a parameter.

Thus, MeCoSim will generate a parameter for each combination of values forthe indexes. For instance, the following types of parameters might be generated:name=value, namei=value, namei,j,k,l=value.

When parameter values are being generated, if an index t is defined as a range[initialt..finalt], then a loop is generated as the following:

• The current value for index t goes from initialt to finalt with step 1; that is,all integer numbers between initialt and finalt are generated as index values.

• For each step, the following assignment is generated:namei, . . . , t, . . . , l = expr(i, . . . , $t$, . . . , l), a valid expression where thecurrent value for index t is accessed by expression $t$.

Any ranged index may avoid generating every possible integer value inside therange. A step value can be specified instead for generating integer values separatedby that step. For example, a value of [1..10,2] for an index would generateodd values between 1 and 10 for that index. The accepted language for settingparameters, values and indexes is given by the grammar shown in figure 4.5. Threeroot elements are possible: parameter value, index value and string value (verysimilar to the first one but not for simulation purposes but for its later use forcertain plugins as GraphsPlugin, as seen in section 4.2.3).

In order to generate the corresponding tools for the parsing of the language de-rived from this grammar, JavaCC software has been used, thus generating the lexicaland syntactic analyzers from an input .jj file with the grammar definition. This gen-erated tools are used by MeCoSim to parse and generate the P system associated tothe model or solution loaded by the designer or end user, once applied to a specific

82

root → valor

| index

| stringV alue

value → number

index → expression

expression → number

| LSQUARE number POINTS number RSQUARE

number → number2(op2 number2) ∗op2 → PLUS

| MINUS

number2 → number1(op1 number1) ∗op1 → MUL

| DIV

| MOD

number1 → number0(POW number0) ∗number0 → (PLUS|MINUS)?

(constant|cycles|sims|steps|rows|columns|cellV alue|var|pLinguaV ar|normal|random|mx|func|excel|LPARnumber RPAR)

constant → NUMBER

cycles → CY CLES

sims → SIMS

steps → STEPS

rows → ROWS COMMAnumber GT

columns → COLUMNS COMMAnumber GT

cellV alue → LT number COMMAnumber COMMAnumber GT

var → DOLARNUMBERdolar

pLinguaV ar → ID (LBRACE number (COMMAnumber) ∗ RBRACE)?

normal → NORMALCOMMAnumber COMMAnumber COMMAnumber GT

random → RANDOM COMMAnumber GT

max → MAX COMMAnumber COMMAnumber GT

func → FUNC COMMAID (COMMAnumber) ∗excel → EXCELCOMMAstring0GT

string0 → STRING

| stringV ariable

stringV ariable → DOLARID

valorDeCadena → devStringV alue

devStringV alue → (stringCellV alue | string0 | stringfunc)(PLUS devStringV alue)?stringCellV alue → LT COMMAnumber COMMAnumber COMMAnumber GT

stringfunc → SFUNC COMMAID (COMMA (number | devStringV alue))∗

Figure 4.5: Parameters language grammar definition


scenario. After presenting the formal grammar, let us look at its functioning in aconcise way:

• Parameter definitions are tuples < name, value, ind1, ind2, ind3, ind4 >, sucha way that:

– name is a P-Lingua variable, given by a valid identifier.

– value is obtained from a valid expression according to the grammar,from root element, then value.

– Indexes ind1, ind2, ind3, ind4 are generated from valid expressions ac-cording to the grammar, from root element,then index. As shown ingrammar, indexes can be represented by numeric expressions or rangesof numeric values.

• Valid identifiers in P-Lingua language are made of any finite sequence oflowercase or uppercase characters, digits or underscore, not starting by a digitnor being equal to a reserved word in P-Lingua language. Thus, some validparameter names would be: R, P , Q. Let P and Q be arrays, P$1$, $2$ yQ$1$, $2$ would also be valid parameters.

• The values for numeric parameters can be:

– Integer or real numbers, possibly using exponential notation.

– Usual arithmetic expressions as product (*), division (/), remainder (%),addition (+) or subtraction (-). Obviously, operands of these type ofexpressions are also any other expressions returning numeric values. Forinstance: 3e-5, (3^(4-x)+17)/23.

– Previously defined parameters, as x. This way, previously calculatedparameters (variables or arrays of variables) can be referenced to usetheir values.

– Distinguished numeric values, as @cycles, @sims and @steps represent-ing number of cycles, simulations and steps, respectively.

– Information present in input or output tables:

∗ Number of rows in the table: < @r, ID >.

∗ Number of columns in the table: < @c, ID >.

∗ Specific cell in the table, as number: < ID, i, j >; returns the valuein the cell of the table with id ID, row i, column j.

∗ Specific cell in the table, as text: <, ID, i, j >; returns the value inthe cell of the table with id ID, row i, column j, but interpretingthe value as a text.

84

– Predefined functions: some preexisting functions are defined in MeCoSim,that can be used in numeric or text expressions. For instance:

∗ <@random,N>: returns a pseudo random number between 1 and N ,following a uniform random distribution, with N a numeric expres-sion.

∗ <@max,X,Y>: returns the maximum value among numeric expres-sions X and Y .

∗ <@ncdf,mu,sigma,x>: returns the value for the normal cumulativedistribution function with parameters mu, sigma y x being numericexpressions.

– Along with previous predefined functions, a new mechanism for extend-ing this set of functions has been included in MeCoSim, and calls to thesefunctions are accepted in the language for generating parameters, withexpressions as the following:

∗ < @func, ID, par1, . . . , parn >: takes a list of numeric expressionspar1, . . . , parn, evaluates them, and calls function named ID, bypassing it the values of the corresponding expressions evaluated.This functions must return a number.

∗ < @sfunc, ID, par1, . . . , parn >: very similar to the previous one,but receives a list of elements, numeric or not, possibly includingstrings, and calls function ID returning a string.

∗ < @excel, formula excel >: allows the use of an Excel formulaas a value for a parameter or expression. The evaluation of theExcel formula is performed by the mechanism provided by Jakarta

POI library; if the function is not included in this library and we areworking in Windows operating system with Excel installed, a VisualBasic script runs the evaluation by delegating in Excel software itselfin background mode, transparent for the user.

The extensibility mechanism consisting in the use of @func provides thedeveloper a way to include new functions, and provides the designer themechanism to call any of these functions as part of the language acceptedfor generating parameters. These functions to implement by developersmust take a list of numeric arguments and also returns a numeric value.The process for the developer would be as follows:

1. To develop a Java class implementing IAlgorithm interface:

1 package a lgor i thms ;2

3 import java . u t i l . L i s t ;4


5 pub l i c i n t e r f a c e IAlgorithm 6 pub l i c Number a lgor i thm ( List<Number> params ) ;7

The only method to implement is algorithm, with the signatureshown above. For instance, the class associated to method floorwould contain the code:



5 pub l i c c l a s s Floor implements IAlgorithm 6 pub l i c Number a lgor i thm ( List<Number> params ) 7 Number r e s u l t = 0 ;8

9 Number n = params . get (0 ) ;10

11 r e s u l t = ( i n t ) Math . f l o o r (n . doubleValue ( ) ) ;12

13 re turn r e s u l t ;14 15

2. Provide the new function a name that can be recognized by theparameters generation mechanism of MeCoSim, by associating thename of the function to the fully qualified class inecosim-properties file. Thus, for floor function, the text func-floor= algorithms.Floor would be enough to state the association.

An analog process is performed for functions implemented for beingcalled by @sfunc mechanism, but implementing IStringAlgorithm in-terface:



5 pub l i c i n t e r f a c e IStr ingAlgor i thm 6 pub l i c S t r ing s t r i n g a l g o r i t h m ( List<Object> params ) ;7

A series of functions are available so far in MeCoSim using this mechanismfor numeric functions: floor, ceil, min, eq, if , abs, g, log, exp, initialize,caudal, renovation, gammanext, normalnext, poissonnext, acumstats.Also, the next string functions are available: conc, color, toString, grm.

86

4.2.2 Outputs generation

As described in 4.2 section, after the model or solution is loaded and the inputdata about the specific scenario is entered, the parameters values are generatedby the mechanism described above. Then, the P system is instantiated, and thesimulation starts by executing the computation until a halting condition is reached(fixed number of steps or halting configuration). Every configuration will be storedto an on-memory database, such a way that flexible criteria can be defined to extractresults from these data. As previously indicated, the stored information presents theformat of the figure 4.6.

Figure 4.6: Simulation registers format in the database.

Different tabular or graphical results can be defined from this structure depend-ing on the information interesting for the user, showing certain results of the desiredconfigurations, at the end or analyzing the evolution along the computation. In casea number of simulations run for the same scenario (for instance, for probabilisticor stochastic systems), statistical results calculating means, deviations, etc. amongsimulations can be interesting, instead of showing the results of a single computation.

As introduced in the parent section, in order for the simulation results extractionmechanism to be flexible enough for anticipating possible future needs for potentialusers, this mechanism has been designed based on databases technology, specificallyas a layer over SQL standard language. This layer tries to abstract the designers ofP systems and end users from the details of the language, enabling the generation ofoutputs by selecting which data to extract, under which conditions and how to groupthem. From user (designer or end user) selection, when generating the outputs, anSQL query is transparently generated based on the configuration given in the .xlsdefinition file. Following this mechanism is explained by using a top−down approach:

• Defining an output table with the data to show by means of TablesConfigtab, containing a TableId, a name and the number of columns in the table,along with Input/Output indicator fixed to “Output”.

• Setting a result in SimulationResults tab, indicating aResultId, a name, a TableId where the result will be shown and aReferencedResultId.Thus, a result can refer to another one, implying a new aggregation level. Forinstance, a result could obtain data from different simulations, and the nextone get means and deviations over the previous one. This permits nested re-sults from the underlying database. If the result does not depend on another,


ReferencedResultId will be 0. Besides, if the result is not being shown inany output table but it only acts as an auxiliary one, TableId will be 0.

• Defining criteria for generating the previous result. If a result is called “Simu-lation”, its configuration would be placed on “SD Simulation” tab, containingrows for the definition of selecting, filtering and grouping data, each one ofthem containing some of the data in figure 4.7:

Figure 4.7: Simulation criteria for results definition.

In summary, simulation criteria to include should state which data to show(Select), accounting for which restrictions (Where) and how to group them(Group). These criteria can be set as follows:

– Select: any data from the original database data can be selected (seefigure 4.6), also any data from a previous result, or an operation from anauxiliary criteria (Auxiliary) previously defined in the same tab. Theseare similar to Select criteria, but qualified as Auxiliary, such a way thatit can be referenced by its criteria id. This way, as permitted in SQLlanguage, usual operators or functions over previous criteria might beapplied, including the ones listed in [3]. An example of the definitionof this kind of Auxiliary and Select simulation criteria are shown infigure 4.8.

Figure 4.8: Selection criteria for a simulation result.

The first four criteria are of type Select, extracting data from the simu-lation. The first one gets the first character for each object (by functionLEFT with Argument equals to 1), using auxiliary criteria 5, object, ref-erenced by Referred Criteria Id. Qualified name associates a name tothe calculated value on Select, in this case type. Nested simulation cri-teria 7 to 10 permit the generation of data specieI, as an integer numbergenerated by casting the string from the third character to ’’.Condition

88

type sets the type (for example, Integer or String) of Argument whenapplied over a Select criteria. A value of Reference makes the argumentbe interpreted as a reference to the Id of another criteria, as in the usualbehavior of Referred Criteria Id. A value of DirectString makes theargument be interpreted as a text without quotes.

– Where: states the filter criteria for obtaining the data, that is, therestrictions over the data selected. Thus, the computation could containmany types of objects but we may be interested in the ones startingwith C or H; the same way, it could be required to get data about allconfigurations or in certain steps only. An example of Where clause isshown in figure 4.9.

Figure 4.9: Filtering criteria

As it can be seen, a single Where clause states the condition for thesimulation data to appear, being a simple formula as MOD(step, 15) =0) or including logic operators AND, OR, NOT. That way, auxiliaryfiltering criteria should be provided by WhereAux, that could also makeuse dependent Auxiliary rows to apply numeric functions over criteria,as MOD. The example shows Where condition (22), conjunction of 21and 20. Criteria 21 is the disjunction of criteria 14 and 15; in summary,the output will be limited to registers whose objects start by C or H.

– Group: grouping level of the data to extract. If a single simulation isperformed and there is a requirement to show the total number of individ-uals of a species (for instance, represented by objects X) for each mem-brane (each value of membraneID), Select criteria should include thedata to extract (membraneID, COUNT (object)), such a way that theyare grouped by membrane with a Group criteria set as membraneID.Group criteria will also be used for the ordering of the data as sortedin the output definition (as Orderby particles in SQL language). Theprevious example is completed with the grouping criteria shown in fig-ure 4.10.

A full reference of the elements available for simulation results definition is avail-able in [4].


Figure 4.10: Group criteria

If a chart output is desired, an output result should be defined for extractingthe data as described before. Then, the following steps are necessary to make thisresult appears as a chart:

1. Define the table as Output: in TablesConfig, with Input/Output set toOutput.

2. Declare the output as a chart: in TablesConfig, with a non empty nor Nonevalue for OutputGraphic field. This should be a valid name for a chart typein MeCoSim or Default (automatically assign a default type depending on thenumber of columns of the table). The following types are available so far:

• PieChart, for two columns charts, with category being shown with a sizeproportional to its value in the corresponding output table.

• LineChart, from a table with three columns, representing the evolution ofdifferent series of data presenting a value for each category; An exampleis shown in figure 4.11.

Figure 4.11: Line chart.

• BarChart, from a three column output table representing, for eachcategory, bars of different colors for each series with lengths dependingon their value. An example is shown in figure 4.12.

• StackedBarChart, representing from a four column chart the value ofdata grouped by category (group) divided into subcategory (verticalbars), each one showing values of different series in sectors with differentcolors. Figure 4.13 shows an example.

90

Figure 4.12: Bar chart.

Figure 4.13: Stacked bar chart.

• MultiLineChart/MultiBarChart, presenting a list of elements for eachdifferent subcategory; when an element is selected, a line/bar chart isshown for that subcategory, with category, serie and value behavingthe same way as in LineChart/BarChart described above. Figure 4.14shows an example.

Figure 4.14: MultiLineChart - Line charts list

The roles Category, Subcategory, Series and Data (value) qualify the differentdata of the output tables, being included in GraphicRole field in their definition, asshown in figure 4.15.


Figure 4.15: Chart definition - Roles assignment

4.2.3 Plugins

Functionalities described in section 4.2 constitutes the CORE of MeCoSim, but manyothers provide additional features and abilities to interact with other software. Theplugins architecture and customization elements permit adding Java-based func-tionality or external programs being called from MeCoSim. Following some currentlyimplemented plugins taking advantage of these mechanisms are listed:

• MeCoSimBasics plugin: includes a P-Lingua (.pli) files editor, along withviewers for alphabets, structures and multisets.

• Processes plugin: permits connecting MeCoSim to external programs, directlyinvoked by operating system or command line calls transparently, from MeCoSim

menu options. Besides, additional custom menu options can be included forsending emails or opening web sites.

• Graphs plugin: enables the definition of graphs from parameters information,coming from input/output tables through parameters generation mechanism.Options for showing graphs, trees or graphs in a tree hierarchical structureare available.

The details for setting plugins-properties are given in MeCoSim web site [111],in Getting started > User guide > Plugins section.

Along with the previously described basic plugins, some others for more specificfunctionalities have been developed:

• Daikon plugin: plugin for invariants extraction from the trace of the modelsor solutions computation. A plugin was developed to connect MeCoSim withDaikon by means of a daikonapplication program, developed by collaboratorsof the University of Pitesti, responsible for calling Daikon with the requiredinput parameters. This way, MeCoSim generates a file with the trace of thecomputation in a format expected for daikonapplication, which is then calledfrom MeCoSim. This interface loads the trace file and generates an output withthe detected invariants.

The starting point to do so is the outputs mechanism in MeCoSim, allowingthe design of an output for extracting the desired trace. In addition, some

92

specific tabs in the definition .xls file permit setting the trace files informationfrom that output. The contents of this settings is the following:

– General information:

∗ StepIndex : index of the column of the referenced table storing thedata “step”.

∗ Enabled (TRUE/FALSE): enables or disables Daikon trace extrac-tion.

– Trace data: information about each data to generate.

∗ Extraction Id : identifier for the data to extract.

∗ Extraction Type: could be Named, thus extracting the set data andassigning a name: or Generated, thus generating different data froma column of the output table (a data type for the trace is generatedfor each different value present in that column).

∗ Object Name: names the data if it has type Named..

∗ Extraction Data Index : output order for data inside each row of thetrace.

– Extraction data: details for generation of elements of type Generated.The following data must be set:

∗ Extraction Id : identifier for the data to extract.

∗ Extraction Order : order of the portion of data (subdata) as part ofthe data to extract.

∗ Extraction Index : index of the data in the output table placed inthe extraction order in the generated extraction.

For instance, for producing the trace for Daikon with the step and data of eachobject inside each membrane, starting from the table in figure 4.16, the configurationset in figure 4.17 must be given.

Figure 4.16: Daikon - Output data - TableConfig

As observed in figure 4.17, step is the first data in the output, so its value is 1.The trace extracts step as Named, followed by data generated from the multiplicityof every type of object (4, being multiplicity the fourth column in the output table).


Figure 4.17: Daikon - Extraction - DaikonConfig

Thus, a different name is generated for each name given by the block stated in Extrac-tion details. This way, a multiplicity object is extracted per (object, compartment)pair; for instance, A12 2, for the multiplicity of objects A12 inside compartment2.

The definition of these extractions is included in the app .xls file and storedin the database. Once a simulation over that app is performed and outputs aregenerated, if some Daikon extraction is set and enabled, the corresponding tracefiles are generated (one per extraction previously set).

“Daikon” menu option shows the list of trace files. Once the desired one isselected, a new window is shown (daikonapplication) with the contents of the tracefile, its transformation to Daikon format, and Daikon output with the detectedinvariants.

4.2.4 Repositories

MeCoSim based simulation apps, models, scenarios and plugins developed could beinteresting for other P systems designers or end users of the apps. To make themavailable publicly, a repositories system has been designed, developed and releasedfor:

• Plugins (.jar).

• Apps (.xls).

• Models (.pli).

• Scenarios (.ec2 ).

Any MeCoSim user may provide a repository of plugins, apps, etc. generatingdepending on the type of repository:

• Plugins: a plugins.xml file like this:

94

<plugins>

<plugin name="MeCoSimBasicsPlugin" jnlp="MeCoSimBasicsPlugin.jnlp"

path="http://p-lingua.org/mecosim/jnlp/plugins/MeCoSimBasicsPlugin.jnlp"/>

...

</plugins>

• Apps: an apps.xml file like this:

<apps>

<app name="Tricolor Simple Kernel 1" config="TricolorConfigFile.xls"

path="http://www.gcn.us.es/redmine/dmsf/files/2951/download"/>

...

</apps>

• Models: a models.xml file like this:

<models>

<model name="Tricolor Simple Kernel 1" pli="tricolor.pli"


...

</models>

• Scenarios: a scenarios.xml file like this:

<scenarios>

<scenario name="Tricolor Simple Kernel 1" pli="3color.ec2"


...

</scenarios>

Submenu options available in “Manage repositories” menu permit adding repos-itories, providing a public reachable path where the corresponding xml file is placed.Once an added repository is selected, the data about the corresponding files in-cluded in the repository are listed. This way, when installing the plugin, app, modelor scenario, the corresponding files will be downloaded and installed.

The goal of this mechanism is to provide the community an easy and fast wayof accessing the available models. In addition, it permits other members to sharetheir own models, enforcing the collaborative work and knowledge sharing.

4.3 Methodology

The infrastructure provided by P-Lingua and MeCoSim has permitted the applicationof an integral methodology being simultaneously being designed. This methodologyenables the resolution of problems in real life or from literature, interesting bothfrom a theoretical computer science point of view, or more practical ones, being im-mediately applicable to a real life problem under interest. In this sense, a first draftinvolving some steps of this methodology was first presented in [64] for models orsolutions simulation, invariants extraction and verification of properties over models

4.3. Methodology 95

based on P systems was presented. This approach was later extended in [43]. Fol-lowing the main aspects of this methodology are described, supported by the toolsincluded in P-Lingua and MeCoSim, providing a simulation environment enabling theintegration of the different functionalities involved in the process:

Modeling

From the initial analysis of the problem under study, an abstraction process is per-formed to capture the essential data relevant to the studied phenomena, until aP systems based model or solution is designed to answer the questions posed inthat analysis, including the necessary processes and data. Some of the main stepsinvolved in this sense, specifically under the scope of the so called Population Dy-namics P systems (PDP systems), are described in the protocol detailed in [26].

Once a model capturing the essence of a phenomena is designed, this modelcan be translated to P-Lingua [40] language and be stored as a .pli file. If thedata corresponding to a specific instance of the problem are introduced in the samefile (that is, the specific values for the parameter of the corresponding scenario ofinterest), the model would be ready to work with it in pLinguaCore or MeCoSim[84].

Simulation

The previous model could be simulated by P-Lingua framework, or in a graphicalway by MeCoSim interface, delegating in pLinguaCore the parsing and simulationprocess (also other external simulators can be used). P systems types and variantssupported so far under the scope of pLinguaCore include several variants of Cell-Like, Tissue-Like, Spiking Neural o Simple kernel P systems (a full list is availablein P-Lingua web site [8]. Thus, when a model file is loaded, a number of availablesimulators for its corresponding variant of P systems will appear in a submenu inMeCoSim, ready for the user to choose the desired one, as shown in figure 4.18.

Customization

MeCoSim mechanism for defining custom simulation apps allows the definition ofinput tables for the user to enter the custom data for the studied problem, readyto introduce data about each particular scenario of that problem. From these datathe corresponding parameters values will complement the model to be simulated,instead of being those values hardcoded in the model file. This way, a single modelfile can define a family of P systems including a number of parameters, such a waythat the different instances of the problem and their corresponding scenarios lead todifferent P systems and inputs for them in simulation time.

96

Figure 4.18: Available simulators for a loaded P systems variant

Debugging

MeCoSim includes a mechanism, inherited from Ecosim 1.0 family, then generalizedand extended, to perform the debugging of models and solutions based on P systems.The main options include (SetModel), to load s .pli, (InitModel) to initialize themodel, Errors tab to show possible errors detected when initializing and validating,and Warnings tab to inform over non critical possible issues detected. If the modelalong with the parameters generated for the specific instance introduced are valid,the values for the parameters and the unfolded rules will be shown in Parsing Infotab. Then functionalities for step by step simulation (Step) or the simulation ofa fixed number of steps (Run steps) will be enabled, thus showing the data aboutthe sequence of configurations and rules appliances in Simulation Info tab. Anexample of debugging is shown in figure 4.19.

The debugging of the models permits detecting errors, not meeting their syntac-tic or semantic constraints, as well as mismatches in the values of the parametersused by the model, depending on the loaded scenario.

Visualization and data analysis

• Definition of custom post-processed outputs: P-Lingua simulations show ev-ery configuration and appliance of rule during the computation, both exter-

4.3. Methodology 97

Figure 4.19: Model debugging

nally or inside MeCoSim debug tab. In order for this “plain” information tobe complemented, the definition of MeCoSim outputs permits showing specificinformation in the form of tables or charts. This extends the functionalities tovisualize information from the computation, focusing on the specific elementsthat we are interested in. Besides, it permits showing more complex out-puts, post-processing the data coming from the database of the computation,including filtering and grouping techniques broadening the possible analysisover data resulting from simulations. These tools are devoted to provide moreinformation to the P systems designer and the end user of the simulation app,interested in his application domain and not in the underlying P systems.

• Advanced visualization of structures and elements of P systems configura-tions: MeCoSim basics plugin provide viewers oriented to the designer user, foralphabet (figure 4.20, left), structure (figure 4.20, right) and multisets insideeach compartment (figure 4.21).

• Graphs visualization: in addition to the previous viewers, a plugin has beendeveloped to show graphs with their nodes and edges coming from the infor-mation generated as parameters from the input or output tables. An exampleis illustrated in figure 4.22.

This plugin can interpret parameters generated in MeCoSim as useful informa-tion for visualizing graphs, as the number of vertices (default n), number ofedges (default ne) or the specific edges of the graph ( default ek, 1 for thefirst node of edge k, ek, 2 from the second). This way, the plugin will show

98

Figure 4.20: Alphabet (left) and structure (right) viewers

Figure 4.21: Multisets viewer

the graph associated to these parameters. Any other parameter names canbe used, by simply choosing the desired ones when choosing the parametersvisually, as shown in figure 4.23.

The mentioned graphs can be generated from the number of vertices plus theedges list, or from the numeric or text list of edges. The different availableoptions are shown in figure 4.24.

“Generate tree of graphs” option generates an interface with a two level treestructure, such a way that each leaf of that tree structure presents a graph.It was originated from the need of visualizing, for each step and compartmentof the computation, the graph represented by a set of objects present in acompartment (membrane, cell or neuron). This process was made possible byparameters versInfok, l for each node k of each graph, with 1 ≤ l ≤ 3.

4.3. Methodology 99

Figure 4.22: Graphs visualization plugin

Figure 4.23: GraphsPlugin - Parameters

Thus, for that node k, versInfok, 1 represents the value for the first levelof the tree, versInfok, 2 for the second level, and versInfok, 3 the val-ue/information of the node in the graph determined by the previous pair. Eachgraph will therefore represent the nodes depending on versInfo parameters,including the possible edges from the original graph as described in ek1, k2parameters. Figure 4.25 shows two different examples of visualizations of treesof graphs.

In addition, if parameters of type versAttr exist, they can include additionalinformation about the nodes. This additional meta-information may includea text description for the node, complementing the numerical identifier forthe node. New treatments for meta information in graphs is expected to beincluded in new releases of the plugin. Obviously, versInfo and versAttrparameters can present other names, being chosen from selectable options in

100

Figure 4.24: GraphsPlugin - Generation options

Figure 4.25: GraphsPlugin - Trees of graphs

figure 4.23.

Invariants detection

The joint power of customizable outputs in MeCoSim and Daikon [37, 47, 48] ex-traction plugin permits the detection of invariants from the models and solutionsdesigned based on P systems. The outputs definition is used to select the desiredelements from the computation (for instance, as shown in figure 4.26), and Daikonplugin is use to extract traces, select the desired one (see figure 4.27) and detectproperties by delegating in Daikon invariant detector (see figure 4.28). This processis described in a deeper way in [64].

Figure 4.26: Custom output for later Daikon extraction

4.3. Methodology 101

Figure 4.27: Extracted trace selection

Properties verification

Apart from the previous mechanism, the integration of MeCoSim with tools for for-mal verification of properties of the models by model checking techniques has beenperformed. To achieve this goal, a collaboration was established1 in the develop-ment of a plugin, PromelaP lugin, that generates a .pml file in Promela formatfrom the model and scenario loaded in MeCoSim to simulate. This file could then beedited to include properties to verify, and run from MeCoSim by calling Spin Modelchecker [14, 55, 9]. Some details are commented in [43], taking into considerationthe basis for automated verification of P systems through Spin stated in [57, 65].The visual interface for the generation of Promela code and Spin execution fromMeCoSim is shown in figure 4.29

Given the simulation abilities also present in Spin model checker, along with thementioned plugin, it has been also integrated in MeCoSim a simulator of a variantof P systems, simple kernel P systems, which makes use of Spin for running thesimulation, that once finished loads the data from the computation to the samedatabase as the internal simulators based on P-Lingua, such a way that conventionalMeCoSim custom outputs mechanism can be used.

1A collaboration was made with the Department of Mathematics and Computer Science,University of Pitesti, and the Department of Computer Science, University of Sheffield

102

Figure 4.28: Invariants detection based on Daikon

Figure 4.29: Plugin for generation of Promela code and verification by meansof Spin

5Simple Kernel P systems

Kernel P systems emerge from the need of developing an integrative model involvingfeatures from a broad range of cellular systems, with their more relevant syntacticand semantic ingredients. In this variant a simplified variant is presented, the socalled simple kernel P systems, that was first presented in [43].

In section 5.1 simple kernel P systems are introduced, justifying his irruption.Section 5.2 describes a formalization of the cited model, including its syntax andsemantics. Section 5.3.1 is devoted to expose the work developed in terms of thesoftware tools working with simple kernel P systems, setting the goals addressed,as well as the main technological and methodological contributions made. The lastsection 5.4 presents an efficient solution for 3-COL problem by a family of simplekernel P systems.

5.1 Introduction

Simple kernel P systems consists basically on a specification system for P systemsof a relatively low level whose essential goal resides in the combination of relevantfeatures and ingredients present in several variants of P systems studied so far. Thesesystems emerge from its conception with an intention of being formally defined inan operational style and being finally implemented in a model checker (SPIN [14],Maude [25]). In addition, this mechanisms also intends to be integrated in the

103

Chapter 5. Simple Kernel P systems 104

platform provided by P-Lingua framework.

The main idea underlying this formalism is acting as an integrative model ableto be implemented with a double purpose:

• Providing P systems designers with a computational device flexible enough tosolve many different problems, from a core (kernel) of basic elements in termsof structural elements and dynamics.

• Providing the developers of platforms for computational modeling, simulationand verification of models based on P systems with a unified framework underwhich the needed tools can be developed in a uniform way.

With the introduction of this formalism it is intended to combine in an integratedmechanism the abilities of the different variants of P systems with a general model,describing within this formalism the needed elements to permit somehow to replacethe variety of structure, notations and dynamics of its predecessors, without losingtheir power. This overall view would provide therefore an external facade easing thework of designers in terms of learning (a single formalism with a flexible but boundedset of ingredients), and promoting the development of general tools to simulate andverify these elements within the model of computation in a uniform way.

5.2 Simple Kernel P Systems

Simple kernel P systems hold a series of basic components of processing called com-partments, structured as a dynamic non directed graph. Each component in thesystem contains a finite multiset of objects, along with a finite set of rules of differ-ent types that can be applied according to an execution strategy. These rules will beresponsible for the evolution and transport of objects among different components,as well as for the changes in the structure itself associated to the model. In addition,every simple kernel P system has a “special” which will be denoted as environmentof the system.

In simple kernel P system certain types exist so that each compartment will beof a specific type. Besides, each type of compartment has associated a finite set ofrules, that can be rules processing objects (so called rewriting and communicationrules), or rules modifying the structure (division rules).

Another innovative fact derived from this framework is that each rule has aformula associated to it (denoted by guard) including a single free variable whosevalues are multisets of objects of the system. That formula acts in a similar waythan promoters and inhibitors associated to certain rules in “classical” P systems.

5.2. Simple Kernel P Systems 105

5.2.1 Formalization

Definition 5.1. An atomic guard over an alphabet Γ is the formula TRUE, theformula FALSE, or an expression of type wγw0, with w a variable over Mf (Γ),w0 ∈Mf (Γ) and γ ∈ ≤,≥,=, 6=, >,<.

Definition 5.2. A guard over an alphabet Γ is a finite sequence of atomic guardsover Γ connected by logical operators ¬,∧,∨.

Let us recall the normal execution policy for logical operators according to thefollowing priority order: first negation (¬), then conjunction (∧) and, finally, dis-junction (∨).

Definition 5.3. A type of compartment t over an alphabet Γ is a pair (Rt, σt),where Rt is a set of rules over Γ injectively labeled by elements of set Lab(Rt) andσt an execution strategy over the rules in Rt. These rules are associated to a setT = t1, . . . , ts of types of compartments such that t ∈ T and can have one of thefollowing forms:

• Rewriting and communication rule: u → v g, where u ∈ Mf (Γ), u 6= ∅,v = (a1, ti1) . . . (ah, tih), with aj ∈ Γ, tij ∈ T and g a guard over Γ. Thelength of this rule is defined as: |u|+ |v|.

• Division rule: [a]t → [v1]tj1 . . . [vp]tjp g, where a ∈ Γ, vj ∈ Mf (Γ), tj,p′ ∈ Tand g is a guard over Γ. The length of this rule is defined as: 1+|v1|+· · ·+|vp|.

Definition 5.4. A compartment over an alphabet Γ is an ordered pair (t, w), wheret is a type of compartment of Γ and w is a multiset of objects over Γ.

Definition 5.5. A simple Kernel P system of degree n ≥ 1 is a tuple

Π = (Γ, E , T,G,C1, . . . , Cn, iout)

where

• Γ is a finite alphabet whose elements are called objects.

• E is an alphabet contained in Γ (called output alphabet).

• T = t1, . . . , ts is a set of types of compartment.

• G = (V,E) is a non directed graph.

• V = C1, . . . , Cn is the set of nodes in the graph, called compartments of thesystem, such a way that Ci = (ti, wi), 1 ≤ i ≤ n, with ti ∈ T and wi ∈Mf (Γ).


• iout ∈ 0, 1, . . . , n is a number representing the environment (if iout = 0) ora compartment of the system, if iout ∈ 1, . . . , n.

A simple kernel P system of degree n can be considered a set of n compartmentsinterconnected by a non directed graph G, such a way that each compartment Cicontains initially a multiset of objects, and belongs to a certain type T of “typesof compartments”. This set T determines the set of rules in the system; regardingthe execution strategies, in simple kernel P systems the execution strategy will bethe same in every type of compartment: maximal parallelism with an additionalconstraint: in a computational step, at most one division rule can be applied toeach compartment.

There exists a distinguished zone in the system representing by the number ioutrepresenting the environment or a special compartment where the “output” of thecomputation will be sent.

Definition 5.6. A configuration of a simple kernel P system, is a tuple (G′, C ′i1 , . . . , C′ir

),with G′ a non directed graph whose nodes are the compartments (C ′i1 , . . . , C

′ir

).

Given the simple kernel P system Π = (Γ, E , T,G,C1, . . . , Cn, iout), configuration(G,C1, . . . , Cn) is called the initial configuration of the system Π.

Definition 5.7. A rewriting rule associated to a type of compartment t, u→ v g,with u ∈ Mf (Γ), u 6= ∅ and v = (a1, ti1) . . . (ah, tih), is applicable to a configurationC = (G′, C ′i1 , . . . , C

′ir

) and a compartment d = (t, w) if:

(a) There exists j (1 ≤ j ≤ r), such that C ′ij = d; that is, compartment d appearsin configuration C.

(b) u ⊆ w. C.

(c) The formula g(w) is true; that is, the guard is satisfied by the multiset con-tained in the compartment where it is applied.

(d) There exists compartments d1, . . . , dh of types ti1 . . . tih, respectively, such thatd, d1, . . . , d, dh are edges of the graph G′.

Definition 5.8. A division rule associated to a type of compartment t, [a]t →[v1]tj1 . . . [vp]tjp g, with a ∈ Γ, vj ∈ Mf (Γ), is applicable to a configurationC = (G′, C ′i1 , . . . , C

′ir

) and a compartment d = (t, w) if:

(a) There exists j (1 ≤ j ≤ r), such that C ′ij = d; that is, compartment d appearsin configuration C. Besides, d is not the output compartment.

5.2. Simple Kernel P Systems 107

(b) a ∈ w; that is, object a is an element of multiset w present in compartmentC ′ij of configuration C.

(c) The formula g(w) is true; that is, the guard is satisfied by the multiset con-tained in the specific compartment where it is applied.

If the guard associated to a rule is TRUE, it will not be written, given thatTRUE “condition” will always verify.

Definition 5.9. If a rewriting rule associated to a type of compartment t, u →(a1, ti1) . . . (ah, tih) g, is applicable to a configuration C = (G′, C ′i1 , . . . , C

′ir

) and acompartment d = (t, w), the effect of its application is as follows:

(a) Multiset u defining the left hand side of the rule is removed from compartmentd.

(b) For each k (1 ≤ k ≤ h), object ak is added to a compartment of G′ of type tik(if more than one existed, one of them would be non deterministically chosen).

Definition 5.10. If a division rule associated to a type of compartment t, [a]t →[v1]tj1 . . . [vp]tjp g, is applicable to a configuration C = (G′, C ′i1 , . . . , C

′ir

) and acompartment d = (t, w), the effect of its application is as follows:

(a) Object a firing the rule is removed from the contents of compartment d.

(b) p new compartments d1 . . . dp of types tj1 . . . tjp, respectively, are created. Theircontent are identical to the one in compartment d with the exception that, foreach k (1 ≤ k ≤ p), in compartment dk object a is replaced by multiset vk.

(c) Edges (d, d1) . . . (d, dp) are added to the graph G′.

The concepts of configuration, transition step and computation are defined ina similar way than for other P systems. Every computation starts from an initialconfiguration, an only the halting computations provide a result that will be codifiedby the objects present in a certain output compartment in the halting configuration(that could be the environment of the system).

The whole computation is considered to be executed in a synchronized process;that is, a matter of universal clock is supposed to exist for the entire system alongthe computation.


5.3 Software tools for modeling and simula-

tion

At the beginning of this section (5.3.1) a methodology similar to the one illustratedin chapter 4 is introduced, but applied in particular to the problems to solve, analyzeand verify by means of simple kernel P systems.

5.3.1 A framework for modeling, simulation and verifi-cation

This section presents a methodology for modeling, simulation and verification (bymodel checking techniques), for simple kernel P systems [64]. This methodology,highlighted in figure 5.1, is supported by MeCoSim software environment [84, 111],including P-Lingua [40, 83] specification language and many variants of P systems.During the work presented in this dissertation, a variant of the language was designedfor simple kernel P systems, and its corresponding parsers, simulators and associatedtools were developed.

Simulation

MeCoSim

P-lingua model

Simulation

traces

Verification

Spin

Invariant detector

Daikon

Promela

model

Property

extraction cycle

Properties

Figure 5.1: Specification, analysis and verification of simple kernel P systems

This methodology involves a sequence of steps. First of all, a solution is designedfor the problem under study by a simple kernel P system, later translated to aP-Lingua [33, 83] specification. A set of customized visual interfaces, specificallydesigned by setting MeCoSim [84, 111] configuration files, allow the entrance of inputdata for each problem, provide simulation results and extract the proper output

5.3. Software tools for modeling and simulation 109

data. The simulations are performed in MeCoSim by using the simulation enginefor simple kernel P systems included in pLinguaCore [33]. The results can then beverified by model checking techniques (for instance, by using Spin for a solutionwritten in Promela format [14]). For a more detailed description see [64].

As a complement for the tabular outputs, with the aim of helping interpreting theresults, additional visualization tools have been incorporated in MeCoSim, includingviewers of different elements of the P systems, charts and graphs.

In chapter 6 some simulations performed over simple kernel P systems for solvingNP-complete problems are detailed, highlighting the benefits of using an approachbased on simple kernel P systems with respect to other formalisms using P systems.It is worth noting some addition made in the environment, related to a substantialimprovement with minimal implementation costs. It consists on a mechanism toavoid the use of compartments where for sure will not provide a correct solution andno more rules are applicable.

5.3.2 Specification of simple kernel P systems

The proposed methodology is supported by the development and integration of toolsenabling the definition, customization, simulation, analysis, visualization, invariantextraction and verification of properties for the solutions (to relevant problems)based on P systems.

The first step consists on the specification of a simple kernel P system in alanguage understandable by the machine.

Following the needed elements of the language are presented. They representtheir homologous structures and ingredients in the design of a simple kernel P sys-tem.

5.3.2.1 Structures in P–Lingua

A non trivial subatomic guard g(w) over an alphabet Γ is an atomic guard over Γ oftype w(a) γ an, where a ∈ Γ, n ≥ 1, with w(a) the multiplicity of object a in multisetw. Then a non trivial atomic guard g(w) ≡ wγw0 over Γ, with w a variable overMf (Γ), w0 ∈Mf (Γ) and γ ∈ ≤,≥,=, 6=, >,<, will be expressed as follows:∧

x∈supp(w0)

w(x) γ w0(x)

In the rest of the chapter, instead of working with alphabet Γ, will use thealphabet Γ ∪ Γ, where Γ = a : a ∈ Γ. Besides, we will only use guards being


disjunctions of conjunctions of subatomic guards (let us remember, over alphabetΓ ∪ Γ).

The following structures were added during the development of this work inP-Lingua 4.0 release, available in [83] and also as part of MeCoSim. The currentversion of P-Lingua allows the definition of simple kernel P systems where both theparser and the associated simulator support the features inherent to this kind ofmodels.

Guards:

A subatomic guard g(w) ≡ w(a) γ an, is written as γ′a ∗n, being γ′ a repre-sentation of γ using < (for<), <= (for≤), = (for =), <> (para 6=), >= (for≥) and> (for >). As examples of use, <=+c*2 represents guard ≤ c2; while >=-brepresents ≥ b. Boolean operator involved in Boolean expressions, ∧ and ∨,are represented as && and ||, respectively. For instance, <=+a*2&&<=-brepresents guard ≤ a2∧ ≤ b. Similarly, <=-a*2||<=+b represents guard≤ a2∨ ≤ b. Operators ∧ and ∨ can be combined to describe complex guards,such as <=+a*2&&<=-b||<=-a*3&&<=+c*3.A rule r g is defined as @guard g ? r. For example, rule a→ b = a2 isdefined as @guard =+a*2 ? [a --> b].

Initialization of components (membranes/cells/compartments):

The initialization of the basic components in the system enables the designerdefining them in the initial configuration. Depending on the underlying struc-ture, syntax could slightly differ. This way,

mu(label1)+=[multiset]’label2;

is used for membrane structures in cell-like P systems, while

mu(0)*=[multiset]’label;

is used for the cells present in a conventional tissue-like P system, or in thecompartments present in simple kernel P systems.

Definition of initial multisets:

In the initialization of basic components of the system some multisets asso-ciated to each individual component has been included. It is also possibleto define the multiset associated to every compartment belonging to a cer-tain compartment type. This can be specified by a sentence as: ms(label) =

multiset;.

Thus, depending on the scope desired for the definition (specific compartmentor type of compartment) two options are possible:

5.3. Software tools for modeling and simulation 111

• Multiset associated to each specific compartment: it is included in theinitial configuration:

@mu = [[ a*2 ]’1 [ b ]’2 [ c*2 ]’2]’0;

• Multiset associated to all the compartments of a certain type:

@ms(1) = x;

@ms(2) = y*3;

New rule types in P-Lingua:

In order to define simple kernel P systems, some new rules have been addedto P-Lingua he description described in section 5.2.1:

Rewriting and communication rules:

A rewriting and communication rule u → v g, where u ∈ Mf (Γ),u 6= ∅, v = (a1, t1) . . . (ah, th), with aj ∈ Γ, th ∈ T and g a guard over Γ,is represented in P-Lingua as:

@guard g ? [a]’t0 --> [a1]’t1, ..., [ah]’th,

with t0 the type of the current compartment. The implementation ofthis type of rules in P-Lingua does not require t0 to be connected by anedge to every compartment of types ti, 1 ≤ i ≤ h in an explicit way, it isimplied by the rule itself as considered by P-Lingua.

Division rules:

A division rule [a]t → [v1]tj1 . . . [vp]tjp g, where a ∈ Γ, vj ∈ Mf (Γ),tj,p′ ∈ T and g is a guard over Γ, is represented in P-Lingua as:

@guard g ? [a]’t |--> [v1]’tj1, ..., [vp]’tjp;.

It is possible for some multiset vj , 1 ≤ j ≤ p to contain special symbol@d. This symbol is used to implement the previously cited mechanismallowing the decrease in the amount of space occupied, by removingcompartments not codifying a correct solution where no more rules areapplicable.

Both rewriting and division rules can be used joint with internal itera-tors (explained below), thus possibly appearing in the rules some labels,parameterized by some index, such as:

[a]’1 |--> [b]’2 &[c,di]’i:3<=i<=n;.

Internal iterators:

These iterators permit designers defining multisets, structures and guards de-pendent on parameters. These iterators expand the possibilities when definingrules and initial configurations. The syntax for internal iterators is as follows:


&items:index ranges,except by guards joined by ∨, that is the following:

|items:index ranges.

Different internal iterators might be combined in the same rule or sentence,but can not be nested.

Internal iterators can be used in three different contexts:

1. Internal iterators over multisets:

The syntax of this type of operators is

&multiset:index ranges

These iterators permit the extension of multisets in the definition of rulesor initial configurations.

2. Internal iterators over compartments:

The syntax for this type of operators is

&[multiset]’label:index ranges

They permit specifying communications to several compartments in theright hand side of rules (this mechanism can not be used for elements inthe left hand side).

3. Internal iterators over guards:

These iterators are a special case given that two different types of ele-ments could appear depending on the nature of the Boolean operatorsinvolved. These forms are:

&guard:index ranges, for conjunction, and

|guard:index ranges, for disjunction.

This way, expressions of the first type are used to build guards joined bythe operator ∧ (∧–joined guards), while the ones of the second type buildguards joined by operator ∨ (∨–joined guards). Besides, they are theonly internal operators that contradicts a previously stated constraint,so that they can be nested, by using an “∧–joined guard” inside an“∨–joined guard” (disjunctive normal form). By contrast, no “∨–joinedguards” can be defined inside “∧–joined guards”.

5.4. A solution for 3-COL problem based on simple kernel P systems 113

Some constraints exist over the indexes over internal iterators, so that theycan not be included in numerical expressions, as i + 1 in the expression&ai+1:1 <= i <= 10, nor they can be used to access indexed con-stants, as gi &agi:1 <= i <= 10.

5.4 A solution for 3-COL problem based on

simple kernel P systems

This last section in the chapter is devoted to present an efficient solution to 3-COL

problem by a family of simple kernel P systems. This work is described in furtherdetail in [43].

Following two computable functions, s and cod, are defined over the set of in-stances of 3-COL problem as follows:

s(G) = |V|cod(G) = Ai,j : i, j ∈ E , 1 ≤ i < j ≤ n

with G = (V, E) a non directed graph containing at least two vertices.

A family of simple kernel P systems is considered: Π = Π(n) : n ∈ IN, whereΠ(n) = (Γ, IO, T,G,C1, C2, iout, iin) is defined as follows:

• The working alphabet Γ is the following set:

Γ = A1, . . . , An ∪ Ai,j | 1 ≤ i < j ≤ n ∪ T1, . . . , Tn∪B1, . . . , Bn ∪ R1, . . . , Rn ∪ G1, . . . , Gn∪a, s,X, Y, Z, yes, no ∪ X1, . . . , X2n+3

Where:

– Ai, 1 ≤ i ≤ n, are symbols representing the n vertices in G.

– Ai,j , 1 ≤ i < j ≤ n, are symbols representing the possible edges in G.

– Ti, 1 ≤ i ≤ n, are symbols used in the process dividing compartments oftype C2.

– Bi, Ri, Gi, 1 ≤ i ≤ n, are symbols codifying the three colors (as in thecase of tissue-like P systems).

– Symbol a is used only in compartment C1 to select a single answer to belater sent to the environment.

– s,X, Y are symbols user in compartments of type C2.


– Z is a symbol to be sent to compartment C1.

– yes, no are the possible answers: one of them will reach the environmentfrom C1 in the last step of the computation, as required by the decisionproblem.

– Symbols X1, . . . , X2n+3 are used as a counter to control the maximumnumber of steps (2n+ 2) required by the only possible input from com-partments of type C2.

• IO = yes, no.

• T = t1, t2, with t1 = (R1, σ1) and t2 = (R2, σ2); that is, there exist twotypes of compartments t1 and t2. The execution strategy σ1 = σ2 is themaximal parallelism with the constraint for each compartment to apply, atmost, a division rule for each step of the computation.

The sets of rules are the following:

– R1 is the set of rules:

? r1,i : Xi → Xi+1, 1 ≤ i ≤ 2n+ 2.

? r1,2n+3 : aZ → (yes, 0).

? r1,2n+4 : aX2n+3 → (no, 0) ≥ Z.Rules r1,i, 1 ≤ i ≤ 2n + 2 are responsible for counting the first 2n + 2steps; during that stage, for each solution found, an object Z is sent fromC2 to C1; if one or more Z objects were received from compartments oftype C2, that is, there exist at least one solution, then the compartmentof type C1 sends yes to the environment; otherwise, if no Z object hasbeen received, after 2n+ 3 steps an object no is sent;

– R2 is the following set of rules:

Division rules:

? r2,2i−1 : [Ai]2 → [RiAi+1]2[Ti]2 = s.? r2,2i : [Ti]2 → [BiAi+1]2[GiAi+1]2, 1 ≤ i ≤ n− 1.

? r2,2n−1 : [An]2 → [RnX]2[Tn]2 = s.? r2,2n : [Tn]2 → [BnX]2[GnX]2.

These rules are applied at most in 2n steps, where all possible coloringsare obtained for the n vertices.

Rewriting and communication rules:

5.4. A solution for 3-COL problem based on simple kernel P systems 115

? r2,2n+1 : s→ λ g with g the following guard

= A1,2 = B1 = B2 ∨ = A1,2 = G1 = G2 ∨ = A1,2 = R1 = R2 ∨∨ . . . . . . . . . . . . . . . ∨

= An−1,n = Bn−1 = Bn∨ = An−1,n = Gn−1 = Gn∨ = An−1,n = Rn−1 = Rn

? r2,2n+2 : X → Y .

? r2,2n+3 : Y s→ (Z, 1).

The guard appearing in rule r2,2n+1 contains 3n(n − 1)/2 terms andchecks, for each pair 1 ≤ i < j ≤ n, if the colors in nodes i and jis the same. If the current compartment contains object s, then thatobject is removed and, from that moment, no rule will be applied tothat compartment.

Rule r2,2n+2 will transform X into Y once all possible calculation havefinished.

Rule r2,2n+3 will be applied a solution is present in the current compart-ment of type C2, and will send object Z to the compartment with typeC1.

• G = (1, 2, 1, 2).

• C1 = (t1, w1), C2 = (t2, w2), where w1 = aX1, w2 = A1 s.

• iout = 0; that is, the output of the system is codified in the environment.

• iin = 2; that is, the input compartment is the initial C2.

It is important to note that instance G = (V, E) of 3-COL problem will be pro-cessed by the simple kernel P system Π(s(G)) with input multiset cod(G).

6Case study 1: Modeling of a real

ecosystem

The aim of this chapter is to present a first application of the platform provided bythe software MeCoSim for the design of a plan for the management of the reservoirof Ribarroja in the area of Ebro River basin, managed by Endesa S.A., regardingthe presence of an exotic invasive species: Zebra Mussel. In the first section anoverview of some analyzed complex systems is shown. Section 6.2 is devoted topresent the main features of the ecosystem under study. In section 6.3 the modelingframework based on Population Dynamics P systems is presented, and the designof the proposed model is presented in section 6.4. The last section of this chaptershows the P-Lingua code of the model previously designed, and describes in detaila simulation application based on MeCoSim, customized by the system under study.

6.1 Computational modeling of real ecosystems

based on PDP

The first work in the field of ecosystems modeling within the framework of Mem-brane Computing [20, 21] took place in 2008, and was focused in the study of thepopulation dynamics of Bearded Vulture in the Catalan Pyrenees. In that work, a

117

Chapter 6. Case study 1: Modeling of a real ecosystem 118

novel computational model was presented applied to the cited ecosystem, studyingin the target area the population dynamics of Bearded Vulture, along with otherfive species providing the bones which vultures feed from.

In order for the experimental validation of the model designed in this frameworkto be possible, a first ad-hoc simulator [1] was developed, including in the sourcecode in C++ language all the data about the specific scenario under study: (a) therules of the system; (b) the parameters and constants; (c) the rest of the elementsof the model; and (c) the simulation engine itself.

In [19] a new model was presented, adding population density regulation, limitsover feeding in case of shortage, variability in terms of growth rate (“reproduction”)of Bearded Vulture and competition for certain resources.

The cited work makes use of P-Lingua framework [40] for specifying and simu-lating the model, stating a clear separation among: (a) the parser of the specificationlanguage and simulation engine, provided by P-Lingua developers; (b) the modelmade by the designer, specifying the structure, rules, multisets, etc. in the system;and (c) input data, provided by the end users.

Due to the success in the results coming from the previous modeling works, anew requirement was received from the company Endesa S.A., in order to work inthe modeling of an ecosystem placed in the reservoir of Ribarroja in the area ofthe Ebro River basin; specifically, the modeling of the ecosystem in this reservoirregarding an exotic invasive species: Zebra Mussel. This species has produced animportant damage both from an ecological and an economical point of view over thelast years and decades.

Thus, a computational model was designed, based on P systems, to providethe company with a global view of the problem to help, somehow, predicting theevolution of the density of larvae of this species [18].

After those previous experiences, different models based on P systems were de-signed, covering a broad range: (a) ecosystems related to scavenger birds in theNavarre Pyrenees and in Swaziland (South Africa); (b) ecosystems affected by ran-dom changes in the environment related to temperature, rain, etc. (developmentand growth of certain amphibians in ponds or lakes); (c) reintroduction of a speciesof birds in the Catalan Pyrenees (Hazel Grouse); (d) ecosystems very sensitive tofloods and high rainfalls (prediction of possible scenarios of extinction of species suchas the newt) and (d) the effect of pestivirus in the population dynamics of PyreneanChamois.

This would be the starting point to develop a general purpose application thatcould be customized to define each specific simulation application. That is, a generalsimulation environment providing the ability to:

6.2. Zebra Mussel in the reservoir of Ribarroja 119

1. Define the specific software simulation application (app) the user wants togenerate, adapted to each different problem.

2. Work with our models in the generated app.

3. Perform an experimental validation of the model and the virtual experimen-tation by the end user.

The basic components of an interface for the ecologists to work transparentlywith the ingredients of the problem domain, abstracting them from P systems orimplementation details. These components may include::

• Input mechanism to enter specific values for the parameters of the model.

• Input mechanism to enter initial populations for each proposed scenario.

• Input mechanism to add environmental conditions.

• General mechanism for setting simulation parameters.

• Mechanism for outputs generation and visualization.

These ideas established the starting point of MeCoSim, whose spectrum of featuresand functionalities will include other variants of P systems and their associatedsimulation algorithms.

6.2 Zebra Mussel in the reservoir of Ribarroja

Zebra Mussel is an exotic invasive species producing an important damage froman environmental and also an economical point of view, every place where it hassettled. Its presence in Spain was first detected in 2001, in the reservoir of Ribarroja,managed by the company Endesa S.A.

In section 6.2.1 the complexity of the design of a model related to Zebra Musselwill be analized. In section 6.4 the designed model based on PDP systems will bedescribed, and section 6.4.2 illustrate the process of releasing sound tools based onMeCoSim for the managers of the reservoir.

6.2.1 Description of the problem

Zebra Mussel is an exotic species producing a significant ecological change when in-vading an aquatic ecosystem. These individuals are true engineers of the ecosystem,


able to alter its structure and functioning [62]: produce changes in the water com-position in many aspects, and increase operative and maintenance costs, as wells asthe ones related to the release of drains and pipes [70, 60, 27].

The rapid expansion of this species and its important negative effectshave led tothe invest on numerous studies, focused on the study of the biology of the species,its geographical dispersion and its influence in the invaded environment. Many ofthem include essays of methods to try to control or eradicate the species. [100, 73,110, 105, 51, 52, 106, 99]

6.2.2 Biology of the species

Zebra Mussel (Dreissena polymorpha) is an aquatic bivalve mollusc presenting afast life cycle with a high reproductive potential, high mobility of larvae and a greatdispersal capacity[67, 12, 93]. Such life cycle presents two main stages: larval phase,suspended in the water column in planktonic state and a latter phase settled to thesubstrate in benthonic state, where it keeps during its whole young and adult life.

Figure 6.1: Zebra Mussel

Zebra Mussel is a dioecious species with a proportion of genders around 1:1. Thenumber of eggs emitted by female individual per reproductive cycle depends on itssize, influenced by its age [102, 23].

In [107] the influence of different factors over the size of mussels is studied,included the growth of its shell per instant (year) t + 1 in relation to its size ininstant t. Adjusting a logarithmic regression model over the corresponding valuesthe following equation is obtained:

Y = 6.6649 lnx− 13.235 (6.1)

where Y represents the size in millimeters, and X the age in years.

6.2. Zebra Mussel in the reservoir of Ribarroja 121

In [103, 113, 107] the number of eggs is estimated depending on the length ofthe shell by the expression:

Z = 0.4 · Y 4.4 (6.2)

The number of eggs for mussels between 20 and 53 weeks can be estimated from thefollowing expression:

Z = 12.15 d2 + 117.81 d− 3391.5, R2 = 0.9999 (6.3)

where variable d represents the age in weeks.

Above 53 weeks the expression would be:

Z = 1920.5 d− 79065, R2 = 0.9993 (6.4)

Larvae remain in the water column between 3 and 5 weeks [93]. Some of themare depredated by the adults themselves. After this larval stage, they fall over thesubstrate by the effect of gravity.

According to [104], the recruitment of young mussels depending on the densityof adult mussels is given by the expression:

R = −2 ·X + 1, X ≤ 0.5 (6.5)

with R the percentage of larvae being recruited and X representing the percentageof population with respect to the maximum carrying capacity.

The mortality rate from the spawning period to the beginning of juvenile phasecan reach up to 98% [66].

6.2.3 The species in the reservoir of Ribarroja

Two reproductive cycles are observed in the reservoir along the year: the mostimportant one, from March to June, and a second one, from October to November.The individuals produced in the first cycle could reach sexual maturity before thestart of the second one. The production of larvae is small when the temperature is inthe interval [12-15) oC, being bigger if the temperature raises 15-17 oC [60]. Giventhe size of the reservoir, the different temperatures arising and the movements amongdifferent zones, it might imply the mussels are in different stages of development inthe same area of the reservoir.

Zebra Mussel can form aggregates of individuals, forming different layers. Max-imum densities above 100.000 individuals per m2 has been observed [72], reachingup to 250.000 in the reservoir of Ribarroja[79].

The reservoir is placed in the Ebro River basin (see 6.2), in the Northeast osSpain. It has a length of 35 km and a variable deph reaching in some areas up


to 28 m. It receives water from Ebro river from the reservoir of Mequinenza, andfrom rivers Segre and Matarrana. Due to the different temperature of the upperand lower water currents, different thermal conditions and features of the substratesshould be taken into account [36].

Figure 6.2: Ebro river basin

The river is longitudinally structured in 9 different zones, each one divided in2 parts depending on their depths (U, upper y L, lower), summarizing 17 areas(see figure 6.3). This division is relevant, due to the different development rates ofmussels and different intensity depending on such environmental factors.

6.3. Approach and modeling framework 123

Figure 6.3: Division in zones in the reservoir

6.3 Approach and modeling framework

In order to perform the study of the population dynamics of Zebra Mussel in thereservoir of Ribarroja, the following factors have been considered:

1. The basic biological processes involved in the species life cycle, determined bythe thermal conditions and the soundness of tha substrate in each area understudy.

2. The special features related to the habitat: an artificial reservoir with watercurrents and changes in the renewal process over them, managed for the gen-eration of hydroelectric power, being affected by the features of the incomingwater.

3. The possibility for external larvae to enter from reservoirs and close tributaries,and the transference of individuals from external rivers to the reservoir throughthe traffic of vessels.

It is worth noting the influence of the water thermal conditions. It affectstheprobability for an individual to reproduce, as shown in table 6.1. In addition, thenature and composition of the substrate, specially its toughness and porosity, will


influence drastically the density of mussels and mortality rate of larvae, as shown intable 6.2.

Week 1 2 3 4 5 6 7 8 9 10 11

Cycle 1 (%) 4 4 7 15 20 20 15 10 3 1 1Cycle 2 (%) 80 15 5

Table 6.1: % of mussels starting reproduction per week, given the thermalconditions

Area Type I Type II Type III Type IV Capacity

1U 19 24 50 7 22022U 10 9 5 76 7773U 11 7 10 72 8514U 24 11 10 55 15935U 20 5 15 60 13256U 30 15 10 45 19857U 25 11 18 46 17551L 9 55 26 10 20792L 8 15 11 66 8993L 12 19 5 64 11074L 15 23 4 58 13355L 17 20 8 55 14226L 15 12 14 59 12227L 20 16 12 52 15368U 5 50 20 25 16809U 35 13 7 45 21478L 0 0 0 100 09L 22 28 14 36 1940

Table 6.2: % of terrain of each type of soil per zone: type I bedrock, type IIshingle, type III gravels, type IV small gravels, sands, silts, and capacity tohold mussels per zone

Another decisive factor is the effect of human actions over the water flow, affect-ing the movement of larvae among different zones or outside the environment.

In [26] a standarized protocol was presented for computational modeling basedon P systems, briefly presented below.

Stage 1: Purpose

The modelinig of the population of Zebra Musselin the reservoir of Ribarrojaand the development of tools to perfrom virtual experiments.


Stage 2: Processes

The main processes to model are the the following:

• Biology of the species: eggs release, larval phase, settlement to the substrate,mortality depending on state and depredation.

• Environmental processes: generation of thermal conditions, features of thesubstrate per zone and control of carrying capacity depending on its soundness.

• Human intervention: displacement of larvae among zones due to the watermanagement, and of adults due to the movement of vessels.

Figure 6.4 shows the different processes and interactions involving every twoarea, capturing the possibility of movements among adjacent zones in a specificorientation (unidirectional arrows) or in both (bidirectional arrows).


Figure 6.4: Processes and interactions

Stage 3: Input of the model and parameters to consider

The input of the model is the size of the initial population, along with someparameters regarding the biology of the species, the environment and the possiblehuman interventions.

Stage 4: Sequencing and parallelization of processes

In order to have a bigger control over the model, the process to be representedare sequenced. In this case, a partial sequencing of the process is proposed, as shownin figure 6.5.


Figure 6.5: Model blocks sequencing

The presence of young individuals reaching sexual maturity later than adultsincrements the difficulty of a sequencing of processes. This way, processes are saidto be unsynchronized.

A natural year involves the execution of two iterations of the basic cycle, corre-sponding to the two phases that take place in the two reproductive cycles of Zebra


Mussel along the year.

Stage 5: The model

The design of the model should reflect all the processes and input elementscommented in the previous stages descriptions, by using a Population Dynamics Psystem. This design is detailed in section 6.4.

Stage 6: Graphical analysis of a cycle in the execution of a model

In section 6.4.1 an execution trace of a cycle of the model is outlined, illustratingthe evolution of the objects in the system along he cycle. This allows us to deeplyanalyze the correction of the model and its accuracy with respect to the initialpurpose addressed, thus easing the detection of errors before adapting the model toa software platform to simulate it.

Stage 7: Design of the simulator

The model is translated to a language understandable by some machine ableto simulate its evolution. P-Lingua provides a language for specifying P systemsincluding PDP systems, along with the needed parsing and simulation tools. Thisway, it is only necessary to directly translate our model specification to P-Lingua

language, very close to the previous specification.

There will be necessary to have tools to introduce the data about specific sce-narios, generating the codification cod(s) of that input in the form of parameters tobe used in the model translated to P-Lingua. This tools must then permit settingthe number of cycle to simulate and a number of simulations to perform, and finallyreturn the output with a determined meaning for the end user. These aspects willbe covered by MeCoSim, as explained in section 6.4.2.

6.4 Design of the model

In order to detail the model, we start describing some notations used:

(a) Common indexes

- s (week): represents the weeks of interestfor the study (generally the range is1, . . . , 36).

- j (compartment): represents the different zones in which the reservoir is di-vided; the range is 1, . . . , 18, according to the order of appearance of thecolumns in table 6.3).

- c (reproductive cycle): represents the reproductive cycles (enumerated by 1and 2, respectively); the first one involves 20 weeks and the second 16.

6.4. Design of the model 129

- sem (semester): represents the semesters, being used to distinguished thevalues of parameters affecting differently to individuals depending on theirage measured in semesters (in principle, from 1 to 6).

- i (type of soil): represents the type of soil, and four are distinguished, enumer-ated from 1 to 4 (denoted good, medium-high, medium-low and bad, respec-tively, so that the more capacity the soil has to the settlement and preservationof mussels, the better the soil is considered).

(b) Parameters

Environmental conditions and influence over the species:

- Ts,j : temperature in week s for compartment j.

- ITc: temperature for starting the reproductive cycle c.

- PIs,c: proportion of larvae released during week s of reproductive cycle c.

- moc: mortality of eggs in reproductive cycle c (probability for them not to befertilized).

- Nj : number of individuals per square meter initially placed in compartmentj.

- qj : Nj/7, number of individuals for each range of age; from number Nj auniform distribution is considered for the ages of the individuals contained inthe compartment, including seven groups of age, five corresponding to adultsXs with 2 ≤ s ≤ 6, plus two additional ones representing young individualsaged 13 or 39 weeks.

- ps,j : probability for the reproduction to get enabled for individuals in com-partment j during week s. This value comes from the accumulated probabilityfor IT1 in the case of weeks 1 to 20 and IT2 for weeks from 21 to 36, from thenormal probability function N(Ts,j , 0.5).

Biological parameters:

- g1: percentage of eggs released in the first cycle.

- g2: reduction of eggs.

- g3: mortality of larvae.

- msem: mortality of individuals aged sem (in semesters).

Chapter 6. Case study 1: Modeling of a real ecosystem 130F

echa

Sem

1U

2U

3U

4U

5U

6U

7U

1L

2L

3L

4L

5L

6L

7L

8U

9U

8L

9L

8-1

4M

ar

19.4

11.2

11.2

11.8

10.3

9.5

9.5

8.5

9.0

9.0

9.1

8.2

8.5

8.5

11.8

9.7

0.0

8.9

15-2

1M

ar

210.1

11.7

11.7

12.0

11.5

10.3

10.3

9.1

10.0

10.0

9.6

8.5

9.7

9.6

12.9

10.7

0.0

9.9

22-2

8M

ar

310.8

12.2

12.2

12.1

12.6

11.0

11.1

9.6

10.9

10.9

10.0

8.7

10.9

10.7

13.9

11.7

0.0

10.9

29

Mar

-4

Ap

r4

11.0

12.7

12.7

12.3

12.8

12.0

12.0

10.3

11.0

11.0

10.6

9.4

11.4

11.2

14.4

12.4

0.0

11.4

5-1

1A

pr

511.2

13.1

13.1

12.5

13.0

13.0

12.9

10.9

11.1

11.1

11.1

10.1

11.9

11.7

14.9

13.1

0.0

11.8

12-1

8A

pr

611.9

13.5

13.5

13.0

13.2

13.3

13.1

11.7

11.6

11.6

11.8

10.7

12.1

12.1

15.5

13.6

0.0

12.2

19-2

5A

pr

712.5

13.8

13.8

13.5

13.3

13.5

13.2

12.5

12.0

12.0

12.5

11.3

12.2

12.5

16.1

14.0

0.0

12.6

26

Ap

r-2M

ay

813.1

14.3

14.3

14.3

13.9

13.8

13.7

13.1

12.8

12.8

13.2

11.9

12.7

13.1

16.7

14.6

0.0

13.3

3-9

May

913.6

14.8

14.8

15.0

14.5

14.0

14.1

13.6

13.5

13.5

13.8

12.5

13.2

13.6

17.2

15.1

0.0

14.0

9-1

6M

ay

10

14.2

15.4

15.4

15.4

15.2

15.0

15.2

14.2

14.2

14.2

14.4

13.2

14.1

14.4

17.5

16.0

0.0

14.6

17-2

3M

ay

11

14.8

16.0

16.0

15.8

15.8

15.9

16.2

14.8

14.8

14.8

15.0

13.9

15.0

15.2

17.8

16.9

0.0

15.1

24-3

0M

ay

12

15.9

16.7

16.7

16.4

16.5

16.8

16.8

15.9

15.9

15.9

15.8

14.3

16.0

16.1

17.8

17.6

0.0

16.0

31

May-6

Ju

n13

16.9

17.3

17.3

16.9

17.3

17.6

17.4

16.9

16.9

16.9

16.7

14.7

17.0

17.1

17.8

18.2

0.0

16.8

7-

13

Ju

n14

18.0

18.0

18.0

17.5

18.0

18.5

18.0

18.0

18.0

18.0

17.5

15.1

18.0

18.0

17.8

18.9

0.0

17.7

14-2

0Ju

n15

18.9

19.4

19.4

19.5

19.5

19.5

19.3

18.3

18.4

18.4

18.3

16.5

18.3

18.4

19.4

20.0

0.0

18.0

21-2

7Ju

n16

19.8

20.7

20.7

21.5

21.0

20.5

20.5

18.5

18.7

18.7

19.0

17.9

18.5

18.8

21.0

21.0

0.0

18.2

28

Ju

n-4

Ju

l17

20.4

21.9

21.9

23.2

22.3

21.4

21.5

18.3

18.5

18.5

19.2

18.3

18.8

18.9

22.4

22.0

0.0

18.6

5-1

1Ju

l18

21.0

23.0

23.0

24.8

23.5

22.2

22.4

18.1

18.2

18.2

19.3

18.6

19.0

19.0

23.8

23.0

0.0

18.9

12-1

8Ju

l19

22.2

24.0

24.0

25.3

24.2

23.1

23.1

18.5

18.4

18.4

19.8

18.7

20.4

20.0

24.0

23.6

0.0

20.5

19-2

5Ju

l20

23.3

24.9

24.9

25.7

24.9

23.9

23.8

18.9

18.5

18.5

20.2

18.7

21.8

20.9

24.1

24.1

0.0

22.0

26

Ju

l-1

Au

g21

23.5

25.0

25.0

25.7

25.0

24.0

23.8

19.1

18.8

18.8

20.6

19.4

21.9

21.0

24.1

24.4

0.0

22.2

2-8

Au

g22

23.8

25.1

25.1

25.7

25.1

24.1

23.9

19.2

19.2

19.2

20.9

20.1

21.9

21.1

24.1

24.7

0.0

22.4

9-1

5A

ug

23

24.0

25.2

25.2

25.7

25.2

24.2

23.9

19.4

19.5

19.5

21.3

20.8

22.0

21.2

24.1

25.0

0.0

22.6

16-2

2A

ug

24

23.6

25.1

25.1

25.5

25.2

24.2

23.6

19.7

20.3

20.3

21.9

21.3

21.5

21.2

24.1

25.1

0.0

22.0

23-2

9A

ug

25

23.2

24.9

24.9

25.2

25.1

24.1

23.2

20.0

21.0

21.0

22.5

21.7

21.0

21.2

24.0

25.2

0.0

21.3

30

Au

g-

5S

ep26

22.7

24.5

24.5

25.0

25.0

24.1

23.6

20.7

21.3

21.3

22.5

21.9

21.4

21.7

24.0

25.1

0.0

21.8

6-1

2S

ep27

22.2

24.0

24.0

24.8

24.9

24.1

23.9

21.3

21.5

21.5

22.5

22.1

21.8

22.2

24.0

24.9

0.0

22.2

13-1

9S

ep28

21.6

23.2

23.2

24.4

24.4

23.8

23.7

21.2

20.7

20.7

21.9

22.2

21.8

22.1

23.4

24.3

0.0

22.2

20-2

6S

ep29

21.0

22.3

22.3

24.0

23.8

23.4

23.5

21.0

19.9

19.9

21.3

22.2

21.8

22.0

22.7

23.6

0.0

22.1

27

Sep

-3

Oct

30

20.7

21.7

21.7

23.3

23.0

22.7

22.8

20.6

19.4

19.4

20.7

22.0

21.2

21.5

21.8

22.8

0.0

21.5

4-

10

Oct

31

20.5

21.1

21.1

22.7

22.2

22.0

22.2

20.3

19.0

19.0

20.1

21.8

20.6

21.0

20.8

22.0

0.0

20.9

11-1

7O

ct32

20.2

20.5

20.5

22.0

21.4

21.3

21.5

19.9

18.5

18.5

19.5

21.6

20.0

20.5

19.9

21.2

0.0

20.3

18-2

4O

ct33

19.9

19.7

19.7

21.0

20.3

20.3

20.4

19.1

17.4

17.4

18.7

20.7

19.2

19.7

18.4

20.1

0.0

19.3

25-

31

Oct

34

19.5

18.9

18.9

20.0

19.1

19.3

19.3

18.3

16.2

16.2

17.9

19.7

18.3

18.9

16.8

19.0

0.0

18.3

1-

7N

ov

35

19.1

17.9

17.9

19.0

17.9

18.2

18.2

17.6

15.1

15.1

17.0

18.7

17.4

18.0

15.3

18.0

0.0

17.2

8-

14

Nov

36

18.6

16.8

16.8

18.0

16.7

17.0

17.0

16.9

14.0

14.0

16.0

17.6

16.5

17.0

13.8

16.9

0.0

16.0

Tab

le6.3:

Average

water

temp

erature

eachw

eek,

oneach

compartm

ent


Properties of the compartment:

- SURFj : width (in meters) of compartment j.

- A2j : half-width (in meters) of compartment j.

- Lj : length (in meters) of compartment j.

- DSj : depth (in meters) of compartment j.

- Cj : capacity (in cubic meters) of compartment j.

- Si,j : percentage of soil of type i in compartment j. Given that 4 types of soilare distinguished, there will exist parameters from S1,j to S4,j .

- ASi: capacity to hold mussels by the type of soil i.

- ϕj : capacity of compartment j, calculated from the proportion of each typeof soil present in the compartment and the capacity of them.

Human intervention:

- LEj,c: External inoculation of larvaein compartment j during reproductivecycle c.

- PAj,j′ : probability for an adult mussel to be transported from compartmentj to compartment j′ due to the traffic of vessels.

- PRs,j,j′ : probability for larvae to be displaced during week s, from compart-ment j to compartment j′ due to the hydraulic regime for water renewal.

- CVs: multiplier factor for the probability of a larvae placed in an upper areato move to the lower one during week s. The corresponding probability is0.2 ∗ CVs.

(c) Symbols corresponding to objects in the model

- Xsem: adult mussels aged sem (in semesters) at the beginning of the year.

- Qs: young mussels aged s weeks at the beginning of the year.

- α, αi (with 1 ≤ i ≤ 7), βi (with 0 ≤ i ≤ 9) : auxiliary objects used to enableand synchronize density regulation processes.

- Ts: auxiliary object to trigger the process of pseudo-random generation oftemperatures during the weeks of each reproductive cycle.


- Ic: auxiliary object used to enable external inoculation of larvae at the begin-ning of reproductive cycle c.

- γs: auxiliary object representing the existence of favorable conditions of tem-perature to start the reproductive cycle during week s.

- γ: auxiliary object enabling the reproductive cycle in the membrane where itis placed, corresponding to week s.

- I ′: objects coming from external inoculation of larvae.

- V R: objects representing young mussels or adults, with the aim of controllingthe carrying capacity at the end of each cycle.

- Os: eggs produced during week s of reproductive cycle.

- Q′s,s2: young mussels aged s weeks during week s2.

- Ysem: adult mussels aged sem after reproduction stage.

- Vsem: adult mussels aged sem after mortality stage.

- V ′sem: adult mussels aged sem during the stage of possible displacement bytraffic of vessels.

- L1s: larvae generated from eggs released during week s, once finished theirviability stage.

- L2s: larvae in week s surviving mortality stage.

- L3s: larvae released during week s.

- Ls,i,j,j′ : larvae released durin week s that has spent i+1 weeks, with 0 ≤ i ≤ 3,in the water column.

- L′s: larvae released on week s that finished their period in the water column.

- δ, δ20, δ35 , δ36: auxiliary objects responsible for the synchronization of theobjects representing individuals.

- ρ, ρ0, ρ1, ρ2, ωi (con 0 ≤ i ≤ 15): objects involved in the synchronization ofthe carrying capacity process and the recruitment of young individuals.

- X ′sem: adult mussels aged sem semesters when there is no reproduction, laterevolving to Ysem.

- Q′′s+20: young mussels aged s + 20 generated from objects entering as Qs atthe beginning of the first reproductive cycle.


- Q′′s+16: similar to the previous one, for young mussels aged s + 16 generatedfrom objects entering as Qs in the second cycle.

- A, Ai (with 1 ≤ i ≤ 2): auxiliary objects for the regulation of the excess ofdensity for each compartment.

- AR: objects responsible for the regulation of maximum carrying capacity.

- DPi (with 0 ≤ i ≤ 39): auxiliary objects representing the availability inpercentage of capacity (possible excess over the maximum).

- QQs,k (with 1 ≤ s ≤ 52, 37 ≤ k ≤ 38): auxiliary objects that will finallyproduce objects Qs and X1 (if allowed by carrying capacity).

- XX2,k (with 37 ≤ k ≤ 38): auxiliary objects finally evolving to objects X2, incase it is permitted by the carrying capacity.

- T ′20: auxiliary object allowing the synchronization in tha Update stage to resetthe initial conditions.

(d) Formalization of the PDP system

The model presents the modules shown in figure 6.5. The simulation of a naturalyear implies the running of two cycles of the model. It is a PDP system of degree(18, 40) taking T ≥ 1 time units (steps),

Π = (G,Γ,Σ, µ, T,Π1, . . . ,Π18,R, E1, . . . , E40,RE)

where:

- G = (V, S) is the directed graph containing nodes V = e1, . . . , e18. Themovements among environments are shown in figure 6.6.

- The working alphabet, Γ, is the set:

Σ ∪ Om, L1m , L2m | 1 ≤ m ≤ 36 ∪ ∪γ, V R, δ20, δ, δ36, ρ∪ρi | 3 ≤ i ≤ 11 ∪ Xs, X

′s, Ys, Vs, V

′s | 1 ≤ s ≤ 6 ∪ Qd | 0 ≤ d ≤ 87∪

Q′d,m | − 19 ≤ d ≤ 72, 1 ≤ m ≤ 40 ∪ ωi | 1 ≤ i ≤ 15∪Q′′d | 16 ≤ d ≤ 52 ∪ A,α, η ∪ ARi | 1 ≤ i ≤ 5 ∪ As | 3 ≤ s ≤ 5∪αi | 1 ≤ i ≤ 7 ∪ DPi | 0 ≤ i ≤ 39 ∪ βi | 0 ≤ i ≤ 9∪QQd,k | 1 ≤ d ≤ 52, 37 ≤ k ≤ 38 ∪ XX2,k, | 37 ≤ k ≤ 38 ∪ T ′20, D

with Σ (alphabet of the environments) the following set:

Σ = I, I ′, I1, I2 ∪ Td | 0 ≤ d ≤ 35 ∪ γm | 1 ≤ m ≤ 36∪L3m | 1 ≤ m ≤ 39 ∪ L′m | 5 ≤ m ≤ 43∪Lm,i,j,j′ | 1 ≤ m ≤ 43, 0 ≤ i ≤ 4, 1 ≤ j ≤ 18, 1 ≤ j′ ≤ 18∪ρ0, ρ1, ρ2, ω0, δ20, δ35, δ36, A1, A2, AR


- µ = [ [ ]1 . . . [ ]39 ]0 is the membrane structure, and the initial multisets for theenvironment j are: M1,j = · · · =M36,j = ∅; M37,j =M38,j =M39,j = αy M0,j = Xqj,i

i , Qqj,dd | 1 ≤ j ≤ 18, 2 ≤ i ≤ 6, 1 ≤ d ≤ 52. Xi represents

adult mussels aged i semesters and qj,i is the number of them initially placedin environment j. Qd represents young mussels aged d weeks and qj,d is thenumber of them initially placed in environment j.

- T = 51 · 2 · Y ears. Each year is simulated by 2 cycles of 51 steps.

- E1 = · · · = E18 = T0, I1

- The set of rules in the system is the following:

External inoculation

re1,j ≡ ( I1 → ILE(j,1)I ′ )ej , 1 ≤ j ≤ 18

re2,j ≡ ( I2 → ILE(j,2) )ej , 1 ≤ j ≤ 18

r1 ≡ I [ ]00 → [ I ]00

r2 ≡ I ′ [ ]00 → [ I ′ ]00

Temperatures

re3,j,d ≡ (Tdp(d+1,j)−−−→ γd+1 Td+1 )ej

1 ≤ j ≤ 180 ≤ d ≤ 34, d 6= 19

re4,j,d ≡ (Td1−p(d+1,j)−−−→ Td+1 )ej

1 ≤ j ≤ 180 ≤ d ≤ 34, d 6= 19

r3,m ≡ γm [ ]00 → [ γm ]00 , 1 ≤ m ≤ 36

r4,m ≡ γm [ ]0m → [ γ ]−m , 1 ≤ m ≤ 36

r5,m ≡ [ γ ]−m → [ ]0m , 1 ≤ m ≤ 36

Reproductive cycle and eggs release

r6,m ≡ I [ ]−m → [ I ]0m , 1 ≤ m ≤ 36

r7,m ≡ X1 [ ]−m → [ ]0m , 1 ≤ m ≤ 36

r8,m,s ≡ Xs [ ]−m → V R [Xs ]0m

1 ≤ m ≤ 362 ≤ s ≤ 6

r9,m,d ≡ Qd [ ]−m → V R [Qd+m ]0m

1 ≤ m ≤ 2020−m ≤ d ≤ 52−m

r10,m,d ≡ Qd [ ]−m → V R [Qd+m−20 ]0m

21 ≤ m ≤ 3640−m ≤ d ≤ 72−m


r11,m,d ≡ Qd [ ]−m → V R [X1 ]0m

1 ≤ m ≤ 2053−m ≤ d ≤ 72−m

r12,m,d ≡ Qd [ ]−m → V R [X1 ]0m

21 ≤ m ≤ 3653−m+ 20 ≤ d ≤ 72−m+ 20

The formulas regulating the eggs production are:

Θ(s) = 1920.5 ·(

52

4+

52

2· s)− 79065, with 2 ≤ s 6 the age in semesters.

Ψ(d) = 12.15 · d2 + 117.81 · d− 3392, with 20 ≤ s ≤ 52 the age in weeks.

The corresponding rules are the following:


e1

e2

e3

e4

e5

e6

e7

e8

e9

e10

e11

e12

e15

e13

e14

e16 e18

e17

00

00

00

0 0

0 0

0 0

0 0

00

0 0

Figure 6.6: Main edges of the environments graph of the PDP system


r13,m ≡ [ I ]0m → Om [ ]0m , 1 ≤ m ≤ 36

r14,m,d ≡ [Qd ]0m → Q′d,m Og(1)·Ψ(d)m [ ]0m

1 ≤ m ≤ 2020 ≤ d ≤ 52

r15,m,d ≡ [Qd ]0m0.5−−−→ Q′d,m [ ]0m

1 ≤ m ≤ 2020 ≤ d ≤ 52

r16,m,d ≡ [Qd ]0m0.5−−−→ Q′d,m O

(1−g(1))·Ψ(d)m [ ]0m

21 ≤ m ≤ 3620 ≤ d ≤ 52

r17,m,d ≡ [Qd ]0m0.5−−−→ Q′d,m [ ]0m

21 ≤ m ≤ 3620 ≤ d ≤ 52

r18,m,s ≡ [Xs ]0m0.5−−−→ Ys O

g(1)·Θ(s)m [ ]0m

1 ≤ m ≤ 202 ≤ s ≤ 6

r19,m,s ≡ [Xs ]0m0.5−−−→ Ys O

(1−g(1))·Θ(s)m [ ]0m

21 ≤ m ≤ 362 ≤ s ≤ 6

r20,m,s ≡ [Xs ]0m0.5−−−→ Ys [ ]0m

1 ≤ m ≤ 362 ≤ s ≤ 6

r21,m ≡ [X1 ]0m0.5−−−→ Y1 O

g(1)·Θ(3

2)

m [ ]0m , 1 ≤ m ≤ 20

r22,m ≡ [X1 ]0m0.5−−−→ Y1 O

(1−g(1))·Θ(3

2)

m [ ]0m , 21 ≤ m ≤ 36

r23,m ≡ [X1 ]0m0.5−−−→ Y1 [ ]0m , 1 ≤ m ≤ 36

Natural mortality

r24,s ≡ [Ysm(s)−−−→ # ]00 , 1 ≤ s ≤ 6

r25,s ≡ [Ys ]001−m(s)−−−→ Vs [ ]00 , 1 ≤ s ≤ 6

Adults movements by vessels

re5,s,j,j′ ≡ (Vs )ejPA(j,j′)−−−→ (V ′s )ej′

1 ≤ s ≤ 61 ≤ j ≤ 181 ≤ j′ ≤ 18, j′ 6= j

re6,s,j ≡ (Vs )ejPA(j,j)−−−→ (V ′s )ej

1 ≤ s ≤ 61 ≤ j ≤ 18


r26,s ≡ V ′s [ ]00 → [Vs]00 , 1 ≤ s ≤ 6

Viability of eggs

r27,m ≡ [Omg(2)−−−→ # ]00 , 1 ≤ m ≤ 36

r28,m ≡ [Om(1−g(2))·(1−mo(1))−−−→ L1m ]00 , 1 ≤ m ≤ 20

r29,m ≡ [Om(1−g(2))·mo(1)−−−→ # ]00 , 1 ≤ m ≤ 20

r30,m ≡ [Om(1−g(2))·(1−mo(2))−−−→ L1m ]00 , 21 ≤ m ≤ 36

r31,m ≡ [Om(1−g(2))·mo(2)−−−→ # ]00 , 21 ≤ m ≤ 36

Mortality of larvae

r32,m ≡ [L1m1−g(3)−−−→L2m ]00 , 1 ≤ m ≤ 36

r33,m ≡ [L1mg(3)−−−→# ]00 , 1 ≤ m ≤ 36

r34,j,m ≡ [L2m ]00PI(j,1)−−−→ L3m+j−1 [ ]00

1 ≤ j ≤ 111 ≤ m ≤ 20

r35,j,m ≡ [L2m ]00PI(j,2)−−−→ L3m+j−1 [ ]00

1 ≤ j ≤ 31 ≤ m ≤ 36

Movements of larvae

Vertical movement

re7,j,m ≡ (L3m0.2·CV (m)−−−→ Lm,0,j,j+7 )ej

1 ≤ j ≤ 71 ≤ m ≤ 39

re8,j,m ≡ (L3m1−0.2·CV (m)−−−→ Lm,0,j,j )ej

1 ≤ j ≤ 71 ≤ m ≤ 39

re9,j,m ≡ (L3m0.001−−−→ Lm,0,j,j−7 )ej

8 ≤ j ≤ 141 ≤ m ≤ 39

re10,j,m ≡ (L3m1−0.001−−−→ Lm,0,j,j )ej

8 ≤ j ≤ 141 ≤ m ≤ 39

re11,j,m ≡ (L3m0.001−−−→ Lm,0,j,j−2 )ej

17 ≤ j ≤ 181 ≤ m ≤ 39


re12,j,m ≡ (L3m1−0.001−−−→ Lm,0,j,j )ej

17 ≤ j ≤ 181 ≤ m ≤ 39

Movement by hydraulic regime

Central areas in the reservoir

re13,j,m,i,j1,j2≡ (Lm,i,j,j1

PR(m,j1,j2)−−−→ Lm+1,i+1,j,j2 )ej

1 ≤ j ≤ 181 ≤ m ≤ 420 ≤ i ≤ 31 ≤ j1 ≤ 71 ≤ j2 ≤ 7

re14,j,m,i,j1≡ (Lm,i,j,j1

PR(m,j1,8)−−−→ # )ej

1 ≤ j ≤ 181 ≤ m ≤ 420 ≤ i ≤ 38 ≤ j1 ≤ 14

re15,j,m,i,j1,j2≡ (Lm,i,j,j1

PR(m,j1,j2)−−−→ Lm+1,i+1,j,j2 )ej

1 ≤ j ≤ 181 ≤ m ≤ 420 ≤ i ≤ 38 ≤ j1 ≤ 148 ≤ j2 ≤ 14

re16,j,m,i,j1≡ (Lm,i,j,j1

PR(m,j1,15)−−−→ # )ej

1 ≤ j ≤ 181 ≤ m ≤ 420 ≤ i ≤ 38 ≤ j1 ≤ 14

Lateral areas

re17,m,i ≡ (Lm,i,15,150.5−−−→ Lm+1,i+1,15,15 )e15

1 ≤ m ≤ 420 ≤ i ≤ 3

re18,m,i ≡ (Lm,i,15,150.5−−−→ Lm+1,i+1,15,1 )e15

1 ≤ m ≤ 420 ≤ i ≤ 3

re19,m,i ≡ (Lm,i,17,170.5)−−−→ Lm+1,i+1,17,17 )e17

1 ≤ m ≤ 420 ≤ i ≤ 3

re20,m,i ≡ (Lm,i,17,170.5−−−→ Lm+1,i+1,17,8 )e17

1 ≤ m ≤ 420 ≤ i ≤ 3

re21,m,i ≡ (Lm,i,17,150.5−−−→ Lm+1,i+1,17,15 )e17

1 ≤ m ≤ 420 ≤ i ≤ 3


re22,m,i ≡ (Lm,i,17,150.5−−−→ Lm+1,i+1,17,1 )e17

1 ≤ m ≤ 420 ≤ i ≤ 3

re23,m,i ≡ (Lm,i,16,160.5−−−→ Lm+1,i+1,16,16 )e16

1 ≤ m ≤ 420 ≤ i ≤ 3

re24,m,i ≡ (Lm,i,16,160.5−−−→ Lm+1,i+1,16,6 )e16

1 ≤ m ≤ 420 ≤ i ≤ 3

re25,m,i ≡ (Lm,i,18,180.5−−−→ Lm+1,i+1,18,18 )e18

1 ≤ m ≤ 420 ≤ i ≤ 3

re26,m,i ≡ (Lm,i,18,180.5−−−→ Lm+1,i+1,18,13 )e18

1 ≤ m ≤ 420 ≤ i ≤ 3

re27,m,i ≡ (Lm,i,18,160.5−−−→ Lm+1,i+1,18,16 )e18

1 ≤ m ≤ 420 ≤ i ≤ 3

re28,m,i ≡ (Lm,i,18,160.5−−−→ Lm+1,i+1,18,6 )e18

1 ≤ m ≤ 420 ≤ i ≤ 3

re29,j,j′,m ≡ (Lm,4,j,j′ )ej → (L′m )e′j

1 ≤ j ≤ 181 ≤ j′ ≤ 18, j′ 6= j5 ≤ m ≤ 43

re30,j,m ≡ (Lm,4,j,j → L′m )ej

1 ≤ j ≤ 185 ≤ m ≤ 43

r36,m ≡ L′m [ ]00 → [Q′0,m−1 ]00 , 5 ≤ m ≤ 43

No reproduction rules

re31,j ≡ (T19p(20,j)−−−→ γ20 ρ1 ρ0 )ej , 1 ≤ j ≤ 18

re32,j ≡ (T191−p(20,j)−−−→ δ20 ρ1 ρ0 )ej , 1 ≤ j ≤ 18

re33,j ≡ (T35 → δ36 ρ2 ω0 )ej , 1 ≤ j ≤ 18

- During the first cycle:

r37 ≡ δ20 [ ]00 → [ δ20 ]00

r38 ≡ δ20 [ ]020 → [ δ ]+20

r39 ≡ [ δ ]+20 → [ # ]020


r40,s ≡ Xs [ ]+20 → V R [X ′s ]020 , 2 ≤ s ≤ 6

r41 ≡ X1 [ ]+20 → [ # ]020

r42,d ≡ Qd [ ]+20 → V R [Q′′d+20 ]020 , 1 ≤ d ≤ 32

r43,d ≡ Qd [ ]+20 → V R [X ′1 ]020 , 33 ≤ d ≤ 52

r44,s ≡ [X ′s ]020 → Ys [ ]020 , 1 ≤ s ≤ 6

r45,d ≡ [Q′′d ]020 → Q′d,20 [ ]020 , 20 ≤ d ≤ 52

- During the second cycle:

r46 ≡ δ36 [ ]00 → [ δ36 ]00

r47 ≡ δ36 [ ]036 → [ δ ]+36

r48 ≡ [ δ ]+36 → [ # ]036

r49,s ≡ Xs [ ]+36 → V R [X ′s ]036 , 2 ≤ s ≤ 6

r50 ≡ X1 [ ]+36 → [ # ]036

r51,d ≡ Qd [ ]+36 → [Q′′d+16 ]036 , 1 ≤ d ≤ 36

r52,d ≡ Qd [ ]+36 → V R [X ′1 ]036 , 37 ≤ d ≤ 52

r53,s ≡ [X ′s ]036 → Ys [ ]036 , 1 ≤ s ≤ 6

r54,d ≡ [Q′′d ]036 → Q′d,36 [ ]036 , 16 ≤ d ≤ 52

r55 ≡ ρ0 [ ]00 → [ ρ0 ]00

r56 ≡ ρ0 [ ]037 → [ ρ0 ]037

r57,i ≡ [ ρi → ρi+1 ]037 , 0 ≤ i ≤ 10

r58 ≡ [ ρ11 ]037 → [ ρ ]−37

r59 ≡ ω0 [ ]00 → [ω0 ]00

r60 ≡ ω0 [ ]038 → [ω0 ]038

r61,i ≡ [ωi → ωi+1 ]038 , 0 ≤ i ≤ 14

r62 ≡ [ω15 ]037 → [ ρ ]−38

Recruitment level control


re34,j,i ≡ ( ρi → Aϕj

i AR2500 )ej

1 ≤ j ≤ 181 ≤ i ≤ 2

r63,i ≡ Ai [ ]00 → [Ai ]00 , 1 ≤ i ≤ 2

r64,i ≡ Ai [ ]036+i → [A ]036+i , 1 ≤ i ≤ 2

r65 ≡ AR [ ]00 → [AR1 ]00

r66,i ≡ [ARi → ARi+1 ]00 , 1 ≤ i ≤ 4

r67 ≡ AR5 [ ]039 → [AR ]+39

r68 ≡ [α → α1 DP0 ]+39

r69 ≡ V R [ ]+39 → [V R ]+39

r70 ≡ [α1 ]+39 → [α1 ]−39

r71 ≡ [ARV R ]+39 → [ # ]−36

r72,i ≡ [αi → αi+1 ]−39 , 1 ≤ i ≤ 6

r73 ≡ [AR125 → DP1 ]−39

r74,i,k ≡ [DPi DPk → DPi+k ]−39

0 ≤ i ≤ 201 ≤ k ≤ 9

r75 ≡ [α7 ]−39 → [β1 ]039

r76 ≡ [AR → # ]039

r77 ≡ [V R → # ]039

r78,i ≡ [DPi ]039 → DP 1250·250000i [ ]039 , 1 ≤ i ≤ 20

r79,i ≡ [βi → βi+1 ]039 , 1 ≤ i ≤ 7

r80 ≡ [β8 ]039 → [β9 ]−39

r81 ≡ [β9 ]−39 → [α ]039

Mortality depending on the density and recruitment of young individuals

r82,k ≡ [ ρ ]−k → [ η ]0k , 37 ≤ k ≤ 38

r83,k ≡ [α ]−k → [β0 ]0k , 37 ≤ k ≤ 38


r84,k,s ≡ Vs [ ]−k → [Vs ]0k

37 ≤ k ≤ 381 ≤ s ≤ 6

r85,m,d ≡ Q′d,m [ ]−37 → [Q20−m+d ]037

1 ≤ m ≤ 20m− 20 ≤ d ≤ 52 +m− 20

r86,m,d ≡ Q′d,m [ ]−37 → [V1 ]037

1 ≤ m ≤ 2053 +m− 20 ≤ d ≤ 71 +m− 20

r87,m,d ≡ Q′d,m [ ]−38 → [Q52−m+d ]038

21 ≤ m ≤ 400 ≤ d ≤ m

r88,m,d ≡ Q′d,m [ ]−38 → [V1 ]038

21 ≤ m ≤ 40m+ 1 ≤ d ≤ 83 +m− 52

Beginning of the process of mortality due to the excess of density

r89,k,s ≡ [VsA ]0k0.5·0.2·(s+1)−−−→ Xs+1 [ ]+k

37 ≤ k ≤ 382 ≤ s ≤ 5

r90,k,s ≡ [VsA ]0k1−0.5·0.2·(s+1)−−−→ [VsA ]+k

37 ≤ k ≤ 382 ≤ s ≤ 5

r91,k ≡ [A ]+k → [A0 ]0k , 37 ≤ k ≤ 38

r92,k,s ≡ [As ]+k → [As+1 ]0k

37 ≤ k ≤ 380 ≤ s ≤ 4

r93,k ≡ [β0 ]+k → [β1 ]0k , 37 ≤ k ≤ 38

r94,k ≡ [β1 ]+k → [β1 ]0k , 37 ≤ k ≤ 38

r95,k,i ≡ [βi ]0k → [αi+1 ]+k

37 ≤ k ≤ 381 ≤ i ≤ 6

r96,k,i ≡ [αi ]+k → [βi ]0k

37 ≤ k ≤ 382 ≤ i ≤ 6

r97,k ≡ [α7 ]+k → [ # ]−k , 37 ≤ k ≤ 38

r98,k,d ≡ [QdA0 ]0k → QQd,k [ ]+k

37 ≤ k ≤ 381 ≤ d ≤ 52

r99,k ≡ [V1A1 ]0k → XX2,k [ ]+k , 37 ≤ k ≤ 38

r100,k,s ≡ [VsAs ]0k → Xs+1 [ ]+k

37 ≤ k ≤ 382 ≤ s ≤ 5


r101,k,d,i ≡ QQd,kDPi [ ]+k0.1·i−1−−−→ QdX1 [ ]0k

37 ≤ k ≤ 381 ≤ d ≤ 5210 ≤ i ≤ 20

r102,k,d,i ≡ QQd,kDPi [ ]+k1−0.1·i−1−−−→ [A1 ]0k

37 ≤ k ≤ 381 ≤ d ≤ 5210 ≤ i ≤ 20

r103,k,i ≡ XX2,kDPi [ ]+k0.1·i−1−−−→ X2 [ ]0k

37 ≤ k ≤ 3810 ≤ i ≤ 20

r104,k,i ≡ XX2,kDPi [ ]+k1−0.1·i−1−−−→ [A2 ]0k

37 ≤ k ≤ 3810 ≤ i ≤ 20

r105,k,d,i ≡ QQd,kDPi [ ]+k → [A1 ]0k

37 ≤ k ≤ 381 ≤ d ≤ 520 ≤ i ≤ 9

r106,k,i ≡ XX2,kDPi [ ]+k → [A2 ]0k

37 ≤ k ≤ 380 ≤ i ≤ 9

Reset of initial configuration

r107 ≡ [ η ]−37 → T20 T′20 [α ]037

r108 ≡ [ η ]−38 → T0 [α ]038

r109 ≡ [ I ′ T ′20 ]00 → I2 [ ]00

r110 ≡ [T20 ]00 → T20 [ ]00

r111 ≡ [T0 ]00 → T0 [ ]00

r112 ≡ T ′20 [ ]+36 → [ ]036

r113,k,s ≡ [Vs ]−k → D [ ]0k

37 ≤ k ≤ 382 ≤ s ≤ 6

r114,k,s ≡ [Qd ]−k → D [ ]0k

37 ≤ k ≤ 381 ≤ d ≤ 87

r115,k ≡ [A5 ]−k → [ ]0k, 37 ≤ k ≤ 38

r116,i ≡ DPi [ ]−39 → [ ]039 , 0 ≤ i ≤ 20


6.4.1 Trace of the model

In order to ease the understanding of the dynamics of the model, a partial trace withits evolution is presented. The simulation of each year will involve the execution oftwo cycles of 51 steps of computation.

This trace is shown in figure 6.7, and the number of the corresponding configura-tion can be identified by the subindex of the object Ti present in the first steps in theenvironment; that is, external to membrane 0. The computation being simulatedwill depend on the data about the specific scenario introduced, and the applicablerules will have a certain probability to be applied.

For the example shown in figure 6.7, the first step consists on the simulation oftemperatures. During steps 2 to 5 reproduction process is performed. In step 6 theprocess of natural mortality of adults is applied (evolving the survivors from objectsYs to Vs), at the same time that tha viability of eggs is checked (evolving viable eggsfrom O1 to L11). In steps two processes are executed: on the one hand, the processof movement of adults by vessels, moving objects Vs among environments or to thecurrent one, evolving both cases to objects V ′s ; on the other hand, the process ofmortality of larvae, passing the survivors from L11 to L21 .

In step 8, adult mussels V ′s that reached the target environment, are transformedto Vs when passing into membrane 0. At the same time, eggs release is produced.To do so, objects of type L3m+j−1 , 1 ≤ m ≤ 20, 1 ≤ j ≤ 11 are produced, as shownin the trace, simulating the eggs release from week m (in the possible configurationshown in the trace would be m = 1, therefore coming from first week) until week11. In order to simplify the diagram, these objects are shown in the trace as L3s ,with s the week.

In step 9, the vertical movement of larvae is calculated, and steps 10 to 13 aredevoted to implement the movements among different areas of the reservoir due tothe water renewal regime along the 4 weeks that larvae can stay in the water column.Step 14 makes the effective movement, passing object L5,4,j,j′ in environment ej toL′5 in environment ej′ . In step 15 a new object is introduced in skin membrane(labelled by 0): the one corresponding to the young individual Q′0,4. Recall thatthese individuals we are analyzing in this trace comes from the reproduction in firstweek when favorable thermal conditions took place in first step, when passing fromT0 to T1. Just created objects Q′0,4 representing young individuals, will remain inmembrane 0 until the end of the reproductive cycle (with a duration of 20 weeks,as commented); no more changes in the trace are observed in the trace shown untilthe end of this reproductive cycle. Then, the processes of recruitment of larvae orcarrying capacity of mussels will be performed. At the end of the cycle, at step20, with a certain probability p(20, j), the object object γ20 will be produced in theenvironment, continuing the reproduction, or on the contrary δ20 will be produced


for no reproduction. From this step onwards, the remaining 32 steps of the firstcycle would take place, followed by the 51 steps of the second cycle, until finishingthe different processes involved in each year simulated by the model.


0

1

0

Xs

I1

36

0

37

0

39

0

38

0

α α

α

0

1

0

Xs

γ1

36

0

37

0

39

0

38

0

α α

α

0

1

0

Xs

36

0

37

0

39

0

38

0

α α

α

0

1

-

Xs

36

0

37

0

39

0

38

0

α α

α

0

1

0Xs Qd+1

36

0

37

0

39

0

38

0

α α

α

0

1

0

Ys

36

0

37

0

39

0

38

0

α α

α

0

1

0

36

0

37

0

39

0

38

0

α α

α

0

1

0

36

0

37

0

39

0

38

0

α α

α

0

1

0

Vs

36

0

37

0

39

0

38

0

α α

α

0

1

0

Vs

36

0

37

0

39

0

38

0

α α

α

0

1

0

Vs

36

0

37

0

39

0

38

0

α α

α

0

1

0

Vs

36

0

37

0

39

0

38

0

α α

α

0

1

0

Vs

36

0

37

0

39

0

38

0

α α

α

0

1

0

Vs

36

0

37

0

39

0

38

0

α α

α

0

1

0

Vs

36

0

37

0

39

0

38

0

α α

α

0

1

0

Vs

36

0

37

0

39

0

38

0

α α

α

0

1

0

Vs

36

0

37

0

39

0

38

0

α α

α

0

1

0

Vs

36

0

37

0

39

0

38

0

α α

α

0

1

0

Vs

36

0

37

0

39

0

38

0

α α

α

0

1

0

Vs

36

0

37

0

39

0

38

0

α α

α

0

1

0

Vs

36

0

37

0

39

0

38

0

α α

α

I I’

I’Iγ1

γ

I VR

I

VR

VR VR VR

VR VR VR

VR VR VR

VR VR VR

VR VR VR

... ... ...

... ... ...

... ... ...

... ... ...

... ... ...

... ... ...

... ... ...

O1

Q’d,1

I’ I’ I’

I’ I’ I’

I’ I’ I’

I’ I’ I’

I’ I’ I’

I’ I’ I’

Qd Qd Qd

Qd Qd Qd

Qd Qd Qd

Qd Qd Qd

Qd Qd Qd

Qd Qd Qd

QdQd Qd

Q’d,1Q’d,1Q’d,1





Vs

T0 T1 T2

T3 T4 T5

T6 T7 T8

T9 T10 T11

T12 T13 T14

T15 T16 T17

T18 T19

V’s

L11 L21

L31

L1,0,j,j’ L2,1,j,j’ L3,2,j,j’

L4,3,j,j’ L5,4,j,j’ L’5

Q’0,4 Q’0,4 Q’0,4

Q’0,4 Q’0,4 Q’0,4

δ20ρ1 ρ0

Configuration 0 Configuration 1 Configuration 2







Figure 6.7: Execution tracered: to remove, green: new, orange: modified


6.4.2 The model as a tool for the management of theecosystem

The model presented here captures many of the processes affecting the populationdynamics of Zebra Musselin the reservoir of Ribarroja, incorporating natural andhuman elements in the environment influencing its evolution.

Following the needed steps are presented to convert the model of Zebra Musselin an application to serve the managers of the reservoir as a tool to assist in decisionmaking processes, allowing him to analyze possible consequences and changes in thepopulation dynamics of the species and the ecosystem, depending on their possibleactions to be performed over the system.

The first step will be the translation of the model to a language understandableby the machine, through the writing of a P-Lingua file, very close to the syntaxdefined in the corresponding modeling framework.

Definition of the model in P-Lingua

Following the P-Lingua code corresponding to the model described is presented.An important part of the required information will depend on each particular sce-nario. Therefore, most of the code will be parameterized.

The basic structure of the file presents the type/variant of the model (throughthe directive @model) the structure of environments and membranes (@mu), the ini-tial multisets (@ms) and the corresponding rules. The working and environmentalphabets are inferred from the symbols used in the set of instructions given by thefile.

@model <probabilistic>

def main()

@mu = []’global;@mu(global) += [[]’0]’j,j : 101<= j <= 118;@mu(0,j) += []’m: 1<=m<=39, 101<= j <= 118;

@ms(0,j+100) += Xs*(qj) : 2<= s <= 6, 1<= j<= 18;@ms(0,j+100) += Q13*(qj), Q39*(qj) : 1<= j<= 18;@ms(36+m) += alpha : 1<=m<=3;@ms(j+100) += T0,I1 : 1<=j<=18;

/*** <External inoculation> ***//*re1*/ [I1]’j+100 --> [I*LEj,1,Ip]’j+100 :: 1: 1<=j<=18;/*re2*/ [I2]’j+100 --> [I*LEj,2]’j+100 :: 1: 1<=j<=18;/*r1*/ I[]’0 --> [I]’0 :: 1;/*r2*/ Ip[]’0 --> [Ip]’0 :: 1;/*** <End External inoculation> ***/

/*** <Simulation of temperatures and order of activation of reproduction> ***//*re3*/[Td]’j+100 --> [gammad+1,Td+1]’j+100 :: pd+1,j : 0<=d<=34,1<=j<=18,d<>19 ;/*re4*/ [Td]’j+100 --> [Td+1]’j+100 :: 1-pd+1,j : 0<= d <=34, 1<=j<=18,d<>19;/*r3*/ gammam[]’0 --> [gammam]’0 :: 1 : 1<=m<=36;/*r4*/ gammam[]’m --> -[gamma]’m :: 1 : 1<=m<=36;/*r5*/ -[gamma]’m --> []’m :: 1 : 1<=m<=36;


/*** <End Simulation of temperatures and order of activation of reproduction>***/

/*** <Preparation for start of reproduction> ***//*r6*/ I -[]’m --> [I]’m :: 1 : 1<=m<=36;/*r7*/ X1 -[]’m --> [#]’m :: 1 : 1<=m<=36;/*r8*/ Xs -[]’m --> VR[Xs]’m :: 1 : 2<=s<=6,1<=m<=36;/*r9*/ Qd -[]’m --> VR[Qd+m]’m :: 1 : 20-m<=d<=52-m, 1<=m<=20;/*r10*/ Qd -[]’m --> VR[Qd+m-20]’m :: 1 : 20-m+20<=d<=52-m+20, 21<=m<=36;/*r11*/ Qd -[]’m --> VR[X1]’m :: 1 : 53-m<=d<=72-m, 1<=m<=20;/*r12*/ Qd -[]’m --> VR[X1]’m :: 1 : 53-m+20<=d<=72-m+20, 21<=m<=36;/*** <End Preparation for start of reproduction> ***/

/*** <Reproduction> ***//*r13*/ [I]’m-->Om []’m:: 1 : 1<=m<=36;/*r14*/ [Qd]’m --> Qpd,m,Om*(g1*(12.15*d*d+117.81*d-3392))[]’m :: 0.5 :

20<=d<= 52, 1<=m<=20;/*r15*/[Qd]’m --> Qpd,m[]’m :: 0.5 : 20<= d =< 52, 1<= m <= 20;/*r16*/ [Qd]’m --> Qpd,m,Om*((12.15*d*d+117.81*d-3392)*(1-g1))[]’m :: 0.5 :

20<= d<= 52, 21<= m <= 36;/*r17*/ [Qd]’m --> Qpd,m[]’m :: 0.5 : 20<= d <= 52, 21<= m <= 36;/*r18*/ [Xs]’m --> Ys,Om*((1920.5*(52/4+52/2*s)-79065)*g1) []’m :: 0.5 :

2<=s<=6, 1<=m<=20;/*r19*/ [Xs]’m --> Ys,Om*((1920.5*(52/4+52/2*s)-79065)*(1-g1)) []’m :: 0.5 :

2<=s<=6, 21<=m<=36;/*r20*/ [Xs]’m --> Ys []’m :: 0.5 : 2<=s<=6, 1<=m<=36;/*r21*/ [X1]’m --> Y1,Om*((1920.5*(52)-79065)*g1) []’m :: 0.5 : 1<=m<=20;/*r22*/ [X1]’m --> Y1,Om*((1920.5*(52)-79065)*(1-g1)) []’m :: 0.5 : 21<=m<=36;/*r23*/ [X1]’m --> Y1 []’m :: 0.5 : 1<=m<=36;/*r24*/ [Ys --> #]’0 :: ms : 1<=s<=6;/*r25*/ [Ys]’0 -->Vs[]’0 :: 1-ms : 1<=s<=6;/*** <End Reproduction> ***/

/**** <Adult environment> ***//*re5*/ [[Vs]’j+100 []’jp+100]’global -->[[]’j+100 [Vps]’jp+100]’global:: PAj,jp:

1<=s<=6, 1<=j<=18, 1 <=jp<=18,j<>jp;/*re6*/ [[Vs]’j+100 ]’global -->[ [Vps]’j+100]’global:: PAj,j: 1<=s<=6, 1<=j<=18;/*r26*/ Vps[]’0 --> [Vs]’0 :: 1: 1<=s<=6;/**** <End Adult environment> ***/

/*** <Viability of eggs> ***//*r27*/ [Om --> #]’0 ::g2:1<=m<=36;

/*** <Temperature for success in fertilization> ***//*r28*/ [Om --> L1m]’0 ::(1-g2)*(1-mo1):1<=m<=20;/*r29*/ [Om --> #]’0 ::(1-g2)*mo1:1<=m<=20;/*r30*/ [Om --> L1m]’0 ::(1-g2)*(1-mo2):21<=m<=36;/*r31*/ [Om --> #]’0 ::(1-g2)*mo2:21<=m<=36;

/*** <Mortality> ***//*r32*/ [L1m --> L2m]’0:: (1-g3): 1<=m<=36;/*r33*/ [L1m --> #]’0:: g3 : 1<=m<=36;

/*** <Distribution per weeks> ***//*r34*/ [L2m]’0 --> L3m+k-1[]’0:: PIk,1: 1<=m<=20, 1<=k<=11;/*r35*/ [L2m]’0 --> L3m+k-1[]’0:: PIk,2: 21<=m<=36, 1<=k<=3;

/*** <Vertical movement of larvae> ***/

/*re7*/ [L3m --> Lm,0,j,j+7]’j+100:: 0.2*CVm: 1<=m<=39, 1<=j<=7;/*re8*/ [L3m --> Lm,0,j,j]’j+100 :: 1-0.2*CVm: 1<=m<=39, 1<=j<=7;/*re9*/ [L3m --> Lm,0,j,j-7]’j+100:: 0.001: 1<=m<=39, 8<=j<=14;/*re10*/ [L3m --> Lm,0,j,j]’j+100 :: 1-0.001: 1<=m<=39, 8<=j<=14;/*re11*/ [L3m --> Lm,0,j,j-2]’j+100:: 0.001: 1<=m<=39, 17<=j<=18;/*re12*/ [L3m --> Lm,0,j,j]’j+100 :: 1-0.001: 1<=m<=39, 17<=j<=18;

/*** <Movement among environments due to water renewal> ***/

/*** <Upper> ***//*re13*/ [Lm,i,j,j1--> Lm+1,i+1,j,j2]’j+100 :: PRm,j1,j2 :

1<=m<=42, 0<=i<=3, 1<=j<=18,1<=j1<=7,1<=j2<=7;


/*re14*/ [Lm,i,j,j1--> #]’j+100 :: PRm,j1,8 : 1<=m<=42, 0<=i<=3, 1<=j<=18,1<=j1<=7;

/*** <Lower> ***//*re15*/ [Lm,i,j,j1--> Lm+1,i+1,j,j2]’j+100 :: PRm,j1,j2 :

1<=m<=42, 0<=i<=3, 1<=j<=18,8<=j1<=14, 8<=j1<=14;/*re16*/ [Lm,i,j,j1--> #]’j+100 :: PRm,j1,15 : 1<=m<=42, 0<=i<=3, 1<=j<=18,8<=j1<=14;

/*** <Lateral areas> ***//*re17*/ [Lm,i,15,15--> Lm+1,i+1,15,15]’115 :: 0.5 : 1<=m<=42, 0<=i<=3;/*re18*/ [Lm,i,15,15--> Lm+1,i+1,15,1]’115 :: 0.5 : 1<=m<=42, 0<=i<=3;/*re19*/ [Lm,i,17,17--> Lm+1,i+1,17,17]’117 :: 0.5 : 1<=m<=42, 0<=i<=3;/*re20*/ [Lm,i,17,17--> Lm+1,i+1,17,8]’117 :: 0.5 : 1<=m<=42, 0<=i<=3;/*re21*/ [Lm,i,17,15--> Lm+1,i+1,17,15]’117 :: 0.5 : 1<=m<=42, 0<=i<=3;/*re22*/ [Lm,i,17,15--> Lm+1,i+1,17,1]’117 :: 0.5 : 1<=m<=42, 0<=i<=3;/*re23*/ [Lm,i,16,16--> Lm+1,i+1,16,16]’116 :: 0.5 : 1<=m<=42, 0<=i<=3;/*re24*/ [Lm,i,16,16--> Lm+1,i+1,16,6]’116 :: 0.5 : 1<=m<=42, 0<=i<=3;/*re25*/ [Lm,i,18,18--> Lm+1,i+1,18,18]’118 :: 0.5 : 1<=m<=42, 0<=i<=3;/*re26*/ [Lm,i,18,18--> Lm+1,i+1,18,13]’118 :: 0.5 : 1<=m<=42, 0<=i<=3;/*re27*/ [Lm,i,18,16--> Lm+1,i+1,18,16]’118 :: 0.5 : 1<=m<=42, 0<=i<=3;/*re28*/ [Lm,i,18,16--> Lm+1,i+1,18,6]’118 :: 0.5 : 1<=m<=42, 0<=i<=3;/*re29*/ [[Lm,4,j,jp]’j+100[]’jp+100]’global-->[[]’j+100[Lpm]’jp+100]’global :: 1 :

5<=m<=43, 1<=j<=18, 1<=jp<=18, jp<>j;/*re30*/ [Lm,4,j,j-->Lpm]’j+100::1: 5<=m<=43, 1<=j<=18;/*r36*/ Lpm []’0-->[Qp0,m-1]’0::1: 5<=m<=43;/*** <End of cycle> ***//*re31*/ [T19]’j+100 --> [gamma20,ro1,ro0]’j+100 :: p20,j : 1<=j<=18;/*re32*/ [T19]’j+100 --> [delta20,ro1,ro0]’j+100 :: 1-p20,j : 1<=j<=18;/*re33*/ [T35]’j+100 --> [delta36,ro2,omega0]’j+100 :: 1 : 1<=j<=18;

/*** <No reproduction> ***//*** <First cycle> ***//*r37*/ delta20[]’0-->[delta20]’0::1;/*r38*/ delta20[]’20-->+[delta]’20::1;/*r39*/ +[delta]’20-->[]’20::1;/*r40*/ Xs+[]’20-->VR[Xps]’20::1: 2<=s<=6;/*r41*/ X1+[]’20-->[#]’20::1;/*r42*/ Qd+[]’20-->VR[Qppd+20]’20::1: 1<=d<=32;/*r43*/ Qd+[]’20-->VR[Xp1]’20::1: 33<=d<=52;/*r44*/ [Xps]’20--> Ys[]’20::1: 1<=s<=6;/*r45*/ [Qppd]’20--> Qpd,20[]’20::1: 20<=d<=52;

/*** <Second cycle> ***//*r46*/ delta36[]’0-->[delta36]’0::1;/*r47*/ delta36[]’36-->+[delta]’36::1;/*r48*/ +[delta]’36-->[]’36::1;/*r49*/ Xs+[]’36-->VR[Xps]’36::1: 2<=s<=6;/*r50*/ X1+[]’36-->[#]’36::1;/*r51*/ Qd+[]’36-->[Qppd+16]’36::1: 1<=d<=36;/*r52*/ Qd+[]’36-->VR[Xp1]’36::1: 37<=d<=52;/*r53*/ [Xps]’36--> Ys[]’36::1: 1<=s<=6;/*r54*/ [Qppd]’36--> Qpd,36[]’36::1: 16<=d<=52;

/*** <Sincronization of carrying capacity control process> ***//*r55*/ ro0[]’0-->[ro0]’0::1;/*r56*/ ro0[]’37-->[ro0]’37::1;/*r57*/ [roi-->roi+1]’37::1: 0<=i<=10;/*r58*/ [ro11]’37-->-[ro]’37::1;

/*r59*/ omega0[]’0-->[omega0]’0::1;/*r60*/ omega0[]’38-->[omega0]’38::1;/*r61*/ [omegai-->omegai+1]’38::1: 0<=i<=14;/*r62*/ [omega15]’38-->-[ro]’38::1;

/*** <Needed objects for control of density> ***//*re34*/ [roi]’j+100 --> [Ai*Fij,AR*2500]’j+100::1: 1<=i<=2,1<=j<=18;/*r63*/ Ai[]’0 --> [Ai]’0::1: 1<=i<=2;/*r64*/ Ai[]’36+i --> [A]’36+i::1: 1<=i<=2 ;/*r65*/ AR[]’0 --> [AR1]’0::1;/*r66*/ [ARi]’0 --> [ARi+1]’0::1:1<=i<=4;/*r67*/ AR5[]’39 --> +[AR]’39::1;


/*r68*/ +[alpha]’39 --> +[alpha1,DP0]’39::1;/*r69*/ VR+[]’39 --> +[VR]’39::1;/*r70*/ +[alpha1]’39 --> -[alpha1]’39::1;/*r71*/ +[AR, VR]’39 --> -[]’39::1;/*r72*/ -[alphai --> alphai+1]’39::1: 1<=i<=6;/*r73*/ -[AR*125 --> DP1]’39::1;/*r74*/ -[DPi,DPk --> DPi+k]’39::1:0<=i<=20,1<=k<=9;/*r75*/ -[alpha7]’39 --> [beta1]’39::1;/*r76*/ [AR]’39 --> []’39::1;/*r77*/ [VR]’39 --> []’39::1;/*r78*/ [DPi]’39 --> DPi*(1250*250000)[]’39::1: 0<=i<=20;/*r79*/ [betai --> betai+1]’39::1: 1<=i<=7;/*r80*/ [beta8]’39 --> -[beta9]’39::1;/*r81*/ -[beta9]’39 --> [alpha]’39::1;/*** <End Needed objects for control of density> ***/

/*r82*/ -[ro]’k-->[eta]’k::1: 37<=k<=38;/*r83*/ -[alpha]’k -->[beta0]’k::1: 37<=k<=38;/*r84*/ Vs -[]’k --> [Vs]’k::1: 1<=s<=6, 37<=k<=38;/*r85*/ Qpd,m -[]’37 -->[Q20-m+d]’37::1: -20+m<=d<=52-20+m,1<=m<=20;/*r86*/ Qpd,m -[]’37 -->[V1]’37::1: 53-20+m<=d<=71-20+m,1<=m<=20;/*r87*/ Qpd,m-[]’38 -->[Q52-m+d]’38::1: 0<=d<=m, 21<=m<=40;/*r88*/ Qpd,m -[]’38 -->[V1]’38::1: 1+m<=d<=83-52+m, 21<=m<=40;

/*** <Mortality due to the excess of density> ***/

/*r89*/ [Vs, A]’k -->Xs+1 +[]’k:: 0.5*0.2*(s+1) : 2<=s<=5,37<=k<=38;/*r90*/ [Vs, A]’k --> +[Vs,A]’k:: 1-0.5*0.2*(s+1) : 2<=s<=5,37<=k<=38;/*r91*/ +[A]’k--> [A0]’k::1: 37<=k<=38;/*r92*/ +[As]’k -->[As+1]’k::1:0<=s<=4,37<=k<=38;/*r93*/ [beta0]’k -->+[beta1]’k::1: 37<=k<=38;/*r94*/ +[beta1]’k -->[beta1]’k::1: 37<=k<=38;/*r95*/ [betai]’k -->+[alphai+1]’k::1: 1<=i<=6,37<=k<=38;/*r96*/ +[alphai]’k -->[betai]’k::1: 2<=i<=6,37<=k<=38;/*r97*/ +[alpha7]’k -->-[]’k::1:37<=k<=38;/*r98*/ [Qd, A0]’k -->QQd,k+[]’k :: 1:1<=d<=52,37<=k<=38;/*r99*/ [V1,A1]’k--> XX2,k +[]’k::1:37<=k<=38;/*r100*/ [Vs,As]’k--> Xs+1 +[]’k::1:2<=s<=5,37<=k<=38;/*r101*/ QQd,k, DPi +[]’k -->Qd,X1[]’k :: 0.1*i-1:

1<=d<=52, 10<=i<=20,37<=k<=38;/*r102*/ QQd,k, DPi +[]’k--> [A1]’k :: 1-(0.1*i-1):

1<=d<=52,10<=i<=20,37<=k<=38;/*r103*/ XX2,k, DPi +[]’k-->X2[]’k :: 0.1*i-1: 10<=i<=20,37<=k<=38;/*r104*/ XX2,k, DPi +[]’k --> [A2]’k :: 1-(0.1*i-1): 10<=i<=20,37<=k<=38;/*r105*/ QQd,k, DPi +[]’k--> [A1]’k :: 1: 1<=d<=52, 0<=i<=9,37<=k<=38;/*r106*/ XX2,k, DPi +[]’k --> [A2]’k :: 1: 0<=i<=9,37<=k<=38;/*r107*/ -[eta]’37 -->T20,Tp20[alpha]’37::1;/*r108*/ -[eta]’38 -->T0[alpha]’38::1;/*r109*/ [Tp20,Ip]’0--> I2[]’0::1;/*r110*/ [T20]’0-->T20[]’0::1;/*r111*/ [T0]’0-->T0[]’0::1;/*r112*/ Tp20+[]’36--> []’36::1;

/***********Update**********//*r113*/ -[Vs]’k -->D[]’k::1: 2<=s<=6,37<=k<=38;/*r114*/ -[Qd]’k -->D []’k::1:1<=d<=87,37<=k<=38;/*r115*/ -[A5]’k-->[]’k::1:37<=k<=38;/*r116*/ DPi-[]’39-->[]’39::1: 0<=i<=20;

Configuration of an application based on MeCoSim adapted to the systemunder study

The model presented includes a number of parameters. The first step in definingan app based on a configuration file consists on the organization, the arrangement ofthe elements in the main window. Apart from the default debugging tab (Debug),


all the input and output information is organized as a rooted tree of tabs, where theroot element is the application itself, and the remaining tabs area defined as firstlevel tabs (children of the application), children of them, etc.

- Visual structure of the application: it is provided in TabsHierarchy tab in theconfiguration file, as shown in figure 6.8.

Figure 6.8: MeCoSim app settings - Visual structure

As shown in figure 6.8, the first element is the application Zebra Mussel, withTab Id 1, easily identifiable for being the first one and having Tab Parent Idequals to 0. The next level will be composed of the tabs Input and Outputthat have application as parent tab (Tab Parent Id 1). The tree structure oftabs of the set application is shown in figure 6.9.

For instance, for output results 5 leaf tabs have been defined, all of themchildren of Output, but any other arrangement could have been defined, asdifferentiating at a level Larvae and Adults, and inside the corresponding leafsfor each group, or distinguishing at a level Tabular outputs and Charts.

- Input and output tables:

In MeCoSim the information is entered in the form of tables. Figure 6.10shows the definition of the tables in the configuration file for Zebra Musselapplication.

The definition of the columns in table Area properties is shown in figure 6.11,including an identifier id for each column, and a tooltip to be displayed whenthe mouse is placed over some data of the column.

- Parameters for instantiating the system:


0

142

1

Parent

Child

3 6 7 8 9 10

11 12 13

15 16 17 18 19

4 5

Figure 6.9: MeCoSim app - Tabs tree structure

Figure 6.10: MeCoSim app settings - Tables

Figure 6.11: MeCoSim app settings - Table definition


From the information of the input tables, the needed parameters should begenerated for the model presented before. In figure 6.12 a subset of suchparameters definition is shown.

Figure 6.12: MeCoSim app settings - Parameters

The table of average temperatures with some test values to generate the cor-responding parameters are shown in figure 6.13.

Figure 6.13: MeCoSim app - Average temperatures per week

In some special cases we will need some very specific functionalities to beprovided as basic functions in a language. An example of functionality thatwas not provided from the beginning with MeCoSim, but using the extensi-bility mechanisms, being called during parameters generation, is shown infigure 6.14.

- Configuration of results from the simulation:

The calculated parameters allow the generation of the PDP system and sim-ulate the period stated by the user. In order to visualize the information, it


Figure 6.14: MeCoSim app settings - Advanced parameters

will be necessary to define which outputs to show for the simulation app ofZebra mussel.

Figure 6.15 shows a result obtained from the computation.

Figure 6.15: MeCoSim app settings - Auxiliary result

The previous result would show the results for each simulation individually,but the final result shoul be set, obtaining mean (AV G) and standard devia-tion (STDDEV POP ) for the sum of multiplicities just calculated.

Simulatoin environment use

Once the custom simulation app has been set, the designer can load the modeland scenario under study, debug it, checking it is correctly loaded and verifying theevolution of the associated PDP system matches the expected result.

The first step for debugging is the initialization. This implies the generation ofparameters for the model from the data about a specific scenario, the parsing of theP-Lingua model, along with the values of the parameters, and the construction ofthe structure needed to represent the PDP system.

It is possible that some errors appear during the parameters generation or theparsing process. In those cases, the corresponding messages will be shown in tabs


Figure 6.16: MeCoSim app settings - Result to show

Figure 6.17: MeCoSim app - Debugging - Parsing


Errors (for critical ones, avoiding the simulation to run) and Warnings (for noncritical ones).

Figure 6.18: MeCoSim app - Debugging - Messages

If the model initialized from P-Lingua model and the scenario have no errors,the proper buttons Step and Run steps will be enabled in the debugging tab, sucha way that the system can be simulated step by step, or run a number of steps,showing in Simulation Info tab the text details for each configuration (see figure6.19).

Alphabet viewer displays the objects of the alphabet of the system, as shownin figure 6.20. Such viewer organizes the object in a tree structure, syntacticallyordered, including as the children of each element the objects presenting differentindexes for the same object type.

Membrane structure viewer permits visualizing the environments and mem-branes contained on them, including their labels, structures in a hierarchical way(see figure 6.21).

Multisets viewer permits visualizing the structure along with the multisets presentinside each membrane of each environment in the current configuration of the system(see figure 6.22).


Figure 6.19: MeCoSim app - Simulation step by step

Figure 6.22: MeCoSim app - Multisets viewer

Once the model has been yet debugged, it can be experimentally validated.Among the input data, the population of mussels present in the reservoir in theinitial configuration should be provided. From these data, the corresponding objectswill be generated with different ages from the information about total population ofindividuals per square meter (ind/m2) per area, as shown in figure 6.23.


Figure 6.20: MeCoSim app - Alphabet viewer

Figure 6.21: MeCoSim app - Membrane structure viewer


Figure 6.23: MeCoSim app - Initial population

In figure 6.24 the need of setting the conditions of the environment is observed,as the properties of the types of soil or the properties of the area.

Once the model has been validated, the user will be able to use the applicationfor performing virtual environments. For instance, it would be interesting for themanagers of the reservoir to know which could happen in case of an external in-oculation of larvae was produced, an input of mussels due to movement of vesselshappened, or a more constant water renewal cycle was applied due to a long periodof heavy rains.

Sometimes will be easier to analyze the qualitative evolution of the species,instead of the exact number. For these cases, some type of graphical evolution bymeans of charts will be more informative. This chart will be also configurable forthe custom simulation app, as in the example shown in figure 6.26. This permitsstudying the evolution of the amount of larvae in a certain zone of the reservoir.


Figure 6.24: MeCoSim app - Area properties

Figure 6.25: MeCoSim app - Adults output


Figure 6.26: MeCoSim app - Larvae evolution chart

7Case study 2: Solving NP-complete

problems

This chapter is devoted to illustrate the set of functionalities provided by MeCoSim,together with P-Lingua, in the context of solving NP-complete decision problemsby means of families of recognizer P systems. Actually, as it was already hintedin the previous chapter, the work developed can be seen as building a general IDE(Integrated Development Environment), based on the parsing and simulating capa-bilities of P-Lingua, and exploiting the possibility to create custom-made simulationapps provided by MeCoSim.

Thus, such apps would allow the users to load associated models, introduce thedata of the instance to be solved, generate parameters for P systems instantiation,perform parsing and debugging tasks, analyze through a visual interface the alpha-bet, the structure of the system and the multisets associated with the basic regions(membrane/cell/neuron/environment). Moreover, another important feature is theability to store simulation results, design specific output formats (tables/charts),and help during the processes of invariants extraction, and formal verification.

In the full version of the thesis, this chapter covers 3-COL and SAT problems,although here, for the summarized version, only the first one will be discussed.

Two main aspects are addressed: (a) the (automatic) generation of invariantswhich confirm the confluence behavior of the P systems from the family which solves

163

Chapter 7. Case study 2: Solving NP-complete problems 164

the specific problem of generating all possible colorings of an undirected graph usingthree colors; and (b) the debugging and analysis of two solutions to 3-COL, one ofthem using tissue P systems with cell division and the other one using simple kernelP systems.

7.1 The 3-COL problem in MeCoSim

Section 1.4.3 from Chapter 1 describes an efficient solution to 3-COL problem, givenby a family of tissue P systems with cell division

Π = Π(〈n,m〉) : n,m ∈ IN

Recall that a particular undirected graph G with n nodes and m edges will be pro-cessed by system Π(〈n,m〉) with input multiset cod(G) (encoding the set of edges).

Such a solution for an abstract problem has to be instantiated when solving theproblem in practice for each particular graph considered.

The solution mentioned before solves an abstract problem. With the purpose ofmanaging this solution in a practical way, for specific instances of the problem, itwould be interesting to define an application, in this case based on MeCoSim. Thissimulation app could be used both for the designer of P systems aiming to analyzehis model in a deep way, assisted by automatic tools, and for the end user thatwants to know, for instance, if a valid coloring exist with three colors of a certainnon directed graph.

The next section 7.1.1 will be focused on a partial aspect of 3-COL problem;specifically, on the generation phase of all possible colorings of a graph with threecolors, and the contribution of MeCoSim and the methodology proposed for P systemsdesigners.

7.1.1 The problem of the generation of colorings

In section 5.3.1 a methodology for the modeling, simulation and verification (throughinvariants detection and model checking techniques) has been described, as illus-trated in figure 5.1. In such methodology, MeCoSim plays a crucial role through theintegration of distinct tools involved in the process. Thus, in section 4.2.3 a plugin isdescribed, for the integration of MeCoSim with Daikon invariants detection software,generating trace files from the simulation in MeCoSim and the configuration of thecorresponding custom extractions, and calling Daikon plugin for MeCoSim over thefile selected by the user.

7.1. The 3-COL problem in MeCoSim 165

In addition, section 4.3 includes a subsection properties verification for the in-tegration of the environment with Spin Model Checker through two possible mech-anisms: the direct simulation in MeCoSim by a simulator delegating in an externalprocess performed by Spin, or by a plugin presenting a window for executing step bystep each stage of the process: firstly, the generation of a Promela file from the sys-tem loaded in MeCoSim; after that, the simulation delegating in Spin from MeCoSim,showing the result in another panel in the window. Obviously, the file automaticallygenerated in MeCoSim could be manually edited to add the desired checking rules fortheir verification during the simulation by Spin.

In work [64] it was first presented this methodology, along with the integrationof the tools involved. In addition, the problems related to the generation phase, theproblems related to the generation phase of all possible coloring in a non directedgraph were analyzed. The corresponding solution to this partial problem would bepart of the solution of the 3-COL problem described in section 1.4.3. The directtranslation to P-Lingua code is the following:

@model<tissue_psystems>def main()

call init_cells();call init_multisets(n);call init_rules(n);

def init_cells()

@mu = [[]’2]’0;def init_multisets(n)

@ms(2) += Ai : 1<=i<=n;def init_rules(n)

/* r1 */ [Ai]’2 --> [Ri]’2 [Ti]’2 : 1<=i<=n;/* r2 */ [Ti]’2 --> [Bi]’2 [Gi]’2 : 1<=i<=n;

As happened in the full 3-COL problem, both the partial solution for the prob-lem and its translation to P-Lingua code are parameterized, depending on a specificvalue, the size of the graph (that is, the number of nodes, n) to generate the cor-responding tissue-like P system. A minimal MeCoSim based custom simulation appintroducing general data, as wells as the specific information, such a way that theuser is enabled to enter the value for n to simulate the evolution of the system vi-sually. The visual structure (tabs to show) of the application will be defined, alongwith the input table and the parameter to generate (that is, n, from table 1, row 1,column 1: <1,1,1>). In figure 7.1 the settings and resulting application are shown.

This application is yet ready to be used by the designer of P systems, able to loadthe solution, provide values for n to generate the corresponding parameter. Then,


Figure 7.1: Colorings - Definition and input visualization

he can visualize the created structures of the P system, debug, simulate step by step,visualizing the text answer in P-Lingua, or inspecting the tree with the structureand multisets present inside each compartment in the current step, as shown 7.2.

For this problem of generation of possible colorings, it would be interesting toanalyze the evolution of the number of cells present in the configuration for everystep of the computation, but it could be too tedious to look for the information intext or viewer tools. Thus, for instance, a custom output could be defined to showthe required information. However, when defining an output, instead of indicatinghow to generate the needed parameters, we should specify the information to beextracted from the whole computation in order to generate the proper output.

The definition to be made makes use of a custom language designed to play


Figure 7.2: Colorings - Debug

the role of an intermediate layer over SQLlanguage, to abstract some details, butpermitting as its lower layer the selection, filtering, grouping and ordering of theprocessed data about the computation, so that it is general enough to be adapted tovery different needs of information. Figure 7.3 the definition of the result to appearin the output.

Figure 7.3: Colorings - Output settings

As it can be seen, two different results are being set. Many times certain in-formation is needed, extracting certain information from the simulation by differentgrouping criteria; sometimes, depending on the specific need, it will be necessary todefine results based on previous ones,from the underlying database described in fig-ure 4.3. In this case, the subquery obtains (Select) pairs (step, membraneID) whose


membrane ID is different from 0, grouped by (step, membraneID) to avoid repeti-tions. Due to the database schema designed, each register represents the presenceof an object with a multiplicity inside a compartment (membrane/cell/neuron/en-vironment) in a certain step. Therefore, if no grouping (step, membraneID) wasprovided, one occurrence of that pair would result for each single object present inthat step in that cell.

In the problem of generating colorings an external membrane labeled 0 (andID 0) is present, and the rest of membranes will be cells labeled by 2, generatedby division, containing different partial colorings (only some nodes have a colorassociated to them) until getting, in the last step, coloring for the entire graph.The main query, whose result will be shown in table 2, will return for every stepthe count (COUNT) of the number of cells. The “parameter n” appearing in theconfiguration will show an additional column with the number n repeated for eachrow, with the aim of being used by a latter process that will be described below; ifthe only purpose of this output was to visualize step and number of cells, then itwould not be necessary. Figure 7.4 shows the output.

Figure 7.4: Colorings - Output

An additional interesting step, following some of the goals of the methodologybeing proposed, could be the detection of invariants (formula being true any mo-ment of the computation, or for a number of computations), non trivial (distinctfrom formula TRUE). These invariants would permit detecting properties related tothe solutions provided, based on P systems. However, it is worth noting that the


integration of MeCoSim with Daikon permits analyzing properties as, for example,the relation between the number of cells for every step or at the end, and the totalnumber n of nodes in the graph. To do so, the corresponding extractions for Daikonare set, according to the process described in section 4.2.3. In this case, the processwould made by the settings shown in figure 7.5, where also the resulting output isshown.

Figure 7.5: Colorings - Extraction settings

Making use of the automated traces extraction and invariants detection fromDaikon plugin integrated in MeCoSim, along with the possibility or joining differentextraction files from different instances of the problem for different values of n beforecalling Daikon plugin, some interesting results arose, regarding invariants detected,associated to the solution presented in this section. Some of the most relevant onesare shown in table 7.1. This trace extraction and invariants detection resultingfrom the simulation of the model could provide interesting clues about the model.Besides, they are very useful for this first detection. However, they should be laterverified by a model checker as Spin. In the right column of the table, it is indicatedif the detected property is finally true or not.

As it can be seen, the truth of these properties was proved: (a) for each step of


Extraction Result Valid

No. cells per step 0 . . . n numcells = 2step true

No. cells per step (n+ 1) . . . 2n numcells = 3(mod 4) false

No. cells per step(n+ 1) . . . (n+ (n/2) + 1) numcells = 3(mod 12) false

No. cells last step, fordifferent values of n put together numcells = 3n true

Table 7.1: Some invariants detected

computation from 0 to n, numcells = 2step is verified; and (b) in the last step ofcomputation, for every input of size n, numcells = 3n meets. It is worth noting that,given this verification process was performed by means of Spin, this last relation wasstated from the analysis of all possible paths from the computing tree. Therefore, italso provides us with information about the confluence of the system being analyzed,given that the cited property is meeting for every path along the tree.

7.1.2 3-COL simulation app in MeCoSim

In the previous section, starting from the study of the problem of generating color-ings, some of the main functionalities provided by MeCoSim environment has beenillustrated, along with its integration with other external tools for debugging thesolutions and analyzing the possible properties of the designs based on P systems,mainly within the scope of the P systems designer.

In this section the main contribution of this environment will be described re-garding its use by an end user. Thus, the starting point is the information aboutthe case study of 3-COL problem and its solution by a family of tissue-like P systemswith division rules, presented in section 1.3.3 of chapter 1. More specifically, will befocusing on the contribution of MeCoSim for providing a visual application for theend user of 3-COL problem to work, entering the input graph desired, and visualizingthe expected results. In addition, we will try to show the advantage of these typeof customizable tools in comparison with the monolithic inclusion of the data aboutspecific instances in the same file as the general solution given by the family of P sys-tems, by separating solution and scenario. Besides, we will study the possibility ofusing the same application and the settings for the inputs and outputs for analyzingsolutions based on different variants of P systems thanks to that decoupling.

Let us see the full translation to P-Lingua code of the full solution:


@model<tissue_psystems>def main()call tricolor_tissue(n,m);

def tricolor_tissue(n,m)call init_cells();call init_multisets(n);call init_environment(n,m);call init_rules(n,m);

def init_cells()@mu = [[]’1 []’2]’0;

def init_multisets(n)

@ms(1) = a1,b,c1,yes,no;@ms(2) = D;@ms(2) += Ai : 1<=i<=n;@ms(2) += Aei,1,ei,2 : 1<=i<=ne;

def init_environment(n,m)@ms(0) = Ai,Ri,Gi,Bi,Ti,noRi,noGi,noBi : 1<=i<=n;@ms(0) += ai : 1<=i<=2*n+m+@ceil(@log(m))+11;@ms(0) += ci : 1<=i<=2*n+1;@ms(0) += di : 1<=i<=@ceil(@log(m))+1;@ms(0) += zi : 2<=i<=m+@ceil(@log(m))+6;@ms(0) += Ai,j,Pi,j,noPi,j,Ri,j,Gi,j,Bi,j : i<j<=n,1<=i<n;@ms(0) += b,D,noD,e,T,S,N,bb;

def init_rules(n,m)

/* r1,i */ [Ai]’2 --> [Ri]’2 [Ti]’2 : 1<=i<=n;/* r2,i */ [Ti]’2 --> [Gi]’2 [Bi]’2 : 1<=i<=n;/* r3,i */ [ai]’1 <--> [ai+1]’0 : 1<=i<=2*n+m+@ceil(@log(m))+10;/* r4,i */ [ci]’1 <--> [ci+1*2]’0 : 1<=i<=2*n;/* r5 */ [c2*n+1]’1 <--> [D]’2;/* r6 */ [c2*n+1]’2 <--> [d1,noD]’0;/* r7,i */ [di]’2 <--> [di+1*2]’0 : 1<=i<=@ceil(@log(m));/* r8 */ [noD]’2 <--> [e,z2]’0;/* r9,i */ [zi]’2 <--> [zi+1]’0 : 2<=i<=m+@ceil(@log(m))+5;/* r10,i,j */ [d@ceil(@log(m))+1,Ai,j]’2 <--> [Pi,j]’0 : i<j<=n, 1<=i<n;/* r11,i,j */ [Pi,j]’2 <--> [Ri,j,noPi,j]’0 : i<j<=n, 1<=i<n;/* r12,i,j */ [noPi,j]’2 <--> [Bi,j,Gi,j]’0 : i<j<=n, 1<=i<n;/* r13,i,j */ [Ri,Ri,j]’2 <--> [Ri,noRj]’0 : i<j<=n, 1<=i<n;/* r14,i,j */ [Bi,Bi,j]’2 <--> [Bi,noBj]’0 : i<j<=n, 1<=i<n;/* r15,i,j */ [Gi,Gi,j]’2 <--> [Gi,noGj]’0 : i<j<=n, 1<=i<n;/* r16,j */ [noRj,Rj]’2 <--> [bb]’0 : 1<=j<=n;/* r17,j */ [noBj,Bj]’2 <--> [bb]’0 : 1<=j<=n;/* r18,j */ [noGj,Gj]’2 <--> [bb]’0 : 1<=j<=n;/* r19 */ [e,bb]’2 <--> []’0;/* r20 */ [e,zm+@ceil(@log(m))+6]’2 <--> [T]’0;/* r21 */ [T]’2 <--> []’1;/* r22 */ [b,T]’1 <--> [S]’0;/* r23 */ [S,yes]’1 <--> []’0;/* r24 */ [b,a2*n+m+@ceil(@log(m))+11]’1 <--> [N]’0;/* r25 */ [N,no]’1 <--> []’0;


As happened in the case of the problem of the colorings generation, it will bedesirable to have a visual application enabling us to introduce the input graph toanalyze in order to check if it is 3-colorable or not. By the configuration of theapplication based on MeCoSim, a new tab and table is defined containing the edgesof the graph, given the many possible input graphs that exists for a tissue-like Psystem with a certain number of nodes n. The input could be similar to the tableshown on the left side in figure 7.6.

Figure 7.6: 3-COL - MeCoSim app

Taking advantage of the graphs plugin described in section 4.2.3, in addition tothe debugging options shown in the previous section, the current graph could bevisualized, with their data coming from the input tables for general data (number ofnodes n and edges m) and the list of edges (a table with two columns indicating, foreach row, the node origin or target for each arc, in the case of a directed graph, orthe edge with the pair of nodes interconnected, in the case of a non directed graph).The visualization presented in 3-COL application based on MeCoSim is shown in figure7.7


Figure 7.7: 3-COL - Initial graph

These graphs are shown from the parameters generated depending on the con-figuration of the application, in this case producing parameters ek,1 y ek,2 for eachpair of nodes received as an input. These pairs of objects will generate objects Ai,j(1 ≤ i < j ≤ n) being part of the input multiset cod(ϕ). In addition, they will serveas information available to be used for any plugin, as in this case for GraphsPlugin.

The graph generated does not contain information about the position of thenodes, so in order to visualize the desired arrangement o nodes the user will beable to pick and move nodes visually. Besides, the configuration of the applicationpermits generating additional parameters to store a tree of graphs showing, forinstance, the objects that are present for each step, then inside each membrane; orthe ones present inside each membrane, then for each step. It is therefore a tree withtwo levels of depth, where each leaf node is a graph with the contents of a membranein a specific step, and each first level node shows the sequence of graphs of the lowerlevel depending on such node. An element of the tree of graphs can be seen in theexample shown in figure 7.8; as it can be observed, it has yet been colored.


Figure 7.8: 3-COL - Tree of graphs

The nodes will be colored according to the usual coding given by RGB format.Specifically, if an object Ri appears in a cell labeled by 2, then that node i will becolored with red color (Red); if an object Bj appears in a cell labeled by 2, then thatnode j will be colored in blue (Blue); finally, if an object Gk appears in a membranelabeled by 2, then that node k will be colored using green (Green).

Both the coloring and the meta-information present in the node can be setthrough the customization mechanisms provided by the parameters that can begenerated from the configuration of the custom application based on MeCoSim. Thus,for example, figure 7.9 shows, in addition to the initial information, not only the


color but also the text associated to the color (R, G or B).

Figure 7.9: 3-COL - A custom solution graph

As it can be observed, if we pay attention to the solution provided, the initialoutput answered the question of the decision problem: “does the graph admit a validcoloring with three colors?”. However, the environment proposed in this work makesavailable to P systems designers a set of tools permitting them to provide the endusers with an application with an added value.

7.1.3 A solution for 3-COL problem based on simple ker-nel P systems using P-Lingua and MeCoSim

In previous sections we have worked on a solution to 3-COL problem by means of afamily of tissue-like P systems with cell division.

In section 5.2.1 of chapter 5 the framework of simple kernel P systems wasintroduced, and their features and constraints were described regarding the types ofrules and execution strategies allowed. In addition, an alternative solution for 3-COLproblem by means of simple kernel P systems was presented, as published in [43].

In section 5.3 the main contributions and changes to P-Lingua were detailed toincorporate the new framework, simple kernel P systems, at the level of the languageand the tools for parsing and simulation.

This section has the aim of illustrating the customization of the application for


3-COL problem to be adapted to that solution based on simple kernel P systems.

Following P-Lingua code is provided corresponding to the alternative solutionto 3-COL problem cited above.

@model<simple_kernel_psystems>def main()call three_coloring(n);

def three_coloring(n)call init_cells();call init_multisets(n);call init_rules(n);

def init_cells()@mu = [[]’1 []’2]’0;

def init_multisets(n)

@ms(1) = a, X1;@ms(2) = A1, s;;@ms(2) += Aei,1,ei,2 : 1<=i<=ne;

def init_rules(n)/*r1,i*/ [Xi]’1 --> [Xi+1]’1 : 1<=i<=(2*n+2);/*r1,2*n+3*/ [a,T]’1 --> [yes]’0;/*r1,2*n+4*/ @guard >=-T ? [a,X2*n+3]’1 --> [no]’0;/*r2,2*i-1*/ @guard =+s ? [Ai]’2 |--> [Ri,Ai+1]’2 [Ti]’2 : 1<=i<=(n-1);/*r2,2*i*/ @guard =+s ?

[Ti]’2 |--> [Bi,Ai+1]’2 [Gi,Ai+1]’2 : 1<=i<=(n-1);/*r2,2*n-1*/ @guard =+s ? [An]’2 |--> [Rn,X]’2 [Tn]’2;/*r2,2*n*/ @guard =+s ? [Tn]’2 |--> [Bn,X]’2 [Gn,X]’2;/*r2,2*n+1*/ @guard

|=+Al1,m1&&=+Bl1&&=+Bm1&&=-Al1,l1:1<=m1<=(n),1<=l1<=(n-1) |||=+Al2,m2&&=+Gl2&&=+Gm2&&=-Al2,l2:1<=m2<=(n),1<=l2<=(n-1) |||=+Al3,m3&&=+Rl3&&=+Rm3&&=-Al3,l3:1<=m3<=(n),1<=l3<=(n-1) ?

[s]’2 --> []’2;/*r2,2*n+2*/ [X]’2 --> [Y]’2;/*r2,2*n+3*/ [Y,s]’2 --> [T]’1;

Obviously, this solution to 3-COL problem by means of simple kernel P systemsis very different from the one based on tissue-like P systems with cell division. Theassociated P-Lingua file follows this same pattern. However, is there any differencein the problem itself? The answer becomes clear: no.

The decision problem associated to (3-COL) consists on answering yes or no (thatis, sending a yes or no) to the possibility of coloring a non directed graph by usingthree colors, such a way that there does not exist neighbor nodes colored with thesame color. However, independently of the solution chosen, it will be necessary toenter the number of nodes of the graph and the list of edges of the graph.


Given the existence of new solutions for the same abstract problem, the samecustom application, as in the case of the one defined in section 7.1.2, can be usedfor any of them, starting from the same input data, also showing the same type ofoutputs. Taking into account that the application defined met the requirements forentering the input graph, it could be reused for the new solution within the frame-work of simple kernel P systems. This advantage derives from the clear decouplingof the different views of P systems designer, interested on the existence of distinctsolutions by different variants of P systems, and of the end user, intending to solvethe same problem independently of the underlying solutions.

In addition, in this case the parameters generated form the input data (number ofvertices n and pairs (ei,1,ei,2), needed for representing edges Aei, 1, ei, 2)are the same for both solutions. However, if the representation of the problemwas different among solutions, implying different input multisets cod(G), the entiresettings of input and output tables could remain the same, only modifying thecodification, by SimulationParams tab, that is, the settings to generate parametersfrom the input data.

Besides, if along with the decision problem, also the problem of the effectivecoloring of the graph would be required, and the computation of the variety ofsolutions implied different representation of the nodes among solutions, the rest ofthe application would remain the same, focusing the change only in the difference:in this case, the configuration of the desired output, indicating which are our objectsof interest depending on our representation, coding of the elements in our solution.The philosophy is again the decoupling of the different roles avoiding, whenever itis possible, the need of developing ad-hoc software for each problem or each solutionto the same problem, so that every role can be devoted to the focus of its work.

Finally, it is worth highlighting that similar applications based on MeCoSim andP-Lingua have been considered to study solutions by means of simple kernel P sys-tems for other NP–complete problems, such as Subset Sum or Partition, detailedin some published papers [56, 42].

Part III

Conclusions and future work

179

8Conclusions and future work

The present chapter has the aim of describing some of the main conclusions ex-tracted from the work developed along the last years, presented in this dissertation,emphasizing on the most important contributions made and outlining possible pathsto follow, from the one that has been opened.

8.1 Conclusions

The imperative need of the man for solving problems affecting his life from thebeginning of time, leads him to a relentless pursuit of tools helping him to face inthe most possible advantageous way such problems, in the whole variety of currentand potential situations that could arise.

The role of the knowledge of the man about the phenomena is essential to addressthe events in a better position. This is a matter of first step before he can risescenarios and assess the possible consequences of his acts a priori, being assisted bythose tools in his looking for answers or possible solutions to the problems.

Many of these problems addressed can be solved by mechanical processes. Inaddition, from the boom of the electronic computers we have been working with fromthe past century, a very powerful tool is available to help us attacking the practicalresolution of this kind of problems. From 1983, it is well known and proved thatthese devices have important limitations, but this tenacious and persistent pursuit

181

Chapter 8. Conclusions and future work 182

for new methods enabling us to solve problems, overcoming any possible barriers.

Under that premise, the wise Nature is observed, offering the man a vision ofthe way it solves the problems in a systematic way; among others, by proceduresgoverning the level of organization and functioning of the living cells and the tissuesthey form, as the essence of life, being the basic components where happen in anatural way a big number of processes inside each compartment of its structure, ata biochemical level.

With this inspiration, the paradigm of Membrane Computing is born. Aftersome years of intense study about its ability to solve problems, this vision is start-ing to be applied to their practical resolution, both at a theoretical and practicallevel, for real life problems affecting different aspects of the social, economical orbiological organization, at a micro or macro level; that is, at the micro level, mainlyof molecular or cellular biology, or at a scale that could be called macro (populationdynamics and complex systems, in general). In this context, it is made available forthe scientific community a novel tool able to solve problems and increase the knowl-edge about the phenomena, through the design of models capturing the portion ofthe reality under study, by adding the elements and interrelations considered morerelevant in the process of abstraction.

Once those models have been designed and validated, the possible answer of theunderlying complex systems could be studied, under certain situations occurring inthe past (with the aim of providing some explanation to phenomena that happened,whose cause is unknown), in the present (in order to solve immediate or short termproblems, under real current situations) or in the future (in order to previously havesome insight about the responses of the systems studied under certain potentialscenarios, or the expected consequences of possible actions the human being couldmake when managing those systems).

In this context of the practical resolution of problems, P-Lingua frameworkprovides software developers and designers of P systems powerful tools for the spec-ification, debugging and simulation of solutions to certain problems by means of Psystems.

The work developed in this dissertation intends to move a step forward to the realprovision, for the common human beings, of practical tools to solve problems withinthe cited scope. To do so, a methodology has been designed from the observationof the problem to solve, to the release of a software application to assist in the en ladeepening in knowledge about the phenomena under study, through the performanceof virtual experiments permitting to anticipate the response of the system studiedunder different possible scenarios of interest.

Along with the referred methodology, a visual environment for virtual simulationhas been developed, MeCoSim (Membrane Computing Simulator), that articulates the

8.1. Conclusions 183

proposed methodology through a set of tools general and flexible enough to coverthe biggest possible set of problems; at the same time, it should be customizableenough to be able to be adapted to the needs of each particular application usingthe methodology. This environment permits the release of applications adapted forthe end users of each particular problem, providing them with all the tools providedby P-Lingua framework in a transparent way, such a way that P systems are notthe goal for them but the media.

To meet that need, the environment will act as an IDE (Integrated DevelopmentEnvironment) for P systems designers, playing the role of an additional layer forthe introspection and visual treatment of the models based on P systems. Whilefor end users, a visual application will be made available for the management of thephenomena under interest, adapted to their application domain. In this application,the specific data for each particular scenario can be entered, in order to study,perform virtual experiments simulating the behavior of the real system and observethe outputs from the model, through tabular data or charts showing the evolution ofthe basic components, under the scope of the end user, not interested in the internaldetails of the underlying P systems and the complexity of the framework.

The goals of this environment require that it is also extensible enough to permitbroadening the covering of current and potential problems and functionalities. To doso, along with MeCoSim simulation environment, it has also been designed a pluginsarchitecture permitting the integration with other software tools implemented in thesame or different technologies than the one used by MeCoSim.

The environment has been integrated with some external tools through the de-velopment of a first set of plugins, as Daikon invariant detector or Spin ModelChecker. In addition, other plugins has been developed for visualizing structuresbased on graphs, with the aim of adding from MeCoSim functions developed in otherprogramming languages, as Haskell, or for the introduction of propositional formu-las in a language similar than the one used by Logicians.

It is worth highlighting the collaboration made in the development and inte-gration of certain simulators within the scope of Population Dynamics P systems,tissue-like P systems or spiking neural P systems. Given the diversity of these sys-tems and variants, in order to achieve certain goals, as the automated verification ofproperties related to some models, we participated in a collaboration for the prac-tical design and development of a new formalism with the aim of unifying, makingmore homogeneous in a certain sense, the existing variety of P systems. Within thisscope, there have been developed some tools in P-Lingua framework: an extensionof the language, a parser for the lexical-syntactic recognition of the language, aswells as a first simulator of a subset of this new formalism: simple kernel P systems.

The design of a methodology and the development of a series of tools to articulateits different phases can not, separately, prove the usefulness of a proposal for the


practical resolution of real problems affecting the human beings, both within thescope of real life applications and within the scope of the resolution of well knownNP-complete problems that can eventually influence over other problems, closer toeveryday needs.

Fortunately, from its beginning, this development has come accompanied bymultiple practical uses of the methodology and the tools, thus being applied toa number of problems both in real life (study of the population dynamics of realecosystems, as the Bearded Vulture in the Catalan or Navarre Pyrenees, analysis ofthe effects of pestivirus in the population of the Pyrenean Chamois in the CatalanPyrenees, reintroduction of a species of bird in Catalonia, plant alliances, newts,development and growth in natural ponds, porcine natural production, a control planfor the exotic invasive species Zebra Mussel, study of pandemics or gene networks,etc.) and within the scope of the computational complexity theory, applied to theresolution of well known NP-complete problems as SAT, 3-COL, Subset Sum, VertexCover or Partition.

These applications have made use or different variants as active membrane Psystems, tissue-like P systems with cell division, or with cell separation, spikingneural P systems, simple kernel P systems or Population Dynamics P systems (PDPsystems) within the scope of complex systems modeling.

The tools developed are being currently used by research groups from severaluniversities as Lleida, Sheffield (U.K.), Bucharest and Pitesti (Romania), Wuhanand Chengdu (China). Besides, we keep having news from new groups working withthe tools developed, (the last one we were recently aware of, from Malaysia [101]).

8.2 Future work

Following some of the main for possible future research lines deriving from thisdissertation are listed.

- Extend the methodology propose in this work with the aim of adding addi-tional aspects as: (a) treatment of uncertainty, for designs based on P systemsdepending on the values of some parameters being unknown or known witha certain level of precision; and (b) the analysis of the relevant data fromsimulations at a statistic level and, in general, in terms of Data Science.

- Expand and standardize the process of calling external simulators from thesimulation environment developed, such a way that it can be used the potentialflexibility of MeCoSim, as a front end able to be integrated with a varietyof external technologies, thus delimiting the protocols y and communication

8.2. Future work 185

formats in a clear way, by a robust design of a specific mechanism with externalparsers and/or simulators, local or remote, in a general and customizable way,according to the philosophy of MeCoSim.

- Modify the simulators available in P-Lingua or develop new ones inside theframework, not centered in the search for further parallelism (path being yetexplored by other interesting projects within the community of MembraneComputing), but materialized through the replacement of individual rulesbeing considered separately, by rules working at a symbolic level. This way, arule schema, given by the possible presence of several indexes covering a broadrange (possibly involving hundreds of thousands or even millions of separatedrules), could be treated as a single rule at a symbolic level, incorporatingsomehow the ranges for each index, and the possible intersections of rangesfrom different symbolic rules, in order to determine possible blocks competingfor certain resources (objects). This design would imply a huge save in termsof space occupied by the definition of rules, and possibly in terms of efficiency,effective time of simulation, given that usually only a small subset of the rulesin a schema are applicable and, nowadays, it is necessary to loop over themillions of individual rules to determine if each one of them is applicable ornot.

- Deepen in the idea recently started exploring of accelerating the simulation bytechniques based on RETE algorithm, used in other computational paradigmsthat, the same way as P systems, include designs based on rules. It wouldbe interesting to explore the combination of the symbolic definition just com-mented with some kind of adaption of RETE algorithm.

- Define P systems through visual tools, as a complement of the possibility ofdefining them by P-Lingua code, as proposed by MDE (Model Driven En-gineering). Some well known tools could be used for representing cellularstructures as, for example, Cell Designer. The output of this kind of pro-grams, generally in some standard formats as SBML or CellML, could thembe integrated as the input of MeCoSim. The other possibility would be thedevelopment, inside MeCoSim, of mechanisms of visual design, similarly to theinteresting visual interfaces developed in MetaPLab[22]. Any of those cases,derived P-Lingua files could then be generated in MeCoSim from the visualmodels.

- Diversify the possible output formats obtained from the computations, asthe custom outputs from the simulations, such a way that, in addition to thetabular and graphical outputs, some standard formats are provided as outputs.For instance, the ones accepted by gnuplot or based on json format. This lastoption has been yet started being explored, with some initial mechanism yet


working experimentally, providing outputs for the whole configuration, tablesand charts by json format, with the later automatic open and visualization viaweb browser, through libraries based on jQuery, Highcharts or Datatables.

- Improve and extend the documentation of the software MeCoSim, with morecomplete guides at an end user level, at the level of P systems designer, andfinally for developers. Besides, the reference of the different languages andtools included and used by MeCoSim should be exhaustively described. Thiswork have been yet started, specifically through the development of MeCoSimweb site.

- Provide a general mechanism for the extension of the functions available inMeCoSim for the generation of parameters, the simulation based on P-Lingua

or other mechanisms to be designed in the future. A common software in-terface could be developed to define functions through a number of possibleprogramming languages currently existing or appearing in the future, by usingsome standard mechanism as the one proposed for Java technology in JavaCommunity Process (JCP) by request JSR 223 (Scripting for the Java Plat-form). An interesting reference, a good example of this approach could beSAGE platform, making available a bunch of functionalities for symbolic andnumeric calculus under a common interface, many of them being provided bynumerous different external software packages, but transparently at disposalof the developer using SAGE.

- Provide more visibility to the addition of new MeCoSim repositories. Thecurrent mechanism of repositories allows any user to make available for thecommunity of Membrane Computing the apps, models or scenarios based onMeCoSim being designed or developed with a simple configuration. However,it would be necessary to design a good mechanism to the release of theserepositories and their dissemination. This way, they would be well known bythe community and each user would know how to easily access to any publishedrepository, from MeCoSim or from its web site. A good example in this sensewould be the plugins system of Eclipse [39], taken as an inspiration. At adissemination and sharing of models repositories level, it would be interestingto explore other systems making available a library of models as Netlogo [114].At a software development level, a great reference, a successful example, wouldbe the community of R [94] language, very active in the development of newplugins and packages for R, being shared for the community of users anddevelopers, so highly active that it presents a big number of new softwarepackages from different members of the community on a daily basis throughits web site. Definitely, it would be very interesting to try to design a goodmechanism for the management of repositories, including the submission andreception of requirement of new plugins releases and their sharing, also for

8.2. Future work 187

MeCoSim based simulation apps, models, solutions or scenarios. This processshould include the validation, standardization of the information required andpossible formats for publishing, dissemination, etc.

- Extend the models of computation and variants covered. The same mechanismnow available for inputs, outputs or plugins might be useful for running simu-lations for other P systems still not covered, inside P-Lingua nor in externalsimulators. They could be even useful for other models outside the paradigmof Membrane Computing, with completely different approaches providing al-ternative solutions for the same problems, such a way that some comparisonamong different approaches could be made within the same computationalframework or among different ones, mainly in different fields of Artificial In-telligence.

- Explore the possibility to incorporate in MeCoSim the resolution of optimiza-tion problems, in the framework of Evolutionary Membrane Algorithms, re-cently introduced [116]. Through these algorithms, the interactions are ex-plored between a discipline as Membrane Computing, well established withstrong theoretical foundations, and another one, Evolutionary Algorithms,with interesting properties such as the flexibility, the comprehensibility, andits usefulness to give successful answers to interesting real life problems froma broad range.

- Add to MeCoSim the possibility to act as a non connected simulation environ-ment, allowing the request for runs of simulations being launched internallywithout the need for the user to keep waiting the answer. It would be nec-essary to determine the mechanism to receive the results of the simulationand to post-visualize the configured outputs in the instant desired by the userinside MeCoSim.

- Include visual controls to ease the user introduce the scenarios under interest,in general well solved by the current approach, but for certain nature of theinformation to introduce being interesting to add buttons and controls similarto the ones used by Netlogo [114], such a way that the user does not need tointroduce all the input information by input tables but for some easier controlsin some cases. This could ease the end user the entering of information forparameters generation in some models. To do so, the corresponding mecha-nism must be developed to define which types of controls could be included,which data will be generated from these new visual controls and how this isperformed.

AThe Neverending Story

of software

Esta tesis, como todo en la Ciencia o en el software, no parte de cero. Se nutre de losesfuerzos de tantos que desde los anales de la Historia fueron haciendo este caminoal andar, al construir sus propias historias, al desarrollar sus propios pensamientos,al explorar el mundo con sus propios ojos y tratar de dar sus propias solucionesa los problemas. Dıa a dıa leemos lo que otros escribieron, aprendemos de lashistorias que otros vivieron, de los pensamientos que otros desarrollaron o de lasteorıas que otros pudieron demostrar. Vivimos en una historia interminable en laque en este momento alguien esta leyendo lo que yo he escrito, y mientras escriboeste texto pienso en lo que leı de otros, muchas historias interminables surgiran dela bifurcacion de este camino, el mıo, que partio de tan solo uno de los multiplescaminos interminables que se abrieron antes que el mıo...

Permıtaseme utilizar este anexo para escribir estas palabras en una reflexionque por seguro muchos otros hicieron antes que yo y que otros muchos continuaranhaciendo conforme la Historia se siga escribiendo. Por favor, no consideren preten-ciosas unas palabras que mas bien siento infantiles mientras escribo y evoco ciertaslecturas y visualizaciones de mi ninez, pero que tan presentes encuentro cada dıaen la Ciencia, en el Software, o en la labor docente en la que transmitimos a losque vienen nuestra propia historia, fruto de nuestra propia vision de la parcela deconocimiento que tratamos de transmitir.

189

190

A lo largo de la evolucion del Hombre, este ha ido acumulando experiencias,testimonios, contribuyendo al aumento del conocimiento acerca del mundo que nosrodea y las leyes que lo rigen. El valor del conocimiento y la sabidurıa desarrolladapor tantos seres humanos a lo largo de la Historia es de un valor incalculable, ycada esfuerzo que ponemos en ello trata de sumar para que entre todos lleguemosa un nuevo granito. No puedo por menos que sumarme a la vision del eminenteGrigori Perelman al considerar que su contribucion a la resolucion de la conjeturade Pointcare no era mayor que la de otros predecesores. No por la afirmacionen sı, con la que quizas no coincida, al entender que la aportacion de cada unode nosotros es genuina y tiene un valor unico porque no hay dos mentes igualescapaces de concebir el mundo y la resolucion de los problemas exactamente desde elmismo prisma. No por esa afirmacion, sino por la vision subyacente de que nuestraaportacion se sustenta sobre las que hicieron otros, que a su vez se apoyaron tantoen los caminos abiertos como descartados por otros, no negando en modo alguno lavalıa de cada aportacion pero sı dando siempre el valor que merecen sus predecesores.

Este pequeno anexo pretende por tanto, en primer lugar, hacer justicia con aque-llas aplicaciones y bibliotecas software que han hecho posible, facilitandolo enorme-mente, el desarrollo de MeCoSim. Para un modesto proyecto software como este, seha hecho uso de numerosos recursos desarrollados por otros, desde entornos de de-sarrollo hasta bibliotecas de software para Java o para la visualizacion de contenidosWeb. Mi infinito agradecimiento a los esfuerzos de los que invirtieron su tiempo y suenergıa en el desarrollo de herramientas que me permitieron resolver los problemasa los que me enfrentaba. Los textos cientıficos a los que alude esta memoria de tesisquedaban debidamente referenciados en el apartado de Bibliografıa, pero no podıaconcluir esta memoria sin referenciar aquı las herramientas software que tanto hanfacilitado el desarrollo de mi trabajo.

En segundo lugar, y para continuar con esta historia interminable, la ultimaseccion del anexo pretende describir las funcionalidades principales del sitio web deMeCoSim, como punto de partida para todos aquellos a los que puedan ser de utilidadla informacion y las herramientas desarrolladas, como lo fueron para mı aquellasdesarrolladas por otros. Se trata unicamente de un resumen de la funcionalidad,con el mero animo de ilustrar sobre los contenidos que se pueden encontrar en lacitada referencia, pero pretende ser un lugar de encuentro en constante actualizacion,en toda la medida posible, siempre que se considere que puede ser una herramientautil para desarrolladores de software, disenadores de sistemas P o usuarios finalesde cualesquiera modelos basados en sistemas P para los que el entorno desarrolladopueda aportar un valor.

The Neverending Story of software 191

Software used by MeCoSim

- Java platform and language. http://www.java.com/

- Eclipse IDE. http://www.eclipse.org/

- Netbeans IDE. https://netbeans.org/

- P-Lingua (pLinguaCore) Framework. http://www.p-lingua.org/

- Colt library. http://acs.lbl.gov/hoschek/colt/

- Jdom library. http://www.jdom.org/

- Jcommon. http://www.jfree.org/jcommon/

- Jfreechart. http://www.jfree.org/jfreechart/

- Java Swing (visual components).http://docs.oracle.com/javase/tutorial/uiswing/

- Visual Swing for Eclipse. https://code.google.com/p/visualswing4eclipse/

- Apache POI. http://poi.apache.org/

- Substance Look & Feel.http://grepcode.com/snapshot/repo1.maven.org/maven2/com.github.insubstantial/substance/

7.1

- SQLite. http://www.sqlite.org/

- HSQLDB. http://hsqldb.org/

- EclipseLink. http://www.eclipse.org/eclipselink/

- Apache Commons. http://commons.apache.org/

- Log4j. http://logging.apache.org/log4j/2.x/

- JavaCC. https://javacc.java.net/

- ANTLR. http://www.antlr.org/

- Daikon invariant detector. http://plse.cs.washington.edu/daikon/

- Spin. http://spinroot.com/spin/whatispin.html

- GHC. http://www.haskell.org/ghc/

- JUNG Java universal Network/Graph framework.http://jung.sourceforge.net/

- Gson. https://code.google.com/p/google-gson/

- jQuery. http://jquery.com/

- jQuery datatables. http://www.datatables.net/

- Highcharts. http://www.highcharts.com/

http://www.java.com/

http://www.eclipse.org/

https://netbeans.org/

http://www.p-lingua.org/

http://acs.lbl.gov/ hoschek/colt/

http://www.jdom.org/

http://www.jfree.org/jcommon/

http://www.jfree.org/jfreechart/

http://docs.oracle.com/javase/tutorial/uiswing/

https://code.google.com/p/visualswing4eclipse/

http://poi.apache.org/

http://grepcode.com/snapshot/repo1.maven.org/maven2/com.github.insubstantial/substance/7.1

http://grepcode.com/snapshot/repo1.maven.org/maven2/com.github.insubstantial/substance/7.1

http://www.sqlite.org/

http://hsqldb.org/

http://www.eclipse.org/eclipselink/

http://commons.apache.org/

http://logging.apache.org/log4j/2.x/

https://javacc.java.net/

http://www.antlr.org/

http://plse.cs.washington.edu/daikon/

http://spinroot.com/spin/whatispin.html

http://www.haskell.org/ghc/

http://jung.sourceforge.net/

https://code.google.com/p/google-gson/

http://jquery.com/

http://www.datatables.net/

http://www.highcharts.com/

192

- Twitter Bootstrap. http://getbootstrap.com/

- Bootbox. http://bootboxjs.com/

- Bootstrap slider. http://www.eyecon.ro/bootstrap-slider/

- FileReader.js. http://bgrins.github.io/filereader.js/

- FileSaver.js. https://github.com/eligrey/FileSaver.js/

- JsonEditor. http://jsoneditoronline.org/

- IzPack. http://izpack.org/

- DCP Setup Maker. http://sourceforge.net/projects/devcompack/

- Getdown. https://github.com/threerings/getdown/

- Sphinx web doc generation. http://sphinx-doc.org/

http://getbootstrap.com/

http://bootboxjs.com/

http://www.eyecon.ro/bootstrap-slider/

http://bgrins.github.io/filereader.js/

https://github.com/eligrey/FileSaver.js/

http://jsoneditoronline.org/

http://izpack.org/

http://sourceforge.net/projects/devcompack/

https://github.com/threerings/getdown/

http://sphinx-doc.org/


MeCoSim web site

During the work presented in this dissertation, as complementary goals for the designof the proposed methodology, the development of the visual simulation environmentand the application to a different case studies in real life and NP-complete problems,we have tried to lay the foundations for the sound dissemination of the software de-veloped and the case studies. To do so, MeCoSim web site has been developed andpublished, with the intent of acting as the meeting point for the current commu-nity of users and all the potential ones interested in this proposal and simulationenvironment.

The main aspects collected in this site are the following:

- Download and installation of the software, based on Java 1.7, available forplatforms based on Windows, Unix and Mac OS X. The installation is auto-matically launched from Install button in web site (see figure A.1), showingan assitant to install the application in a fast an easy way, by successivelyclicking Next in every screen; then a shortcut is created in the user desktop,becoming available for running MeCoSim.

Figure A.1: MeCoSim web site - Installation

194

- General description of the simulation environment, main features and morerelevant data.

Figure A.2: MeCoSim web site - Features

- Documentation to start using MeCoSim, including a user manual, a guide todesign new user custom applications, foundational paper about MeCoSim, anda number of videos showing the main features provide by the tools availablein the program.

Figure A.3: MeCoSim web site - Documentation


- Case studies, categorized by types of P systems, including cell-like P systems(with examples of transition and active membrane P systems), tissue-like Psystems (with examples of division rules and separation rules), spiking neuralP systems, simple kernel P systems and a number of case studies within thescope of Population Dynamics P systems.

For each example, along with its general description, a series of files are pro-vided to work with the example in MeCoSim. These files include applica-tion files (.xls, with the definition of the MeCoSim based simulation app,adapted for the case study), model/solutoin files (.pli, with the correspond-ing P-Lingua code for the solution designed), and scenario files (.ec2, withthe input and output data for each scenario being studied by the user).

Figure A.4: MeCoSim web site - Case studies

Bibliography

[1] Bearded vulture c++ ad-hoc simulator. http://www.gcn.us.es/?q=node/

338.

[2] Gnu gpl license. http://www.gnu.org/licenses/gpl.html.

[3] Hsqldb sql syntax web page. http://www.hsqldb.org/doc/guide/ch09.

html.

[4] The mecosim quick application developing reference guide. http://www.

p-lingua.org/mecosim/doc/_downloads/MeCoSimQuickGuide.pdf.

[5] Nvidia cuda c programming guide 4.2. http://developer.

download.nvidia.com/compute/DevZone/docs/html/C/doc/CUDA$_$C$_

$Programming$_$Guide.pdf.

[6] Opencl standard webpage. http://www.khronos.org/opencl.

[7] The openmp api specification for parallel programming, official website. http://www.openmp.org.

[8] P-lingua supported models variants. http://www.p-lingua.org/wiki/

index.php/Supported_models.

[9] Spin web site. http://www.spinroot.com/.

[10] The stochastic pi-machine. http://www.doc.ic.ac.uk/~anp/spim/.

[11] H. M. A. Arkin, J. Ross. Stochastic kinetic analysis of developmental path-way bifurcation in phage lambda-infected escherichia coli cells. Genetics, 149(4):1633–1648, 1998.

[12] J. D. Ackerman, B. Sim, S. J. Nichols, and R. Claudi. A review of the earlylife history of zebra mussels (dreissena polymorpha): comparisons with marinebivalves. Canadian journal of zoology (Canada), Canadian journal of zoology(Canada). Jul 1994. v. 72(7) p. 1169-1179; 1994-07-01.

197

http://www.gcn.us.es/?q=node/338

http://www.gcn.us.es/?q=node/338

http://www.gnu.org/licenses/gpl.html

http://www.hsqldb.org/doc/guide/ch09.html

http://www.hsqldb.org/doc/guide/ch09.html

http://www.p-lingua.org/mecosim/doc/_downloads/MeCoSimQuickGuide.pdf

http://www.p-lingua.org/mecosim/doc/_downloads/MeCoSimQuickGuide.pdf

http://developer.download.nvidia.com/compute/DevZone/docs/html/C/doc/CUDA$_$C$_$Programming$_$Guide.pdf



http://www.khronos.org/opencl

http://www.openmp.org

http://www.openmp.org

http://www.p-lingua.org/wiki/index.php/Supported_models

http://www.p-lingua.org/wiki/index.php/Supported_models

http://www.spinroot.com/

http://www.doc.ic.ac.uk/~anp/spim/

BIBLIOGRAPHY 198

[13] L. Adleman. Molecular computations of solutions to combinatorial problems.Science, 226:1021–1024, 1994.

[14] M. Ben-Ari. Principles of the Spin Model Checker. Springer-Verlag, London,2008.

[15] G. Bravo, L. Fernandez, and M. A. Pena. Hierarchical master-slave architec-ture for membrane systems implementation. In M. Sugisaka and H. Tanaka,editors, 13th International Symposium on Artificial Life and Robotics, pages485–490, 2008.

[16] F. Cabarle, H. Adorna, and M. A. M. del Amor. A spiking neural p systemsimulator based on cuda. Lecture Notes in Computer Science, 7184:87–103,2012.

[17] F. C. Cabarle, H. N. Adorna, M. A. M. del Amor, and M. J. Perez-Jimenez.Improving gpu simulations of spiking neural p systems. Romanian Journal ofInformation Science and Technology, 15:5–20, 06/2012 2012.

[18] M. Cardona, M. A. Colomer, A. Margalida, A. Palau, I. Perez-Hurtado, M. J.Perez-Jimenez, and D. Sanuy. A computational modeling for real ecosystemsbased on p systems. Natural Computing, 2010.

[19] M. Cardona, M. A. Colomer, A. Margalida, I. Perez-Hurtado, M. J. Perez-Jimenez, and D. Sanuy. A p system based model of an ecosystem of somescavenger birds. In Membrane Computing, volume 5957 of Lecture Notes inComputer Science, pages 182–195. Springer Berlin / Heidelberg, 01/2010 2010.10th International Workshop, WMC 2009, Curtea de Arges, Romania, August24-27, 2009, Revised Selected and Invited Papers.

[20] M. Cardona, M. A. Colomer, M. J. Perez-Jimenez, D. Sanuy, and A. Margal-ida. A p system modeling an ecosystem related to the bearded vulture. 6thBrainstorming Week on Membrane Computing, 6:51–66, 2008.

[21] M. Cardona, M. A. Colomer, M. J. Perez-Jimenez, D. Sanuy, and A. Margal-ida. Modeling ecosystems using p systems: the bearded vulture, a case study.In D. Corne, P. Frisco, G. Paun, G. Rozenberg, and A. Salomaa, editors,Membrane Computing, volume 5391 of Lecture Notes in Computer Science,pages 137–156. Springer Berlin / Heidelberg, Berlın, 01/2009 2009.

[22] A. Castellini and V. Manca. MetaPlab: A computational framework formetabolic P systems. In D. W. Corne, P. Frisco, G. Paun, G. Rozenberg,and A. Salomaa, editors, Membrane Computing: 9th International Workshop,volume 5391 of Lecture Notes in Computer Science, pages 157–168, 2009.

BIBLIOGRAPHY 199

[23] M. E. . . . Chase and R. C. . . . Bailey. The ecology of the zebra mussel(dreissena polymorpha) in the lower great lakes of north america: I. populationdynamics and growth. Journal of Great Lakes Research, 25(1):107–121, /01 / 01 / 1999. ID: edselc.2-52.0-0032935357; M2: 107; Accession Number:edselc.2-52.0-0032935357; (Journal of Great Lakes Research, 1999, 25(1):107-121) Publication Type: Academic Journal; Rights: Copyright 2004 ElsevierScience B.V., Amsterdam. All rights reserved.

[24] G. Ciobanu and G. Wenyuan. P systems running on a cluster of computers. InC. Martın-Vide, G. Mauri, G. Paun, G. Rozenberg, and A. Salomaa, editors,Membrane Computing, volume 2933 of Lecture Notes in Computer Science,pages 123–139. Springer Berlin Heidelberg, 2004.

[25] M. Clavel, F. Duran, S. Eker, P. Lincoln, N. Martı-Oliet, J. Meseguer, andJ. F. Quesada. Maude: specification and programming in rewriting logic.Theoretical Computer Science, 285(2):187 – 243, 2002. Rewriting Logic andits Applications.

[26] M. A. Colomer, A. Margalida, and M. J. Perez-Jimenez. Population dynamicsp system (pdp) models: A standardized protocol for describing and applyingnovel bio-inspired computing tools. PLoS ONE, 4:e60698, 04 2013.

[27] N. A. Connelly, C. R. J. O’Neill, B. A. Knuth, and T. Brown. Economicimpacts of zebra mussels on drinking water treatment and electric power gen-eration facilities. Environmental Management, 40(1):105–112, 2007.

[28] M. A. M. del Amor, I. Perez-Hurtado, M. Garcıa-Quismondo, L. F. Macıas-Ramos, L. Valencia-Cabrera, A. R. Jimenez, C. G. Dıaz, A. Riscos-Nunez,M. A. Colomer, and M. J. Perez-Jimenez. Dcba: Simulating population dy-namics p systems with proportional object distribution. In E. Csuhaj-Varju,M. Gheorghe, G. Rozenberg, A. Salomaa, and G. Vaszil, editors, MembraneComputing, volume 7762 of Lecture Notes in Computer Science, pages 257–276. Springer Berlin Heidelberg, Amsterdam, The Netherlands, 2013.

[29] M. A. M. del Amor, I. Perez-Hurtado, M. Garcıa-Quismondo, L. F.Macıas-Ramos, L. Valencia-Cabrera, A. Romero-Jimenez, C. Graciani-Dıaz,A. Riscos-Nunez, M. A. Colomer, and M. J. Perez-Jimenez. Dcba: Simulat-ing population dynamics p systems with proportional object distribution. InM. Garcıa-Quismondo, L. F. Macıas-Ramos, I. Perez-Hurtado, G. Paun, andL. Valencia-Cabrera, editors, Tenth Brainstorming Week on Membrane Com-puting, volume II, pages 27–56, Seville, Spain, 02/2012 2012. Fenix Editora.

[30] D. Dıaz-Pernil, C. Graciani-Dıaz, M. A. Gutierrez-Naranjo, I. Perez-Hurtado,and M. J. Perez-Jimenez. Software for p systems. The Oxford Handbook ofMembrane Computing, pages 437–454, 2010.

BIBLIOGRAPHY 200

[31] D. Dıaz-Pernil, M. A. Gutierrez-Naranjo, M. J. Perez-Jimenez, and A. Riscos-Nunez. A linear-time tissue p system based solution for the 3-coloring problem.Electronic Notes in Theoretical Computer Science, 171:81–93, 2007.

[32] D. Dıaz-Pernil, M. A. Gutierrez-Naranjo, M. J. Perez-Jimenez, and A. Riscos-Nunez. A uniform family of tissue p systems with cell division solving 3-col ina linear time. Theoretical Computer Science, 404:76–87, 2008.

[33] D. Dıaz-Pernil, I. Perez-Hurtado, M. J. Perez-Jimenez, and A. Riscos-Nunez.A P-Lingua programming environment for membrane computing. In D. W.Corne, P. Frisco, G. Paun, G. Rozenberg, and A. Salomaa, editors, MembraneComputing - 9th International Workshop, WMC 2008, Revised Selected andInvited Papers, volume 5391 of Lecture Notes in Computer Science, pages187–203. Springer, 2009.

[34] L. Dib, Z. Guessoum, N. Bonnet, and M. Laskri. Multi-agent system simu-lating tumoral cells migration. In S. Zhang and R. Jarvis, editors, AI 2005:Advances in Artificial Intelligence, volume 3809 of Lecture Notes in ComputerScience, pages 624–632. Springer Berlin Heidelberg, 2005.

[35] L. Diez Dolinski, R. Nunez Hervas, M. Cruz Echeandıa, and A. Ortega. Dis-tributed simulation of p systems by means of map-reduce: First steps withhadoop and p-lingua. In J. Cabestany, I. Rojas, and G. Joya, editors, Ad-vances in Computational Intelligence, volume 6691 of Lecture Notes in Com-puter Science, pages 457–464. Springer Berlin Heidelberg, 2011.

[36] J. Dolz and J. Armengol. Estudio de la dinamica sedimentaria y ba-timetrıa de precision del embalse de riba-roja d’ebre. Informe tecnico deFlumen (Dinamica Fluvial y Enginyeria Hidrologica) para la ConfederacionHidrografica del Ebro, 2009.

[37] M. D. Ernst, J. H. Perkins, P. J. Guo, S. McCamant, C. Pacheco, M. S.Tschantz, and C. Xiao. The daikon system for dynamic detection of likelyinvariants. Sci. Comput. Program., 69(1-3):35–45, Dec. 2007.

[38] L. Fernandez, V. Martinez, F. Arroyo, and L. Mingo. A hardware circuit forselecting active rules in transition p systems. In in G. Ciobanu, Gh. Paun,Pre-Proc. of First International Workshop on Theoryand Application of PSystems, Timisoara, Romania, September 26-27, pages 45–48, 2005.

[39] T. E. Foundation. Eclipse IDE. http://www.eclipse.org/, 2004.

[40] M. Garcıa-Quismondo, R. Gutierrez-Escudero, M. A. M. del Amor,E. Orejuela-Pinedo, and I. Perez-Hurtado. P-lingua 2.0: A software frameworkfor cell-like p systems. International Journal of Computers, Communicationsand Control, IV:234–243, 09/2009 2009.

http://www.eclipse.org/

BIBLIOGRAPHY 201

[41] M. Garcıa-Quismondo, L. F. Macıas-Ramos, and M. J. Perez-Jimenez. Im-plementing enzymatic numerical p systems for ai applications by means ofgraphic processing units. Beyond Artificial Intelligence: Contemplations, Ex-pectations, Applications, pages 137–157, 10/2012 2013.

[42] M. Gheorghe, F. Ipate, C. Dragomir, L. Mierla, L. Valencia-Cabrera,M. Garcıa-Quismondo, and M. J. Perez-Jimenez. Kernel p systems - ver-sion i. Eleventh Brainstorming Week on Membrane Computing (11BWMC),pages 97–124, 08/2013 2013.

[43] M. Gheorghe, F. Ipate, R. Lefticaru, M. J. Perez-Jimenez, A. Turcanu, L. Va-lencia Cabrera, M. Garcıa-Quismondo, and L. Mierla. 3-col problem modellingusing simple kernel p systems. International Journal of Computer Mathemat-ics, 90(4):816–830, 2013.

[44] M. Gheorghe, C. Martın-Vide, V. Mitrana, and M. J. Perez Jimenez. Anagent based approach of collective foraging. In J. Mira and J. Avarez, editors,Computational Methods in Neural Modeling, volume 2686 of Lecture Notes inComputer Science, pages 638–645. Springer Berlin Heidelberg, 2003.

[45] D. T. Gillespie. Exact stochastic simulation of coupled chemical reactions.The Journal of Physical Chemistry, 81(25):2340–2361, 1977.

[46] P. J. E. Goss and J. Peccoud. Quantitative modelling of stochastic systems inmolecular biology by using Petri Nets. Proceedings of the National Academyof Sciences of the United States of America, 95:6750–6754, 1998.

[47] M. P. A. Group. Daikon web page.

[48] M. P. A. Group. The daikon invariant detector user manual, 2010.

[49] A. Gutierrez and S. Alonso. P systems: from theory to implementation. InZ. Zhao, editor, Sequence and Genome Analytics. Methods and Applications,pages 205–226. Concept Press Ltd, 2010.

[50] A. Gutierrez, L. Fernandez, F. Arroyo, and S. Alonso. Hardware and softwarearchitecture for implementing membrane systems: A case of study to transitionp systems. In M. Garzon and H. Yan, editors, DNA Computing, volume4848 of Lecture Notes in Computer Science, pages 211–220. Springer BerlinHeidelberg, 2008.

[51] S. Hallstan, U. Grandin, and W. Goedkoop. Current and modeled potentialdistribution of the zebra mussel (dreissena polymorpha) in sweden. BiologicalInvasions, 12(1):285, In: Biological Invasions. (Biological Invasions, January2009, 12(1):285-296); 2009-01-01.

BIBLIOGRAPHY 202

[52] S. N. Higglns and M. J. V. Zanden. What a difference a species makes: A meta-analysis of dreissenid mussel impacts on freshwater ecosystems. EcologicalMonographs, 80(2):179, In: Ecological Monographs. (Ecological Monographs,May 2010, 80(2):179-196); 2010-05-01.

[53] M. Holcombe, L. Holcombe, M. Gheorghe, and N. Talbot. A hybrid machinemodel of rice blast fungus, magnaporthe grisea. Biosystems, 68(2–3):223 –228, 2003. IPCAT 01 SI.

[54] J. H. Holland. Adaptation in Natural and Artificial Systems. University ofMichigan Press, Ann Arbor, MI, 1975. second edition, 1992.

[55] G. J. Holzmann. The SPIN Model Checker: Primer and Reference Manual.Addison-Wesley Professional, 1 edition, Sept. 2003.

[56] F. Ipate, R. Lefticaru, L. Mierla, L. V. Cabrera, H. Han, G. Zhang,C. Dragomir, and M. J. P. Jimenez. Kernel p systems: Applications and im-plementations. Eighth International Conference on Bio-Inspired Computing:Theories and Applications (BIC-TA), 2013, 212:1081–1089, 07/2013 2013.

[57] F. Ipate, R. Lefticaru, and C. Tudose. Formal verification of P systems usingSpin. International Journal of Foundations of Computer Science, 22(1):133–142, 2011.

[58] D. Jackson, M. Holcombe, and F. Ratnieks. Coupled computational simulationand empirical research into the foraging system of pharaoh’s ant (monomoriumpharaonis). Biosystems, 76(1–3):101 – 112, 2004. Papers presented at the FifthInternational Workshop on Information Processing in Cells and Tissues.

[59] D. E. Jackson, M. Holcombe, and F. L. W. Ratnieks. Trail geometry givespolarity to ant foraging networks. Nature, 432:907–909, 2004.

[60] H. A. Jenner, J. W. Whitehouse, C. J. Taylor, and M. Khalanski. Coolingwater management in European power stations Biology and control of fouling.Hydroecologie Appliquee, 10:I–225, 1998.

[61] R. A. Juayong, F. G. Cabarle, H. N. Adorna, and M. A. M. del Amor. Onthe simulations of evolution-communication p systems with energy withoutantiport rules for gpus. Tenth Brainstorming Week on Membrane Computing,I:267–290, 02/2012 2012.

[62] A. Karatayev, L. Burlakova, and D. Padilla. Impacts of zebra mussels onaquatic communities and their role as ecosystem engineers. In E. Leppakoski,S. Gollasch, and S. Olenin, editors, Invasive Aquatic Species of Europe. Distri-bution, Impacts and Management, pages 433–446. Springer Netherlands, 2002.

BIBLIOGRAPHY 203

[63] D. Kirk and W. mei Hwu. Programming massively parallel processors :a hands-on approach. Morgan Kaufmann Publishers, Burlington Massachusetts, 2010.David B. Kirk and Wen-mei W. Hwu; :il. ;24 cm; MSC 68Nxx, 68N19; Bibli-ografia. Indice; 1. Introduction 2. History of GPU computing 3. Introductionto CUDA 4. CUDA threads 5. CUDA memories 6. Performance considerations7. Floating point considerations 8. Application case study: advanced MRI re-construction 9. Application case study: molecular visualization and analysis10. Parallel programming and computational thinking 11. A brief introduc-tion to OpenCL 12. Conclusion and future outlook. A. Matrix multiplicationhost-only version source code. B. GPU compute capabilities. Index.

[64] R. Lefticaru, F. Ipate, L. Valencia Cabrera, A. Turcanu, C. Tudose, M. Ghe-orghe, M. J. Perez-Jimenez, I. M. Niculescu, and C. Dragomir. Towards anintegrated approach for model simulation, property extraction and verifica-tion of P systems. In Proceedings of 10th Brainstorming Week on MembraneComputing, pages 291–318, 2012.

[65] R. Lefticaru, C. Tudose, and F. Ipate. Towards automated verification of Psystems using Spin. International Journal of Natural Computing Research,2(3):1–12, 2011.

[66] G. Mackie, W. Gibbons, B. Muncaster, and I. Gray. The zebra mussel, dreis-sena polymorpha, a synthesis of european experiences and a preview for northamerica. Technical report, Queen’s Printer for Ontario, 1989.

[67] R. Margalef. Ecologıa. Omega, Barcelona, 1974. Ramon Margalef, 10 reim-presiones hasta 2005.

[68] C. Maxfield. The design warrior’s guide to FPGAs :devices, tools and flows.Newnes etc, Boston, MA etc, 2004. Clive ”Max” Maxfield.; :il. ;24 cm. +CD-ROM.

[69] W. McCulloch and W. Pitts. A logical calculus of the ideas immanent innervous activity. The bulletin of mathematical biophysics, 5(4):115–133, 1943.

[70] R. McMahon. Impact of european zebra mussel infestation to the electricpower industry. Proceedings of the American Power, page 988, 1990.

[71] R. Milner. Communicating and Mobile Systems: The pi-calculus. CambridgeUniversity Press, New York, NY, USA, 1999.

[72] D. Minchin, F. Lucy, and M. Sullivan. Ireland: a new frontier for the ze-bra mussel dreissena polymorpha(pallas). Oceanological and HydrobiologicalStudies, 34(1):19–30, 2005.

BIBLIOGRAPHY 204

[73] Y. . . . Morales, L. J. . . . Weber, A. E. . . . Mynett, and T. J. . . . Newton. Mus-sel dynamics model: A hydroinformatics tool for analyzing the effects of dif-ferent stressors on the dynamics of freshwater mussel communities. EcologicalModelling, 197(3-4):448–460, / 08 / 25 / 2006. ID: edselc.2-52.0-33745845268;M2: 448; Accession Number: edselc.2-52.0-33745845268; (Ecological Mod-elling, 25 August 2006, 197(3-4):448-460) Publication Type: Academic Jour-nal; Rights: Copyright 2008 Elsevier B.V., All rights reserved.

[74] A. Munshi, B. Gaster, T. G. Mattson, J. Fung, and D. Ginsburg. OpenCLProgramming Guide. Addison-Wesley Professional, 1st edition, 2011.

[75] V. Nguyen, D. Kearney, and G. Gioiosa. Balancing performance, flexibil-ity, and scalability in a parallel computing platform for membrane computingapplications. In G. Eleftherakis, P. Kefalas, G. Paun, G. Rozenberg, andA. Salomaa, editors, Membrane Computing, volume 4860 of Lecture Notes inComputer Science, pages 385–413. Springer Berlin Heidelberg, 2007.

[76] V. Nguyen, D. Kearney, and G. Gioiosa. An extensible, maintainable and ele-gant approach to hardware source code generation in Reconfig-P. The Journalof Logic and Algebraic Programming, 79(6):383–396, Aug. 2010.

[77] V. Nguyen, D. Kearney, and G. Gioiosa. A region-oriented hardware im-plementation for membrane computing applications. In G. Paun, M. Perez-Jimenez, A. Riscos-Nunez, G. Rozenberg, and A. Salomaa, editors, MembraneComputing, volume 5957 of Lecture Notes in Computer Science, pages 385–409. Springer Berlin Heidelberg, 2010.

[78] J. Owens, M. Houston, D. Luebke, S. Green, J. Stone, and J. Phillips. Gpucomputing. Proceedings of the IEEE, 96(5):879–899, May 2008.

[79] A. Palau, I. Cıa, D. Fargas, M. Bardina, and S. Massuti. Resultados prelim-inares sobre ecologıa basica y distribucion del Mejillon cebra en el embalse deRiba-roja (Rıo Ebro). Monografıa de ENDESA, 2003.

[80] G. Paun. Computing with membranes. Journal of Computer and SystemSciences, 61(1):108–143, 2000. and Turku Center for Computer Science-TUCSReport No 208.

[81] G. Paun, G. Rozenberg, and A. Salomaa. Membrane computing with externaloutput. Fundamenta Informaticae, 41(3):313–340, February 2000.

[82] F. Pena-Cantillana, D. Dıaz-Pernil, H. A. Christinal, and M. A. Gutierrez-Naranjo. Implementation on cuda of the smoothing problem with tissue-like psystems. International Journal of Natural Computing Research, 2:25–34, 2011.

BIBLIOGRAPHY 205

[83] I. Perez-Hurtado. P-Lingua webpage. http://www.p-lingua.org, June 2009.

[84] I. Perez-Hurtado, L. Valencia-Cabrera, M. J. Perez-Jimenez, M. A. Colomer,and A. Riscos-Nunez. Mecosim: A general purpose software tool for simulat-ing biological phenomena by means of p systems. IEEE Fifth InternationalConference on Bio-inpired Computing: Theories and Applications (BIC-TA2010), I:637–643, 2010.

[85] M. J. Perez-Jimenez, A. Romero-Jimenez, and F. Sancho-Caparrini. A poly-nomial complexity class in p systems using membrane division. Fifth Inter-national Workshop on Descriptional Complexity of Formal Systems, pages284–294, 12-14/07/2003 2003.

[86] M. J. Perez-Jimenez and P. Sosik. Improving the efficiency of tissue p systemswith cell separation. Tenth Brainstorming Week on Membrane Computing,II:105–140, 02/2012 2012.

[87] B. Petreska and C. Teuscher. A reconfigurable hardware membrane system.In C. Martın-Vide, G. Mauri, G. Paun, GrzegorzRozenberg, and A. Salomaa,editors, Membrane Computing, International Workshop, WMC 2003, Tarrag-ona, Spain,July, 17-22, 2003, Revised Papers, volume 2933 of Lecture Notesin Computer Science, pages 269–285. Springer, July 2003.

[88] A. Phillips and L. Cardelli. A correct abstract machine for the stochasticpi-calculus. In In Bioconcur’04. ENTCS, 2004.

[89] M. Pogson, R. Smallwood, E. Qwarnstrom, and M. Holcombe. Formal agent-based modelling of intracellular chemical interactions. Biosystems, 85(1):37 –45, 2006. Dedicated to the Memory of Ray Paton.

[90] C. Prabhu. Grid and Cluster Computing. Prentice-Hall of India Pvt.Ltd, 2008.

[91] I. Perez-Hurtado. Desarrollo y aplicaciones de un entorno de programacionpara Computacion Celular: P-Lingua. PhD thesis, Escuela Tecnica Superiorde Ingenierıa Informatica, Universidad de Sevilla, 2010.

[92] C. Priami, A. Regev, E. Shapiro, and W. Silverman. Application of a stochasticname-passing calculus to representation and simulation of molecular processes.Information Processing Letters, 80(1):25 – 31, 2001. Process Algebra.

[93] C. R. and M. G.L. Practical manual for zebra mussel monitoring and control.01/01/1993; 1993-01-01.

[94] R Development Core Team. R: A Language and Environment for StatisticalComputing. R Foundation for Statistical Computing, Vienna, Austria, 2012.ISBN 3-900051-07-0.

http://www.p-lingua.org

BIBLIOGRAPHY 206

[95] V. N. Reddy, M. N. Liebman, and M. L. Mavrovouniotis. Qualitative analysisof biochemical reaction systems. Computers in Biology and Medicine, 26(1):9– 24, 1996.

[96] A. Regev and E. Shapiro. Cellular abstractions: Cells as computation. Nature,419(6905):343, Sept. 2002.

[97] A. Regev and E. Shapiro. The π-calculus as an abstraction for biomolecularsystems. In G. Ciobanu and G. Rozenberg, editors, Modelling in MolecularBiology, Natural Computing Series, pages 219–266. Springer Berlin Heidelberg,2004.

[98] F. J. Romero-Campero and M. J. Perez-Jimenez. A model of the quorumsensing system in vibrio fischeri using p systems. Artificial Life, 14:95–109,2008.

[99] F. Sanz-Ronda, S. Lopez-Saenz, R. San-Martın, and A. Palau-Ibars. Phys-ical habitat of zebra mussel (dreissena polymorpha) in the lower ebro river(northeastern spain): influence of hydraulic parameters in their distribution.Hydrobiologia, 735(1):137–147, 2014.

[100] D. W. Schneider, C. D. Ellis, and K. S. Cummings. A transportation modelassessment of the risk to native mussel communities from zebra mussel spread.Conservation Biology, 12(4):788–800, 1998.

[101] B. Shaalan and R. Muniyandi. Implementing mitogen activated protein kinasescascade on membrane computing using p-lingua. 11(1):178–187, 2015.

[102] I.-I. Sivtrr. Shell growth of the zebra mussel (dreissena polymorpha (pallas)) inrelation to selected physico-chemical parameters in the lower rhine and someassociated lakes. 1992.

[103] M. Sprung. Observations on shell growth and mortality of dreissena polymor-pha in lakes. In The Zebra Mussel Dreissena polymorpha: Ecology, BiologicalMonitoring and First Applications in the Water Quality Management, vol-ume 4 of Limnolgie Aktuell, pages 19–28. Gustav Fischer Verlag. Stuttgart,Jena, New York., 1992.

[104] D. Strayer and L. Smith. Relationships between zebra mussels (dreissenapolymorpha) and unionid clams during the early stages of the zebra musselinvasion the hudson river. Freshwater Biology, 36(3):771–779, 1996.

[105] D. L. Strayer. Twenty years of zebra mussels: lessons from the mollusk thatmade headlines. Frontiers in Ecology, 7(3):135–141, 2009.

BIBLIOGRAPHY 207

[106] D. L. Strayer, N. Cid, and H. M. Malcom. Long-term changes in a populationof an invasive bivalve and its effects. Oecologia, 165(4):1063, In: Oecologia.(Oecologia, April 2011, 165(4):1063-1072); 2011-04-01.

[107] D. L. Strayer and H. M. Malcom. Long-term demography of a zebra mussel(dreissena polymorpha) population. Freshwater Biology, 51(1):117, In: Fresh-water Biology. (Freshwater Biology, January 2006, 51(1):117-130); 2006-01-01.

[108] A. Syropoulos, E. G. Mamatas, and P. C. A. andKonstantinos T. Sotiriades. Adistributed simulation of transition P systems. In C. Martın-Vide, G. Mauri,G. Gheorghe Paun, and A. Salomaa, editors, Membrane Computing, Inter-national Workshop, WMC 2003, Tarragona, Spain,July 17-22, 2003, RevisedPapers, volume 2933 of Lecture Notes In Computer Science, pages 357–368.Springer-Verlag Heidelberg, 2004.

[109] A. Tejedor, L. Fernandez, F. Arroyo, and G. Bravo. An architecture for at-tacking the bottleneck communication in P systems. In M. Sugisaka andH. Tanaka, editors, Proceedings of the 12th Int. Symposium on Artificial Lifeand Robotics, pages 500–505, Beppu, Oita, Japan, Jan 25-27 2007.

[110] L. Timar and D. J. Phaneuf. Modeling the human-induced spread of an aquaticinvasive: The case of the zebra mussel. Ecological Economics, 68(12):3060–3071, 10/15 2009.

[111] L. Valencia-Cabrera. MeCoSim web site. http://www.p-lingua.org/

mecosim, July 2010.

[112] D. Walker, J. Southgate, G. Hill, M. Holcombe, D. Hose, S. Wood, S. M.Neil, and R. Smallwood. The epitheliome: agent-based modelling of the socialbehaviour of cells. Biosystems, 76(1–3):89 – 100, 2004. Papers presented at theFifth International Workshop on Information Processing in Cells and Tissues.

[113] N. Walz. The energy balance of the freshwater mussel dreissena polymorphapallas in laboratory experiments and in lake constance. ii. reproduction. InArchives of Hydrobiology, volume 55. 1978.

[114] U. Wilensky. Netlogo. http://ccl.northwestern.edu/netlogo/. Center forConnected Learning and Computer-Based Modeling, Northwestern University.Evanston, IL., 1999.

[115] X. Zeng, H. Adorna, M. A. M. del Amor, L. Pan, and M. J. Perez-Jimenez.Matrix representation of spiking neural p systems. Lecture Notes in ComputerScience, 6501:377–392, 2011.

http://www.p-lingua.org/mecosim

http://www.p-lingua.org/mecosim

http://ccl.northwestern.edu/netlogo/

BIBLIOGRAPHY 208

[116] G. Zhang, M. Gheorghe, L. Pan, and M. J. Perez-Jimenez. Evolutionarymembrane computing: A comprehensive survey and new results. InformationSciences, 279(0):528–551, 9/20 2014.

an environment for virtual experimentation with ...lvalencia/research/phd/thesis_luis...luis...

Documents