Simulating and validating virus machines

RESEARCH Simulating and validating virus machines David Orellana-Martı ´n 1,2 •Antonio Ramı ´rez-de-Arellano 1,2 •Mario J. Pe ´rez-Jime ´nez 1,2 Accepted: 10 February 2025 The Author(s) 2025 Abstract Virus machines are computing devices inspired by the transmission and replication of viruses. This model of computation has been proved to be as powerful as Turing machines, while using very simple semantics: instructions can open channels to let viruses travel between different hosts. The basic model is sequential, in the sense that only one instruction can be executed in each time step. This behaviour is, in principle, easy to follow by using pen and paper, but it can become harder when the model is big enough, as it happens with other models of computation. This paper introduces a base software for virus machines that simulates their behaviour and has an easy approach for both researchers and developers. Besides, apart from the simulator, the software has two other main purposes: on the one hand, a experimental validator has been introduced to help the researcher with both the design and the formal verification of such devices; on the other hand, it has included a tool to create a LaTeX graphic of a virus machine with the usual visuals. Keywords Virus machines Computer simulation Bio-inspired model of computation Experimental validation Mathematics Subject Classification 68Q07 68V05 1 Introduction In Valencia-Cabrera et al. (2015), virus machines were introduced as a bio-inspired model of computation based on the transmission and replication of viruses. This model consists basically on three graphs: a graph of hosts, that represents the hosts and the viruses transmitting from one host to another one; a graph of instructions, that controls the behaviour of the system; and a bipartite graph that connects instructions with channels, allowing the former open the latter to let viruses transmit and replicate. This model has been demonstrated to be computationally complete by proving that it can compute partial recursive functions (Romero-Jime ´nez et al. 2015), generate Diophantine sets (Romero-Jime ´nez et al. 2015), and simulate register machines (Chen et al. 2016). New papers have been published lately in the area, calculating basic arithmetic operators and pairing functions (Ramı ´rez-de-Arellano et al. 2022a; Ramirez-de-Arellano et al. 2023). The machines described in these works are easy to follow for some steps, but it can be a very tedious task to write down a description of a complete computation. For the last two works (Ramı ´rez-de-Arellano et al. 2022a; Ramirez-de-Arellano et al. 2023), authors decided to simulate simple virus machines. However, it became a very useful aid tool in the design process of these devices. One of the important tasks while defining virus machines is to ensure their correctness, thus a formal verification is needed in order to be sure that it works as it should. In this sense, a very useful tool was implemented in the software, the experimental validation module, capable of taking an invariant formula and test it for a wide number of inputs. Of course, it does not guarantee that the machine works properly for all the cases, but it can be very helpful in the formal verification process. Apart from that, in the previous works the graphs were different for each paper, since authors had to use different &David Orellana-Martı ´n [email protected] Antonio Ramı ´rez-de-Arellano [email protected] Mario J. Pe ´rez-Jime ´nez [email protected] 1 Research Group on Natural Computing, Department of Computer Science and Artificial Intelligence, Universidad de Sevilla, Avda. Reina Mercedes s/n, 41012 Seville, Spain 2 SCORE Laboratory, I3US, Universidad de Sevilla, Avda. Reina Mercedes s/n, 41012 Seville, Spain 123 Natural Computing https://doi.org/10.1007/s11047-025-10013-0(0123456789().,-volV)(0123456789().,-volV) graphics editors to paint them. Instead of that, in this software we have implemented a function that automatically generates a PGF/TikZ 1 file that contains all the ingredients of the machine, only having to readjust the positions of the nodes. In a similar model of computation, Membrane Computing (Pa ˘un et al. 2010), several software simulators were created to recreate the behaviour of different variants (Valencia-Cabrera et al. 2019). However, this is an ad hoc approach that needs a totally new simulator when a new class of membrane systems is created. That is why P-Lingua (Pe ´rez-Hurtado et al. 2022) was created, with the objective of having a general framework to include the majority of types of P systems being included as objects of study. Right now, only a single variant of virus machines has been studied, but several different variants can arise from it. Previously, a tool for simulating virus machines was presented at Conde-Marro ´n(2022,2023). This tool, while abstracting very well the ‘‘instruction’’ concept, it lacks of efficiency as well as extensibility. The software presented in this work is a first step to a more general framework of virus machines a la P-Lingua. The rest of the paper is organised as follows. Section 2 includes formal definitions about virus machines. Next sections are devoted to present the software implemented: Sect. 3contains a description of the implemented simulator, Sect. 4includes information about the experimental validator and a brief explanation of the graphics tool is introduced in Sect. 5. We finish the work with some conclusions and interesting research and development lines in this direction. 2 Preliminaries In this section, we recall the definition of a virus machine, both its syntax and semantics, stressing some aspects related with the simulation Definition 1 A (basic) virus machine of degree (p,q), with p1 and q1 is a tuple P¼ðC;H;I;DH;DI;GC;n1;...;np;i1;houtÞ, where: •C¼fvgis the singleton alphabet; •H¼fh1;...;hpgand I¼fi1;...;iqgare ordered sets such that v62 H[I,H\I¼; and hout 2H[fh0g: either hout is a host or hout represents the environment (denoted by h0); •DH¼ðH[fhoutg;EH;wHÞis a weighted directed graph, where EHHðH[fhoutgÞ,ðh;hÞ 62 EHfor each h2H,out degreeðhoutÞ¼0 and wHis a mapping from EHonto Nnf0g; •DI¼ðI;EI;wIÞis a weighted directed graph, where EIII,wIis a mapping from EIonto Nnf0gand the out-degree of each node is less than or equal to 2; •GC¼ðVC;ECÞis an undirected bipartite graph, where VC¼I[EHbeing fI;EHgthe partition associated with it: every edge connects an element from Iwith, at most, an arc from EH; •nj2Nð1jpÞ. A virus machine P¼ ðC;H;I;DH;DI;GC;n1;...;np;i1;houtÞof degree (p,q) can be viewed as an ordered set of phosts labelled with h1;...;hp, where host hjcontains exactly njviruses in the initial configuration, and an ordered set of qcontrol instruction units labelled with i1;...;iq. Symbol hout represents the output region: it can be either a host in the case that hout 2Hor the environment in the case that hout ¼h0. Arcs from the directed graph DHrepresent transmission channels through which viruses can transmit from one host hs(different from hout) to another different region hs0.We use the term region or zone hsto refer a host if hs2Hor to the environment if hs¼h0. In any moment, at most one instruction is activated and then the channel ðhs;hs0Þwith weight ws;s0attached with it will be opened. Then, one virus from hswill be transmitted to hs0replicated ws;s0times. By default, each channel is closed. Arcs from the directed graph DIrepresent instruction transfer paths, and GCrepresents the instruction-channel network, where an edge fij;ðhs;hs0Þg denotes the control of ijover the channel ðhs;hs0Þ. A virus machine of degree (4, 6) can be graphically described as in Fig. 1, where hosts are depicted as rectangles and instructions are depicted as circles. Double arrows represent host channels, single arrows represent instruction transfer paths and discontinuous lines represent the edges of the instruction-channel network. It is important to remark that each instruction is attached to a single channel, while a channel can have more than one instruction. Besides, in the graph DI, since the maximum outdegree of an instruction is 2, we can say that the corresponding arcs will have weight 1 or 2. Aconfiguration Ctat an instant tof a virus machine of degree (p,q) is described by a ðpþ2Þ-tuple ða1;t;...;ap;t;ut;a0;tÞ, where a0;t;a1;t;...;ap;t2N, ut2I[f#g, where #62 H[fh0g[Iis an object for characterising halting configurations. The meaning of Ctis the following: at instant tthe environment contains exactly a0;tviruses and the host hscontains exactly as;tviruses, and if ut2I, then the instruction utwill be activated at step tþ1 (if ut¼#, then no instruction will be activated). The initial configuration of the system P¼ 1 Documentation of PGF/TikZ can be found in https://github.com/ pgf-tikz/pgf. D. Orellana-Martín et al. 123 ðC;H;I;DH;DI;GC;n1;...;np;i1;houtÞis C0¼ðn1; ...;np;i1;0Þ. A configuration Ct¼ða1;t;...;ap;t;ut;a0;tÞ yields configuration Ctþ1¼ða1;tþ1;...;ap;tþ1;utþ1;a0;tþ1Þ in one transition step if we can pass from Ctto Ctþ1in the following form. (a) First, given that Cis a non-halting configuration we have ut2I. Then, the control instruction unit utis activated. (b) If utis attached to a channel ðhs;hs0Þthen the channel will be opened and: •If as;t1 then only one virus is consumed from host hsand ws;s0copies of vare produced in region hs0. •If as;t¼0 then no virus is consumed from host hs and no virus is produced in the region hs0 (c) If utis not attached to any channel then there is no transmission of viruses. (d) Object utþ12I[f#gis obtained as follows:n •If out degreeðutÞ¼2 then there are two different instructions ut0and ut00 such that ðut;ut0Þ2 EI(with weight wt;t0) and ðut;ut00 Þ2EI(with weight wt;t00 ). – If instruction utis attached to a channel ðhs;hs0Þ: If as;t1 then utþ1is the instruction corresponding to the highest weight path (maxðfwt;t0;wt;t00 gÞ). If wt;t0¼wt;t00 , then the next instruction is selected in a non-deterministic way. If as;t¼0 then utþ1is the instruction corresponding to the lowest weight path (minðfwt;t0;wt;t00 gÞ). If wt;t0¼wt;t00 , then the next instruction is selected in a non-deterministic way. – If instruction utis not attached to a channel, then the next instruction utþ1(ut0or ut00 )is selected in a non-deterministic way. •If out degreeðutÞ¼1 then the system behaves deterministically and utþ1is the next instruction that verifies ðut;utþ1Þ2EI. •If out degreeðutÞ¼0 then utþ1¼#, and Ctþ1 is a halting configuration. Let us remark that this is the behaviour of the basic model of virus machines. In Ramı ´rez-de-Arellano et al. (2022a,2022b), different modes of computation are described, for generating sets of numbers, computing functions or recognising languages. However, since the syntax and semantics for the systems are the same, we are not going to describe them here. For the formal verification of virus machines, invariant formulas have been used (Ramirez-de-Arellano et al. 2023; Ramı ´rez-de-Arellano et al. 2022a,b). The consistency of this method falls on the veracity of those formulas throughout the configurations they are defined to. While trivial invariant formulas, as True are true for the whole computation, the main idea consists in the fact that these formulas provides some relevant information about the main loops of the computation. For instance, in the virus machine depicted in Fig. 2, let the number of viruses in host h1be ninstead of 1. Then, the formula ukCk¼ ðnk;i1;2kÞholds for 0 kn. This fact is demonstrated by induction: 1. Base case k¼0: By the definition of the virus machine, the number of viruses in the host h1in the initial configuration is nk¼n, and the number of viruses in the environment is 2k¼0. 2. By induction hypothesis, the formula is valid for k:If ukholds, it means that Ck¼ðnk;i1;2kÞ. Thus, by the application of i1, a virus is removed from host h1, and 2 new viruses are moved to the environment, thus Ckþ1¼ðnk1;i1;2kþ2Þ¼ ðnðkþ1Þ;i1;2ðkþ1ÞÞ. The formula holds then for kþ1. Since this result holds for k2f0;...;ng,Cn¼ð0;i1;2nÞ holds. From this point, it is straightforward to demonstrate that in two steps, the configuration halts and that the number of viruses in the environment is 2n, obtaining a formal proof of the validity of the model. 3 Implementation The software introduced here is a first step towards a general framework of simulators for virus machines. It can be found in Orellana-Martı ´n(2023). Given the syntax of these devices, it seems straightforward to create a programmatic paradigm to create new virus machines. On the one hand, a researcher could easily introduce by hand the Fig. 1 Structure of a Virus Machine Simulating and validating virus machines 123 different elements of the virus machine in order to simulate it. On the other hand, a programmer could use a virus machine as a subroutine by simulating its behaviour and using the results obtained from it to make other calculations with them. Let us recall that a virus machine is defined as P¼ðC;H;I;DH;DI;GC;n1;...;np;i1;houtÞ. However, there are some details that can be omitted/ changed since they do not affect how a computation evolves: •Since we have a single type of virus, v, we omit this information and, in each host, we store a natural number that corresponds to the number of viruses present in the host in a certain moment. •Since each instruction can be connected to, at most, one channel, we can include the definition of the channels while defining the instruction. In this way, when defining a certain instruction ijsuch that ðij;ðhs;hs0ÞÞ is an edge of GC, we will include the weight ws;s0within the instruction ij. This leads to a less restricted version of virus machines where there can exist multiple channels between hosts. •The initial instruction i1will always be the first instruction introduced in the machine. •The output region will not be defined since the user will be able of obtaining information of each host of the machine. Thus, three elements are necessary to define a virus machine in this framework: 1. Hosts list. 2. Instructions list. 3. Instruction transfer paths list. In the following, we will introduce how each element is declared and how the simulator works. 3.1 Definition The simulator is implemented in Python 3. Three classes are defined in the project for simulation purposes: the class Host, the class Instruction and the class VirusMachine. An object of the class Host simulates the behaviour of a host in a virus machine. On the one hand, it has the current number of viruses. On the other hand, since the virus machine can be ‘‘restarted’’, we include the initial number of viruses of the host for this purpose. An object of the class Instruction not only simulates the behaviour of an instruction in the virus machine, but also the channel that it is attached too, besides its weight. In this way, we let the possibility to have multiple channels between two hosts, each of them with their respective weight. In this paper, none of the models implement this behaviour, since it is not allowed in the basic model of virus machines. An object of the class VirusMachine implements all the functions for simulating the behaviour of a virus machine. This type of object has a list of hosts, a list of instructions, the current step and a list of instructions connections.This list contains triplets that represent the connections between the instructions of the system, where the first element of the triplet is the origin instruction, the second element is the destination instruction and the third one is the weight of the edge. An example to create a simple virus machine is the following: Some interesting things can be observed in this example. First, the constructor method of the class Host has an optional parameter that represents the number of viruses in the initial configuration (if not specified, it will be 0). Something similar happens in the class Instruction: the third parameter is optional and, if it is not specified, it will be 1. The object vm contains all the information for simulating the virus machine represented in Fig. 2. 3.2 Simulation The methods for simulating the behaviour of the system are defined within the class VirusMachine. Thus, a virus machine can call these methods to run a computation. compute is the main method of the class, that allows the user/programmer to simulate a computation of the virus machine. It has two optional arguments: verbose has three possible values: 0, 1 or 2. The first one prints nothing Fig. 2 Representation of the Virus Machine vm D. Orellana-Martín et al. 123 to the standard output; the value 1 prints each configuration to the standard output in a compact way, if Ct¼ð3;4;i1;0Þ, the output is [3, 4, 1, 0]; and the value 2 corresponds to an output with LaTeXsyntax, if Ct¼ð3;4;i1;0Þ, the output is C_0=[3,4,’i_1’, 0]. The second argument, steps is float(’inf’) by default, designated for arbitrary large computations, but can be defined so it runs at most that number of computational steps. The system halts when a halting condition has been reached: either the configuration is a halting configuration or we have reached the limit of simulated computational steps. Algorithm 1 simulates a single computational step of a virus machine Pin configuration Ct¼ða1;...;ap;it;a0Þ. The behaviour of this function is simple: it will run a loop with two termination conditions: Either the limit of steps is reached, or there is no current instruction (i.e. the instruction of the current configuration is denoted as #) . Algorithm 1 Algorithm for simulating a single computational step of a virus machine 4 Experimental validation In this section we will introduce the experimental validation module of the project that implements functions that can help the researcher with both the design of a virus machine and the formal verification of invariants of the systems. An invariant is a formula that remains true through the whole computation of the system. This invariant formula can be defined for specific steps of the computation (e.g., odd or even steps). The formal verification of this formula ensures that the system works correctly, but it is difficult to design it without any aid. In principle, the simulator was implemented without the experimental validator, and testing the invariant formulae was a tedious work where we had to make ad hoc functions to check them. However, we though that it would be useful to generalise this behaviour since it can be mechanised. In Simulating and validating virus machines 123 fact, this experimental validator not only helped in this sense, but also in efficiency, since it does not have to restart the machine for each different expression that can arise from the formula but it precomputes the properties to satisfy before the simulation is started and, in each computational step, the software checks for the properties that must be checked for that specific step. The main function in this module is validate, that receives i) a virus machine, ii) a configuration template, that represents the invariant formula which is going to be checked; iii) an expression that represents the step where the property is checked, iv) variables present in both the template and the expression, and v) bucles that represent variables that can take different values in the invariant formula. We stress the importance of the relation between an invariant formula and the template, the expression and the variables. Let us define an invariant formula uCt¼ða1;t;...;aq;t;it;a0;tÞ. Thus, the corresponding template would be ða1;t;...;aq;t;it;a0;tÞ, the expression would be t,variables would contain all the variables (with a fixed value) in the formula and bucles would contain all the possible values that any variable present in the template or the expression can take. If ai;t¼, then we say that it can take any value. Algorithm 2 implements the desired behaviour. Algorithm 2 Algorithm for the method validate First, we restart the virus machine; that is, we restart the number of viruses in the hosts, we set the current instruction to i1and we set the current_step variable to 0. Then, we must ensure that the template configuration is valid for the virus machine; that is, that the length of a configuration of the virus machine corresponds to the length of the template. Function properties_to_satisfy creates a dictionary where keys indicate the configuration that will be inspected and the values will be pairs which first element is the expected configuration for such a configuration, and which second element is the Boolean value False. The later will be used in the function verify_properties. For instance, if properties[5] = [0, 3, 2, 4], then the following must hold: C5¼ð0;3;i2;4Þ. Algorithm 3 describes the procedure. D. Orellana-Martín et al. 123 Algorithm 3 Algorithm for the method properties_to_satisfy Let us explain how functions fcand fereferred to in Algorithm 3 work. fcreceives a moment tand a variable set var. Take into account that tis a string that contains a ‘‘template’’ of a time step, thus it can contain variables that can take different values. These values will be taken from the set var. Let us consider the set of pairs var a function var such that varðaÞ¼b() ð a;bÞ2var. Thus, we will change in tall the appearances of all the elements of x: 9yðx;yÞ2var by their corresponding value var(x). fehas a similar behaviour, but instead of a moment template t,it receives a configuration template ða1;t;...;aq;t;it;a0;tÞ, and it changes the variables appearing in each element of the tuple by their corresponding value using the set var. Next, the algorithms proceeds to verify if all the properties are satisfied by a computation of the virus machine. For this purpose, the function verify_functions is used. We describe the behaviour of this function in Algorithm 4 Simulating and validating virus machines 123 Algorithm 4 Algorithm for the method verify_properties Let properties½t¼ðc;bÞ(that is, ðt;ðc;bÞÞ 2 properties). At the beginning of Algorithm 4, the value of all elements bis False. This value represents if Ct¼ða1;t;...;aq;t;it;a0;tÞfulfils the requirements of the corresponding c. This procedure corresponds to the function compare. If any ai;tð1iqÞis equal to *, it means that any value fulfils the requirement. If Ctc, then we assign bto True. Otherwise, we add an element to the tuple (c,b), that is exactly Ct. The purpose of this addition is that, in the following stage of the validate function, the algorithm can show in screen the expected configuration versus the obtained configuration, helping the designer to correct the model. Finally, the function all_true returns a Boolean and a string. The former one is true if and only if all the elements bsuch that ðt;ðc;bÞÞ 2 properties are true; that is, if the invariant formula is correct. The later one is a string that, for the non-fulfilled properties, contains the expected configuration versus the obtained configuration, that can be useful for the designer in the process of improving the model. 5 PGF/TikZ graphics Previous to this work, graphical representations of virus machines were generated using different graphics editors. In the literature, some of these graphics can be seen. However, the graphics represent very simple machines, but for bigger and more complex machines, the process of creation of these pictures can become overwhelming. In Ramı ´rez-de-Arellano et al. (2022a), Ramı ´rez-de-Arellano et al. (2022b) and Ramirez-de-Arellano et al. (2023), a new type of graphics is depicted where different colours and forms have been used. In fact, all of these pictures were generated using the PGF/TikZ graphics generator implemented in this tool. For Each component of virus machines, a new command in LaTeXhas been created, using for that the commands nnode (for the nodes of the graphs) and ndraw (for the edges/arcs of the graphs) defined in TikZ. When a virus machine is created, we can use the function viruslatex from the file viruslatex.py, with the following arguments: viruslatex(vm, vertical_hosts, horizontal_hosts, filename, verbose), where vm is the virus machine, vertical_hosts (respectively, horizontal_hosts) being the maximum number of hosts depicted in each column (resp., in each row), filename being the name of the .tex file that will be created (if void, it will send the code to the standard output) and verbose will create a legend besides the virus machine. The generated .tex file can be compiled with pdfLaTeX or any other modern LaTeX engine. Of course, it can be edited for the sake of visualisation since, by default, the generator will put all the hosts and instructions in a position where the different edges of the graphs can collide, leading to a image difficult to interpret. .tex files will be generated in the folder genlatex present in the root folder of the software. 6 Examples Besides the implementation of the previous explained tools, the project includes a main.py file that helps the designer to test the created models. A good strategy is the D. Orellana-Martín et al. 123 following one (following the existing folder structure of the project): 1. The designer creates a model in the folder examples and defines a functions that returns a virus machine. Let us call this file model.py. 2. In the tests folder, we can create a file called test_model.py where we can check some properties of the created model. In this file, we can import the model with the instruction import model. In this file we can create a virus machine calling the corresponding function created in model.py, check computations of this virus machine, validate some properties of the virus machine using the formalverification module and generate .tex files using the viruslatex function. 3. If we are running Python from a terminal, we can run the following command: python main.py model. model corresponds to the name of the tests file test_model.py. This file will be then executed, and the corresponding results will be shown in the terminal and/or the corresponding .tex files will be generated in the genlatex folder. Some examples are present within the project, and they can be used as templates for new models. Some examples present in the project are the ones presented in Ramı ´rez-deArellano et al. (2022a), Ramı ´rez-de-Arellano et al. (2022b) and Ramirez-de-Arellano et al. (2023). 7 Conclusions and future work Virus machines are bio-inspired models of computation based on the transmission and replication of viruses in an environment. This abstraction creates a Turing-complete model that has shown very interesting properties while solving problems. Basic virus machines are simple to understand and to simulate using pen and paper, but when the numbers of hosts and instructions increase, it can become a difficult task for a researcher. Besides, it would be interesting to use this model as a problem solver that can be connected to other software tools to take advantage of its utilities. That is why we have implemented a software capable of simulating virus machines and which can also check properties over them. This software is intended as a basis for a general computing framework capable of reproducing the behaviour of different variants of this model. The simulator is a great tool to assist both researchers and programmers to implement their models and simulate their behaviours easily. Besides, a graphics generation tool has been designed for the sake of simplicity for depicting custom virus machines. However, we believe that the most interesting part within the project is the experimental validator, that lets researchers check for possible invariants in the system. Due to the sequential nature of virus machines, the efficiency of the simulator depends exclusively on the computation steps of the virus machine being simulated, but as a future work, we want to generalise the software to make it more flexible for future extensions of the model. Apart from that, we want to refine some methods to make it more efficient, using different Python libraries that outperforms the base functions implemented in Python. Acknowledgements The research described in this work is supported by the Zhejiang Lab BioBit Program (Grant No. 2022BCF05). This work was also supported by the research project FEDER/Junta de Andalucı ´a - Paidi 2020/_Proyecto (P20_00486). D. Orellana-Martı ´n acknowledges Contratacio ´n de Personal Investigador Doctor. (Convocatoria 2019) 43 Contratos Capital Humano Lı ´nea 2. Paidi 2020, supported by the European Social Fund and Junta de Andalucı ´a. Author Contributions DO-M developed the software. All authors wrote and reviewed the manuscript. Data availibility statement The software is available at https://github. com/RGNC/virusmachines. Declarations Conflict of interest The authors declare that they have no conflict of interest. Ethics approval Not applicable. Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article’s Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article’s Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons. org/licenses/by/4.0/. References Chen X, Pe ´rez-Jime ´nez MJ, Valencia-Cabrera L, Wang B, Zeng X (2016) Computing with viruses. Theor Comput Sci 623:146–159. https://doi.org/10.1016/j.tcs.2015.12.006 Conde-Marro ´n F (2022) A simulator for virus machines. Bulletin of the International Membrane Computing Society 14, International Membrane Computing Society. http://membranecomput ing.net/IMCSBulletin/pdf/ed14/IMCSBulletinIssue14.pdf (December) Conde-Marro ´n F (2023) Virus machine simulator website. https:// github.com/felconmar/VirusMachineSimulator. Accessed 14 Mar 2023 Orellana-Martı ´n D (2023) Virus machines simulators website. https:// github.com/RGNC/virusmachines. Accessed 14 Mar 2023 Simulating and validating virus machines 123