A Steering Server for Collaborative Simulation of ...

A Steering Server for Collaborative Simulation of Quantitative Petri Nets Mostafa Herajy1 and Monika Heiner2 1

Department of Mathematics and Computer Science, Faculty of Science, Port Said University, 42521 - Port Said, Egypt 2 Computer Science Institute, Brandenburg University of Technology Postbox 10 13 44, 03013 Cottbus, Germany http://www-dssz.informatik.tu-cottbus.de

Abstract. In this paper we present a Petri net simulation tool called Snoopy Steering and Simulation Server, S 4 for short, which works as a stand-alone extension of Snoopy. The server permits users to share and interactively steer quantitative Petri net models during a running simulation. Moreover, users can collaborate by controlling the execution of a model remotely from different machines (clients). S 4 is shipped with an Application Programming Interface (API) which enables user-defined extensions of the core functionalities. Stochastic, continuous and hybrid Petri nets are supported, both as low-level and coloured ones. S 4 is platform-independent and distributed free of charge for academic use. Keywords: stochastic, continuous, hybrid Petri nets, computational steering, collaborative simulation.

1

Introduction

There exists a wide range of software tools that permit the modelling and execution of Petri nets. Most of them are concerned with facilitating the process of designing and editing a Petri net model and to make it as flexible and convenient as possible, but pay little attention to simulation features. However, improving the user support for running simulations is imperative in certain circumstances. As an example consider the simulation of quantitative Petri nets, such as continuous, stochastic, or hybrid Petri nets, which may become computationally very expensive. For instance, consider the spatial modelling of planar cell polarity in the drosophila wing via Petri nets [6]. This scalable model may contain about 1,000,000 places and 1,000,000 transitions, and the runtime may range from several hours to days or even weeks, particularly when stochastic simulation is involved. Therefore, such models call for sophisticated simulation environments with flexible features for model execution. Examples of such key features are: remote simulation on powerful machines, on-the-fly change of key simulation parameters, collaboration between peer users, or the exploration of one and the same model by different simulation engines. G. Ciardo and E. Kindler (Eds.): PETRI NETS 2014, LNCS 8489, pp. 374–384, 2014. c Springer International Publishing Switzerland 2014 

A Steering Server for Collaborative Simulation of Quantitative PN

375

High performance computers are usually hosted at central locations. Therefore, a software tool should allow users to run Petri net models remotely and control their execution via computer terminals. Moreover, such a feature is of great importance to facilitate the sharing of computational resources. For instance, computationally expensive simulations can run on powerful clusters, while the monitoring of the results can be done from a laptop. Traditionally, a simulation is restarted from the very beginning when a new parameter set is required to be tested. However, for bigger models it consumes a lot of time to restart the simulation from scratch each time when we notice that the simulation goes in a wrong or undesirable direction. As an alternative method, key simulation parameters should be changeable on-the-fly, and the simulation should just continue execution with the new values for these key parameters [13]. By this way, users obtain more control over the model execution which permits to amend errors or play with the model, e.g. to explore the kinetic parameter space or try design alternatives. Furthermore, it is useful to permit the collaboration between users with different backgrounds. Such interaction may promote the sharing of knowledge. Besides, changes done by one user should also be propagated to the others. Nonetheless, in some application domains of Petri nets it is important to explore one and the same model definition using different simulation techniques. For instance, systems biology often suggests to simulate a quantitative Petri net using either the deterministic, stochastic or hybrid approach. This will render it possible to compare results of the different modelling paradigms in order to study which simulation method fits this type of model best. In this paper we present a software tool called S 4 (Snoopy Steering and Simulation Server) that works as a stand-alone extension of Snoopy [20] and permits to distribute, collaborate, share, and interactively steer Petri nets during a running simulation. S 4 is completely written in C++ in a platform-independent manner. S 4 supports three main Petri net classes: stochastic [17], continuous [7], and hybrid Petri nets [11]. The theory behind S 4 can be found in [13], and a detailed technical documentation in [12]. S 4 was previously known as SSServer.

2

Functionality

In this section we list the main functionalities provided by S 4 . Moreover, we discuss how it can communicate and interact with other software (including Snoopy) to read Petri net models. The different simulation algorithms which are supported by S 4 are also pinpointed. 2.1

Main Features

– Remotely run and control a simulation. Users can run their simulation at remote computers. This feature allows the access to machines with high computational power from a local computer. The simulation will run at a server machine while the visualization of the results is done at a different machine, serving as graphical user interface (GUI) client.

376

M. Herajy and M. Heiner

– Execution of one model using different simulation algorithms. Sometimes it is useful to study a model via different paradigms, i.e., stochastic, continuous, or hybrid. Using S 4 , one and the same model definition can be executed with different simulation algorithms. – Managing different models concurrently with possibly different simulators. Different models can be simultaneously executed at the server side. A separate simulator is assigned to each model and can be executed independently from other running models. Moreover, running models can be saved on the server side for future restore. – Defining different views to explore simulation results. Views provide a quick means to explore simulation results from different perspectives. Each view is defined by a set of data curves and their associated attributes. Several different views can be defined for a model. – Exploring the running models on-the-fly. By help of the steering graphical user interface (Steering GUI), users can easily navigate among different models. The list of running models at the server side can be refreshed if another user adds/deletes a model to/from the server. – Steering simulation parameters while a simulation is running. The main goal of S 4 is to enable users to interact with their models during simulations. Users can change model parameters as well as the current marking and immediately monitor the system’s response to such changes. This is a very useful tool since a user is allowed to ask ”what-if” questions. – Controlling the simulation speed. The simulation speed can be set to an appropriate level to facilitate the interaction with a running model during its execution. This feature is especially important if simulation parameters are allowed to be changed while the simulation is running. – Connecting to a simulation at any time from whatever place. S 4 is flexible to let users connect/disconnect to/from running models without affecting their execution. Moreover, users can connect to running models from different places, for example from the office or from home. – Collaborating with other people while simulating a model. More than one user is permitted to connect to the same models. Users can collaborate by executing and steering a running simulation. – Platform-independent implementation. The core communication library is written in standard C++, thus it can run on different platforms, among them Windows, Mac OS X, and Linux. Clients and servers need not to run on the same platform. 2.2

Petri Net Model Definition

Before S 4 can be used to execute a simulation, a model needs to be defined. The model has to be specified in terms of quantitative Petri nets: places, transitions, arcs, kinetic parameters, transition rates (rate functions), and initial making, with the specific constraints depending on the net class, see [7,11,17] for details. S 4 accepts models that are defined by either of two ways: through Snoopy [9], or via an Application Programming Interface (API) [13].

A Steering Server for Collaborative Simulation of Quantitative PN

377

Defining a model via Snoopy. Snoopy is a powerful tool to design and edit Petri nets. It supports many different Petri net classes. Thus, we sought to make use of Snoopy’s capabilities as a way of conveniently defining a Petri net model, and afterwards the model is communicated to S 4 . In a typical scenario, a user constructs a Petri net and then asks Snoopy to execute it in the steering mode. Snoopy then inquires the address of a running server on the local or a remote computer. Snoopy knows how to communicate with S 4 as they are compatible with each other. Defining a model via API. Sometimes it may be more appropriate to define a Petri net model without using a graphical user interface. For instance, if the model is automatically generated from another specification, or if the model will be designed by other tools which are not close relatives of Snoopy. In these cases, S 4 permits the definition and communication of the Petri net using API calls [13]. Figure 1 gives an overview of the different classes supported by the API. A complete documentation as well as some examples can be found in [12]. 2.3

Model Exploration

Once a Petri net model has been defined and sent to S 4 , it can be further explored. The initial exploration process is meant to provide basic information about the model under study. This includes information about places, transitions, and the connections between these two node types. Model exploration can be done either on the server side or remotely through the graphical user interface. 2.4

Monitoring and Steering

During the execution of a Petri net model by help of S 4 , users can remotely monitor the progress of the simulation results via Snoopy’s GUI. Moreover, users can change key simulation parameters, and thus steer the simulation. In this case, they will immediately get a feedback according to their changes; see Section 4 for a typical user scenario. Figure 2 presents a screenshot of Snoopy’s GUI. It is worth mentioning that it is not a prerequisite to submit a model in order to be able to monitor and steer it. One can also make use of an existing one, which has been previously submitted by another user. 2.5

Supported Petri Net Classes

S 4 supports the following Petri net classes. – GSPN – Generalised stochastic Petri nets provide four transition types: stochastic, immediate, deterministic and scheduled transitions. In biological context, these transitions correspond to different reaction types. There are also five arc types: standard, read, inhibitory, equal and reset arcs. – CPN – Continuous Petri nets are built from continuous places and transitions. Unlike GSPN , CPN ’s places hold non-negative real numbers as net markings, and arcs can be weighted with non-negative real numbers.

378

M. Herajy and M. Heiner

Fig. 1. Inheritance diagram of Snoopy’s steering APIs (SPSA). The Snoopy steering API classes can be classified into four main functional categories: communication, data structures, control commands, and end point components.

– GHPN – Generalised hybrid Petri nets combine all features of GSPN and CPN into one net class. They permit the full interplay between the stochastic and continuous components. – GSPN C , CPN C , GHPN C – In addition to the low-level Petri nets, S 4 reads the coloured counterparts; see [9] for more details re the relation between these Petri net classes. 2.6

Available Simulators

Petri net models submitted to S 4 can be simulated via a wide range of simulation techniques. These simulators can be classified into three main categories: deterministic, stochastic, and hybrid. Any simulation algorithm can be used to execute a model independently of the original net type. For instance, a net that has been originally designed as a continuous Petri net can be later simulated using the stochastic approach. However, an alert will be issued at the beginning of the simulation. Besides, S 4 permits the adaptation of external simulators, provided by the users, to produce the model dynamics. Furthermore, the simulation library is structured in such a way that it can be used independently of S 4 . Deterministic. One way to produce the model dynamics is to execute the model deterministically. This simulation approach involves the transformation of continuous Petri nets into a set of ordinary differential equations (ODEs) [7]. The set of ODEs are then solved numerically using an ODE solver. S 4 supports 14 different ODE solver types (seven solvers for stiff models and seven for solving non-stiff models) ranging from simple fixed step-size, explicit solvers (e.g., Runge Kutta) to variable step-size, variable order, implicit solvers (e.g., Backward differentiation formula). For the latter solver types we deploy the numerical integration library SUNDIAL CVODE [15]. Stochastic. Stochastic simulation applies a different approach to producing model dynamics. Unlike in the deterministic simulation, the fluctuation

A Steering Server for Collaborative Simulation of Quantitative PN

379

Fig. 2. Snoopy’s steering GUI: steering panel (left), output panel (middle), control panel (bottom) and manipulation panel (right). The user can select a subset of the model parameters to change their values on-the-fly while the simulation is running. The simulation results can be viewed as a table, xy plot, or histogram plot; they can also be exported in csv or image format.

of tokens is captured when a model is simulated stochastically. Moreover, stochastic simulation provides a more convenient approach to permit the intervention of user changes during a model execution. The steering action can be immediately carried out during the individual firing of a stochastic transition instead of after each time step as it has to be done for deterministic simulations. S 4 currently supports one algorithm (the Gillespie stochastic simulation algorithm [8]) to simulate Petri nets stochastically; alternative algorithms are scheduled for further developments. Hybrid. With the progress of modelling and simulation, it becomes crucial to handle systems involving some degree of complexity. Such models can often not be executed using exclusively either the deterministic or the stochastic paradigm. As an example consider the model in [14]. Thus, a hybrid method that combines both discrete and continuous places as well as stochastic and continuous transitions is required [11]. S 4 provides the ability to execute such a model via the hybrid approach applying either static or dynamic partitioning [10,11]. In the former, place types (discrete/continuous) and transition types (stochastic/continuous) are explicitly specified by the modeller, while in the latter, place as well as transition types are changed on-the-fly during the simulation based on some dynamically determined measures (e.g., the current values of the transition rates). Other Simulators. For more flexible functionality, S 4 allows advanced users to adopt external solvers to produce the model dynamics. This feature is specifically useful if legacy code exists that has been maintained and debugged over a long time.

M. Herajy and M. Heiner #

 # 

 

  

  

  



  

   

 

  

    

 

  

  

  

      

 

  


   

    

 

 $%   %

 



# 

      

 



  



# 


   !

 "

 $%   %

380


   


   

 



  

Fig. 3. The S 4 architecture. The core components are the models, which consist of the Petri net definition and the result views. Additionally, each model is associated with an internal simulator. S 4 can communicate with an external simulator or GUI client by an API library. Snoopy also adopts the API library to communicate with S 4 .

3

Architecture

Figure 3 presents the different components of S 4 . It consists of one or more models, internal simulators, and a set of clients. Moreover, S 4 can communicate with an external simulator as well as a GUI client through an API library. In the sequel, the different components of S 4 are briefly discussed. 3.1

Models

The basic building blocks inside S 4 are the models. Multiple models can reside in the server memory, and they can run simultaneously. When a new Petri net is submitted via the GUI or the API, a new model data structure is created. A model consists of two main components: the Petri net definition and the model result views. The Petri net definition captures the main model components. It consists of all necessary information that are related to places, transitions, and arcs. Result views are elegant tools to view the simulation results from different perspectives. They can be defined by a user and submitted to S 4 in order to

A Steering Server for Collaborative Simulation of Quantitative PN

381

be shared by other users connected to the same model. Each model can contain several, different views. Views are specified by selecting a set of places and/or transitions for which the progress shall to be monitored. Additional information, such as visualization methods and curve colours, can also be specified. 3.2

Internal Simulators

Each model is associated with an internal simulator to produce the model dynamics. Different simulators that are associated with different models can run simultaneously by creating an individual thread for each running simulation. The supported algorithms are sketched in Section 2.6. 3.3

Clients

S 4 stores the mandatory information about connected users in a special data structure called clients. Clients can be a GUI client or an external simulator. In the former, S 4 creates a separate thread and afterwards replies to the GUI requests, while in the latter it receives simulation results from a (probably remote) external simulator.

4

Typical Use Case

The main purpose of S 4 is to provide sophisticated user support to steer a running simulation. In general, it can be deployed for any application where a quantitative simulation of Petri nets is required. However, the particular application domain, for which S 4 has been developed, is systems and synthetic biology. As an example of models where monitoring and steering is important, we consider the modelling of circadian oscillation – a mechanism that is found in many organisms [5]. A GHPN model for this process is given in [11]. Figure 4 presents the final results of simulating this GHPN model using S 4 . Without user intervention, the simulation will continue with the same values of the key parameters. However, using the computational steering capabilities of S 4 , the user is able to change some key parameters while the simulation is in progress, e.g. to explore the parameter space, and the simulator will directly respond with the accordingly adjusted simulation results. Please refer to [10] and [13] for the detailed intermediate steering steps for this GHPN model.

5

Comparison

S 4 provides a number of dedicated functionalities that are not found in other software tools which utilize Petri nets for modelling and simulation. Thus, we compare S 4 with other tools that provide one or more similar functionalities. We use three tools for comparison purpose: CPN Assistant II, Cell Illustrator, and VCell. However, none of these tools does support the steering of key simulation parameters during model execution.

382

M. Herajy and M. Heiner 18000 25000 16000

14000

20000

concentration

concentration

12000

10000

8000

15000

10000 6000

4000 5000 2000

0

0 0

100

200

300 time

(a)

400

500

0

100

200

300

400

500

time

(b)

Fig. 4. Simulation results of the GHPN model for circadian oscillation. (a) The same key parameter values are used throughout the whole simulation time. (b) Different values are used during the running simulation, fed by the steering feature.

CPN Assistant II [16] is a simulation management tool for coloured Petri nets which were designed using CPN tools [2]. It supports users to prepare, run, and manage multiple simulations over a network. Although CPN Assistant II provides useful features to the users such as the execution of post-processing plug-ins, it does not enable them to collaborate with each other during the simulation. CPN tools do not explicitly support stochastic, continuous or hybrid Petri nets. VCell [3] is a computational environment for modelling of cell biology. It is a distributed software tool where all models are stored on the server side. VCell permits users to collaborate in model construction, however, there is no collaboration supported during the simulation. VCell only supports the simulation of deterministic and stochastic models. Another (commercialised) software that is known in the literature to model biological systems, is Cell Illustrator [19]. It is based on hybrid functional Petri nets [18]. Recently, Cell Illustrator has been extended to support the remote simulation of Petri net models. Nevertheless, it does not allow the adaptation of external simulators to execute model dynamics if the users are not satisfied with the simulator provided by the software. Furthermore, neither stochastic nor hybrid (deterministic – stochastic) simulation are offered.

6

Installation

S 4 is a platform-independent application. Installation packages for Windows, Mac OS, and some selected Linux distribution are available at http://www-dssz.informatik.tu-cottbus.de/snoopy.html. A complete documentation of the installation process as well as the hardware and software requirements are given in [12]. Moreover, a comprehensive user manual, quick start, and a product sheet can be found in [12]. Although the implementation of S 4 builds on several additional libraries (e.g., wxWidgets [4], BOOST [1], and SUNDIAL [15]), no additional dependencies are required in order to run it.

A Steering Server for Collaborative Simulation of Quantitative PN

383

Acknowledgements. The authors would like to thank Christian Rohr for his valuable comments during the implementation of S 4 . We would also like to acknowledge the work of Fei Liu for implementing coloured Petri nets in Snoopy.

References 1. 2. 3. 4. 5. 6.

7.

8. 9.

10. 11. 12. 13. 14.

15.

16.

17.

Boost website, http://www.boost.org/ (accessed: January 14, 2014) CPN tools website, http://cpntools.org/ (accessed: January 10, 2014) Virtual cell website, http://vcell.org/ (accessed: January 10, 2014) wxWidgets website, http://www.wxwidgets.org/ (accessed: January 15, 2014) Barkai, N., Leibler, S.: Biological rhythms: circadian clocks limited by noise. Nature 403, 267–268 (2000) Gao, Q., Gilbert, D., Heiner, M., Liu, F., Maccagnola, D., Tree, D.: Multiscale Modelling and Analysis of Planar Cell Polarity in the Drosophila Wing. IEEE/ACM Transactions on Computational Biology and Bioinformatics 10(2), 337–351 (2013) Gilbert, D., Heiner, M.: From petri nets to differential equations - an integrative approach for biochemical network analysis. In: Donatelli, S., Thiagarajan, P. (eds.) ICATPN 2006. LNCS, vol. 4024, pp. 181–200. Springer, Heidelberg (2006) Gillespie, D.T.: Exact stochastic simulation of coupled chemical reactions. Journal of Physical Chemistry 81(25), 2340–2361 (1977) Heiner, M., Herajy, M., Liu, F., Rohr, C., Schwarick, M.: Snoopy – A unifying Petri net tool. In: Haddad, S., Pomello, L. (eds.) PETRI NETS 2012. LNCS, vol. 7347, pp. 398–407. Springer, Heidelberg (2012) Herajy, M.: Computational Steering of Multi-Scale Biochemical Networks. Ph.D. thesis, BTU Cottbus, Dep. of CS (January 2013) Herajy, M., Heiner, M.: Hybrid representation and simulation of stiff biochemical networks. J. Nonlinear Analysis: Hybrid Systems 6(4), 942–959 (2012) Herajy, M., Heiner, M.: Snoopy Computational Steering Framework – User Manual Version 1.0. Tech. Rep. 02-13, BTU Cottbus, Dept. of CS (July 2013) Herajy, M., Heiner, M.: Petri net-based collaborative simulation and steering of biochemical reaction networks. Fundamenta Informatica (129), 49–67 (2014) Herajy, M., Schwarick, M., Heiner, M.: Hybrid Petri Nets for Modelling the Eukaryotic Cell Cycle. In: Koutny, M., van der Aalst, W.M.P., Yakovlev, A. (eds.) ToPNoC VIII. LNCS, vol. 8100, pp. 123–141. Springer, Heidelberg (2013) Hindmarsh, A., Brown, P., Grant, K., Lee, S., Serban, R., Shumaker, D., Woodward, C.: Sundials: Suite of nonlinear and differential/algebraic equation solvers. ACM Trans. Math. Softw. 31, 363–396 (2005) ˇ Marcinˇcin, J., Slodiˇc´ Koreˇcko, S., ak, V.: CPN Assistant II: A tool for management of networked simulations. In: Haddad, S., Pomello, L. (eds.) PETRI NETS 2012. LNCS, vol. 7347, pp. 408–417. Springer, Heidelberg (2012) Marwan, W., Rohr, C., Heiner, M.: Petri nets in Snoopy: A unifying framework for the graphical display, computational modelling, and simulation of bacterial regulatory networks. In: Methods in Molec. Biol., vol. 804, ch. 1, pp. 409–437 (2012)

384

M. Herajy and M. Heiner

18. Matsuno, H., Nagasaki, M., Miyano, S.: Hybrid Petri net based modeling for biological pathway simulation. Natural Computing 10(3), 1099–1120 (2011) 19. Nagasaki, M., Saito, A., Jeong, E., Li, C., Kojima, K., Ikeda, E., Miyano, S.: Cell Illustrator 4.0: a Computational Platform for Systems Biology. Silico Biology 10 (2010) 20. Rohr, C., Marwan, W., Heiner, M.: Snoopy - a unifying Petri net framework to investigate biomolecular networks. Bioinformatics 26(7), 974–975 (2010) (Advanced Access published February 7, 2010)