E-Cell 3.1.106 Released
Results from the Workshop
This is the two day schedule of the Workshop, with minutes filled in. Topics will give a synopsis of the points mentioned at the Workshop, however, the more detailed and ongoing discussions will also link to a wiki type page where discussion continues.
Day One - January 24th
10:30 - Welcome - Introductions. (Nathan)
Nathan welcomed everyone to the E-Cell 4 Workshop. Explained that this workshop began the process of development for E-Cell 4, by giving opportunities for the E-Cell developer community to go over many topics related to the development of E-Cell 4, such as software requirements, organizational requirements, and generally performing technical steering for the E-Cell Project
10:45 - The E-Cell 4 Project. (Koichi)
History of the E-Cell Project and the E-Cell System explained.
1:30 - Updates from everyone, about five minutes each. (Koichi)
Participants introduced themselves, and the work they have been doing using E-Cell.
2:10 - Feature Set of the Simulation Engine. Overview and Discussion. (Koichi)
The major new goals for E-Cell 4 were introduced. These included models written as python files, an extension of the simulation engine to include several varieties of spatial representation, the ability to reconfigure model structure during simulation, and potential changes to the internal object model of E-Cell. More general ideas about ways that grammar (model-building) and simulation could be further brought together and extended were also expressed.
2:55 - Modeling scheme and object model. (Nathan)
Currently, the algorithms specified within an EM file are paired to simulation algorithms implemented in C++ that are used to instantiate Processes during libecs' model interpretation file. The major result here is that EML files will likely be made obsolete in E-Cell 4, with E-Cell 4 models being written as Python scripts which instantiate model objects.
This topic is under discussion here.
3:30 - Guest talk: E-Cell in Naito lab. (15 + 5 min, Yasuhiro Naito)
Prof. Naito-san gave an overview of his research on ventricular cell models. He suggested some requests for ecell4 as a user, like extensibility of Variable, improvement of empy to enable more flexible model definition, and rich error message.
3:50 - Guest talk: (10+5min, Kazunari Kaizu, Katsuyuki Yugi)
Kaizu-san gave an overview of his work on the current E-Cell ODEStepper and a new Stepper for detection of event location, which was recently developed to construct a cell division model. He is also interested in efficient framework for DEV, dynamic structure of the model, and modeling environment. Yugi-san also gave a talk about his teaching experience using ecell3 in his class.
4:15 - E-Cell as platform. (Nathan)
Went over the current state of the E-Cell System v.3, including the E-Cell Modeling Environment and the E-Cell Analysis Toolkit. For the time being, due to limited resources, all development efforts will focus on the E-Cell 4 Simulation Engine, but with an eye to the future for eventually making these projects, after development of the Simulation Engine nears completion.
On session manager, it was suggested to implement web-based job dispatcher and to divide session scripts / session manager scripts more clearly than in ecell3. A user requested to develop the platform(libraries?) to help users over writing their own analysis scripts. Some ready-made analysis scripts should come with the software package.
A current MSS-sponsored, third party Modeling Environment, currently in development by Sachio Nohara and Motokazu Ishikawa of Mitsubishi Space Software was presented, written using C# and the .NET platform. Everyone was impressed with this as possibly being a type of prototype for the E-Cell 4 Modeling Environment, although it was agreed that "official" components of the E-Cell project should be cross-platform. Various potential toolkits for E-Cell 4 GUI applications were discussed.
Discussion continues here.
4:40 - Development plan and organization. Maintenance of E-Cell 3. (Koichi)
Code management topics were discussed. It was generally agreed that we should stick with sourceforge for now. The topic of dual licensing came up. It was decided that E-Cell 4 should be a branch(?) of the current E-Cell SVN. Slides prepared by Petterri were presented, showing his recommendations for future code-management type things, such as automated nightly builds and tests, and using some tools to enforce naming conventions and coding style. We agreed to make unit tests for the ecell core and try astyle. As for python, we use the coding standards on python.org?.
More here.
Day Two -January 25th
11:15 - Organization. (Koichi)
Don't exactly remember this, distinct from the quasi-organization session the day before. Making another site that focuses ecell as more general, not limited on biology, simulation platform like multi-physics simulator was considered. It was expected to broaden ecell developer community by attracting people from open-source community.
12:00 - Object Model
This was mostly reviewed. The object model of E-Cell currently has several objects that make up the data structure that takes part in simulation, Steppers, Processes, Systems, and Variables. The major result is that it is likely that the System object will be renamed to Entity, in order to reflect conceptual changes in the meaning of that object. Entity object will have 'attributes' as constants and 'properties' as dynamic variables. There was discussion over whether the role between Steppers and Processes, whether that role should be updated, or whether simply the method by which it is invoked by the users could be updated. Some ideas on the Stepper sync in parallel computing environment were also discussed. Base Processes should include that corresponds to physical properties of reactions, time, and space.
1:30 - Technical Discussion: Multi-Spatial Representation. (Koichi)
Koichi introduced his work on Multi-Spatial Representations, that will be one of the big changes to E-Cell 4. In this system, objects can have position represented in one of several schemes, such as particles, lattices, or compartments. Algorithms will be able to manipulate objects based on their position in space, including objects using different intrinsic representations, by a form of "casting" between them. Specifics on the implementation were discussed.
More info here.
2:15 - Technical Discussion: Object model, model structure and specification, dynamic models. (Nathan)
Nathan discussed his work on dynamic model structure. It is a straightforward process in which the major work comes with properly extending the data structure of the libecs Model in real-time. For instance, if a Process is added, that process ptr must be added to a stepper, that stepper must then inventory all the variables either read or mutated by the Process and possibly make changes to its internal structure accordingly, and then new connections between steppers must be calculated. The API for this module was discussed, with possible changes being suggested.
More info here.
2:45 - Technical Discussion: Modeling scheme. (Nathan)
Discussed the advantages and possible disadvantages to using python scripts as model files. It was thought that this would provide more expressibility and flexibility to models, and possess several disadvantages. A model can be regarded as a description of initial condition and configuration including higher level information, and serves as an autogenerator. The major difficulty here appears to be in the problem of dumping models. The python model scripts must know about the corresponding C++ objects, however, for dumping purposes, the C++ must know about the existence of the python objects. Nevertheless, this appears very promising. Another concern about the python-based model definition discussed here was that it might keep beginners away. Keeping SBML compatibility was agreed for this reason.
More info here.
