This material correspends to an early release of version 3 and some of it is out of date. It is still included here for reference while the new documentation is being written.
Catacomb 3 is designed to address two big problems that hinder the effective use of biological models:
The resolution of both these problems follows the standard paradigm of separating out the different aspects of a model. Part of the work behind a model involve writing software to perform numerical calculations; part of the work is in choosing a good structure and parameterization for a particular class of models; and part is in actually making models themselves - filling out structures and assigning values to parameters to represent particular things.
This closely matches the separation represented by XML (for actual models), XML schema (for model types) and programming languages (for model implementation). However, XML is a technology for IT experts, and XML schema even more so. The challenge in building a modeling system is to give access to the first two levels without depending on specific IT skills.
This has the benefit of modelling to be accessible to people who do not have the particular IT skills. But even for those who do, it is much better to think about how to structure a model without worrying at the same time about implementing it in some particular system. Moreover, models that are free from implementation details or system-specific constraints can be expected to last longer and be more widely used.
A Bit of History
This bit will be about Catacomb 2 and how the structures were hard-coded as java classes (ie created by programmers) with a GUI to create instances and connect them together. Lessons learned, etc - more to come...
The Catacomb 3 approach
This will explain the data model of the data model, how it is actually defined in itself, why this is a good thing, and why it can be confusing. Also, how code is generated from user-defined structures and what should (and more importantly shouldn't) be involved in implementing a model in code.
For now, the types section covers some of this from a more hands-on perspective.
Note that all the model-specific documentation (about particular classes of models such as cells or ion channels) is included within the frameworks themselves. A static version will be generated for inclusion in this site in due course.