libSBML Perl API  libSBML 5.8.0 Perl API
 All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Friends Macros Groups Pages
sbmlfwd.h File Reference

Detailed Description

Forward declarations for all opaque C types.

Author
Ben Bornstein

Declaring all types up-front avoids compilation errors of the form "Redefinition of type 'Foo'", and allows our combined C/C++ headers to depend minimally upon each other. Put another way, the type definitions below serve the same purpose as class Foo; forward declarations in C++ code.

Include dependency graph for sbmlfwd.h:
This graph shows which files directly or indirectly include this file:

Macros

#define CLASS_OR_STRUCT   class
 Defined as a class when compiling for C++ and as a C struct when compiling for C. More...
 

Typedefs

typedef class ASTNode ASTNode_t
 Abstract Syntax Tree (AST) representation of a mathematical expression. More...
 
typedef class Compartment Compartment_t
 Implementation of SBML's Compartment construct. More...
 
typedef class CompartmentType CompartmentType_t
 Implementation of SBML's Level 2's CompartmentType construct. More...
 
typedef class Constraint Constraint_t
 Implementation of SBML's Constraint construct. More...
 
typedef class ConversionOption ConversionOption_t
 
typedef class ConversionProperties ConversionProperties_t
 
typedef class CVTerm CVTerm_t
 Representation of MIRIAM-compliant controlled vocabulary annotation. More...
 
typedef class Date Date_t
 Representation of MIRIAM-compliant dates used in ModelHistory. More...
 
typedef class Delay Delay_t
 Implementation of SBML's Delay construct for Event. More...
 
typedef class Event Event_t
 Implementation of SBML's Event construct. More...
 
typedef class EventAssignment EventAssignment_t
 Implementation of SBML's EventAssignment construct for Event. More...
 
typedef class ExpectedAttributes ExpectedAttributes_t
 
typedef class FunctionDefinition FunctionDefinition_t
 Implementation of SBML's FunctionDefinition construct. More...
 
typedef class InitialAssignment InitialAssignment_t
 Implementation of SBML's InitialAssignment construct. More...
 
typedef class KineticLaw KineticLaw_t
 Implementation of SBML's KineticLaw construct. More...
 
typedef class L3ParserSettings L3ParserSettings_t
 
typedef class List List_t
 Simple, plain, generic lists, and associated list utilities. More...
 
typedef class ListOf ListOf_t
 Parent class for the various SBML "ListOfXYZ" classes. More...
 
typedef class LocalParameter LocalParameter_t
 Implementation of SBML Level 3's LocalParameter construct. More...
 
typedef class Model Model_t
 Implementation of SBML's Model construct. More...
 
typedef class ModelCreator ModelCreator_t
 Representation of MIRIAM-compliant model creator data used in ModelHistory. More...
 
typedef class ModelHistory ModelHistory_t
 Representation of MIRIAM-compliant model history data. More...
 
typedef class Parameter Parameter_t
 Implementation of SBML's Parameter construct. More...
 
typedef class Priority Priority_t
 Implementation of SBML Level 3's Priority construct for Event. More...
 
typedef class Reaction Reaction_t
 Implementation of SBML's Reaction construct. More...
 
typedef class Rule Rule_t
 Implementation of SBML's Rule construct. More...
 
typedef class SBase SBase_t
 Implementation of SBase, the base class of most SBML objects. More...
 
typedef class SBaseExtensionPoint SBaseExtensionPoint_t
 Representation of an extension point of SBML's package extension. More...
 
typedef class SBasePlugin SBasePlugin_t
 
typedef class
SBasePluginCreatorBase 
SBasePluginCreatorBase_t
 
typedef class SBMLDocument SBMLDocument_t
 Container for an SBML document and interface for global operations on SBML documents. More...
 
typedef class SBMLDocumentPlugin SBMLDocumentPlugin_t
 
typedef class SBMLError SBMLError_t
 Representation of errors, warnings and other diagnostics. More...
 
typedef class SBMLExtension SBMLExtension_t
 The core component of SBML's package extension. More...
 
typedef class
ISBMLExtensionNamespaces 
SBMLExtensionNamespaces_t
 Class to store level, version and namespace information of SBML extension package. More...
 
typedef class SBMLNamespaces SBMLNamespaces_t
 Class to store SBML level, version and namespace information. More...
 
typedef class SBMLReader SBMLReader_t
 Methods for reading SBML from files and text strings. More...
 
typedef class SBMLWriter SBMLWriter_t
 Methods for writing SBML to files and text strings. More...
 
typedef class Species Species_t
 Implementation of SBML's Species construct. More...
 
typedef class
SimpleSpeciesReference 
SpeciesReference_t
 In C, a SpeciesReference_t is actually a synonym for the SimpleSpeciesReference base class. More...
 
typedef class SpeciesType SpeciesType_t
 Implementation of SBML Level 2's SpeciesType construct. More...
 
typedef class StoichiometryMath StoichiometryMath_t
 Implementation of SBML Level 2's StoichiometryMath construct. More...
 
typedef class Trigger Trigger_t
 Implementation of SBML's Trigger construct for Event. More...
 
typedef class Unit Unit_t
 Implementation of SBML's Unit construct. More...
 
typedef class UnitDefinition UnitDefinition_t
 Implementation of SBML's UnitDefinition construct. More...
 
typedef class XMLAttributes XMLAttributes_t
 Representation of attributes on an XML node. More...
 
typedef class XMLError XMLError_t
 Representation of errors, warnings and other diagnostics. More...
 
typedef class XMLErrorLog XMLErrorLog_t
 Log of errors and other events encountered while processing an XML file or data stream. More...
 
typedef class XMLNamespaces XMLNamespaces_t
 Representation of XML Namespaces. More...
 
typedef class XMLNode XMLNode_t
 Representation of a node in an XML document tree. More...
 
typedef class XMLToken XMLToken_t
 Representation of a token in an XML stream. More...
 
typedef class XMLTriple XMLTriple_t
 Representation of a qualified XML name. More...
 

Macro Definition Documentation

#define CLASS_OR_STRUCT   class

Defined as a class when compiling for C++ and as a C struct when compiling for C.

Typedef Documentation

typedef class ASTNode ASTNode_t

Abstract Syntax Tree (AST) representation of a mathematical expression.

This class of objects is defined by libSBML only and has no direct equivalent in terms of SBML components. This class is not prescribed by the SBML specifications, although it is used to implement features defined in SBML.

Abstract Syntax Trees (ASTs) are a simple kind of data structure used in libSBML for storing mathematical expressions. The ASTNode is the cornerstone of libSBML's AST representation. An AST "node" represents the most basic, indivisible part of a mathematical formula and come in many types. For instance, there are node types to represent numbers (with subtypes to distinguish integer, real, and rational numbers), names (e.g., constants or variables), simple mathematical operators, logical or relational operators and functions. LibSBML ASTs provide a canonical, in-memory representation for all mathematical formulas regardless of their original format (which might be MathML or might be text strings).

An AST node in libSBML is a recursive structure containing a pointer to the node's value (which might be, for example, a number or a symbol) and a list of children nodes. Each ASTNode node may have none, one, two, or more children depending on its type. The following diagram illustrates an example of how the mathematical expression "1 + 2" is represented as an AST with one plus node having two integer children nodes for the numbers 1 and 2. The figure also shows the corresponding MathML representation:

Example AST representation of a mathematical expression.
Infix AST MathML
1 + 2 <math xmlns="http://www.w3.org/1998/Math/MathML">
  <apply>
    <plus/>
    <cn type="integer"> 1 </cn>
    <cn type="integer"> 2 </cn>
  </apply>
</math>

The following are other noteworthy points about the AST representation in libSBML:

  • A numerical value represented in MathML as a real number with an exponent is preserved as such in the AST node representation, even if the number could be stored in a double data type. This is done so that when an SBML model is read in and then written out again, the amount of change introduced by libSBML to the SBML during the round-trip activity is minimized.

  • Rational numbers are represented in an AST node using separate numerator and denominator values. These can be retrieved using the methods ASTNode::getNumerator() and ASTNode::getDenominator().

  • The children of an ASTNode are other ASTNode objects. The list of children is empty for nodes that are leaf elements, such as numbers. For nodes that are actually roots of expression subtrees, the list of children points to the parsed objects that make up the rest of the expression.

The set of possible ASTNode types

Every ASTNode has an associated type code to indicate, for example, whether it holds a number or stands for an arithmetic operator. The list of possible types is quite long, because it covers all the mathematical functions that are permitted in SBML. The values are shown in the following table:

  • AST_CONSTANT_E
  • AST_CONSTANT_FALSE
  • AST_CONSTANT_PI
  • AST_CONSTANT_TRUE
  • AST_DIVIDE
  • AST_FUNCTION
  • AST_FUNCTION_ABS
  • AST_FUNCTION_ARCCOS
  • AST_FUNCTION_ARCCOSH
  • AST_FUNCTION_ARCCOT
  • AST_FUNCTION_ARCCOTH
  • AST_FUNCTION_ARCCSC
  • AST_FUNCTION_ARCCSCH
  • AST_FUNCTION_ARCSEC
  • AST_FUNCTION_ARCSECH
  • AST_FUNCTION_ARCSIN
  • AST_FUNCTION_ARCSINH
  • AST_FUNCTION_ARCTAN
  • AST_FUNCTION_ARCTANH
  • AST_FUNCTION_CEILING
  • AST_FUNCTION_COS
  • AST_FUNCTION_COSH
  • AST_FUNCTION_COT
  • AST_FUNCTION_COTH
  • AST_FUNCTION_CSC
  • AST_FUNCTION_CSCH
  • AST_FUNCTION_DELAY
  • AST_FUNCTION_EXP
  • AST_FUNCTION_FACTORIAL
  • AST_FUNCTION_FLOOR
  • AST_FUNCTION_LN
  • AST_FUNCTION_LOG
  • AST_FUNCTION_PIECEWISE
  • AST_FUNCTION_POWER
  • AST_FUNCTION_ROOT
  • AST_FUNCTION_SEC
  • AST_FUNCTION_SECH
  • AST_FUNCTION_SIN
  • AST_FUNCTION_SINH
  • AST_FUNCTION_TAN
  • AST_FUNCTION_TANH
  • AST_INTEGER
  • AST_LAMBDA
  • AST_LOGICAL_AND
  • AST_LOGICAL_NOT
  • AST_LOGICAL_OR
  • AST_LOGICAL_XOR
  • AST_MINUS
  • AST_NAME
  • AST_NAME_AVOGADRO (Level 3 only)
  • AST_NAME_TIME
  • AST_PLUS
  • AST_POWER
  • AST_RATIONAL
  • AST_REAL
  • AST_REAL_E
  • AST_RELATIONAL_EQ
  • AST_RELATIONAL_GEQ
  • AST_RELATIONAL_GT
  • AST_RELATIONAL_LEQ
  • AST_RELATIONAL_LT
  • AST_RELATIONAL_NEQ
  • AST_TIMES
  • AST_UNKNOWN

The types have the following meanings:

  • If the node is basic mathematical operator (e.g., "+"), then the node's type will be AST_PLUS, AST_MINUS, AST_TIMES, AST_DIVIDE, or AST_POWER, as appropriate.

  • If the node is a predefined function or operator from SBML Level 1 (in the string-based formula syntax used in Level 1) or SBML Levels 2 and 3 (in the subset of MathML used in SBML Levels 2 and 3), then the node's type will be either AST_FUNCTION_X, AST_LOGICAL_X, or AST_RELATIONAL_X, as appropriate. (Examples: AST_FUNCTION_LOG, AST_RELATIONAL_LEQ.)

  • If the node refers to a user-defined function, the node's type will be AST_FUNCTION (because it holds the name of the function).

  • If the node is a lambda expression, its type will be AST_LAMBDA.

  • If the node is a predefined constant ("ExponentialE", "Pi", "True" or "False"), then the node's type will be AST_CONSTANT_E, AST_CONSTANT_PI, AST_CONSTANT_TRUE, or AST_CONSTANT_FALSE.

  • (Levels 2 and 3 only) If the node is the special MathML csymbol time, the value of the node will be AST_NAME_TIME. (Note, however, that the MathML csymbol delay is translated into a node of type AST_FUNCTION_DELAY. The difference is due to the fact that time is a single variable, whereas delay is actually a function taking arguments.)

  • (Level 3 only) If the node is the special MathML csymbol avogadro, the value of the node will be AST_NAME_AVOGADRO.

  • If the node contains a numerical value, its type will be AST_INTEGER, AST_REAL, AST_REAL_E, or AST_RATIONAL, as appropriate.

Converting between ASTs and text strings

The text-string form of mathematical formulas produced by and read by and

are in a simple C-inspired infix notation. A formula in this text-string form can be handed to a program that understands SBML mathematical expressions, or used as part of a translation system. The libSBML distribution comes with an example program in the "examples" subdirectory called translateMath that implements an interactive command-line demonstration of translating infix formulas into MathML and vice-versa.

The formula strings may contain operators, function calls, symbols, and white space characters. The allowable white space characters are tab and space. The following are illustrative examples of formulas expressed in the syntax:

0.10 * k4^2
(vm * s1)/(km + s1)

The following table shows the precedence rules in this syntax. In the Class column, operand implies the construct is an operand, prefix implies the operation is applied to the following arguments, unary implies there is one argument, and binary implies there are two arguments. The values in the Precedence column show how the order of different types of operation are determined. For example, the expression a * b + c is evaluated as (a * b) + c because the * operator has higher precedence. The Associates column shows how the order of similar precedence operations is determined; for example, a - b + c is evaluated as (a - b) + c because the + and - operators are left-associative. The precedence and associativity rules are taken from the C programming language, except for the symbol ^, which is used in C for a different purpose. (Exponentiation can be invoked using either ^ or the function power.)

Token Operation Class Precedence Associates
namesymbol referenceoperand6n/a
(expression)expression groupingoperand6n/a
f(...)function callprefix6left
-negationunary5right
^powerbinary4left
*multiplicationbinary3left
/divisonbinary3left
+additionbinary2left
-subtractionbinary2left
,argument delimiterbinary1left
A table of the expression operators and their precedence in the text-string format for mathematical expressions used by SBML_parseFormula().

A program parsing a formula in an SBML model should assume that names appearing in the formula are the identifiers of Species, Parameter, Compartment, FunctionDefinition, Reaction (in SBML Levels 2 and 3), or SpeciesReference (in SBML Level 3 only) objects defined in a model. When a function call is involved, the syntax consists of a function identifier, followed by optional white space, followed by an opening parenthesis, followed by a sequence of zero or more arguments separated by commas (with each comma optionally preceded and/or followed by zero or more white space characters), followed by a closing parenthesis. There is an almost one-to-one mapping between the list of predefined functions available, and those defined in MathML. All of the MathML functions are recognized; this set is larger than the functions defined in SBML Level 1. In the subset of functions that overlap between MathML and SBML Level 1, there exist a few differences. The following table summarizes the differences between the predefined functions in SBML Level 1 and the MathML equivalents in SBML Levels 2 and  3:

Text string formula functions MathML equivalents in SBML Levels 2 and 3
acosarccos
asinarcsin
atanarctan
ceilceiling
logln
log10(x)log(10, x)
pow(x, y)power(x, y)
sqr(x)power(x, 2)
sqrt(x)root(2, x)
Table comparing the names of certain functions in the SBML text-string formula syntax and MathML. The left column shows the names of functions recognized by SBML_parseFormula(); the right column shows their equivalent function names in MathML 2.0, used in SBML Levels 2 and 3.
Warning
We urge developers to keep in mind that the text-string formula syntax is specific to SBML Level 1's C-like mathematical formula syntax. In particular, it is not a general-purpose mathematical expression syntax. LibSBML provides methods for parsing and transforming text-string math formulas back and forth from AST structures, but it is important to keep the system's limitations in mind.
typedef class Compartment Compartment_t

Implementation of SBML's Compartment construct.

A compartment in SBML represents a bounded space in which species are located. Compartments do not necessarily have to correspond to actual structures inside or outside of a biological cell.

It is important to note that although compartments are optional in the overall definition of Model, every species in an SBML model must be located in a compartment. This in turn means that if a model defines any species, the model must also define at least one compartment. The reason is simply that species represent physical things, and therefore must exist somewhere. Compartments represent the somewhere.

Compartment has one required attribute, "id", to give the compartment a unique identifier by which other parts of an SBML model definition can refer to it. A compartment can also have an optional "name" attribute of type string. Identifiers and names must be used according to the guidelines described in the SBML specifications.

Compartment also has an optional attribute "spatialDimensions" that is used to indicate the number of spatial dimensions possessed by the compartment. Most modeling scenarios involve compartments with integer values of "spatialDimensions" of 3 (i.e., a three-dimensional compartment, which is to say, a volume), or 2 (a two-dimensional compartment, a surface), or 1 (a one-dimensional compartment, a line). In SBML Level 3, the type of this attribute is double, there are no restrictions on the permitted values of the "spatialDimensions" attribute, and there are no default values. In SBML Level 2, the value must be a positive integer, and the default value is 3; the permissible values in SBML Level 2 are 3, 2, 1, and 0 (for a point).

Another optional attribute on Compartment is "size", representing the initial total size of that compartment in the model. The "size" attribute must be a floating-point value and may represent a volume (if the compartment is a three-dimensional one), or an area (if the compartment is two-dimensional), or a length (if the compartment is one-dimensional). There is no default value of compartment size in SBML Level 2 or Level 3. In particular, a missing "size" value does not imply that the compartment size is 1. (This is unlike the definition of compartment "volume" in SBML Level 1.) When the compartment's "spatialDimensions" attribute does not have a value of 0, a missing value of "size" for a given compartment signifies that the value either is unknown, or to be obtained from an external source, or determined by an InitialAssignment, AssignmentRule, AlgebraicRule or RateRule elsewhere in the model. In SBML Level 2, there are additional special requirements on the values of "size"; we discuss them in a separate section below.

The units associated with a compartment's "size" attribute value may be set using the optional attribute "units". The rules for setting and using compartment size units differ between SBML Level 2 and Level 3, and are discussed separately below.

Finally, the optional Compartment attribute named "constant" is used to indicate whether the compartment's size stays constant after simulation begins. A value of true indicates the compartment's "size" cannot be changed by any other construct except InitialAssignment; a value of false indicates the compartment's "size" can be changed by other constructs in SBML. In SBML Level 2, there is an additional explicit restriction that if "spatialDimensions"="0", the value cannot be changed by InitialAssignment either. Further, in Level 2, "constant" has a default value of true. In SBML Level 3, there is no default value for the "constant" attribute.

Additional considerations in SBML Level 2

In SBML Level 2, the default units of compartment size, and the kinds of units allowed as values of the attribute "units", interact with the number of spatial dimensions of the compartment. The value of the "units" attribute of a Compartment object must be one of the base units (see Unit), or the predefined unit identifiers volume, area, length or dimensionless, or a new unit defined by a UnitDefinition object in the enclosing Model, subject to the restrictions detailed in the following table:

Restrictions on values permitted for compartment size and units attributes.
Value of
spatialDimensions
size
allowed?
units
allowed?
Allowable kinds of units Default value of attribute units
"3" yes yes units of volume, or dimensionless "volume"
"2" yes yes units of area, or dimensionless "area"
"1" yes yes units of length, or dimensionless "length"
"0" no no (no units allowed)

In SBML Level 2, the units of the compartment size, as defined by the "units" attribute or (if "units" is not set) the default value listed in the table above, are used in the following ways when the compartment has a "spatialDimensions" value greater than 0:

  • The value of the "units" attribute is used as the units of the compartment identifier when the identifier appears as a numerical quantity in a mathematical formula expressed in MathML.

  • The math element of an AssignmentRule or InitialAssignment referring to this compartment must have identical units.

  • In RateRule objects that set the rate of change of the compartment's size, the units of the rule's math element must be identical to the compartment's "units" attribute divided by the default time units. (In other words, the units for the rate of change of compartment size are compartment size/time units.

  • When a Species is to be treated in terms of concentrations or density, the units of the spatial size portion of the concentration value (i.e., the denominator in the units formula substance/size) are those indicated by the value of the "units" attribute on the compartment in which the species is located.

Compartments with "spatialDimensions"=0 require special treatment in this framework. As implied above, the "size" attribute must not have a value on an SBML Level 2 Compartment object if the "spatialDimensions" attribute has a value of 0. An additional related restriction is that the "constant" attribute must default to or be set to true if the value of the "spatialDimensions" attribute is 0, because a zero-dimensional compartment cannot ever have a size.

If a compartment has no size or dimensional units, how should such a compartment's identifier be interpreted when it appears in mathematical formulas? The answer is that such a compartment's identifier should not appear in mathematical formulas in the first place—it has no value, and its value cannot change. Note also that a zero-dimensional compartment is a point, and species located at points can only be described in terms of amounts, not spatially-dependent measures such as concentration. Since SBML KineticLaw formulas are already in terms of substance/time and not (say) concentration/time, volume or other factors in principle are not needed for species located in zero-dimensional compartments.

Finally, in SBML Level 2 Versions 2–4, each compartment in a model may optionally be designated as belonging to a particular compartment type. The optional attribute "compartmentType" is used identify the compartment type represented by the Compartment structure. The "compartmentType" attribute's value must be the identifier of a CompartmentType instance defined in the model. If the "compartmentType" attribute is not present on a particular compartment definition, a unique virtual compartment type is assumed for that compartment, and no other compartment can belong to that compartment type. The values of "compartmentType" attributes on compartments have no effect on the numerical interpretation of a model. Simulators and other numerical analysis software may ignore "compartmentType" attributes. The "compartmentType" attribute and the CompartmentType class of objects are not present in SBML Level 3 Core nor in SBML Level 1.

Additional considerations in SBML Level 3

One difference between SBML Level 3 and lower Levels of SBML is that there are no restrictions on the permissible values of the "spatialDimensions" attribute, and there is no default value defined for the attribute. The value of "spatialDimensions" does not have to be an integer, either; this is to allow for the possibility of representing structures with fractal dimensions.

The number of spatial dimensions possessed by a compartment cannot enter into mathematical formulas, and therefore cannot directly alter the numerical interpretation of a model. However, the value of "spatialDimensions" does affect the interpretation of the units associated with a compartment's size. Specifically, the value of "spatialDimensions" is used to select among the Model attributes "volumeUnits", "areaUnits" and "lengthUnits" when a Compartment object does not define a value for its "units" attribute.

The "units" attribute may be left unspecified for a given compartment in a model; in that case, the compartment inherits the unit of measurement specified by one of the attributes on the enclosing Model object instance. The applicable attribute on Model depends on the value of the compartment's "spatialDimensions" attribute; the relationship is shown in the table below. If the Model object does not define the relevant attribute ("volumeUnits", "areaUnits" or "lengthUnits") for a given "spatialDimensions" value, the unit associated with that Compartment object's size is undefined. If both "spatialDimensions" and "units" are left unset on a given Compartment object instance, then no unit can be chosen from among the Model's "volumeUnits", "areaUnits" or "lengthUnits" attributes (even if the Model instance provides values for those attributes), because there is no basis to select between them and there is no default value of "spatialDimensions". Leaving the units of compartments' sizes undefined in an SBML model does not render the model invalid; however, as a matter of best practice, we strongly recommend that all models specify the units of measurement for all compartment sizes.

Interpretation of the Compartment "units" attribute.
Value of attribute
"spatialDimensions"
Attribute of Model used
for inheriting the unit
Recommended candidate units
"3" "volumeUnits" units of volume, or dimensionless
"2" "areaUnits" units of area, or dimensionless
"1" "lengthUnits" units of length, or dimensionless
other no units inherited no specific recommendations

The unit of measurement associated with a compartment's size, as defined by the "units" attribute or (if "units" is not set) the inherited value from Model according to the table above, is used in the following ways:

  • When the identifier of the compartment appears as a numerical quantity in a mathematical formula expressed in MathML, it represents the size of the compartment, and the unit associated with the size is the value of the "units" attribute.

  • When a Species is to be treated in terms of concentrations or density, the unit associated with the spatial size portion of the concentration value (i.e., the denominator in the formula amount/size) is specified by the value of the "units" attribute on the compartment in which the species is located.

  • The "math" elements of AssignmentRule, InitialAssignment and EventAssignment objects setting the value of the compartment size should all have the same units as the unit associated with the compartment's size.

  • In a RateRule object that defines a rate of change for a compartment's size, the unit of the rule's "math" element should be identical to the compartment's "units" attribute divided by the model-wide unit of time. (In other words, {unit of compartment size}/{unit of time}.)

Other aspects of Compartment

In SBML Level 1 and Level 2, Compartment has an optional attribute named "outside", whose value can be the identifier of another Compartment object defined in the enclosing Model object. Doing so means that the other compartment contains it or is outside of it. This enables the representation of simple topological relationships between compartments, for those simulation systems that can make use of the information (e.g., for drawing simple diagrams of compartments). It is worth noting that in SBML, there is no relationship between compartment sizes when compartment positioning is expressed using the "outside" attribute. The size of a given compartment does not in any sense include the sizes of other compartments having it as the value of their "outside" attributes. In other words, if a compartment B has the identifier of compartment A as its "outside" attribute value, the size of A does not include the size of B. The compartment sizes are separate.

In Level 2, there are two restrictions on the "outside" attribute. First, because a compartment with "spatialDimensions" of 0 has no size, such a compartment cannot act as the container of any other compartment except compartments that also have "spatialDimensions" values of 0. Second, the directed graph formed by representing Compartment structures as vertexes and the "outside" attribute values as edges must be acyclic. The latter condition is imposed to prevent a compartment from being contained inside itself. In the absence of a value for "outside", compartment definitions in SBML Level 2 do not have any implied spatial relationships between each other.

Implementation of SBML's Level 2's CompartmentType construct.

SBML Level 2 Versions 2–4 provide the compartment type as a grouping construct that can be used to establish a relationship between multiple Compartment objects. A CompartmentType object only has an identity, and this identity can only be used to indicate that particular Compartment objects in the model belong to this type. This may be useful for conveying a modeling intention, such as when a model contains many similar compartments, either by their biological function or the reactions they carry. Without a compartment type construct, it would be impossible within SBML itself to indicate that all of the compartments share an underlying conceptual relationship because each SBML compartment must be given a unique and separate identity. Compartment types have no mathematical meaning in SBML—they have no effect on a model's mathematical interpretation. Simulators and other numerical analysis software may ignore CompartmentType definitions and references to them in a model.

There is no mechanism in SBML Level 2 for representing hierarchies of compartment types. One CompartmentType instance cannot be the subtype of another CompartmentType instance; SBML provides no means of defining such relationships.

As with other major structures in SBML, CompartmentType has a mandatory attribute, "id", used to give the compartment type an identifier. The identifier must be a text string conforming to the identifer syntax permitted in SBML. CompartmentType also has an optional "name" attribute, of type string. The "id" and "name" must be used according to the guidelines described in the SBML specification (e.g., Section 3.3 in the Level 2 Version 4 specification).

CompartmentType was introduced in SBML Level 2 Version 2. It is not available in SBML Level 1 nor in Level 3.

See Also
Compartment
ListOfCompartmentTypes
SpeciesType
ListOfSpeciesTypes
typedef class Constraint Constraint_t

Implementation of SBML's Constraint construct.

The Constraint object class was introduced in SBML Level 2 Version 2 as a mechanism for stating the assumptions under which a model is designed to operate. The constraints are statements about permissible values of different quantities in a model. Constraints are not used to compute dynamical values for simulation or analysis, but rather, they serve an advisory role for simulation/analysis tools.

SBML's Constraint object class has one required attribute, "id", to give the parameter a unique identifier by which other parts of an SBML model definition can refer to it. A Constraint object can also have an optional "name" attribute of type string. Identifiers and names must be used according to the guidelines described in the SBML specification (e.g., Section 3.3 in the Level 2 Version 4 specification).

Constraint has one required subelement, "math", containing a MathML formula defining the condition of the constraint. This formula must return a boolean value of true when the model is a valid state. The formula can be an arbitrary expression referencing the variables and other entities in an SBML model. The evaluation of "math" and behavior of constraints are described in more detail below.

A Constraint structure also has an optional subelement called "message". This can contain a message in XHTML format that may be displayed to the user when the condition of the formula in the "math" subelement evaluates to a value of false. Software tools are not required to display the message, but it is recommended that they do so as a matter of best practice. The XHTML content within a "message" subelement must follow the same restrictions as for the "notes" element on SBase described in in the SBML Level 2 specification; please consult the SBML specification document corresponding to the SBML Level and Version of your model for more information about the requirements for "notes" content.

Constraint was introduced in SBML Level 2 Version 2. It is not available in earlier versions of Level 2 nor in any version of Level 1.

Semantics of Constraints

In the context of a simulation, a Constraint has effect at all times t $\geq$ 0. Each Constraint's "math" subelement is first evaluated after any InitialAssignment definitions in a model at t = 0 and can conceivably trigger at that point. (In other words, a simulation could fail a constraint immediately.)

Constraint structures cannot and should not be used to compute the dynamical behavior of a model as part of, for example, simulation. Constraints may be used as input to non-dynamical analysis, for instance by expressing flux constraints for flux balance analysis.

The results of a simulation of a model containing a constraint are invalid from any simulation time at and after a point when the function given by the "math" subelement returns a value of false. Invalid simulation results do not make a prediction of the behavior of the biochemical reaction network represented by the model. The precise behavior of simulation tools is left undefined with respect to constraints. If invalid results are detected with respect to a given constraint, the "message" subelement may optionally be displayed to the user. The simulation tool may also halt the simulation or clearly delimit in output data the simulation time point at which the simulation results become invalid.

SBML does not impose restrictions on duplicate Constraint definitions or the order of evaluation of Constraint objects in a model. It is possible for a model to define multiple constraints all with the same mathematical expression. Since the failure of any constraint indicates that the model simulation has entered an invalid state, a system is not required to attempt to detect whether other constraints in the model have failed once any one constraint has failed.

typedef class CVTerm CVTerm_t

Representation of MIRIAM-compliant controlled vocabulary annotation.

This class of objects is defined by libSBML only and has no direct equivalent in terms of SBML components. This class is not prescribed by the SBML specifications, although it is used to implement features defined in SBML.

The SBML Level 2 and Level 3 specifications define a simple format for annotating models when (a) referring to controlled vocabulary terms and database identifiers that define and describe biological and biochemical entities, and (b) describing the creator of a model and the model's modification history. This SBML format is a concrete syntax that conforms to the guidelines of MIRIAM ("Minimum Information Requested in the Annotation of biochemical Models", Nature Biotechnology, vol. 23, no. 12, Dec. 2005). The format uses a subset of W3C RDF (Resource Description Format). In order to help application developers work with annotations in this format, libSBML provides several helper classes that provide higher-level interfaces to the data elements; these classes include CVTerm, ModelCreator, ModelHistory, RDFAnnotationParser, and Date.

Components of an SBML annotation

The SBML annotation format consists of RDF-based content placed inside an <annotation> element attached to an SBML component such as Species, Compartment, etc. The following template illustrates the different parts of SBML annotations in XML form:

<SBML_ELEMENT +++ metaid="meta id" +++>
  +++
  <annotation>
    +++
    <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:dcterm="http://purl.org/dc/terms/"
             xmlns:vcard="http://www.w3.org/2001/vcard-rdf/3.0#"
             xmlns:bqbiol="http://biomodels.net/biology-qualifiers/"
             xmlns:bqmodel="http://biomodels.net/model-qualifiers/" >
      <rdf:Description rdf:about="#meta id">
        HISTORY
        <RELATION_ELEMENT>
          <rdf:Bag>
            <rdf:li rdf:resource="URI" />
            ...
          </rdf:Bag>
        </RELATION_ELEMENT>
        ...
      </rdf:Description>
      +++
    </rdf:RDF>
    +++
  </annotation>
  +++
</SBML_ELEMENT>

In the template above, the placeholder SBML_ELEMENT stands for the XML tag name of an SBML model component (e.g., model, reaction, etc.) and the placeholder meta id stands for the element's meta identifier, which is a field available on all SBML components derived from the SBase base object class. The dotted portions are optional, the symbol +++ is a placeholder for either no content or valid XML content that is not defined by this annotation scheme, and the ellipses ... are placeholders for zero or more elements of the same form as the immediately preceding element. The optional content HISTORY is a creation and modification history; in libSBML, this is stored using ModelHistory objects.

The placeholder RELATION_ELEMENT refers to a BioModels.net qualifier element name. This is an element in either the XML namespace "http://biomodels.net/model-qualifiers" (for model qualifiers) or "http://biomodels.net/biology-qualifiers" (for biological qualifier). The URI is a required data value that uniquely identifies a resource and data within that resource to which the annotation refers. (Since a URI is only a label, not an address, applications will often want a means of looking up the resource to which the URI refers. Providing the facilities for doing this is the purpose of MIRIAM Resources.)

The relation-resource pairs above are the "controlled vocabulary" terms that which CVTerm is designed to store and manipulate. The next section describes these parts in more detail. For more information about SBML annotations in general, please refer to Section 6 in the SBML Level 2 (Versions 2–4) or Level 3 specification documents.

The parts of a CVTerm

Annotations that refer to controlled vocabularies are managed in libSBML using CVTerm objects. A set of RDF-based annotations attached to a given SBML <annotation> element are read by RDFAnnotationParser and converted into a list of these CVTerm objects. Each CVTerm object instance stores the following components of an annotation:

  • The qualifier, which can be a BioModels.net "biological qualifier", a BioModels.net "model qualifier", or an unknown qualifier (as far as the CVTerm class is concerned). Qualifiers are used in MIRIAM to indicate the nature of the relationship between the object being annotated and the resource. In CVTerm, the qualifiers can be manipulated using the methods CVTerm::getQualifierType(), CVTerm::setQualifierType(), and related methods.

  • The resource, represented by a URI (which, we must remind developers, is not the same as a URL). In the CVTerm class, the resource component can be manipulated using the methods CVTerm::addResource() and CVTerm::removeResource().

Note that a CVTerm contains a single qualifier, but possibly more than one resource. This corresponds to the possibility of an annotation that points to multiple resources, all of which are qualified by the same BioModels.net qualifier. The CVTerm object class supports this by supporting a list of resources.

Detailed explanations of the qualifiers defined by BioModels.net can be found at http://biomodels.net/qualifiers.

typedef class Date Date_t

Representation of MIRIAM-compliant dates used in ModelHistory.

This class of objects is defined by libSBML only and has no direct equivalent in terms of SBML components. This class is not prescribed by the SBML specifications, although it is used to implement features defined in SBML.

A Date object stores a reasonably complete representation of date and time. Its purpose is to serve as a way to store dates to be read and written in the W3C date format used in RDF Dublin Core annotations within SBML. The W3C date format is a restricted form of ISO 8601, the international standard for the representation of dates and times. A time and date value in this W3C format takes the form YYYY-MM-DDThh:mm:ssXHH:ZZ (e.g., 1997-07-16T19:20:30+01:00) where XHH:ZZ is the time zone offset. The libSBML Date object contains the following fields to represent these values:

  • year: an unsigned int representing the year. This should be a four-digit number such as 2011.

  • month: an unsigned int representing the month, with a range of values of 1–12. The value 1 represents January, and so on.

  • day: an unsigned int representing the day of the month, with a range of values of 1–31.

  • hour: an unsigned int representing the hour on a 24-hour clock, with a range of values of 0–23.

  • minute: an unsigned int representing the minute, with a range of 0–59.

  • second: an unsigned int representing the second, with a range of 0–59.

  • sign: an unsigned int representing the sign of the offset (0 signifying + and 1 signifying -). See the paragraph below for further explanations.

  • hours offset: an unsigned int representing the time zone's hour offset from GMT.

  • minute offset: an unsigned int representing the time zone's minute offset from GMT.

To illustrate the time zone offset, a value of -05:00 would correspond to USA Eastern Standard Time. In the Date object, this would require a value of 1 for the sign field, 5 for the hour offset and 0 for the minutes offset.

In the restricted RDF annotations used in SBML, described in Section 6 of the SBML Level 2 and Level 3 specification documents, date/time stamps can be used to indicate the time of creation and modification of a model. The following SBML model fragment illustrates this:

<model metaid="_180340" id="GMO" name="Goldbeter1991_MinMitOscil">
    <annotation>
        <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
                 xmlns:dc="http://purl.org/dc/elements/1.1/"
                 xmlns:dcterms="http://purl.org/dc/terms/"
                 xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#" >
            <rdf:Description rdf:about="#_180340">
                <dc:creator>
                    <rdf:Bag>
                        <rdf:li rdf:parseType="Resource">
                            <vCard:N rdf:parseType="Resource">
                                <vCard:Family>Shapiro</vCard:Family>
                                <vCard:Given>Bruce</vCard:Given>
                            </vCard:N>
                            <vCard:EMAIL>bshapiro@jpl.nasa.gov</vCard:EMAIL>
                            <vCard:ORG rdf:parseType="Resource">
                                <vCard:Orgname>NASA Jet Propulsion Laboratory</vCard:Orgname>
                            </vCard:ORG>
                        </rdf:li>
                    </rdf:Bag>
                </dc:creator>
                <dcterms:created rdf:parseType="Resource">
                    <dcterms:W3CDTF>2005-02-06T23:39:40+00:00</dcterms:W3CDTF>
                </dcterms:created>
                <dcterms:modified rdf:parseType="Resource">
                    <dcterms:W3CDTF>2005-09-13T13:24:56+00:00</dcterms:W3CDTF>
                </dcterms:modified>
            </rdf:Description>
        </rdf:RDF>
    </annotation>
</model>
typedef class Delay Delay_t

Implementation of SBML's Delay construct for Event.

An Event object defines when the event can occur, the variables that are affected by the event, and how the variables are affected. The effect of the event can optionally be delayed after the occurrence of the condition which invokes it. An event delay is defined using an object of class Delay.

The object class Delay is derived from SBase and adds a single subelement called "math". This subelement is used to hold MathML content. The mathematical formula represented by "math" must evaluate to a numerical value. It is used as the length of time between when the event is triggered and when the event's assignments are actually executed. If no delay is present on a given Event, a time delay of zero is assumed.

The expression in "math" must be evaluated at the time the event is triggered. The expression must always evaluate to a nonnegative number (otherwise, a nonsensical situation could arise where an event is defined to execute before it is triggered!).

The units of the mathematical expression in a Delay

In SBML Level 2 versions before Version 4, the units of the numerical value computed by the Delay's "math" expression are required to be in units of time, or the model is considered to have a unit consistency error. In Level 2 Version 4 as well as SBML Level 3 Version 1 Core, this requirement is relaxed; these specifications only stipulate that the units of the numerical value computed by a Delay instance's "math" expression should match the model's units of time (meaning the definition of the time units in the model). LibSBML respects these requirements, and depending on whether an earlier Version of SBML Level 2 is in use, libSBML may or may not flag unit inconsistencies as errors or merely warnings.

Note that units are not predefined or assumed for the contents of "math" in a Delay object; rather, they must be defined explicitly for each instance of a Delay object in a model. This is an important point to bear in mind when literal numbers are used in delay expressions. For example, the following Event instance would result in a warning logged by SBMLDocument::checkConsistency() about the fact that libSBML cannot verify the consistency of the units of the expression. The reason is that the formula inside the "math" element does not have any declared units, whereas what is expected in this context is units of time:

<model>
    ...
    <listOfEvents>
        <event useValuesFromTriggerTime="true">
            ...
            <delay>
                <math xmlns="http://www.w3.org/1998/Math/MathML">
                    <cn> 1 </cn>
                </math>
            </delay>
            ...
        </event>
    </listOfEvents>
    ...
</model>

The <cn> 1 </cn> within the mathematical formula of the delay above has no units declared. To make the expression have the needed units of time, literal numbers should be avoided in favor of defining Parameter objects for each quantity, and declaring units for the Parameter values. The following fragment of SBML illustrates this approach:

<model>
    ...
    <listOfParameters>
        <parameter id="transcriptionDelay" value="10" units="second"/>
    </listOfParameters>
    ...
    <listOfEvents>
        <event useValuesFromTriggerTime="true">
            ...
            <delay>
                <math xmlns="http://www.w3.org/1998/Math/MathML">
                    <ci> transcriptionDelay </ci>
                </math>
            </delay>
            ...
        </event>
    </listOfEvents>
    ...
</model>

In SBML Level 3, an alternative approach is available in the form of the units attribute, which SBML Level 3 allows to appear on MathML cn elements. The value of this attribute can be used to indicate the unit of measurement to be associated with the number in the content of a cn element. The attribute is named units but, because it appears inside MathML element (which is in the XML namespace for MathML and not the namespace for SBML), it must always be prefixed with an XML namespace prefix for the SBML Level 3 Version 1 namespace. The following is an example of this approach:

<model timeUnits="second" ...>
    ...
    <listOfEvents>
        <event useValuesFromTriggerTime="true">
            ...
            <delay>
                <math xmlns="http://www.w3.org/1998/Math/MathML"
                      xmlns:sbml="http://www.sbml.org/sbml/level3/version1/core">
                    <cn sbml:units="second"> 10 </cn>
                </math>
            </delay>
            ...
        </event>
    </listOfEvents>
    ...
</model>
typedef class Event Event_t

Implementation of SBML's Event construct.

An SBML Event object defines when the event can occur, the variables that are affected by it, how the variables are affected, and the event's relationship to other events. The effect of the event can optionally be delayed after the occurrence of the condition which invokes it.

The operation of Event is divided into two phases (even when the event is not delayed): one when the event is triggered, and the other when the event is executed. Trigger objects define the conditions for triggering an event, Delay objects define when the event is actually executed, EventAssignment objects define the effects of executing the event, and (in SBML Level 3) Priority objects influence the order of EventAssignment performance in cases of simultaneous events. Please consult the descriptions of Trigger, Delay, EventAssignment and Priority for more information.

Version differences

SBML Level 3

SBML Level 3 introduces several changes to the structure and components of Events compared to SBML Level 2. These changes fall into two main categories: changes to what is optional or required, and additions of new attributes and elements.

  • The attribute "useValuesFromTriggerTime" on Event is mandatory (it was optional in Level 2);
  • Event's "listOfEventAssignments" element (of class ListOfEventAssignments) is optional (it was mandatory in Level 2);
  • Event's "priority" element (of class Priority) is new in Level 3; and
  • The Trigger object gains new mandatory attributes (described as part of the definition of Trigger).

The changes to the attributes of Event are described below; the changes to Trigger and Priority are described in their respective sections.

SBML Level 2

In SBML Level 2 versions before Version 4, the semantics of Event time delays were defined such that the expressions in the event's assignments were always evaluated at the time the event was triggered. This definition made it difficult to define an event whose assignment formulas were meant to be evaluated at the time the event was executed (i.e., after the time period defined by the value of the Delay element). In SBML Level 2 Version 4 and in Level 3, the attribute "useValuesFromTriggerTime" on Event allows a model to indicate the time at which the event's assignments are intended the values of the assignment formulas are computed at the moment the event is triggered, not after the delay. If "useValuesFromTriggerTime"=false, it means that the formulas in the event's assignments are to be computed after the delay, at the time the event is executed.

The definition of Event in SBML Level 2 Versions 1 and 2 includes an additional attribute called "timeUnits", which allowed the time units of the Delay to be set explicitly. Later Versions of SBML Level 2 as well as SBML Level 3 do not define this attribute. LibSBML supports this attribute for compatibility with previous versions of SBML Level 2; however, if a model in SBML Level 3 or Level 2 Versions 3–4 format sets the attribute, the consistency-checking method SBMLDocument::checkConsistency() will report an error.

The attribute "useValuesFromTriggerTime" was introduced in SBML Level 2 Version 4. Models defined in prior Versions of SBML Level 2 cannot use this attribute, and SBMLDocument::checkConsistency() will report an error if they do.

Semantics of events in SBML Level 3 Version 1

The detailed semantics of events are described in the specification documents for each SBML Level/Version. Here we include the description from the SBML Level 1 Version 1. Any transition of a Trigger object's "math" formula from the value false to true will cause the enclosing Event object to trigger. Such a transition is not possible at the very start of a simulation (i.e., at time t = 0) unless the Trigger object's "initialValue" attribute has a value of false; this defines the value of the trigger formula to be false immediately prior to the start of simulation, thereby giving it the potential to change in value from false to true when the formula is evaluated at t = 0. If "initialValue"=true, then the trigger expression cannot transition from false to true at t = 0 but may do so at some time t > 0.

Consider an Event object definition E with delay d in which the Trigger object's "math" formula makes a transition in value from false to true at times t1 and t2. The EventAssignment within the Event object will have effect at t1 + d and t2 + d irrespective of the relative times of t1 and t2. For example, events can "overlap" so that t1 < t2 < t1 + d still causes an event assignments to occur at t1 + d and t2 + d.

It is entirely possible for two events to be executed simultaneously, and it is possible for events to trigger other events (i.e., an event assignment can cause an event to trigger). This leads to several points:

  • A software package should retest all event triggers after executing an event assignment in order to account for the possibility that the assignment causes another event trigger to transition from false to true. This check should be made after each individual Event object's execution, even when several events are to be executed simultaneously.

  • Any Event object whose Trigger "persistent" attribute has the value false must have its trigger expression reevaluated continuously between when the event is triggered and when it is executed. If its trigger expression ever evaluates to false, it must be removed from the queue of events pending execution and treated as any other event whose trigger expression evaluates to false.

  • Although the precise time at which events are executed is not resolved beyond the given execution point in simulated time, it is assumed that the order in which the events occur is resolved. This order can be significant in determining the overall outcome of a given simulation. When an event X triggers another event Y and event Y has zero delay, then event Y is added to the existing set of simultaneous events that are pending execution. Events X and Y form a cascade of events at the same point in simulation time. An event such as Y may have a special priority if it contains a Priority subobject.

  • All events in a model are open to being in a cascade. The position of an event in the event queue does not affect whether it can be in the cascade: event Y can be triggered whether it is before or after X in the queue of events pending execution. A cascade of events can be potentially infinite (never terminate); when this occurs a simulator should indicate this has occurred—it is incorrect for a simulator to break a cascade arbitrarily and continue the simulation without at least indicating that the infinite cascade occurred.

  • Simultaneous events having no defined priorities are executed in an undefined order. This does not mean that the behavior of the simulation is completely undefined; merely that the order of execution of these particular events is undefined. A given simulator may use any algorithm to choose an order as long as every event is executed exactly once.

  • Events with defined priorities are executed in the order implied by their Priority "math" formula values, with events having higher priorities being executed ahead of events with lower priorities, and events with identical priorities being executed in a random order with respect to one another (as determined at run-time by some random algorithm equivalent to coin-flipping). Newly-triggered events that are to be executed immediately (i.e., if they define no delays) should be inserted into the queue of events pending execution according to their priorities: events with higher priority values value must be inserted ahead of events with lower priority values and after any pending events with even higher priorities, and inserted randomly among pending events with the same priority values. Events without Priority objects must be inserted into the queue in some fashion, but the algorithm used to place it in the queue is undefined. Similarly, there is no restriction on the order of a newly-inserted event with a defined Priority with respect to any other pending Event without a defined Priority.

  • A model variable that is the target of one or more event assignments can change more than once when simultaneous events are processed at some time point t. The model's behavior (output) for such a variable is the value of the variable at the end of processing all the simultaneous events at time t.

See Also
Trigger
Priority
Delay
EventAssignment

Implementation of SBML's EventAssignment construct for Event.

Event contains an optional element called "listOfEventAssignments", of class ListOfEventAssignments. In every instance of an event definition in a model, the object's "listOfEventAssignments" element must have a non-empty list of one or more "eventAssignment" elements of class EventAssignment. The object class EventAssignment has one required attribute, "variable", and a required element, "math". Being derived from SBase, it also has all the usual attributes and elements of its parent class.

An Event object defines when the event can occur, the variables that are affected by the event, and how the variables are affected. The purpose of the EventAssignment object class is to define how variables are affected by an Event. In SBML Level 2, every Event object instance must have a nonempty list of event assignments; in SBML Level 3, the list of assignments is optional.

The operation of an Event is divided into two phases (regardless of whether a delay is involved): one phase when the event is triggered, and the other when the event is executed. EventAssignment objects are interpreted when an event is executed. The effects are described below.

The attribute "variable"

The EventAssignment attribute "variable" must be the identifier of an existing Compartment, Species, SpeciesReference, or Parameter instance defined in the model. When the event is executed, the value of the model component identified by "variable" is changed by the EventAssignment to the value computed by the "math" element; that is, a species' quantity, species reference's stoichiometry, compartment's size or parameter's value are reset to the value computed by "math".

Certain restrictions are placed on what can appear in "variable":

  • The object identified by the value of the EventAssignment attribute "variable" must not have its "constant" attribute set to or default to true. (Constants cannot be affected by events.)

  • The "variable" attribute must not contain the identifier of a reaction; only species, species references, compartment and parameter values may be set by an Event.

  • The value of every "variable" attribute must be unique among the set of EventAssignment structures within a given Event structure. In other words, a single event cannot have multiple EventAssignment objects assigning the same variable. (All of them would be performed at the same time when that particular Event triggers, resulting in indeterminacy.) However, separate Event instances can refer to the same variable.

  • A variable cannot be assigned a value in an EventAssignment object instance and also be assigned a value by an AssignmentRule; i.e., the value of an EventAssignment's "variable" attribute cannot be the same as the value of a AssignmentRule' "variable" attribute. (Assignment rules hold at all times, therefore it would be inconsistent to also define an event that reassigns the value of the same variable.)

Note that the time of assignment of the object identified by the value of the "variable" attribute is always the time at which the Event is executed, not when it is triggered. The timing is controlled by the optional Delay in an Event. The time of assignment is not affected by the "useValuesFromTriggerTime" attribute on Event—that attribute affects the time at which the EventAssignment's "math" expression is evaluated. In other words, SBML allows decoupling the time at which the "variable" is assigned from the time at which its value expression is calculated.

The "math" subelement in an EventAssignment

The MathML expression contained in an EventAssignment defines the new value of the variable being assigned by the Event.

As mentioned above, the time at which the expression in "math" is evaluated is determined by the attribute "useValuesFromTriggerTime" on Event. If the attribute value is true, the expression must be evaluated when the event is triggered; more precisely, the values of identifiers occurring in MathML <ci> elements in the EventAssignment's "math" expression are the values they have at the point when the event triggered. If, instead, "useValuesFromTriggerTime"'s value is false, it means the values at execution time should be used; that is, the values of identifiers occurring in MathML <ci> elements in the EventAssignment's "math" expression are the values they have at the point when the event executed.

Version differences

Between Version 4 and previous versions of SBML Level 2, the requirements regarding the matching of units between an EvengAssignment's formula and the units of the object identified by the "variable" attribute changed. Previous versions required consistency, but in SBML Level 2 Version 4 and in SBML Level 3, unit consistency is only recommended. More precisely:

  • In the case of a species, an EventAssignment sets the referenced species' quantity (concentration or amount of substance) to the value determined by the formula in the EventAssignment's "math" subelement. The units of the "math" formula should (in SBML Level 2 Version 4 and in Level 3) or must (in previous Versions of Level 2) be identical to the units of the species.

  • (SBML Level 3 only.) In the case of a species reference, an EventAssignment sets the stoichiometry of the reactant or product referenced by the SpeciesReference object to the value determined by the formula in the "math" element. The unit associated with the value produced by the "math" formula should be dimensionless, because reactant and product stoichiometries in reactions are dimensionless quantities.

  • In the case of a compartment, an EventAssignment sets the referenced compartment's size to the size determined by the formula in the "math" subelement of the EventAssignment. The overall units of the formula should (in SBML Level 2 Version 4 and in Level 3) or must (in previous Versions of Level 2) be identical to the units specified for the size of the compartment identified by the EventAssignment's "variable" attribute.

  • In the case of a parameter, an EventAssignment sets the referenced parameter's value to that determined by the formula in "math". The overall units of the formula should (in SBML Level 2 Version 4 and Level 3) or must (in previous Versions of Level 2) be identical to the units defined for the parameter.

Note that the formula placed in the "math" element has no assumed units. The consistency of the units of the formula, and the units of the entity which the assignment affects, must be explicitly established just as in the case of the value of the Delay subelement. An approach similar to the one discussed in the context of Delay may be used for the formula of an EventAssignment.

See Also
Event
typedef class ExpectedAttributes ExpectedAttributes_t

Implementation of SBML's FunctionDefinition construct.

The FunctionDefinition structure associates an identifier with a function definition. This identifier can then be used as the function called in subsequent MathML content elsewhere in an SBML model.

FunctionDefinition has one required attribute, "id", to give the function a unique identifier by which other parts of an SBML model definition can refer to it. A FunctionDefinition instance can also have an optional "name" attribute of type string. Identifiers and names must be used according to the guidelines described in the SBML specification (e.g., Section 3.3 in the Level 2 Version 4 specification).

FunctionDefinition has a required "math" subelement containing a MathML expression defining the function body. The content of this element can only be a MathML "lambda" element. The "lambda" element must begin with zero or more "bvar" elements, followed by any other of the elements in the MathML subset allowed in SBML Level 2 except "lambda" (i.e., a "lambda" element cannot contain another "lambda" element). This is the only place in SBML where a "lambda" element can be used. The function defined by a FunctionDefinition is only available for use in other MathML elements that follow the FunctionDefinition definition in the model. (These restrictions prevent recursive and mutually-recursive functions from being expressed.)

A further restriction on the content of "math" is that it cannot contain references to variables other than the variables declared to the "lambda" itself. That is, the contents of MathML "ci" elements inside the body of the "lambda" can only be the variables declared by its "bvar" elements, or the identifiers of other FunctionDefinition instances in the model. This means must be written so that all variables or parameters used in the MathML content are passed to them via their function parameters. In SBML Level 2, this restriction applies also to the MathML csymbol elements for time and delay; in SBML Level 3, it additionally applies to the csymbol element for avogadro.

Note
Function definitions (also informally known as user-defined functions) were introduced in SBML Level 2. They have purposefully limited capabilities. A function cannot reference parameters or other model quantities outside of itself; values must be passed as parameters to the function. Moreover, recursive and mutually-recursive functions are not permitted. The purpose of these limitations is to balance power against complexity of implementation. With the restrictions as they are, function definitions could be implemented as textual substitutions—they are simply macros. Software implementations therefore do not need the full function-definition machinery typically associated with programming languages.

Another important point to note is FunctionDefinition does not have a separate attribute for defining the units of the value returned by the function. The units associated with the function's return value, when the function is called from within MathML expressions elsewhere in SBML, are simply the overall units of the expression in FunctionDefinition's "math" subelement when applied to the arguments supplied in the call to the function. Ascertaining these units requires performing dimensional analysis on the expression. (Readers may wonder why there is no attribute. The reason is that having a separate attribute for declaring the units would not only be redundant, but also lead to the potential for having conflicting information. In the case of a conflict between the declared units and those of the value actually returned by the function, the only logical resolution rule would be to assume that the correct units are those of the expression anyway.)

Implementation of SBML's InitialAssignment construct.

SBML Level 2 Versions 2–4 and SBML Level 3 provide two ways of assigning initial values to entities in a model. The simplest and most basic is to set the values of the appropriate attributes in the relevant components; for example, the initial value of a model parameter (whether it is a constant or a variable) can be assigned by setting its "value" attribute directly in the model definition. However, this approach is not suitable when the value must be calculated, because the initial value attributes on different components such as species, compartments, and parameters are single values and not mathematical expressions. In those situations, the InitialAssignment construct can be used; it permits the calculation of the value of a constant or the initial value of a variable from the values of other quantities in a model.

As explained below, the provision of InitialAssignment does not mean that models necessarily must use this construct when defining initial values of quantities in a model. If a value can be set directly using the relevant attribute of a component in a model, then that approach may be more efficient and more portable to other software tools. InitialAssignment should be used when the other mechanism is insufficient for the needs of a particular model.

The InitialAssignment construct has some similarities to AssignmentRule. The main differences are: (a) an InitialAssignment can set the value of a constant whereas an AssignmentRule cannot, and (b) unlike AssignmentRule, an InitialAssignment definition only applies up to and including the beginning of simulation time, i.e., t $\leq$ 0, while an AssignmentRule applies at all times.

InitialAssignment has a required attribute, "symbol", whose value must follow the guidelines for identifiers described in the SBML specification (e.g., Section 3.3 in the Level 2 Version 4 specification). The value of this attribute in an InitialAssignment object can be the identifier of a Compartment, Species or global Parameter elsewhere in the model. The InitialAssignment defines the initial value of the constant or variable referred to by the "symbol" attribute. (The attribute's name is "symbol" rather than "variable" because it may assign values to constants as well as variables in a model.) Note that an initial assignment cannot be made to reaction identifiers, that is, the "symbol" attribute value of an InitialAssignment cannot be an identifier that is the "id" attribute value of a Reaction object in the model. This is identical to a restriction placed on rules.

InitialAssignment also has a required "math" subelement that contains a MathML expression used to calculate the value of the constant or the initial value of the variable. The units of the value computed by the formula in the "math" subelement should (in SBML Level 2 Version 4 and in SBML Level 3) or must (in previous Versions) be identical to be the units associated with the identifier given in the "symbol" attribute. (That is, the units are the units of the species, compartment, or parameter, as appropriate for the kind of object identified by the value of "symbol".)

InitialAssignment was introduced in SBML Level 2 Version 2. It is not available in SBML Level 2 Version 1 nor in any version of Level 1.

Semantics of Initial Assignments

The value calculated by an InitialAssignment object overrides the value assigned to the given symbol by the object defining that symbol. For example, if a compartment's "size" attribute is set in its definition, and the model also contains an InitialAssignment having that compartment's identifier as its "symbol" attribute value, then the interpretation is that the "size" assigned in the Compartment object should be ignored and the value assigned based on the computation defined in the InitialAssignment. Initial assignments can take place for Compartment, Species and global Parameter objects regardless of the value of their "constant" attribute.

The actions of all InitialAssignment objects are in general terms the same, but differ in the precise details depending on the type of variable being set:

  • In the case of a species, an InitialAssignment sets the referenced species' initial quantity (concentration or amount of substance) to the value determined by the formula in the "math" subelement. The overall units of the formula should (in SBML Level 2 Version 4 and in SBML Level 3) or must (in previous Versions) be the same as the units specified for the species.

  • In the case of a compartment, an InitialAssignment sets the referenced compartment's initial size to the size determined by the formula in "math". The overall units of the formula should (in SBML Level 2 Version 4 and in SBML Level 3) or must (in previous Versions) be the same as the units specified for the size of the compartment.

  • In the case of a parameter, an InitialAssignment sets the referenced parameter's initial value to that determined by the formula in "math". The overall units of the formula should (in SBML Level 2 Version 4 and SBML Level 3) or must (in previous Versions) be the same as the units defined for the parameter.

In the context of a simulation, initial assignments establish values that are in effect prior to and including the start of simulation time, i.e., t $\leq$ 0. Section 3.4.8 in the SBML Level 2 Version 4 and SBML Level 3 Version 1 Core specifications provides information about the interpretation of assignments, rules, and entity values for simulation time up to and including the start time t = 0; this is important for establishing the initial conditions of a simulation if the model involves expressions containing the delay "csymbol".

There cannot be two initial assignments for the same symbol in a model; that is, a model must not contain two or more InitialAssignment objects that both have the same identifier as their "symbol" attribute value. A model must also not define initial assignments and assignment rules for the same entity. That is, there cannot be both an InitialAssignment and an AssignmentRule for the same symbol in a model, because both kinds of constructs apply prior to and at the start of simulated time—allowing both to exist for a given symbol would result in indeterminism).

The ordering of InitialAssignment objects is not significant. The combined set of InitialAssignment, AssignmentRule and KineticLaw objects form a set of assignment statements that must be considered as a whole. The combined set of assignment statements should not contain algebraic loops: a chain of dependency between these statements should terminate. (More formally, consider the directed graph of assignment statements where nodes are a model's assignment statements and directed arcs exist for each occurrence of a symbol in an assignment statement "math" attribute. The directed arcs in this graph start from the statement assigning the symbol and end at the statement that contains the symbol in their math elements. Such a graph must be acyclic.)

Finally, it is worth being explicit about the expected behavior in the following situation. Suppose (1) a given symbol has a value x assigned to it in its definition, and (2) there is an initial assignment having the identifier as its "symbol" value and reassigning the value to y, and (3) the identifier is also used in the mathematical formula of a second initial assignment. What value should the second initial assignment use? It is y, the value assigned to the symbol by the first initial assignment, not whatever value was given in the symbol's definition. This follows directly from the behavior described above: if an InitialAssignment object exists for a given symbol, then the symbol's value is overridden by that initial assignment.

typedef class KineticLaw KineticLaw_t

Implementation of SBML's KineticLaw construct.

An object of class KineticLaw is used to describe the rate at which the process defined by a given Reaction takes place. KineticLaw has subelements called "math" (for MathML content) and "listOfParameters" (of class ListOfParameters), in addition to the attributes and subelements it inherits from SBase.

KineticLaw's "math" subelement for holding a MathML formula defines the rate of the reaction. The formula may refer to other entities in a model as well as local parameter definitions within the scope of the Reaction (see below). It is important to keep in mind, however, that the only Species identifiers that can be used in this formula are those declared in the lists of reactants, products and modifiers in the Reaction structure. (In other words, before a species can be referenced in the KineticLaw, it must be declared in one of those lists.)

KineticLaw provides a way to define local parameters whose identifiers can be used in the "math" formula of that KineticLaw instance. Prior to SBML Level 3, these parameter definitions are stored inside a "listOfParameters" subelement containing Parameter objects; in SBML Level 3, this is achieved using a specialized object class called LocalParameter and the containing subelement is called "listOfLocalParameters". In both cases, the parameters so defined are only visible within the KineticLaw; they cannot be accessed outside. A local parameter within one reaction is not visible from within another reaction, nor is it visible to any other construct outside of the KineticLaw in which it is defined. In addition, another important feature is that if such a Parameter (or in Level 3, LocalParameter) object has the same identifier as another object in the scope of the enclosing Model, the definition inside the KineticLaw takes precedence. In other words, within the KineticLaw's "math" formula, references to local parameter identifiers shadow any identical global identifiers.

The values of local parameters defined within KineticLaw objects cannot change. In SBML Level 3, this quality is built into the LocalParameter construct. In Level 2, where the same kind of Parameter object class is used as for global parameters, the Parameter objects' "constant" attribute must always have a value of true (either explicitly or left to its default value).

A warning about identifier shadowing

A common misconception is that different classes of objects (e.g., species, compartments, parameters) in SBML have different identifier scopes. They do not. The implication is that if a KineticLaw's local parameter definition uses an identifier identical to any other identifier defined in the model outside the KineticLaw, even if the other identifier does not belong to a parameter type of object, the local parameter's identifier takes precedence within that KineticLaw's "math" formula. It is not an error in SBML for identifiers to shadow each other this way, but can lead to confusing and subtle errors.

Version differences

In SBML Level 2 Version 1, the SBML specification included two additional attributes on KineticLaw called "substanceUnits" and "timeUnits". They were removed beginning with SBML Level 2 Version 2 because further research determined they introduced many problems. The most significant problem was that their use could easily lead to the creation of valid models whose reactions nevertheless could not be integrated into a system of equations without outside knowledge for converting the quantities used. Examination of real-life models revealed that a common reason for using "substanceUnits" on KineticLaw was to set the units of all reactions to the same set of substance units, something that is better achieved by using UnitDefinition to redefine "substance" for the whole Model.

As mentioned above, in SBML Level 2 Versions 2–4, local parameters are of class Parameter. In SBML Level 3, the class of object is LocalParameter.

typedef class List List_t

Simple, plain, generic lists, and associated list utilities.

This class of objects is defined by libSBML only and has no direct equivalent in terms of SBML components. This class is not prescribed by the SBML specifications, although it is used to implement features defined in SBML.

This class implements basic vanilla lists for libSBML. It was developed in the time before libSBML was converted to C++ and used C++ STL library classes more extensively. At some point in the future, this List class may be removed in favor of using standard C++ classes.

This class is distinct from ListOf because the latter is derived from the SBML SBase class, whereas this List class is not. ListOf can only be used when a list is actually intended to implement an SBML ListOfX class. This is why libSBML has both a List and a ListOf.

typedef class ListOf ListOf_t

Parent class for the various SBML "ListOfXYZ" classes.

This class of objects is defined by libSBML only and has no direct equivalent in terms of SBML components. This class is not prescribed by the SBML specifications, although it is used to implement features defined in SBML.

SBML defines various ListOf___ classes that are containers used for organizing the main components of an SBML model. All are derived from the abstract class SBase, and inherit the attributes and subelements of SBase, such as "metaid" as and "annotation". The ListOf___ classes do not add any attributes of their own.

The ListOf class in libSBML is a utility class that serves as the parent class for implementing the ListOf__ classes. It provides methods for working generically with the various SBML lists of objects in a program. LibSBML uses this separate list class rather than ordinary lists, so that it can provide the methods and features associated with SBase.

See Also
ListOfFunctionDefinitions
ListOfUnitDefinitions
ListOfCompartmentTypes
ListOfSpeciesTypes
ListOfCompartments
ListOfSpecies
ListOfParameters
ListOfInitialAssignments
ListOfRules
ListOfConstraints
ListOfReactions
ListOfEvents

Implementation of SBML Level 3's LocalParameter construct.

LocalParameter has been introduced in SBML Level 3 to serve as the object class for parameter definitions that are intended to be local to a Reaction. Objects of class LocalParameter never appear at the Model level; they are always contained within ListOfLocalParameters lists which are in turn contained within KineticLaw objects.

Like its global Parameter counterpart, the LocalParameter object class is used to define a symbol associated with a value; this symbol can then be used in a model's mathematical formulas (and specifically, for LocalParameter, reaction rate formulas). Unlike Parameter, the LocalParameter class does not have a "constant" attribute: local parameters within reactions are always constant.

LocalParameter has one required attribute, "id", to give the parameter a unique identifier by which other parts of an SBML model definition can refer to it. A parameter can also have an optional "name" attribute of type string. Identifiers and names must be used according to the guidelines described in the SBML specifications.

The optional attribute "value" determines the value (of type double) assigned to the parameter. A missing value for "value" implies that the value either is unknown, or to be obtained from an external source, or determined by an initial assignment. The unit of measurement associated with the value of the parameter can be specified using the optional attribute "units". Here we only mention briefly some notable points about the possible unit choices, but readers are urged to consult the SBML specification documents for more information:

  • In SBML Level 3, there are no constraints on the units that can be assigned to parameters in a model; there are also no units to inherit from the enclosing Model object.

  • In SBML Level 2, the value assigned to the parameter's "units" attribute must be chosen from one of the following possibilities: one of the base unit identifiers defined in SBML; one of the built-in unit identifiers "substance", "time", "volume", "area" or "length"; or the identifier of a new unit defined in the list of unit definitions in the enclosing Model structure. There are no constraints on the units that can be chosen from these sets. There are no default units for local parameters.

As with all other major SBML components, LocalParameter is derived from SBase, and the methods defined on SBase are available on LocalParameter.

Warning
LibSBML derives LocalParameter from Parameter; however, this does not precisely match the object hierarchy defined by SBML Level 3, where LocalParameter is derived directly from SBase and not Parameter. We believe this arrangement makes it easier for libSBML users to program applications that work with both SBML Level 2 and SBML Level 3, but programmers should also keep in mind this difference exists. A side-effect of libSBML's scheme is that certain methods on LocalParameter that are inherited from Parameter do not actually have relevance to LocalParameter objects. An example of this is the methods pertaining to Parameter's attribute "constant" (i.e., isSetConstant(), setConstant(), and getConstant()).
See Also
ListOfLocalParameters
KineticLaw
typedef class Model Model_t

Implementation of SBML's Model construct.

In an SBML model definition, a single object of class Model serves as the overall container for the lists of the various model components. All of the lists are optional, but if a given list container is present within the model, the list must not be empty; that is, it must have length one or more. The following are the components and lists permitted in different Levels and Versions of SBML in version 5.8.0 of libSBML:

Although all the lists are optional, there are dependencies between SBML components such that defining some components requires defining others. An example is that defining a species requires defining a compartment, and defining a reaction requires defining a species. The dependencies are explained in more detail in the SBML specifications.

In addition to the above lists and attributes, the Model class in both SBML Level 2 and Level 3 has the usual two attributes of "id" and "name", and both are optional. As is the case for other SBML components with "id" and "name" attributes, they must be used according to the guidelines described in the SBML specifications. (Within the frameworks of SBML Level 2 and Level 3 Version 1 Core, a Model object identifier has no assigned meaning, but extension packages planned for SBML Level 3 are likely to make use of this identifier.)

Finally, SBML Level 3 has introduced a number of additional Model attributes. They are discussed in a separate section below.

Approaches to creating objects using the libSBML API

LibSBML provides two main mechanisms for creating objects: class constructors (e.g., Species::Species() ), and createObject() methods (such as Model::createSpecies()) provided by certain Object classes such as Model. These multiple mechanisms are provided by libSBML for flexibility and to support different use-cases, but they also have different implications for the overall model structure.

In general, the recommended approach is to use the createObject() methods. These methods both create an object and link it to the parent in one step. Here is an example:

The createObject() methods return a pointer to the object created, but they also add the object to the relevant list of object instances contained in the parent. (These lists become the <listOfObjects> elements in the finished XML rendition of SBML.) In the example above, Model::createSpecies() adds the created species directly to the <listOfSpecies> list in the model. Subsequently, methods called on the species change the species in the model (which is what is expected in most situations).

Checking consistency and adherence to SBML specifications

To make it easier for applications to do whatever they need, libSBML version 5.8.0 is relatively lax when it comes to enforcing correctness and completeness of models during model construction and editing. Essentially, libSBML will not in most cases check automatically that a model's components have valid attribute values, or that the overall model is consistent and free of errors—even obvious errors such as duplication of identifiers. This allows applications great leeway in how they build their models, but it means that software authors must take deliberate steps to ensure that the model will be, in the end, valid SBML. These steps include such things as keeping track of the identifiers used in a model, manually performing updates in certain situations where an entity is referenced in more than one place (e.g., a species that is referenced by multiple SpeciesReference objects), and so on.

That said, libSBML does provide powerful features for deliberately performing validation of SBML when an application decides it is time to do so. The interfaces to these facilities are on the SBMLDocument class, in the form of SBMLDocument::checkInternalConsistency() and SBMLDocument::checkConsistency(). Please refer to the documentation for SBMLDocument for more information about this.

While applications may play fast and loose and live like free spirits during the construction and editing of SBML models, they should always make sure to call SBMLDocument::checkInternalConsistency() and/or SBMLDocument::checkConsistency() before writing out the final version of an SBML model.

Model attributes introduced in SBML Level 3

As mentioned above, the Model class has a number of optional attributes in SBML Level 3 Version 1 Core. These are "substanceUnits", "timeUnits", "volumeUnits", "areaUnits", "lengthUnits", "extentUnits", and "conversionFactor. The following provide more information about them.

The "substanceUnits" attribute

The "substanceUnits" attribute is used to specify the unit of measurement associated with substance quantities of Species objects that do not specify units explicitly. If a given Species object definition does not specify its unit of substance quantity via the "substanceUnits" attribute on the Species object instance, then that species inherits the value of the Model "substanceUnits" attribute. If the Model does not define a value for this attribute, then there is no unit to inherit, and all species that do not specify individual "substanceUnits" attribute values then have no declared units for their quantities. The SBML Level 3 Version 1 Core specification provides more details.

Note that when the identifier of a species appears in a model's mathematical expressions, the unit of measurement associated with that identifier is not solely determined by setting "substanceUnits" on Model or Species. Please see the discussion about units given in the documentation for the Species class.

The "timeUnits" attribute

The "timeUnits" attribute on SBML Level 3's Model object is used to specify the unit in which time is measured in the model. This attribute on Model is the only way to specify a unit for time in a model. It is a global attribute; time is measured in the model everywhere in the same way. This is particularly relevant to Reaction and RateRule objects in a model: all Reaction and RateRule objects in SBML define per-time values, and the unit of time is given by the "timeUnits" attribute on the Model object instance. If the Model "timeUnits" attribute has no value, it means that the unit of time is not defined for the model's reactions and rate rules. Leaving it unspecified in an SBML model does not result in an invalid model in SBML Level 3; however, as a matter of best practice, we strongly recommend that all models specify units of measurement for time.

The "volumeUnits", "areaUnits", and "lengthUnits" attributes

The attributes "volumeUnits", "areaUnits" and "lengthUnits" together are used to set the units of measurements for the sizes of Compartment objects in an SBML Level 3 model when those objects do not otherwise specify units. The three attributes correspond to the most common cases of compartment dimensions: "volumeUnits" for compartments having a "spatialDimensions" attribute value of "3", "areaUnits" for compartments having a "spatialDimensions" attribute value of "2", and "lengthUnits" for compartments having a "spatialDimensions" attribute value of "1". The attributes are not applicable to compartments whose "spatialDimensions" attribute values are not one of "1", "2" or "3".

If a given Compartment object instance does not provide a value for its "units" attribute, then the unit of measurement of that compartment's size is inherited from the value specified by the Model "volumeUnits", "areaUnits" or "lengthUnits" attribute, as appropriate based on the Compartment object's "spatialDimensions" attribute value. If the Model object does not define the relevant attribute, then there are no units to inherit, and all Compartment objects that do not set a value for their "units" attribute then have no units associated with their compartment sizes.

The use of three separate attributes is a carry-over from SBML Level 2. Note that it is entirely possible for a model to define a value for two or more of the attributes "volumeUnits", "areaUnits" and "lengthUnits" simultaneously, because SBML models may contain compartments with different numbers of dimensions.

The "extentUnits" attribute

Reactions are processes that occur over time. These processes involve events of some sort, where a single ``reaction event'' is one in which some set of entities (known as reactants, products and modifiers in SBML) interact, once. The extent of a reaction is a measure of how many times the reaction has occurred, while the time derivative of the extent gives the instantaneous rate at which the reaction is occurring. Thus, what is colloquially referred to as the "rate of the reaction" is in fact equal to the rate of change of reaction extent.

In SBML Level 3, the combination of "extentUnits" and "timeUnits" defines the units of kinetic laws in SBML and establishes how the numerical value of each KineticLaw object's mathematical formula is meant to be interpreted in a model. The units of the kinetic laws are taken to be "extentUnits" divided by "timeUnits".

Note that this embodies an important principle in SBML Level 3 models: all reactions in an SBML model must have the same units for the rate of change of extent. In other words, the units of all reaction rates in the model must be the same. There is only one global value for "extentUnits" and one global value for "timeUnits".

The "conversionFactor" attribute

The attribute "conversionFactor" in SBML Level 3's Model object defines a global value inherited by all Species object instances that do not define separate values for their "conversionFactor" attributes. The value of this attribute must refer to a Parameter object instance defined in the model. The Parameter object in question must be a constant; ie it must have its "constant" attribute value set to "true".

If a given Species object definition does not specify a conversion factor via the "conversionFactor" attribute on Species, then the species inherits the conversion factor specified by the Model "conversionFactor" attribute. If the Model does not define a value for this attribute, then there is no conversion factor to inherit. More information about conversion factors is provided in the SBML Level 3 Version 1 specification.

Representation of MIRIAM-compliant model creator data used in ModelHistory.

This class of objects is defined by libSBML only and has no direct equivalent in terms of SBML components. This class is not prescribed by the SBML specifications, although it is used to implement features defined in SBML.

The SBML specification beginning with Level 2 Version 2 defines a standard approach to recording model history and model creator information in a form that complies with MIRIAM ("Minimum Information Requested in the Annotation of biochemical Models", Nature Biotechnology, vol. 23, no. 12, Dec. 2005). For the model creator, this form involves the use of parts of the vCard representation. LibSBML provides the ModelCreator class as a convenience high-level interface for working with model creator data. Objects of class ModelCreator can be used to store and carry around creator data within a program, and the various methods in this object class let callers manipulate the different parts of the model creator representation.

The different parts of a model creator definition

The ModelCreator class mirrors the structure of the MIRIAM model creator annotations in SBML. The following template illustrates these different fields when they are written in XML form:

<vCard:N rdf:parseType="Resource">
  <vCard:Family>family name</vCard:Family>
  <vCard:Given>given name</vCard:Given>
</vCard:N>
...
<vCard:EMAIL>email address</vCard:EMAIL>
...
<vCard:ORG rdf:parseType="Resource">
  <vCard:Orgname>organization</vCard:Orgname>
</vCard:ORG>

Each of the separate data values family name, given name, email address, and organization can be set and retrieved via corresponding methods in the ModelCreator class. These methods are documented in more detail below.

Representation of MIRIAM-compliant model history data.

This class of objects is defined by libSBML only and has no direct equivalent in terms of SBML components. This class is not prescribed by the SBML specifications, although it is used to implement features defined in SBML.

The SBML specification beginning with Level 2 Version 2 defines a standard approach to recording optional model history and model creator information in a form that complies with MIRIAM ("Minimum Information Requested in the Annotation of biochemical Models", Nature Biotechnology, vol. 23, no. 12, Dec. 2005). LibSBML provides the ModelHistory class as a convenient high-level interface for working with model history data.

Model histories in SBML consist of one or more model creators, a single date of creation, and one or more modification dates. The overall XML form of this data takes the following form:

<dc:creator>
  <rdf:Bag>
    <rdf:li rdf:parseType="Resource">
      +++
      <vCard:N rdf:parseType="Resource">
        <vCard:Family>family name</vCard:Family>
        <vCard:Given>given name</vCard:Given>
      </vCard:N>
      +++
      <vCard:EMAIL>email address</vCard:EMAIL>
      +++
      <vCard:ORG rdf:parseType="Resource">
       <vCard:Orgname>organization name</vCard:Orgname>
      </vCard:ORG>
      +++
    </rdf:li>
    ...
  </rdf:Bag>
</dc:creator>
<dcterms:created rdf:parseType="Resource">
  <dcterms:W3CDTF>creation date</dcterms:W3CDTF>
</dcterms:created>
<dcterms:modified rdf:parseType="Resource">
  <dcterms:W3CDTF>modification date</dcterms:W3CDTF>
</dcterms:modified>
...

In the template above, the underlined portions are optional, the symbol +++ is a placeholder for either no content or valid XML content that is not defined by the annotation scheme, and the ellipses ... are placeholders for zero or more elements of the same form as the immediately preceding element. The various placeholders for content, namely family name, given name, email address, organization, creation date, and modification date are data that can be filled in using the various methods on the ModelHistory class described below.

typedef class Parameter Parameter_t

Implementation of SBML's Parameter construct.

A Parameter is used in SBML to define a symbol associated with a value; this symbol can then be used in mathematical formulas in a model. By default, parameters have constant value for the duration of a simulation, and for this reason are called parameters instead of variables in SBML, although it is crucial to understand that SBML parameters represent both concepts. Whether a given SBML parameter is intended to be constant or variable is indicated by the value of its "constant" attribute.

SBML's Parameter has a required attribute, "id", that gives the parameter a unique identifier by which other parts of an SBML model definition can refer to it. A parameter can also have an optional "name" attribute of type string. Identifiers and names must be used according to the guidelines described in the SBML specifications.

The optional attribute "value" determines the value (of type double) assigned to the parameter. A missing value for "value" implies that the value either is unknown, or to be obtained from an external source, or determined by an initial assignment. The unit of measurement associated with the value of the parameter can be specified using the optional attribute "units". Here we only mention briefly some notable points about the possible unit choices, but readers are urged to consult the SBML specification documents for more information:

  • In SBML Level 3, there are no constraints on the units that can be assigned to parameters in a model; there are also no units to inherit from the enclosing Model object (unlike the case for, e.g., Species and Compartment).

  • In SBML Level 2, the value assigned to the parameter's "units" attribute must be chosen from one of the following possibilities: one of the base unit identifiers defined in SBML; one of the built-in unit identifiers "substance", "time", "volume", "area" or "length"; or the identifier of a new unit defined in the list of unit definitions in the enclosing Model structure. There are no constraints on the units that can be chosen from these sets. There are no default units for parameters.

The Parameter structure has another boolean attribute named "constant" that is used to indicate whether the parameter's value can vary during a simulation. (In SBML Level 3, the attribute is mandatory and must be given a value; in SBML Levels below Level 3, the attribute is optional.) A value of true indicates the parameter's value cannot be changed by any construct except InitialAssignment. Conversely, if the value of "constant" is false, other constructs in SBML, such as rules and events, can change the value of the parameter.

SBML Level 3 uses a separate object class, LocalParameter, for parameters that are local to a Reaction's KineticLaw. In Levels prior to SBML Level 3, the Parameter class is used both for definitions of global parameters, as well as reaction-local parameters stored in a list within KineticLaw objects. Parameter objects that are local to a reaction (that is, those defined within the KineticLaw structure of a Reaction) cannot be changed by rules and therefore are implicitly always constant; consequently, in SBML Level 2, parameter definitions within Reaction structures should not have their "constant" attribute set to false.

What if a global parameter has its "constant" attribute set to false, but the model does not contain any rules, events or other constructs that ever change its value over time? Although the model may be suspect, this situation is not strictly an error. A value of false for "constant" only indicates that a parameter can change value, not that it must.

As with all other major SBML components, Parameter is derived from SBase, and the methods defined on SBase are available on Parameter.

Note
The use of the term parameter in SBML sometimes leads to confusion among readers who have a particular notion of what something called "parameter" should be. It has been the source of heated debate, but despite this, no one has yet found an adequate replacement term that does not have different connotations to different people and hence leads to confusion among some subset of users. Perhaps it would have been better to have two constructs, one called constants and the other called variables. The current approach in SBML is simply more parsimonious, using a single Parameter construct with the boolean flag "constant" indicating which flavor it is. In any case, readers are implored to look past their particular definition of a parameter and simply view SBML's Parameter as a single mechanism for defining both constants and (additional) variables in a model. (We write additional because the species in a model are usually considered to be the central variables.) After all, software tools are not required to expose to users the actual names of particular SBML constructs, and thus tools can present to their users whatever terms their designers feel best matches their target audience.
See Also
ListOfParameters
typedef class Priority Priority_t

Implementation of SBML Level 3's Priority construct for Event.

The Priority object class (which was introduced in SBML Level 3 Version 1), like Delay, is derived from SBase and contains a MathML formula stored in the element "math". This formula is used to compute a dimensionless numerical value that influences the order in which a simulator is to perform the assignments of two or more events that happen to be executed simultaneously. The formula may evaluate to any double value (and thus may be a positive or negative number, or zero), with positive numbers taken to signifying a higher priority than zero or negative numbers. If no Priority object is present on a given Event object, no priority is defined for that event.

The interpretation of priorities on events in a model

For the purposes of SBML, simultaneous event execution is defined as the situation in which multiple events have identical times of execution. The time of execution is calculated as the sum of the time at which a given event's Trigger is triggered plus its Delay duration, if any. Here, identical times means mathematically equal instants in time. (In practice, simulation software adhering to this specification may have to rely on numerical equality instead of strict mathematical equality; robust models will ensure that this difference will not cause significant discrepancies from expected behavior.)

If no Priority subobjects are defined for two or more Event objects, then those events are still executed simultaneously but their order of execution is undefined by the SBML Level 3 Version 1 specification. A software implementation may choose to execute such simultaneous events in any order, as long as each event is executed only once and the requirements of checking the "persistent" attribute (and acting accordingly) are satisfied.

If Priority subobjects are defined for two or more simultaneously-triggered events, the order in which those particular events must be executed is dictated by their Priority objects, as follows. If the values calculated using the two Priority objects' "math" expressions differ, then the event having the higher priority value must be executed before the event with the lower value. If, instead, the two priority values are mathematically equal, then the two events must be triggered in a random order. It is important to note that a random order is not the same as an undefined order: given multiple runs of the same model with identical conditions, an undefined ordering would permit a system to execute the events in (for example) the same order every time (according to whatever scheme may have been implemented by the system), whereas the explicit requirement for random ordering means that the order of execution in different simulation runs depends on random chance. In other words, given two events A and B, a randomly-determined order must lead to an equal chance of executing A first or B first, every time those two events are executed simultaneously.

A model may contain a mixture of events, some of which have Priority subobjects and some do not. Should a combination of simultaneous events arise in which some events have priorities defined and others do not, the set of events with defined priorities must trigger in the order determined by their Priority objects, and the set of events without Priority objects must be executed in an undefined order with respect to each other and with respect to the events with Priority subobjects. (Note that undefined order does not necessarily mean random order, although a random ordering would be a valid implementation of this requirement.)

The following example may help further clarify these points. Suppose a model contains four events that should be executed simultaneously, with two of the events having Priority objects with the same value and the other two events having Priority objects with the same, but different, value. The two events with the higher priorities must be executed first, in a random order with respect to each other, and the remaining two events must be executed after them, again in a random order, for a total of four possible and equally-likely event executions: A-B-C-D, A-B-D-C, B-A-C-D, and B-A-D-C. If, instead, the model contains four events all having the same Priority values, there are 4! or 24 possible orderings, each of which must be equally likely to be chosen. Finally, if none of the four events has a Priority subobject defined, or even if exactly one of the four events has a defined Priority, there are again 24 possible orderings, but the likelihood of choosing any particular ordering is undefined; the simulator can choose between events as it wishes. (The SBML specification only defines the effects of priorities on Event objects with respect to other Event objects with priorities. Putting a priority on a single Event object in a model does not cause it to fall within that scope.)

Evaluation of Priority expressions

An event's Priority object "math" expression must be evaluated at the time the Event is to be executed. During a simulation, all simultaneous events have their Priority values calculated, and the event with the highest priority is selected for next execution. Note that it is possible for the execution of one Event object to cause the Priority value of another simultaneously-executing Event object to change (as well as to trigger other events, as already noted). Thus, after executing one event, and checking whether any other events in the model have been triggered, all remaining simultaneous events that either (i) have Trigger objects with attributes "persistent"=false or (ii) have Trigger expressions that did not transition from true to false, must have their Priority expression reevaluated. The highest-priority remaining event must then be selected for execution next.

Units of Priority object's mathematical expressions

The unit associated with the value of a Priority object's "math" expression should be dimensionless. This is because the priority expression only serves to provide a relative ordering between different events, and only has meaning with respect to other Priority object expressions. The value of Priority objects is not comparable to any other kind of object in an SBML model.

Note
The Priority construct exists only in SBML Level 3; it cannot be used in SBML Level 2 or Level 1 models.
See Also
Event
Delay
EventAssignment
typedef class Reaction Reaction_t

Implementation of SBML's Reaction construct.

A reaction represents any transformation, transport or binding process, typically a chemical reaction, that can change the quantity of one or more species. In SBML, a reaction is defined primarily in terms of the participating reactants and products (and their corresponding stoichiometries), along with optional modifier species, an optional rate at which the reaction takes place, and optional parameters.

As with other major object in SBML, Reaction has a mandatory attribute, "id", used to give the compartment type an identifier. The identifier must be a text string conforming to the identifer syntax permitted in SBML. In SBML Level 2 and Level 3, the reaction "id" identifier can be used in mathematical formulas elsewhere in an SBML model to represent the rate of that reaction; this usage is explained below. Reaction also has an optional "name" attribute, of type string. The "id" and "name" must be used according to the guidelines described in the SBML specification.

The species participating as reactants, products, and/or modifiers in a reaction are declared using lists of SpeciesReference and/or ModifierSpeciesReference instances stored in subelements "listOfReactants", "listOfProducts" and "listOfModifiers". Certain restrictions are placed on the appearance of species in reaction definitions:

  • The ability of a species to appear as a reactant or product of any reaction in a model is governed by certain flags in that species' definition; see the definition of Species for more information.

  • Any species appearing in the mathematical formula of the subelement "kineticLaw" (described below) of a Reaction must be declared in at least one of that Reaction's lists of reactants, products, and/or modifiers. Put another way, it is an error for a reaction's kinetic law formula to refer to species that have not been declared for that reaction.

  • A reaction definition can contain an empty list of reactants or an empty list of products, but it must have at least one reactant or product; in other words, a reaction without any reactant or product species is not permitted. (This restriction does not apply to modifier species, which remain optional in all cases.)

A reaction can contain up to one KineticLaw object in a subelement named "kineticLaw". It defines the speed at which the process defined by the reaction takes place. The description of KineticLaw provides more details about its use. Note that although the inclusion of a KineticLaw object in an instance of a Reaction component is optional, there is no useful default that can be substituted in place of a missing rate expression in a reaction. Moreover, a reaction's rate cannot be defined in any other way in SBML—InitialAssignment, AssignmentRule, RateRule, AlgebraicRule, Event, and other constructs in SBML cannot be used to set the reaction rate separately. Nevertheless, for some modeling applications, reactions without any defined rate can be perfectly acceptable.

Reaction also has a boolean attribute named "reversible" for indicating whether the reaction is reversible. This attribute is optional in SBML Level 2, with a default of true; it is mandatory in SBML Level 3 (with no default value). To say that a reaction is reversible is to say it can proceed in either the forward or the reverse direction. Although the reversibility of a reaction can sometimes be deduced by inspecting its rate expression, this is not always the case, especially for complicated expressions. Moreover, the need in SBML to allow rate expressions (i.e., KineticLaw) to be optional leads to the need for a separate flag indicating reversibility. Note that labeling a reaction as irreversible is an assertion that the reaction always proceeds in the given forward direction. (Why else would it be flagged as irreversible?) This implies the rate expression in the KineticLaw always has a non-negative value during simulations. Software tools could provide a means of optionally testing that this condition holds. The presence of reversibility information in two places (i.e., the rate expression and the "reversible" attribute on Reaction) leaves open the possibility that a model could contain contradictory information, but the creation of such a model would be an error on the part of the software generating it.

The Reaction object class has another boolean attribute called "fast". This attribute is optional in SBML Level 2, with a default of false; it is mandatory in SBML Level 3 (with no default value). It is used to indicate that a reaction occurs on a vastly faster time scale than others in a system. Readers are directed to the SBML Level 2 Version 4 specification, which provides more detail about the conditions under which a reaction can be considered to be fast in this sense. The attribute's default value is false. SBML Level 1 and Level 2 Version 1 incorrectly claimed that software tools could ignore this attribute if they did not implement support for the corresponding concept; however, further research in SBML has revealed that this is not true, and "fast" cannot be ignored if it is set to true. SBML Level 2 Versions 2–4 therefore stipulate that if a model has any reactions with "fast" set to true, a software tool must be able to respect the attribute or else indicate to the user that it does not have the capacity to do so. Analysis software cannot ignore the value of the "fast" attribute because doing so may lead to different results as compared to a software system that does make use of "fast".

In SBML Level 3 Version 1, the Reaction object has an additional optional attribute named "compartment", whose value must be the identifier of a compartment defined in the enclosing Model object. The "compartment" attribute can be used to indicate the compartment in which the reaction is assumed to take place. If the attribute is present, its value must be the identifier of a Compartment object defined in the enclosing Model object. Similar to the "reversible" attribute, the value of the "compartment" attribute has no direct impact on the construction of mathematical equations for the SBML model. When a kinetic law is given for a reaction, the compartment location may already be implicit in the kinetic law (although this cannot always be guaranteed). Nevertheless, software tools may find the "compartment" attribute value useful for such purposes as analyzing the structure of the model, guiding the modeler in constructing correct rate formulas, and visualization purposes.

Readers are urged to read the SBML specification for more details about the proper use of Reaction.

typedef class Rule Rule_t

Implementation of SBML's Rule construct.

In SBML, rules provide additional ways to define the values of variables in a model, their relationships, and the dynamical behaviors of those variables. They enable encoding relationships that cannot be expressed using Reaction nor InitialAssignment objects alone.

The libSBML implementation of rules mirrors the SBML Level 3 Version 1 Core definition (which is in turn is very similar to the Level 2 Version 4 definition), with Rule being the parent class of three subclasses as explained below. The Rule class itself cannot be instantiated by user programs and has no constructor; only the subclasses AssignmentRule, AlgebraicRule and RateRule can be instantiated directly.

General summary of SBML rules

In SBML Level 3 as well as Level 2, rules are separated into three subclasses for the benefit of model analysis software. The three subclasses are based on the following three different possible functional forms (where x is a variable, f is some arbitrary function returning a numerical result, V is a vector of variables that does not include x, and W is a vector of variables that may include x):
Algebraic:left-hand side is zero0 = f(W)
Assignment:left-hand side is a scalar:x = f(V)
Rate:left-hand side is a rate-of-change:dx/dt = f(W)
In their general form given above, there is little to distinguish between assignment and algebraic rules. They are treated as separate cases for the following reasons:
  • Assignment rules can simply be evaluated to calculate intermediate values for use in numerical methods. They are statements of equality that hold at all times. (For assignments that are only performed once, see InitialAssignment.)

  • SBML needs to place restrictions on assignment rules, for example the restriction that assignment rules cannot contain algebraic loops.

  • Some simulators do not contain numerical solvers capable of solving unconstrained algebraic equations, and providing more direct forms such as assignment rules may enable those simulators to process models they could not process if the same assignments were put in the form of general algebraic equations;

  • Those simulators that can solve these algebraic equations make a distinction between the different categories listed above; and

  • Some specialized numerical analyses of models may only be applicable to models that do not contain algebraic rules.
The approach taken to covering these cases in SBML is to define an abstract Rule structure containing a subelement, "math", to hold the right-hand side expression, then to derive subtypes of Rule that add attributes to distinguish the cases of algebraic, assignment and rate rules. The "math" subelement must contain a MathML expression defining the mathematical formula of the rule. This MathML formula must return a numerical value. The formula can be an arbitrary expression referencing the variables and other entities in an SBML model. Each of the three subclasses of Rule (AssignmentRule, AlgebraicRule, RateRule) inherit the the "math" subelement and other fields from SBase. The AssignmentRule and RateRule classes add an additional attribute, "variable". See the definitions of AssignmentRule, AlgebraicRule and RateRule for details about the structure and interpretation of each one.

Additional restrictions on SBML rules

An important design goal of SBML rule semantics is to ensure that a model's simulation and analysis results will not be dependent on when or how often rules are evaluated. To achieve this, SBML needs to place two restrictions on rule use. The first concerns algebraic loops in the system of assignments in a model, and the second concerns overdetermined systems.

A model must not contain algebraic loops

The combined set of InitialAssignment, AssignmentRule and KineticLaw objects in a model constitute a set of assignment statements that should be considered as a whole. (A KineticLaw object is counted as an assignment because it assigns a value to the symbol contained in the "id" attribute of the Reaction object in which it is defined.) This combined set of assignment statements must not contain algebraic loops—dependency chains between these statements must terminate. To put this more formally, consider a directed graph in which nodes are assignment statements and directed arcs exist for each occurrence of an SBML species, compartment or parameter symbol in an assignment statement's "math" subelement. Let the directed arcs point from the statement assigning the symbol to the statements that contain the symbol in their "math" subelement expressions. This graph must be acyclic. SBML does not specify when or how often rules should be evaluated. Eliminating algebraic loops ensures that assignment statements can be evaluated any number of times without the result of those evaluations changing. As an example, consider the set of equations x = x + 1, y = z + 200 and z = y + 100. If this set of equations were interpreted as a set of assignment statements, it would be invalid because the rule for x refers to x (exhibiting one type of loop), and the rule for y refers to z while the rule for z refers back to y (exhibiting another type of loop). Conversely, the following set of equations would constitute a valid set of assignment statements: x = 10, y = z + 200, and z = x + 100.

A model must not be overdetermined

An SBML model must not be overdetermined; that is, a model must not define more equations than there are unknowns in a model. An SBML model that does not contain AlgebraicRule structures cannot be overdetermined. LibSBML implements the static analysis procedure described in Appendix B of the SBML Level 3 Version 1 Core specification for assessing whether a model is overdetermined. (In summary, assessing whether a given continuous, deterministic, mathematical model is overdetermined does not require dynamic analysis; it can be done by analyzing the system of equations created from the model. One approach is to construct a bipartite graph in which one set of vertices represents the variables and the other the set of vertices represents the equations. Place edges between vertices such that variables in the system are linked to the equations that determine them. For algebraic equations, there will be edges between the equation and each variable occurring in the equation. For ordinary differential equations (such as those defined by rate rules or implied by the reaction rate definitions), there will be a single edge between the equation and the variable determined by that differential equation. A mathematical model is overdetermined if the maximal matchings of the bipartite graph contain disconnected vertexes representing equations. If one maximal matching has this property, then all the maximal matchings will have this property; i.e., it is only necessary to find one maximal matching.)

Rule types for SBML Level 1

SBML Level 1 uses a different scheme than SBML Level 2 and Level 3 for distinguishing rules; specifically, it uses an attribute whose value is drawn from an enumeration of 3 values. LibSBML supports this using methods that work with the enumeration values listed below.

typedef class SBase SBase_t

Implementation of SBase, the base class of most SBML objects.

Most components in SBML are derived from a single abstract base type, SBase. In addition to serving as the parent class for most other classes of objects in SBML, this base type is designed to allow a modeler or a software package to attach arbitrary information to each major element or list in an SBML model.

SBase has an optional subelement called "notes". It is intended to serve as a place for storing optional information intended to be seen by humans. An example use of the "notes" element would be to contain formatted user comments about the model element in which the "notes" element is enclosed. There are certain conditions on the XHTML content permitted inside the "notes" element; please consult the SBML specification document corresponding to the SBML Level and Version of your model for more information about the requirements for "notes" content.

SBase has another optional subelement called "annotation". Whereas the "notes" element described above is a container for content to be shown directly to humans, the "annotation" element is a container for optional software-generated content not meant to be shown to humans. The element's content type is XML type "any", allowing essentially arbitrary data content. SBML places only a few restrictions on the organization of the content; these are intended to help software tools read and write the data as well as help reduce conflicts between annotations added by different tools. As is the case with "notes", it is important to refer to the SBML specification document corresponding to the SBML Level and Version of your model for more information about the requirements for "annotation" content.

It is worth pointing out that the "annotation" element in the definition of SBase exists in order that software developers may attach optional application-specific data to the elements in an SBML model. However, it is important that this facility not be misused. In particular, it is critical that data essential to a model definition or that can be encoded in existing SBML elements is not stored in "annotation". Parameter values, functional dependencies between model elements, etc., should not be recorded as annotations. It is crucial to keep in mind the fact that data placed in annotations can be freely ignored by software applications. If such data affects the interpretation of a model, then software interoperability is greatly impeded.

SBML Level 2 introduced an optional SBase attribute named "metaid" for supporting metadata annotations using RDF (Resource Description Format). The attribute value has the data type XML ID, the XML identifier type, which means each "metaid" value must be globally unique within an SBML file. (Importantly, this uniqueness criterion applies across any attribute with type XML ID, not just the "metaid" attribute used by SBML—something to be aware of if your application-specific XML content inside the "annotation" subelement happens to use XML ID.) The "metaid" value serves to identify a model component for purposes such as referencing that component from metadata placed within "annotation" subelements.

Beginning with SBML Level 2 Version 3, SBase also has an optional attribute named "sboTerm" for supporting the use of the Systems Biology Ontology. In SBML proper, the data type of the attribute is a string of the form "SBO:NNNNNNN", where "NNNNNNN" is a seven digit integer number; libSBML simplifies the representation by only storing the "NNNNNNN" integer portion. Thus, in libSBML, the "sboTerm" attribute on SBase has data type int, and SBO identifiers are stored simply as integers. (For convenience, SBase offers methods for returning both the integer form and a text-string form of the SBO identifier.) SBO terms are a type of optional annotation, and each different class of SBML object derived from SBase imposes its own requirements about the values permitted for "sboTerm". Please consult the SBML Level 2 Version 4 specification for more information about the use of SBO and the "sboTerm" attribute.

Finally, note that, in the list of methods on SBase, there is no public constructor because SBase is an abstract class. The constructors reside in the subclasses derived from SBase.

Standard format for annotations linking data resources

SBML Level 2 Versions 2, 3 and 4, and Level 3, define a proposed regular format for encoding two particular categories of annotations: (a) references to controlled vocabulary terms and database identifiers which define and describe biological and biochemical entities in a model; and (b) descriptions of the provenance of a model, including its author(s) and modification history.

Representation of an extension point of SBML's package extension.

SBaseExtensionPoint represents an element to be extended (extension point) and the extension point is identified by a combination of a package name and a typecode of the element.

For example, an SBaseExtensionPoint object which represents an extension point of the model element defined in the core package can be created as follows:

      SBaseExtensionPoint  modelextp("core", SBML_MODEL);

Similarly, an SBaseExtensionPoint object which represents an extension point of the layout element defined in the layout extension can be created as follows:

      SBaseExtensionPoint  layoutextp("layout", SBML_LAYOUT_LAYOUT);

SBaseExtensionPoint object is required as one of arguments of the constructor of SBasePluginCreator<class SBasePluginType, class SBMLExtensionType> template class to identify an extension poitnt to which the plugin object created by the creator class is plugged in. For example, the SBasePluginCreator class which creates a LayoutModelPlugin object of the layout extension which is plugged in to the model element of the core package can be created with the corresponding SBaseExtensionPoint object as follows:

  // std::vector object that contains a list of URI (package versions) supported 
  // by the plugin object.
  std::vector<std::string> packageURIs;
  packageURIs.push_back(getXmlnsL3V1V1());
  packageURIs.push_back(getXmlnsL2());  

  // creates an extension point (model element of the "core" package)
  SBaseExtensionPoint  modelExtPoint("core",SBML_MODEL);
   
  // creates an SBasePluginCreator object 
  SBasePluginCreator<LayoutModelPlugin, LayoutExtension>  modelPluginCreator(modelExtPoint,packageURIs);

This kind of code is implemented in init() function of each SBMLExtension derived classes.

typedef class SBasePlugin SBasePlugin_t

Container for an SBML document and interface for global operations on SBML documents.

When creating fresh models programmatically, the starting point is typically the creation of an SBMLDocument object instance. The SBMLDocument constructor accepts arguments for the SBML Level and Version of the model to be created. After creating the SBMLDocument object, calling programs then typically call SBMLDocument::createModel() almost immediately, and then proceed to call the methods on the Model object to fill out the model's contents.

SBMLDocument corresponds roughly to the class Sbml defined in the SBML Level 2 specification and SBML in the Level 3 specification. It does not have a direct correspondence in SBML Level 1. (However, to make matters simpler for applications, libSBML creates an SBMLDocument no matter whether the model is Level 1, Level 2 or Level 3.) In its barest form, when written out in XML format for (e.g.) SBML Level 2 Version 4, the corresponding structure is the following:

<sbml xmlns="http://www.sbml.org/sbml/level2/version4" level="2" version="4">
  ...
</sbml>

SBMLDocument is derived from SBase, and therefore contains the usual SBase attributes (in SBML Level 2 and Level 3) of "metaid" and "sboTerm", as well as the subelements "notes" and "annotation". It also contains the attributes "level" and "version" indicating the Level and Version of the SBML data structure. These can be accessed using the methods defined by the SBase class for that purpose.

Checking consistency and adherence to SBML specifications

One of the most important features of libSBML is its ability to perform SBML validation to ensure that a model adheres to the SBML specification for whatever Level+Version combination the model uses. SBMLDocument provides the methods for running consistency-checking and validation rules on the SBML content.

First, a brief explanation of the rationale is in order. In libSBML versions up to and including the version 3.3.x series, the individual methods for creating and setting attributes and other components were quite lenient, and allowed a caller to compose SBML entities that might not, in the end, represent valid SBML. This allowed applications the freedom to do things such as save incomplete models (which is useful when models are being developed over long periods of time). In the version 4.x series, libSBML is somewhat stricter, but still permits structures to be created independently and the results to be combined in a separate step. In all these cases, it means that a separate validation step is necessary when a calling program finally wants to finish a complete SBML document.

The primary interface to this validation facility is SBMLDocument's SBMLDocument::checkInternalConsistency() and SBMLDocument::checkConsistency(). The former verifies the basic internal consistency and syntax of an SBML document, and the latter implements more elaborate validation rules (both those defined by the SBML specifications, as well as additional rules offered by libSBML).

These methods have slightly different relevance depending on whether a model is created programmaticaly from scratch, or whether it is read in from a file or data stream. The following list summarizes the possible scenarios.

Scenario 1: Creating a model from scratch. Before writing out the model,

Scenario 2: Reading a model from a file or data stream. After reading the model,

  • Basic consistency checks will have been performed automatically by libSBML upon reading the content, so you only need to inquire about the results by using SBMLDocument::getNumErrors()

Converting documents between Levels and Versions of SBML

LibSBML provides facilities for limited translation of SBML between Levels and Versions of the SBML specifications. The method for doing is is setLevelAndVersion() . In general, models can be converted upward without difficulty (e.g., from SBML Level 1 to Level 2, or from an earlier Version of Level 2 to the latest Version of Level 2). Sometimes models can be translated downward as well, if they do not use constructs specific to more advanced Levels of SBML.

Calling SBMLDocument::setLevelAndVersion() will not necessarily lead to a successful conversion. The method will return a boolean value to indicate success or failure. Callers must check the error log (see next section) attached to the SBMLDocument object after calling SBMLDocument::setLevelAndVersion() in order to assess whether any problems arose.

If an application is interested in translating to a lower Level and/or Version of SBML within a Level, the following methods allow for prior assessment of whether there is sufficient compatibility to make a translation possible:

Some changes between Versions of SBML Level 2 may lead to unexpected behaviors when attempting conversions in either direction. For example, SBML Level 2 Version 4 relaxed the requirement for consistency in units of measurement between expressions annd quantities in a model. As a result, a model written in Version 4, if converted to Version 3 with no other changes, may fail validation as a Version 3 model because Version 3 imposed stricter requirements on unit consistency.

Other changes between SBML Level 2 and Level 3 make downward conversions challenging. In some cases, it means that a model converted to Level 2 from Level 3 will contain attributes that were not explicitly given in the Level 3 model, because in Level 2 these attributes may have been optional or have default values.

Error handling

Upon reading a model, SBMLDocument logs any problems encountered while reading the model from the file or data stream. The log contains objects that record diagnostic information about any notable issues that arose. Whether the problems are warnings or errors, they are both reported through a single common interface involving the object class SBMLError.

The methods SBMLDocument::getNumErrors(), SBMLDocument::getError() and SBMLDocument::printErrors() allow callers to interact with the warnings or errors logged. Alternatively, callers may retrieve the entire log as an SBMLErrorLog object using the method SBMLDocument::getErrorLog(). The SBMLErrorLog object provides some alternative methods for interacting with the set of errors and warnings. In either case, applications typically should first call SBMLDocument::getNumErrors() to find out if any issues have been logged after specific libSBML operations such as the ones discussed in the sections above. If they have, then an application will should proceed to inspect the individual reports using either the direct interfaces on SBMLDocument or using the methods on the SBMLErrorLog object.

typedef class SBMLError SBMLError_t

Representation of errors, warnings and other diagnostics.

This class of objects is defined by libSBML only and has no direct equivalent in terms of SBML components. This class is not prescribed by the SBML specifications, although it is used to implement features defined in SBML.

When a libSBML operation on SBML content results in an error, or when there is something wrong with the SBML content, the problems are reported as SBMLError objects. These are generally stored in an SBMLErrorLog object; this log object, in turn, is kept in the SBMLDocument object containing the SBML content. Applications can obtain the list of logged errors using SBMLDocument::getErrorLog() and then use the methods provided by SBMLErrorLog to access individual SBMLError objects. (Note that despite the word "error" in the name, SBMLError objects are used to represent not only "true" errors, but also warnings and some informational diagnostics. The name is a historical hold-over from early versions of libSBML, in which the object really was only used to report errors.)

Error codes are useful mainly for software. For human readers, SBMLError also includes text messages that describe the nature of a given problem. The messages can be accessed using SBMLError::getShortMessage() and SBMLError::getMessage(). The former provides a brief one-line description of the issue, while SBMLError::getMessage() provides a more detailed text, including (if appropriate) references to sections of the SBML specifications where relevant topics are discussed. These text strings are suitable for displaying to human users.

In addition, SBMLError also has a severity code. Its value may be retrieved using the method SBMLError::getSeverity(). The possible severity values are the same as those reported by Severity levels currently range from informational (LIBSBML_SEV_INFO) to fatal errors (LIBSBML_SEV_FATAL). They can be used by an application to evaluate how serious a given problem is.

Finally, SBMLError records the line and column near where the problem occurred in the SBML content. The values may be retrieved using the methods SBMLError::getLine() and SBMLError::getColumn(). We say "near", because a lot of factors affect how accurate the line/column information ultimately is. For example, different XML parsers have different conventions for which line and column number they report for a particular problem (which makes a difference when a problem involves an opening XML tag on one line and a closing tag on another line). In some situations, some parsers report invalid line and/or column numbers altogether. If this occurs, libSBML sets the line and/or column number in the SBMLError object to the the value of the maximum unsigned long integer representable on the platform where libSBML is running. (This is equal to the constant named ULONG_MAX in C and C++.) The probability that a true line or column number in an SBML model would equal this value is vanishingly small; thus, if an application encounters these values in an XMLError object, it can assume no valid line/column number could be provided by libSBML in that situation.

N= Not applicable
I= Informational
W= Warning
E= Error
F= Fatal

The text shown in the "Meaning" is the text returned by the SBMLError::getShortMessage() method on a given SBMLError object. A longer and (hopefully) clearer explanation of the issue is returned by SBMLError::getMessage().

Enumerator Meaning L 1 V 1 L 1 V 2 L 2 V 1 L 2 V 2 L 2 V 3 L 2 V 4 L 3 V 1
UnknownErrorEncountered unknown internal libSBML errorFFFFFFF
NotUTF8File does not use UTF-8 encodingEEEEEEE
UnrecognizedElementEncountered unrecognized elementEEEEEEE
NotSchemaConformantDocument does not conform to the SBML XML schemaEEEEEEE
L3NotSchemaConformantDocument is not well-formed XMLNNNNNNE
InvalidMathElementInvalid MathMLNNEEEEE
DisallowedMathMLSymbolDisallowed MathML symbol foundNNEEEEE
DisallowedMathMLEncodingUseUse of the MathML 'encoding' attribute is not allowed on this elementNNEEEEE
DisallowedDefinitionURLUseUse of the MathML 'definitionURL' attribute is not allowed on this elementNNEEEEE
BadCsymbolDefinitionURLValueInvalid <csymbol> 'definitionURL' attribute valueNNEEEEE
DisallowedMathTypeAttributeUseUse of the MathML 'type' attribute is not allowed on this elementNNEEEEE
DisallowedMathTypeAttributeValueDisallowed MathML 'type' attribute valueNNEEEEE
LambdaOnlyAllowedInFunctionDefUse of <lambda> not permitted outside of FunctionDefinition objectsNNEEEEE
BooleanOpsNeedBooleanArgsNon-Boolean argument given to Boolean operatorNNWEEEE
NumericOpsNeedNumericArgsNon-numerical argument given to numerical operatorNNWEEEE
ArgsToEqNeedSameTypeArguments to <eq> and <neq> must have the same data typesNNWEEEE
PiecewiseNeedsConsistentTypesTerms in a <piecewise> expression must have consistent data typesNNWEEEE
PieceNeedsBooleanThe second argument of a <piece> expression must yield a Boolean valueNNWEEEE
ApplyCiMustBeUserFunctionA <ci> element in this context must refer to a function definitionNNWEEEE
ApplyCiMustBeModelComponentA <ci> element in this context must refer to a model componentNNWEEEE
KineticLawParametersAreLocalOnlyCannot use a KineticLaw local parameter outside of its local scopeNNWEEEE
MathResultMustBeNumericA formula's result in this context must be a numerical valueNNWEEEE
OpsNeedCorrectNumberOfArgsIncorrect number of arguments given to MathML operatorNNWEEEE
InvalidNoArgsPassedToFunctionDefIncorrect number of arguments given to function invocationNNNNNEE
DisallowedMathUnitsUseAttribute 'units' is only permitted on <cn> elementsNNNNNNE
InvalidUnitsValueInvalid value given for the 'units' attributeNNNNNNE
DuplicateComponentIdDuplicate 'id' attribute valueEEEEEEE
DuplicateUnitDefinitionIdDuplicate unit definition 'id' attribute valueEEEEEEE
DuplicateLocalParameterIdDuplicate local parameter 'id' attribute valueEEEEEEE
MultipleAssignmentOrRateRulesMultiple rules for the same variable are not allowedEEEEEEE
MultipleEventAssignmentsForIdMultiple event assignments for the same variable are not allowedNNEEEEE
EventAndAssignmentRuleForIdAn event assignment and an assignment rule must not have the same value for 'variable'NNEEEEE
DuplicateMetaIdDuplicate 'metaid' attribute valueNNEEEEE
InvalidSBOTermSyntaxInvalid syntax for an 'sboTerm' attribute valueNNNEEEE
InvalidMetaidSyntaxInvalid syntax for a 'metaid' attribute valueNNEEEEE
InvalidIdSyntaxInvalid syntax for an 'id' attribute valueEEEEEEE
InvalidUnitIdSyntaxInvalid syntax for the identifier of a unitNNNEEEE
InvalidNameSyntaxInvalid syntax for a 'name' attribute valueNNNNNNE
MissingAnnotationNamespaceMissing declaration of the XML namespace for the annotationNNNEEEE
DuplicateAnnotationNamespacesMultiple annotations using the same XML namespaceNNNEEEE
SBMLNamespaceInAnnotationThe SBML XML namespace cannot be used in an Annotation objectNNNEEEN
MultipleAnnotationsOnly one Annotation object is permitted under a given SBML objectNNNNNNE
InconsistentArgUnitsThe units of the function call's arguments are not consistent with its definitionWWWEEWW
InconsistentKineticLawUnitsL3The kinetic law's units are inconsistent with those of other kinetic laws in the modelNNNNNNW
AssignRuleCompartmentMismatchMismatched units in assignment rule for compartmentEEEEEWW
AssignRuleSpeciesMismatchMismatched units in assignment rule for speciesEEEEEWW
AssignRuleParameterMismatchMismatched units in assignment rule for parameterEEEEEWW
AssignRuleStoichiometryMismatchMismatched units in assignment rule for stoichiometryNNNNNNW
InitAssignCompartmenMismatchMismatched units in initial assignment to compartmentNNNEEWW
InitAssignSpeciesMismatchMismatched units in initial assignment to speciesNNNEEWW
InitAssignParameterMismatchMismatched units in initial assignment to parameterNNNEEWW
InitAssignStoichiometryMismatchMismatched units in initial assignment to stoichiometryNNNNNNW
RateRuleCompartmentMismatchMismatched units in rate rule for compartmentEEEEEWW
RateRuleSpeciesMismatchMismatched units in rate rule for speciesEEEEEWW
RateRuleParameterMismatchMismatched units in rate rule for parameterEEEEEWW
RateRuleStoichiometryMismatchMismatched units in rate rule for stoichiometryNNNNNNW
KineticLawNotSubstancePerTimeThe units of the kinetic law are not 'substance'/'time'EEEEEWW
SpeciesInvalidExtentUnitsThe species' units are not consistent with units of extentNNNNNNW
DelayUnitsNotTimeThe units of the delay expression are not units of timeNNEEEWW
EventAssignCompartmentMismatchMismatched units in event assignment for compartmentNNEEEWW
EventAssignSpeciesMismatchMismatched units in event assignment for speciesNNEEEWW
EventAssignParameterMismatchMismatched units in event assignment for parameterNNEEEWW
EventAssignStoichiometryMismatchMismatched units in event assignment for stoichiometryNNNNNNW
PriorityUnitsNotDimensionlessThe units of a priority expression must be 'dimensionless'NNNNNNW
UpperUnitBoundUpper boundary of unit validation diagnostic codesNNNNNNN
OverdeterminedSystemThe model is overdeterminedWWWEEEE
InvalidModelSBOTermInvalid 'sboTerm' attribute value for a Model objectNNNEEWW
InvalidFunctionDefSBOTermInvalid 'sboTerm' attribute value for a FunctionDefinition objectNNNEEWW
InvalidParameterSBOTermInvalid 'sboTerm' attribute value for a Parameter objectNNNEEWW
InvalidInitAssignSBOTermInvalid 'sboTerm' attribute value for an InitialAssignment objectNNNEEWW
InvalidRuleSBOTermInvalid 'sboTerm' attribute value for a Rule objectNNNEEWW
InvalidConstraintSBOTermInvalid 'sboTerm' attribute value for a Constraint objectNNNEEWW
InvalidReactionSBOTermInvalid 'sboTerm' attribute value for a Reaction objectNNNEEWW
InvalidSpeciesReferenceSBOTermInvalid 'sboTerm' attribute value for a SpeciesReference objectNNNEEWW
InvalidKineticLawSBOTermInvalid 'sboTerm' attribute value for a KineticLaw objectNNNEEWW
InvalidEventSBOTermInvalid 'sboTerm' attribute value for an Event objectNNNEEWW
InvalidEventAssignmentSBOTermInvalid 'sboTerm' attribute value for an EventAssignment objectNNNEEWW
InvalidCompartmentSBOTermInvalid 'sboTerm' attribute value for a Compartment objectNNNNEWW
InvalidSpeciesSBOTermInvalid 'sboTerm' attribute value for a Species objectNNNNEWW
InvalidCompartmentTypeSBOTermInvalid 'sboTerm' attribute value for a CompartmentType objectNNNNEWN
InvalidSpeciesTypeSBOTermInvalid 'sboTerm' attribute value for a SpeciesType objectNNNNEWN
InvalidTriggerSBOTermInvalid 'sboTerm' attribute value for an Event Trigger objectNNNNEWW
InvalidDelaySBOTermInvalid 'sboTerm' attribute value for an Event Delay objectNNNNEWW
NotesNotInXHTMLNamespaceNotes must be placed in the XHTML XML namespaceEEEEEEE
NotesContainsXMLDeclXML declarations are not permitted in Notes objectsNNNEEEE
NotesContainsDOCTYPEXML DOCTYPE elements are not permitted in Notes objectsNNNEEEE
InvalidNotesContentInvalid notes content foundNNNEEEN
OnlyOneNotesElementAllowedOnly one Notes subobject is permitted on a given SBML objectNNNNNNE
InvalidNamespaceOnSBMLInvalid XML namespace for the SBML container elementEEEEEEE
MissingOrInconsistentLevelMissing or inconsistent value for the 'level' attributeEEEEEEE
MissingOrInconsistentVersionMissing or inconsistent value for the 'version' attributeEEEEEEE
PackageNSMustMatchInconsistent or invalid SBML Level/Version for the package namespace declarationNNNNNNE
LevelPositiveIntegerThe 'level' attribute must have a positive integer valueNNNNNNE
VersionPositiveIntegerThe 'version' attribute must have a positive integer valueNNNNNNE
AllowedAttributesOnSBMLInvalid attribute found on the SBML container elementNNNNNNE
L3PackageOnLowerSBMLAn L3 package ns found on the SBML container element.WWWWWWN
MissingModelNo model definition foundEEEEEEE
IncorrectOrderInModelIncorrect ordering of components within the Model objectEEEEEEN
EmptyListElementEmpty ListOf___ object foundEEEEEEE
NeedCompartmentIfHaveSpeciesThe presence of a species requires a compartmentEEEEEEE
OneOfEachListOfOnly one of each kind of ListOf___ object is allowed inside a Model objectNNNNNNE
OnlyFuncDefsInListOfFuncDefsOnly FunctionDefinition, Notes and Annotation objects are allowed in ListOfFunctionDefinitionsNNNNNNE
OnlyUnitDefsInListOfUnitDefsOnly UnitDefinition, Notes and Annotation objects are allowed in ListOfUnitDefinitions objectsNNNNNNE
OnlyCompartmentsInListOfCompartmentsOnly Compartment, Notes and Annotation objects are allowed in ListOfCompartments objectsNNNNNNE
OnlySpeciesInListOfSpeciesOnly Species, Notes and Annotation objects are allowed in ListOfSpecies objectsNNNNNNE
OnlyParametersInListOfParametersOnly Parameter, Notes and Annotation objects are allowed in ListOfParameters objectsNNNNNNE
OnlyInitAssignsInListOfInitAssignsOnly InitialAssignment, Notes and Annotation objects are allowed in ListOfInitialAssignments objectsNNNNNNE
OnlyRulesInListOfRulesOnly Rule, Notes and Annotation objects are allowed in ListOfRules objectsNNNNNNE
OnlyConstraintsInListOfConstraintsOnly Constraint, Notes and Annotation objects are allowed in ListOfConstraints objectsNNNNNNE
OnlyReactionsInListOfReactionsOnly Reaction, Notes and Annotation objects are allowed in ListOfReactions objectsNNNNNNE
OnlyEventsInListOfEventsOnly Event, Notes and Annotation objects are allowed in ListOfEvents objectsNNNNNNE
L3ConversionFactorOnModelA 'conversionFactor' attribute value must reference a Parameter objectNNNNNNE
L3TimeUnitsOnModelInvalid 'timeUnits' attribute valueNNNNNNW
L3VolumeUnitsOnModelInvalid 'volumeUnits' attribute valueNNNNNNW
L3AreaUnitsOnModelInvalid 'areaUnits' attribute valueNNNNNNW
L3LengthUnitsOnModelInvalid 'lengthUnits' attribute valueNNNNNNW
L3ExtentUnitsOnModelInvalid 'extentUnits' attribute valueNNNNNNW
AllowedAttributesOnModelInvalid attribute found on the Model objectNNNNNNE
AllowedAttributesOnListOfFuncsInvalid attribute found on the ListOfFunctionDefinitions objectNNNNNNE
AllowedAttributesOnListOfUnitDefsInvalid attribute found on the ListOfUnitDefinitions objectNNNNNNE
AllowedAttributesOnListOfCompsInvalid attribute found on the ListOfCompartments objectNNNNNNE
AllowedAttributesOnListOfSpeciesInvalid attribute found on the ListOfSpecies objectNNNNNNE
AllowedAttributesOnListOfParamsInvalid attribute found on the ListOfParameters objectNNNNNNE
AllowedAttributesOnListOfInitAssignInvalid attribute found on the ListOfInitialAssignments objectNNNNNNE
AllowedAttributesOnListOfRulesInvalid attribute found on the ListOfRules objectNNNNNNE
AllowedAttributesOnListOfConstraintsInvalid attribute found on the ListOfConstraints objectNNNNNNE
AllowedAttributesOnListOfReactionsInvalid attribute found on the ListOfReactions objectNNNNNNE
AllowedAttributesOnListOfEventsInvalid attribute found on the ListOfEvents objectNNNNNNE
FunctionDefMathNotLambdaInvalid expression found in the function definitionNNEEEEE
InvalidApplyCiInLambdaInvalid forward reference in the MathML <apply><ci>...</ci></apply> expressionNNEEENN
RecursiveFunctionDefinitionRecursive function definitions are not permittedNNEEEEE
InvalidCiInLambdaInvalid <ci> reference found inside the <lambda> mathematical formulaNNEEEEE
InvalidFunctionDefReturnTypeA function's return type must be either a number or a BooleanNNEEEEE
OneMathElementPerFuncA FunctionDefinition object must contain one <math> elementNNNNNNE
AllowedAttributesOnFuncInvalid attribute found on the FunctionDefinition objectNNNNNNE
InvalidUnitDefIdInvalid 'id' attribute value for a UnitDefinition objectEEEEEEE
InvalidSubstanceRedefinitionInvalid redefinition of built-in type 'substance'EEEEEEN
InvalidLengthRedefinitionInvalid redefinition of built-in type 'length'WWEEEEN
InvalidAreaRedefinitionInvalid redefinition of built-in type name 'area'WWEEEEN
InvalidTimeRedefinitionInvalid redefinition of built-in type name 'time'EEEEEEN
InvalidVolumeRedefinitionInvalid redefinition of built-in type name 'volume'EEEEEEN
VolumeLitreDefExponentNotOneMust use 'exponent'=1 when defining 'volume' in terms of litresEEEEENN
VolumeMetreDefExponentNot3Must use 'exponent'=3 when defining 'volume' in terms of metresNNEEENN
EmptyListOfUnitsAn empty list of Unit objects is not permitted in a UnitDefinition objectEEEEEEN
InvalidUnitKindInvalid value for the 'kind' attribute of a UnitDefinition objectEEEEEEE
OffsetNoLongerValidUnit attribute 'offset' is not supported in this Level+Version of SBMLNNNEEEN
CelsiusNoLongerValidUnit name 'Celsius' is not defined in this Level+Version of SBMLNNNEEEN
EmptyUnitListElementA ListOfUnits object must not be emptyNNNNNNE
OneListOfUnitsPerUnitDefAt most one ListOfUnits object is allowed inside a UnitDefinition objectNNNNNNE
OnlyUnitsInListOfUnitsOnly Unit, Notes and Annotation objects are allowed in ListOfUnits objectsNNNNNNE
AllowedAttributesOnUnitDefinitionInvalid attribute found on the UnitDefinition objectNNNNNNE
AllowedAttributesOnListOfUnitsInvalid attribute found on the ListOfUnits objectNNNNNNE
AllowedAttributesOnUnitInvalid attribute found on the Unit objectNNNNNNE
ZeroDimensionalCompartmentSizeInvalid use of the 'size' attribute for a zero-dimensional compartmentNNEEEEN
ZeroDimensionalCompartmentUnitsInvalid use of the 'units' attribute for a zero-dimensional compartmentNNEEEEN
ZeroDimensionalCompartmentConstZero-dimensional compartments must be defined to be constantNNEEEEN
UndefinedOutsideCompartmentInvalid value for the 'outside' attribute of a Compartment objectEEEEEEN
RecursiveCompartmentContainmentRecursive nesting of compartments via the 'outside' attribute is not permittedWWWEEEN
ZeroDCompartmentContainmentInvalid nesting of zero-dimensional compartmentsNNWEEEN
Invalid1DCompartmentUnitsInvalid value for the 'units' attribute of a one-dimensional compartmentNNEEEEW
Invalid2DCompartmentUnitsInvalid value for the 'units' attribute of a two-dimensional compartmentNNEEEEW
Invalid3DCompartmentUnitsInvalid value for the 'units' attribute of a three-dimensional compartmentEEEEEEW
InvalidCompartmentTypeRefInvalid value for the 'compartmentType' attribute of a compartmentNNNEEEN
OneDimensionalCompartmentUnitsNo units defined for 1-D compartmentNNNNNNW
TwoDimensionalCompartmentUnitsNo units defined for 2-D compartmentNNNNNNW
ThreeDimensionalCompartmentUnitsNo units defined for 3-D Compartment objectNNNNNNW
AllowedAttributesOnCompartmentInvalid attribute found on Compartment objectNNNNNNE
NoUnitsOnCompartmentNo units defined for Compartment objectNNNNNNW
InvalidSpeciesCompartmentRefInvalid value found for Species 'compartment' attributeEEEEEEE
HasOnlySubsNoSpatialUnitsAttribute 'spatialSizeUnits' must not be set if 'hasOnlySubstanceUnits'='true'NNEENNN
NoSpatialUnitsInZeroDAttribute 'spatialSizeUnits' must not be set if the compartment is zero-dimensionalNNEENNN
NoConcentrationInZeroDAttribute 'initialConcentration' must not be set if the compartment is zero-dimensionalNNEEEEN
SpatialUnitsInOneDInvalid value for 'spatialSizeUnits' attribute of a one-dimensional compartmentNNEENNN
SpatialUnitsInTwoDInvalid value for the 'spatialSizeUnits' attribute of a two-dimensional compartmentNNEENNN
SpatialUnitsInThreeDInvalid value for the 'spatialSizeUnits' attribute of a three-dimensional compartmentNNEENNN
InvalidSpeciesSusbstanceUnitsInvalid value for a Species 'units' attributeEEEEEEW
BothAmountAndConcentrationSetCannot set both 'initialConcentration' and 'initialAmount' attributes simultaneouslyNNEEEEE
NonBoundarySpeciesAssignedAndUsedCannot use a non-boundary species in both reactions and rules simultaneouslyWWEEEEE
NonConstantSpeciesUsedCannot use a constant, non-boundary species as a reactant or productNNEEEEE
InvalidSpeciesTypeRefInvalid value for the 'speciesType' attribute of a speciesNNNEEEN
MultSpeciesSameTypeInCompartmentCannot have multiple species of the same species type in the same compartmentNNNEEEN
MissingSpeciesCompartmentMissing value for the 'compartment' attributeEEEEEEE
SpatialSizeUnitsRemovedAttribute 'spatialSizeUnits' is not supported in this Level+Version of SBMLNNNNEEN
SubstanceUnitsOnSpeciesNo substance units defined for the speciesNNNNNNW
ConversionFactorOnSpeciesInvalid value for the 'conversionFactor' attributeNNNNNNE
AllowedAttributesOnSpeciesInvalid attribute found on Species objectNNNNNNE
InvalidParameterUnitsInvalid value for the 'units' attribute of a Parameter objectEEEEEEW
ParameterUnitsNo units defined for the parameterNNNNNNW
ConversionFactorMustConstantA conversion factor must reference a Parameter object declared to be a constantNNNNNNE
AllowedAttributesOnParameterInvalid attribute found on Parameter objectNNNNNNE
InvalidInitAssignSymbolInvalid value for the 'symbol' attribute of an InitialAssignment objectNNNEEEE
MultipleInitAssignmentsMultiple initial assignments for the same 'symbol' value are not allowedNNNEEEE
InitAssignmentAndRuleForSameIdCannot set a value using both an initial assignment and an assignment rule simultaneouslyNNNEEEE
OneMathElementPerInitialAssignAn InitialAssignment object must contain one <math> elementNNNNNNE
AllowedAttributesOnInitialAssignInvalid attribute found on an InitialAssignment objectNNNNNNE
InvalidAssignRuleVariableInvalid value for the 'variable' attribute of an AssignmentRule objectEEEEEEE
InvalidRateRuleVariableInvalid value for the 'variable' attribute of a RateRule objectEEEEEEE
AssignmentToConstantEntityAn assignment rule cannot assign an entity declared to be constantNNEEEEE
RateRuleForConstantEntityA rate rule cannot assign an entity declared to be constantNNEEEEE
CircularRuleDependencyCircular dependencies involving rules and reactions are not permittedNNNEEEE
OneMathElementPerRuleA rule object must contain one <math> elementNNNNNNE
AllowedAttributesOnAssignRuleInvalid attribute found on an AssignmentRule objectNNNNNNE
AllowedAttributesOnRateRuleInvalid attribute found on a RateRule objectNNNNNNE
AllowedAttributesOnAlgRuleInvalid attribute found on an AlgebraicRule objectNNNNNNE
ConstraintMathNotBooleanA Constraint object's <math> must evaluate to a Boolean valueNNNEEEE
IncorrectOrderInConstraintSubobjects inside the Constraint object are not in the prescribed orderNNNEEEN
ConstraintNotInXHTMLNamespaceA Constraint's Message subobject must be in the XHTML XML namespaceNNNEEEN
ConstraintContainsXMLDeclXML declarations are not permitted within Constraint's Message objectsNNNEEEE
ConstraintContainsDOCTYPEXML DOCTYPE elements are not permitted within Constraint's Message objectsNNNEEEE
InvalidConstraintContentInvalid content for a Constraint object's Message objectNNNEEEN
OneMathElementPerConstraintA Constraint object must contain one <math> elementNNNNNNE
OneMessageElementPerConstraintA Constraint object must contain one Message subobjectNNNNNNE
AllowedAttributesOnConstraintInvalid attribute found on Constraint objectNNNNNNE
NoReactantsOrProductsCannot have a reaction with neither reactants nor productsEEEEEEE
IncorrectOrderInReactionSubobjects inside the Reaction object are not in the prescribed orderEEEEEEN
EmptyListInReactionReaction components, if present, cannot be emptyEEEEEEE
InvalidReactantsProductsListInvalid object found in the list of reactants or productsEEEEEEE
InvalidModifiersListInvalid object found in the list of modifiersNNEEEEE
OneSubElementPerReactionA Reaction object can only contain one of each allowed type of objectNNNNNNE
CompartmentOnReactionInvalid value for the Reaction 'compartment' attributeNNNNNNE
AllowedAttributesOnReactionInvalid attribute for a Reaction objectNNNNNNE
InvalidSpeciesReferenceInvalid 'species' attribute value in SpeciesReference objectEEEEEEE
BothStoichiometryAndMathThe 'stoichiometry' attribute and StoichiometryMath subobject are mutually exclusiveNNEEEEN
AllowedAttributesOnSpeciesReferenceInvalid attribute found on the SpeciesReference objectNNNNNNE
AllowedAttributesOnModifierInvalid attribute found on the ModifierSpeciesReference objectNNNNNNE
UndeclaredSpeciesRefUnknown species referenced in the kinetic law <math> formulaWWEEEEE
IncorrectOrderInKineticLawIncorrect ordering of components in the KineticLaw objectNNEEEEN
EmptyListInKineticLawThe list of parameters, if present, cannot be emptyEEEEEEE
NonConstantLocalParameterParameters local to a KineticLaw object must have a 'constant' attribute value of 'true'NNWEEEN
SubsUnitsNoLongerValidAttribute 'substanceUnits' is not supported in this Level+Version of SBMLNNNEEEN
TimeUnitsNoLongerValidAttribute 'timeUnits' is not supported in this Level+Version of SBMLNNNEEEN
OneListOfPerKineticLawOnly one ListOfLocalParameters object is permitted within a KineticLaw objectNNNNNNE
OnlyLocalParamsInListOfLocalParamsOnly LocalParameter, Notes and Annotation objects are allowed in ListOfLocalParameter objectsNNNNNNE
AllowedAttributesOnListOfLocalParamInvalid attribute found on the ListOfLocalParameters objectNNNNNNE
OneMathPerKineticLawOnly one <math> element is allowed in a KineticLaw objectNNEEEEE
UndeclaredSpeciesInStoichMathUnknown species referenced in the StoichiometryMath object's <math> formulaNNWEEEN
AllowedAttributesOnKineticLawInvalid attribute found on the KineticLaw objectNNNNNNE
AllowedAttributesOnListOfSpeciesRefInvalid attribute found on the ListOfSpeciesReferences objectNNNNNNE
AllowedAttributesOnListOfModsInvalid attribute found on the ListOfModifiers objectNNNNNNE
AllowedAttributesOnLocalParameterInvalid attribute found on the LocalParameter objectNNNNNNE
MissingTriggerInEventThe Event object is missing a Trigger subobjectNNEEEEE
TriggerMathNotBooleanA Trigger object's <math> expression must evaluate to a Boolean valueNNEEEEE
MissingEventAssignmentThe Event object is missing an EventAssignment subobjectNNEEEEE
TimeUnitsEventUnits referenced by 'timeUnits' attribute are not compatible with units of timeNNEENNN
IncorrectOrderInEventIncorrect ordering of components in Event objectNNEEEEN
ValuesFromTriggerTimeNeedDelayAttribute 'useValuesFromTriggerTime'='false', but the Event object does not define a delayNNNNNEN
DelayNeedsValuesFromTriggerTimeThe use of a Delay object requires the Event attribute 'useValuesFromTriggerTime'NNNNNNN
OneMathPerTriggerA Trigger object must have one <math> elementNNNNNNE
OneMathPerDelayA Delay object must have one <math> elementNNNNNNE
InvalidEventAssignmentVariableInvalid 'variable' attribute value in Event objectNNEEEEE
EventAssignmentForConstantEntityAn EventAssignment object cannot assign to a component having attribute 'constant'='true'NNWEEEE
OneMathPerEventAssignmentAn EventAssignment object must have one <math> elementNNNNNNE
AllowedAttributesOnEventAssignmentInvalid attribute found on the EventAssignment objectNNNNNNE
OnlyOneDelayPerEventAn Event object can only have one Delay subobjectNNNNNNE
OneListOfEventAssignmentsPerEventAn Event object can only have one ListOfEventAssignments subobjectNNNNNNE
OnlyEventAssignInListOfEventAssignOnly EventAssignment, Notes and Annotation objects are allowed in ListOfEventAssignmentsNNNNNNE
AllowedAttributesOnListOfEventAssignInvalid attribute found on the ListOfEventAssignments objectNNNNNNE
AllowedAttributesOnEventInvalid attribute found on the Event objectNNNNNNE
AllowedAttributesOnTriggerInvalid attribute found on the Trigger objectNNNNNNE
AllowedAttributesOnDelayInvalid attribute found on the Delay objectNNNNNNE
PersistentNotBooleanThe Trigger attribute 'persistent' must evaluate to a Boolean valueNNNNNNE
InitialValueNotBooleanThe Trigger attribute 'initialValue' must evaluate to a Boolean valueNNNNNNE
OnlyOnePriorityPerEventAn Event object can only have one Priority subobjectNNNNNNE
OneMathPerPriorityA Priority object must have one <math> elementNNNNNNE
AllowedAttributesOnPriorityInvalid attribute found on the Priority objectNNNNNNE
GeneralWarningNotSpecifiedUnknown errorNNNNNNN
CompartmentShouldHaveSizeIt's best to define a size for every compartment in a modelNNWWWWW
SpeciesShouldHaveValueIt's best to define an initial amount or initial concentration for every species in a modelNNWWWWW
ParameterShouldHaveUnitsIt's best to declare units for every parameter in a modelWWWWWWW
LocalParameterShadowsIdLocal parameters defined within a kinetic law shadow global object symbolsWWWWWWW
CannotConvertToL1V1Cannot convert to SBML Level 1 Version 1NEEEEEE
NoEventsInL1SBML Level 1 does not support eventsNNEEEEE
NoFunctionDefinitionsInL1SBML Level 1 does not support function definitionsNNWWWWW
NoConstraintsInL1SBML Level 1 does not support constraintsNNNWWWW
NoInitialAssignmentsInL1SBML Level 1 does not support initial assignmentsNNNWWWW
NoSpeciesTypesInL1SBML Level 1 does not support species typesNNNWWWN
NoCompartmentTypeInL1SBML Level 1 does not support compartment typesNNNWWWN
NoNon3DCompartmentsInL1SBML Level 1 only supports three-dimensional compartmentsNNEEEEE
NoFancyStoichiometryMathInL1SBML Level 1 does not support non-integer nor non-rational stoichiometry formulasNNEEEEE
NoNonIntegerStoichiometryInL1SBML Level 1 does not support non-integer 'stoichiometry' attribute valuesNNEEEEE
NoUnitMultipliersOrOffsetsInL1SBML Level 1 does not support multipliers or offsets in unit definitionsNNEEEEE
SpeciesCompartmentRequiredInL1In SBML Level 1, a value for 'compartment' is mandatory in species definitionsNNEEEEE
NoSpeciesSpatialSizeUnitsInL1SBML Level 1 does not support species 'spatialSizeUnits' settingsNNEEEEN
NoSBOTermsInL1SBML Level 1 does not support the 'sboTerm' attributeNNNWWWW
StrictUnitsRequiredInL1SBML Level 1 requires strict unit consistencyNNNNNWW
ConversionFactorNotInL1SBML Level 1 does not support the 'conversionFactor' attributeNNNNNNE
CompartmentNotOnL1ReactionSBML Level 1 does not support the 'compartment' attribute on Reaction objectsNNNNNNW
ExtentUnitsNotSubstanceUnits of extent must be compatible with units of substanceNNNNNNE
GlobalUnitsNotDeclaredGlobal units must be refer to unit kind or unitDefinition.NNNNNNE
HasOnlySubstanceUnitsNotinL1The concept of hasOnlySubstanceUnits was not available in SBML Level 1.NNEEEEE
AvogadroNotSupportedAvogadro not supported in Levels 2 and 1.NNNNNNE
NoConstraintsInL2v1SBML Level 2 Version 1 does not support Constraint objectsNNNWWWW
NoInitialAssignmentsInL2v1SBML Level 2 Version 1 does not support InitialAssignment objectsNNNWWWW
NoSpeciesTypeInL2v1SBML Level 2 Version 1 does not support SpeciesType objectsNNNWWWN
NoCompartmentTypeInL2v1SBML Level 2 Version 1 does not support CompartmentType objectsNNNWWWN
NoSBOTermsInL2v1SBML Level 2 Version 1 does not support the 'sboTerm' attributeNNNWWWW
NoIdOnSpeciesReferenceInL2v1SBML Level 2 Version 1 does not support the 'id' attribute on SpeciesReference objectsNNNWWWW
NoDelayedEventAssignmentInL2v1SBML Level 2 Version 1 does not support the 'useValuesFromTriggerTime' attributeNNNNNEE
StrictUnitsRequiredInL2v1SBML Level 2 Version 1 requires strict unit consistencyNNNNNWW
IntegerSpatialDimensionsSBML Level 2 Version 1 requires that compartments have spatial dimensions of 0-3NNNNNNE
StoichiometryMathNotYetSupportedConversion to StoichiometryMath objects not yet supportedNNNNNNN
PriorityLostFromL3SBML Level 2 Version 1 does not support priorities on Event objectsNNNNNNE
NonPersistentNotSupportedSBML Level 2 Version 1 does not support the 'persistent' attribute on Trigger objectsNNNNNNE
InitialValueFalseEventNotSupportedSBML Level 2 Version 1 does not support the 'initialValue' attribute on Trigger objectsNNNNNNE
SBOTermNotUniversalInL2v2The 'sboTerm' attribute is invalid for this component in SBML Level 2 Version 2NNNNWWW
NoUnitOffsetInL2v2This Level+Version of SBML does not support the 'offset' attribute on Unit objectsNNENNNN
NoKineticLawTimeUnitsInL2v2This Level+Version of SBML does not support the 'timeUnits' attribute on KineticLaw objectsEEENNNN
NoKineticLawSubstanceUnitsInL2v2This Level+Version of SBML does not support the 'substanceUnits' attribute on KineticLaw objectsEEENNNN
NoDelayedEventAssignmentInL2v2This Level+Version of SBML does not support the 'useValuesFromTriggerTime' attributeNNNNNEE
ModelSBOBranchChangedBeyondL2v2The allowable 'sboTerm' attribute values for Model objects differ for this SBML Level+VersionNNNNNEE
StrictUnitsRequiredInL2v2SBML Level 2 Version 2 requires strict unit consistencyNNNNNWW
StrictSBORequiredInL2v2SBML Level 2 Version 2 requires strict SBO term consistencyNNNNNWW
DuplicateAnnotationInvalidInL2v2Duplicate top-level annotations are invalid in SBML Level 2 Version 2WWWNNNN
NoUnitOffsetInL2v3This Level+Version of SBML does not support the 'offset' attribute on Unit objectsNNENNNN
NoKineticLawTimeUnitsInL2v3This Level+Version of SBML does not support the 'timeUnits' attribute on KineticLaw objectsEEENNNN
NoKineticLawSubstanceUnitsInL2v3This Level+Version of SBML does not support the 'substanceUnits' attribute on KineticLaw objectsEEENNNN
NoSpeciesSpatialSizeUnitsInL2v3This Level+Version of SBML does not support the 'spatialSizeUnit' attribute on Species objectsNNEENNN
NoEventTimeUnitsInL2v3This Level+Version of SBML does not support the 'timeUnits' attribute on Event objectsNNEENNN
NoDelayedEventAssignmentInL2v3This Level+Version of SBML does not support the 'useValuesFromTriggerTime' attributeNNNNNEE
ModelSBOBranchChangedBeyondL2v3The allowable 'sboTerm' attribute values for Model objects differ for this SBML Level+VersionNNNNNEE
StrictUnitsRequiredInL2v3SBML Level 2 Version 3 requires strict unit consistencyNNNNNWW
StrictSBORequiredInL2v3SBML Level 2 Version 3 requires strict SBO term consistencyNNNNNWW
DuplicateAnnotationInvalidInL2v3Duplicate top-level annotations are invalid in SBML Level 2 Version 3WWWNNNN
NoUnitOffsetInL2v4This Level+Version of SBML does not support the 'offset' attribute on Unit objectsNNENNNN
NoKineticLawTimeUnitsInL2v4This Level+Version of SBML does not support the 'timeUnits' attribute on KineticLaw objectsEEENNNN
NoKineticLawSubstanceUnitsInL2v4This Level+Version of SBML does not support the 'substanceUnits' attribute on KineticLaw objectsEEENNNN
NoSpeciesSpatialSizeUnitsInL2v4This Level+Version of SBML does not support the 'spatialSizeUnit' attribute on Species objectsNNEENNN
NoEventTimeUnitsInL2v4This Level+Version of SBML does not support the 'timeUnits' attribute on Event objectsNNEENNN
ModelSBOBranchChangedInL2v4The allowable 'sboTerm' attribute values for Model objects differ for this SBML Level+VersionNNNEENN
DuplicateAnnotationInvalidInL2v4Duplicate top-level annotations are invalid in SBML Level 2 Version 4WWWNNNN
NoSpeciesTypeInL3v1SBML Level 3 Version 1 does not support SpeciesType objectsNNNWWWN
NoCompartmentTypeInL3v1SBML Level 3 Version 1 does not support CompartmentType objectsNNNWWWN
NoUnitOffsetInL3v1This Level+Version of SBML does not support the 'offset' attribute on Unit objectsNNENNNN
NoKineticLawTimeUnitsInL3v1This Level+Version of SBML does not support the 'timeUnits' attribute on KineticLaw objectsEEENNNN
NoKineticLawSubstanceUnitsInL3v1This Level+Version of SBML does not support the 'substanceUnits' attribute on KineticLaw objectsEEENNNN
NoSpeciesSpatialSizeUnitsInL3v1This Level+Version of SBML does not support the 'spatialSizeUnit' attribute on Species objectsNNEENNN
NoEventTimeUnitsInL3v1This Level+Version of SBML does not support the 'timeUnits' attribute on Event objectsNNEENNN
ModelSBOBranchChangedInL3v1The allowable 'sboTerm' attribute values for Model objects differ for this SBML Level+VersionNNNEENN
DuplicateAnnotationInvalidInL3v1Duplicate top-level annotations are invalid in SBML Level 3 Version 1WWWNNNN
NoCompartmentOutsideInL3v1This Level+Version of SBML does not support the 'outside' attribute on Compartment objectsWWWWWWN
NoStoichiometryMathInL3v1This Level+Version of SBML does not support the StoichiometryMath objectNNEEEEN
InvalidSBMLLevelVersionUnknown Level+Version combination of SBMLEEEEEEE
AnnotationNotesNotAllowedLevel1Annotation objects on the SBML container element are not permitted in SBML Level 1EENNNNN
InvalidRuleOrderingInvalid ordering of rulesEEENNNN
RequiredPackagePresentThe SBML document requires an SBML Level 3 package unavailable in this softwareNNNNNNE
UnrequiredPackagePresentThe SBML document uses an SBML Level 3 package unavailable in this softwareNNNNNNW
PackageRequiredShouldBeFalseThis package expects required to be false.NNNNNNW
SubsUnitsAllowedInKLDisallowed value for attribute 'substanceUnits' on KineticLaw objectEEENNNN
TimeUnitsAllowedInKLDisallowed value for attribute 'timeUnits' on KineticLaw objectEEENNNN
FormulaInLevel1KLOnly predefined functions are allowed in SBML Level 1 formulasEENNNNN
L3SubstanceUnitsOnModelInvalid 'substanceUnits' attribute valueNNNNNNW
TimeUnitsRemovedThis Level+Version of SBML does not support the 'timeUnits' attribute on Event objectsNNNNEEE
BadMathMLInvalid MathML expressionNNEEEEE
FailedMathMLReadOfDoubleMissing or invalid floating-point number in MathML expressionNNEEEEE
FailedMathMLReadOfIntegerMissing or invalid integer in MathML expressionNNEEEEE
FailedMathMLReadOfExponentialMissing or invalid exponential expression in MathMLNNEEEEE
FailedMathMLReadOfRationalMissing or invalid rational expression in MathMLNNEEEEE
BadMathMLNodeTypeInvalid MathML elementNNEEEEE
NoTimeSymbolInFunctionDefUse of <csymbol> for 'time' not allowed within FunctionDefinition objectsNNWEEEE
NoBodyInFunctionDefThere must be a <lambda> body within the <math> element of a FunctionDefinition objectNNEEEEE
DanglingUnitSIdRefUnits must refer to valid unit or unitDefinitionWWWWWWW
RDFMissingAboutTagRDF missing the <about> tag.NNNWWWW
RDFEmptyAboutTagRDF empty <about> tag.NNNWWWW
RDFAboutTagNotMetaidRDF <about> tag is not metaid.NNNWWWW
RDFNotCompleteModelHistoryRDF does not contain valid ModelHistory.NNNWWWW
RDFNotModelHistoryRDF does not result in a ModelHistory.NNNWWWW
AnnotationNotElementAnnotation must contain element.NNNWWWW
UndeclaredUnitsMissing unit declarations on parameters or literal numbers in expressionWWWWWWW
UndeclaredTimeUnitsL3Unable to verify consistency of units: the unit of time has not been declaredNNNNNNW
UndeclaredExtentUnitsL3Unable to verify consistency of units: the units of reaction extent have not been declaredNNNNNNW
UndeclaredObjectUnitsL3Unable to verify consistency of units: encountered a model entity with no declared unitsNNNNNNW
UnrecognisedSBOTermUnrecognized 'sboTerm' attribute valueNNNWWWW
ObseleteSBOTermObsolete 'sboTerm' attribute valueNNNWWWW
IncorrectCompartmentSpatialDimensionsIn SBML Level 1, only three-dimensional compartments are allowedEENNNNN
CompartmentTypeNotValidAttributeCompartmentType objects are not available in this Level+Version of SBMLEEENNNE
ConstantNotValidAttributeThis Level+Version of SBML does not support the 'constant' attribute on this componentEENNNNN
MetaIdNotValidAttributeAttribute 'metaid' is not available in SBML Level 1EENNNNN
SBOTermNotValidAttributeBeforeL2V3The 'sboTerm' attribute is not available on this component before SBML Level 2 Version 3EEEENNN
InvalidL1CompartmentUnitsInvalid units for a compartment in SBML Level 1EENNNNN
L1V1CompartmentVolumeReqdIn SBML Level 1, a compartment's volume must be specifiedENNNNNN
CompartmentTypeNotValidComponentCompartmentType objects are not available in this Level+Version of SBMLEEENNNE
ConstraintNotValidComponentConstraint objects are not available in this Level+Version of SBMLEEENNNN
EventNotValidComponentEvent objects are not available in this Level+Version of SBMLEENNNNN
SBOTermNotValidAttributeBeforeL2V2The 'sboTerm' attribute is invalid for this component before Level 2 Version 2EEENNNN
FuncDefNotValidComponentFunctionDefinition objects are not available in this Level+Version of SBMLEENNNNN
InitialAssignNotValidComponentInitialAssignment objects are not available in this Level+Version of SBMLEEENNNN
VariableNotValidAttributeAttribute 'variable' is not available on this component in this Level+Version of SBMLEEEEEEE
UnitsNotValidAttributeAttribute 'units' is not available on this component in this Level+Version of SBMLEEEEEEE
ConstantSpeciesNotValidAttributeAttribute 'constant' is not available on Species objects in SBML Level 1EENNNNN
SpatialSizeUnitsNotValidAttributeAttribute 'spatialSizeUnits' is not available on Species objects in SBML Level 1EENNNNN
SpeciesTypeNotValidAttributeAttribute 'speciesType' is not available on Species objects in SBML Level 1EEENNNE
HasOnlySubsUnitsNotValidAttributeAttribute 'hasOnlySubstanceUnits' is not available on Species objects in SBML Level 1EENNNNN
IdNotValidAttributeAttribute 'id' is not available on SpeciesReference objects in SBML Level 1EEENNNN
NameNotValidAttributeAttribute 'name' is not available on SpeciesReference objects in SBML Level 1EEENNNN
SpeciesTypeNotValidComponentThe SpeciesType object is not supported in SBML Level 1EEENNNE
StoichiometryMathNotValidComponentThe StoichiometryMath object is not supported in SBML Level 1EENNNNE
MultiplierNotValidAttributeAttribute 'multiplier' on Unit objects is not supported in SBML Level 1EENNNNN
OffsetNotValidAttributeAttribute 'offset' on Unit objects is only available in SBML Level 2 Version 1EENNNNN
L3SpatialDimensionsUnsetNo value given for 'spatialDimensions' attribute; assuming a value of 3NNNNNNW
PackageConversionNotSupportedConversion of SBML Level 3 package constructs is not yet supportedEEEEEEE
InvalidTargetLevelVersionThe requested SBML Level/Version combination is not known to existEEEEEEE
L3NotSupportedSBML Level 3 is not yet supportedEEEEEEE
Enumerator Meaning
LIBSBML_CAT_SBMLGeneral error not falling into another category below.
LIBSBML_CAT_SBML_L1_COMPATCategory of errors that can only occur during attempted translation from one Level/Version of SBML to another. This particular category applies to errors encountered while trying to convert a model from SBML Level 2 to SBML Level 1.
LIBSBML_CAT_SBML_L2V1_COMPATCategory of errors that can only occur during attempted translation from one Level/Version of SBML to another. This particular category applies to errors encountered while trying to convert a model to SBML Level 2 Version 1.
LIBSBML_CAT_SBML_L2V2_COMPATCategory of errors that can only occur during attempted translation from one Level/Version of SBML to another. This particular category applies to errors encountered while trying to convert a model to SBML Level 2 Version 2.
LIBSBML_CAT_GENERAL_CONSISTENCYCategory of errors that can occur while validating general SBML constructs. With respect to the SBML specification, these concern failures in applying the validation rules numbered 2xxxx in the Level 2 Versions 2–4 and Level 3 Version 1 specifications.
LIBSBML_CAT_IDENTIFIER_CONSISTENCYCategory of errors that can occur while validating symbol identifiers in a model. With respect to the SBML specification, these concern failures in applying the validation rules numbered 103xx in the Level 2 Versions 2–4 and Level 3 Version 1 specifications.
LIBSBML_CAT_UNITS_CONSISTENCYCategory of errors that can occur while validating the units of measurement on quantities in a model. With respect to the SBML specification, these concern failures in applying the validation rules numbered 105xx in the Level 2 Versions 2–4 and Level 3 Version 1 specifications.
LIBSBML_CAT_MATHML_CONSISTENCYCategory of errors that can occur while validating MathML formulas in a model. With respect to the SBML specification, these concern failures in applying the validation rules numbered 102xx in the Level 2 Versions 2–4 and Level 3 Version 1 specifications.
LIBSBML_CAT_SBO_CONSISTENCYCategory of errors that can occur while validating SBO identifiers in a model. With respect to the SBML specification, these concern failures in applying the validation rules numbered 107xx in the Level 2 Versions 2–4 and Level 3 Version 1 specifications.
LIBSBML_CAT_OVERDETERMINED_MODELError in the system of equations in the model: the system is overdetermined, therefore violating a tenet of proper SBML. With respect to the SBML specification, this is validation rule #10601 in the SBML Level 2 Versions 2–4 and Level 3 Version 1 specifications.
LIBSBML_CAT_SBML_L2V3_COMPATCategory of errors that can only occur during attempted translation from one Level/Version of SBML to another. This particular category applies to errors encountered while trying to convert a model to SBML Level 2 Version 3.
LIBSBML_CAT_MODELING_PRACTICECategory of warnings about recommended good practices involving SBML and computational modeling. (These are tests performed by libSBML and do not have equivalent SBML validation rules.)
LIBSBML_CAT_INTERNAL_CONSISTENCYCategory of errors that can occur while validating libSBML's internal representation of SBML constructs. (These are tests performed by libSBML and do not have equivalent SBML validation rules.)
LIBSBML_CAT_SBML_L2V4_COMPATCategory of errors that can only occur during attempted translation from one Level/Version of SBML to another. This particular category applies to errors encountered while trying to convert a model to SBML Level 2 Version 4.
LIBSBML_CAT_SBML_L3V1_COMPAT

Category of errors that can only occur during attempted translation from one Level/Version of SBML to another. This particular category applies to errors encountered while trying to convert a model to SBML Level 3 Version 1.

The core component of SBML's package extension.

SBMLExtension class (abstract class) is a core component of package extension which needs to be extended by package developers. The class provides functions for getting common attributes of package extension (e.g., package name, package version, and etc.), functions for adding (registering) each instantiated SBasePluginCreator object, and a static function (defined in each SBMLExtension extended class) for initializing/registering the package extension when the library of the package is loaded.

How to implement an SBMLExtension extended class for each package extension

Package developers must implement an SBMLExtension extended class for their packages (e.g. GroupsExtension class is implemented for groups extension). The extended class is implemented based on the following steps:

(NOTE: "src/pacakges/groups/extension/GroupsExtension.{h,cpp}" and "src/pacakges/layout/extension/LayoutExtension.{h,cpp}" are example files in which SBMLExtension derived classes are implemented)

  1. Define the following static functions in the extended class: (examples of groups extension are shown respectively)

    1. A string of package name (label) (The function name must be "getPackageName".)

        const std::string& GroupsExtension::getPackageName ()
        {
      	static const std::string pkgName = "groups";
      	return pkgName;
        }
      

    2. Methods returning an integer of Default SBML level, version, and package version (The method names must be "getDefaultLevel()", "getDefaultVersion()", and "getDefaultPackageVersion()" respectively.)

        unsigned int GroupsExtension::getDefaultLevel()
        {
      	return 3;
        }  
        unsigned int GroupsExtension::getDefaultVersion()
        {
      	return 1; 
        }
        unsigned int GroupsExtension::getDefaultPackageVersion()
        {
      	return 1;
        }  
      
    3. Methods returning Strings that represent the URI of packages

        const std::string& GroupsExtension::getXmlnsL3V1V1 ()
        {
      	static const std::string xmlns = "http://www.sbml.org/sbml/level3/version1/groups/version1";
      	return xmlns;
        }
      
    4. Strings that represent the other URI needed in this package (if any)

  2. Override the following pure virtual functions

    • virtual const std::string& getName () const =0. This function returns the name of the package (e.g., "layout", "groups").
    • virtual unsigned int getLevel (const std::string &uri) const =0. This function returns the SBML level with the given URI of this package.
    • virtual unsigned int getVersion (const std::string &uri) const =0. This function returns the SBML version with the given URI of this package.
    • virtual unsigned int getPackageVersion (const std::string &uri) const =0. This function returns the package version with the given URI of this package.
    • virtual unsigned int getURI (unsigned int sbmlLevel, unsigned int sbmlVersion, unsigned int pkgVersion) const =0. This function returns the URI (namespace) of the package corresponding to the combination of the given sbml level, sbml version, and pacakege version
    • virtual SBMLExtension* clone () const = 0. This function creates and returns a deep copy of this derived object.

    For example, the above functions are overridden in the groups package ("src/packages/groups/extension/GroupsExtension.cpp") as follows:

    const std::string&
    GroupsExtension::getName() const
    {
      return getPackageName();
    }
    
    unsigned int 
    GroupsExtension::getLevel(const std::string &uri) const
    {
      if (uri == getXmlnsL3V1V1())
      {
        return 3;
      }
      
      return 0;
    }
    
    unsigned int 
    GroupsExtension::getVersion(const std::string &uri) const
    {
      if (uri == getXmlnsL3V1V1())
      {
        return 1;
      }
    
      return 0;
    }
    
    unsigned int
    GroupsExtension::getPackageVersion(const std::string &uri) const
    {
      if (uri == getXmlnsL3V1V1())
      {
        return 1;
      }
    
      return 0;
    }
    
    const std::string& 
    GroupsExtension::getURI(unsigned int sbmlLevel, unsigned int sbmlVersion, unsigned int pkgVersion) const
    {
      if (sbmlLevel == 3)
      {
        if (sbmlVersion == 1)
        {
          if (pkgVersion == 1)
          {
            return getXmlnsL3V1V1();
          }
        }
      }
    
      static std::string empty = "";
    
      return empty;
    }
    
    GroupsExtension* 
    GroupsExtension::clone () const
    {
      return new GroupsExtension(*this);  
    }
    

    Constructor, copy Constructor, and destructor also must be overridden if additional data members are defined in the derived class.

  3. Define typedef and template instantiation code for the package specific SBMLExtensionNamespaces template class

    1. typedef for the package specific SBMLExtensionNamespaces template class

      For example, the typedef for GroupsExtension (defined in the groups package) is implemented in GroupsExtension.h as follows:

        // GroupsPkgNamespaces is derived from the SBMLNamespaces class and used when creating an object of 
        // SBase derived classes defined in groups package.
        typedef SBMLExtensionNamespaces<GroupsExtension> GroupsPkgNamespaces;
      

    2. template instantiation code for the above typedef definition in the implementation file (i.e., *.cpp file).

      For example, the template instantiation code for GroupsExtension is implemented in GroupsExtension.cpp as follows:

        // Instantiate SBMLExtensionNamespaces<GroupsExtension> (GroupsPkgNamespaces) for DLL.
        template class LIBSBML_EXTERN SBMLExtensionNamespaces<GroupsExtension>;
      

    The SBMLExtensionNamespaces template class is a derived class of SBMLNamespaces and can be used as an argument of constructors of SBase derived classes defined in the package extensions. For example, a GroupsPkgNamespaces object can be used when creating a group object as follows:

       GroupPkgNamespaces gpns(3,1,1);  // The arguments are SBML Level, SBML Version, and Groups Package Version.
    
       Group g = new Group(&gpns);      // Creates a group object of L3V1 Groups V1.
    

    Also, the GroupsPkgNamespaces object can be used when creating an SBMLDocument object with the groups package as follows:

       GroupsPkgNamespaces gpns(3,1,1);
       SBMLDocument* doc;
    
       doc  = new SBMLDocument(&gnps); // Creates an SBMLDocument of L3V1 with Groups V1.
    

  4. Override the following pure virtual function which returns the SBMLNamespaces derived object

           virtual SBMLNamespaces* getSBMLExtensionNamespaces (const std::string &uri) const =0
    

    For example, the function is overridden in GroupsExtension class as follows:

    SBMLNamespaces*
    GroupsExtension::getSBMLExtensionNamespaces(const std::string &uri) const
    {
      GroupsPkgNamespaces* pkgns = NULL;
      if ( uri == getXmlnsL3V1V1())
      {
        pkgns = new GroupsPkgNamespaces(3,1,1);    
      }  
      return pkgns;
    }
    

  5. Define an enum type for representing the typecode of elements (SBase extended classes) defined in the package extension

    For example, SBMLGroupsTypeCode_t for groups package is defined in GroupsExtension.h as follows:

          typedef enum
          {
             SBML_GROUPS_GROUP  = 200
           , SBML_GROUPS_MEMBER = 201
          } SBMLGroupsTypeCode_t;
    

    SBML_GROUPS_GROUP corresponds to the Group class (<group>) and SBML_GROUPS_MEMBER corresponds to the Member (<member>) class, respectively.

    Similarly, SBMLLayoutTypeCode_t for layout package is defined in LayoutExtension.h as follows:

          typedef enum
          {
             SBML_LAYOUT_BOUNDINGBOX           = 100
           , SBML_LAYOUT_COMPARTMENTGLYPH      = 101
           , SBML_LAYOUT_CUBICBEZIER           = 102
           , SBML_LAYOUT_CURVE                 = 103
           , SBML_LAYOUT_DIMENSIONS            = 104
           , SBML_LAYOUT_GRAPHICALOBJECT       = 105
           , SBML_LAYOUT_LAYOUT                = 106   
           , SBML_LAYOUT_LINESEGMENT           = 107   
           , SBML_LAYOUT_POINT                 = 108    
           , SBML_LAYOUT_REACTIONGLYPH         = 109    
           , SBML_LAYOUT_SPECIESGLYPH          = 110    
           , SBML_LAYOUT_SPECIESREFERENCEGLYPH = 111
           , SBML_LAYOUT_TEXTGLYPH             = 112
          } SBMLLayoutTypeCode_t;
    

    These enum values are returned by corresponding getTypeCode() functions. (e.g. SBML_GROUPS_GROUP is returned in Group::getTypeCode())

    The value of each typecode can be duplicated between those of different packages (In the above SBMLayoutTypeCode_t and SBMLGroupsTypeCode_t types, unique values are assigned to enum values, but this is not mandatory.)

    Thus, to distinguish the typecodes of different packages, not only the return value of getTypeCode() function but also that of getPackageName() function should be checked as follows:

              void example (const SBase *sb)
              {
                const std::string pkgName = sb->getPackageName();
                if (pkgName == "core") {
                  switch (sb->getTypeCode()) {
                    case SBML_MODEL:
                       ....
                       break;
                    case SBML_REACTION:
                       ....
                  }
                } 
                else if (pkgName == "layout") {
                  switch (sb->getTypeCode()) {
                    case SBML_LAYOUT_LAYOUT:
                       ....
                       break;
                    case SBML_LAYOUT_REACTIONGLYPH:
                       ....
                  }
                } 
                else if (pkgName == "groups") {
                  switch (sb->getTypeCode()) {
                    case SBML_GROUPS_GROUP:
                       ....
                       break;
                    case SBML_GROUPS_MEMBER:
                       ....
                  }
                }
                ...
              } 
    

  6. Override the following pure virtual function which returns a string corresponding to the given typecode:

           virtual const char* SBMLExtension::getStringFromTypeCode(int typeCode) const;
    

    For example, the function for groups extension is implemented as follows:

    static
    const char* SBML_GROUPS_TYPECODE_STRINGS[] =
    {
        "Group"
      , "Member"
    };
    
    const char* 
    GroupsExtension::getStringFromTypeCode(int typeCode) const
    {
      int min = SBML_GROUPS_GROUP;
      int max = SBML_GROUPS_MEMBER;
    
      if ( typeCode < min || typeCode > max)
      {
        return "(Unknown SBML Groups Type)";  
      }
    
      return SBML_GROUPS_TYPECODE_STRINGS[typeCode - min];
    }
    

  7. Implements a "static void init()" function in the derived class

    In the init() function, initialization code which creates an instance of the derived class and registering code which registers the instance to SBMLExtensionRegistry class are implemented.

    For example, the init() function for groups package is implemented as follows:

    void 
    GroupsExtension::init()
    {
      //-------------------------------------------------------------------------
      //
      // 1. Checks if the groups pacakge has already been registered.
      //
      //-------------------------------------------------------------------------
    
      if (SBMLExtensionRegistry::getInstance().isRegistered(getPackageName()))
      {
        // do nothing;
        return;
      }
    
      //-------------------------------------------------------------------------
      //
      // 2. Creates an SBMLExtension derived object.
      //
      //-------------------------------------------------------------------------
    
      GroupsExtension groupsExtension;
    
      //-------------------------------------------------------------------------------------
      //
      // 3. Creates SBasePluginCreatorBase derived objects required for this 
      //    extension. The derived classes can be instantiated by using the following 
      //     template class.
      //
      //    temaplate<class SBasePluginType> class SBasePluginCreator
      //
      //    The constructor of the creator class has two arguments:
      //
      //        (1) SBaseExtensionPoint : extension point to which the plugin object connected
      //        (2) std::vector<std::string> : a std::vector object that contains a list of URI
      //                                       (package versions) supported by the plugin object.
      //
      //    For example, two plugin objects (plugged in SBMLDocument and Model elements) are 
      //    required for the groups extension.
      //
      //    Since only 'required' attribute is used in SBMLDocument by the groups package, and
      //    the 'required' flag must always be 'false', the existing
      //    SBMLDocumentPluginNotRequired class can be used as-is for the plugin.
      //
      //    Since the lists of supported package versions (currently only L3V1-groups-V1 supported )
      //    are equal in the both plugin objects, the same vector object is given to each 
      //    constructor.
      //
      //---------------------------------------------------------------------------------------
    
      std::vector<std::string> packageURIs;
      packageURIs.push_back(getXmlnsL3V1V1());
    
      SBaseExtensionPoint sbmldocExtPoint("core",SBML_DOCUMENT);
      SBaseExtensionPoint modelExtPoint("core",SBML_MODEL);
    
      SBasePluginCreator<SBMLDocumentPluginNotRequired, GroupsExtension> sbmldocPluginCreator(sbmldocExtPoint,packageURIs);
      SBasePluginCreator<GroupsModelPlugin,   GroupsExtension> modelPluginCreator(modelExtPoint,packageURIs);
    
      //--------------------------------------------------------------------------------------
      //
      // 3. Adds the above SBasePluginCreatorBase derived objects to the SBMLExtension derived object.
      //
      //--------------------------------------------------------------------------------------
    
      groupsExtension.addSBasePluginCreator(&sbmldocPluginCreator);
      groupsExtension.addSBasePluginCreator(&modelPluginCreator);
    
      //-------------------------------------------------------------------------
      //
      // 4. Registers the SBMLExtension derived object to SBMLExtensionRegistry
      //
      //-------------------------------------------------------------------------
    
      int result = SBMLExtensionRegistry::getInstance().addExtension(&groupsExtension);
    
      if (result != LIBSBML_OPERATION_SUCCESS)
      {
        std::cerr << "[Error] GroupsExtension::init() failed." << std::endl;
      }
    }
    

  8. Instantiate a global SBMLExtensionRegister variable in appropriate implementation file

    For example, the global variable for the groups extension is instantiated in GroupsExtension.cpp as follows:

      static SBMLExtensionRegister<GroupsExtension> groupsExtensionRegister;
    

    The init() function is invoked when the global variable is instantiated, by which initialization and registering the package extension are performed.

Class to store level, version and namespace information of SBML extension package.

Class to store SBML level, version and namespace information.

This class of objects is defined by libSBML only and has no direct equivalent in terms of SBML components. This class is not prescribed by the SBML specifications, although it is used to implement features defined in SBML.

There are differences in the definitions of components between different SBML Levels, as well as Versions within Levels. For example, the "sboTerm" attribute was not introduced until Level 2 Version 2, and then only on certain component classes; the SBML Level 2 Version 3 specification moved the "sboTerm" attribute to the SBase class, thereby allowing nearly all components to have SBO annotations. As a result of differences such as those, libSBML needs to track the SBML Level and Version of every object created.

The purpose of the SBMLNamespaces object class is to make it easier to communicate SBML Level and Version data between libSBML constructors and other methods. The SBMLNamespaces object class tracks 3-tuples (triples) consisting of SBML Level, Version, and the corresponding SBML XML namespace.

The plural name (SBMLNamespaces) is not a mistake, because in SBML Level 3, objects may have extensions added by Level 3 packages used by a given model and therefore may have multiple namespaces associated with them; however, until the introduction of SBML Level 3, the SBMLNamespaces object only records one SBML Level/Version/namespace combination at a time. Most constructors for SBML objects in libSBML take a SBMLNamespaces object as an argument, thereby allowing the constructor to produce the proper combination of attributes and other internal data structures for the given SBML Level and Version.

typedef class SBMLReader SBMLReader_t

Methods for reading SBML from files and text strings.

This class of objects is defined by libSBML only and has no direct equivalent in terms of SBML components. This class is not prescribed by the SBML specifications, although it is used to implement features defined in SBML.

The SBMLReader class provides the main interface for reading SBML content from files and strings. The methods for reading SBML all return an SBMLDocument object representing the results.

In the case of failures (such as if the SBML contains errors or a file cannot be read), the errors will be recorded with the SBMLErrorLog object kept in the SBMLDocument returned by SBMLReader. Consequently, immediately after calling a method on SBMLReader, callers should always check for errors and warnings using the methods for this purpose provided by SBMLDocument.

For convenience as well as easy access from other languages besides C++, this file also defines two global functions, libsbml::readSBML() and libsbml::readSBMLFromString(). They are equivalent to creating an SBMLReader object and then calling the SBMLReader::readSBML() or SBMLReader::readSBMLFromString() methods, respectively.

Support for writing compressed files

LibSBML provides support for reading (as well as writing) compressed SBML files. The process is transparent to the calling application—the application does not need to do anything deliberate to invoke the functionality. If a given SBML filename ends with an extension for the gzip, zip or bzip2 compression formats (respectively, .gz, .zip, or .bz2), then the methods SBMLReader::readSBML() and SBMLWriter::writeSBML() will automatically decompress and compress the file while writing and reading it. If the filename has no such extension, it will be read and written uncompressed as normal.

The compression feature requires that the zlib (for gzip and zip formats) and/or bzip2 (for bzip2 format) be available on the system running libSBML, and that libSBML was configured with their support compiled-in. Please see the libSBML for more information about this. The methods hasZlib() and hasBzip2() can be used by an application to query at run-time whether support for the compression libraries is available in the present copy of libSBML.

Support for compression is not mandated by the SBML standard, but applications may find it helpful, particularly when large SBML models are being communicated across data links of limited bandwidth.

typedef class SBMLWriter SBMLWriter_t

Methods for writing SBML to files and text strings.

This class of objects is defined by libSBML only and has no direct equivalent in terms of SBML components. This class is not prescribed by the SBML specifications, although it is used to implement features defined in SBML.

The SBMLWriter class is the converse of SBMLReader, and provides the main interface for serializing SBML models into XML and writing the result to files and text strings. The methods for writing SBML all take an SBMLDocument object and a destination. They return a boolean or integer value to indicate success or failure.

Support for writing compressed files

LibSBML provides support for writing (as well as reading) compressed SBML files. The process is transparent to the calling application—the application does not need to do anything deliberate to invoke the functionality. If a given SBML filename ends with an extension for the gzip, zip or bzip2 compression formats (respectively, ".gz", ".zip", or ".bz2"), then the methods SBMLWriter::writeSBML() and SBMLReader::readSBML() will automatically compress and decompress the file while writing and reading it. If the filename has no such extension, it will be written and read uncompressed as normal.

The compression feature requires that the zlib (for gzip and zip formats) and/or bzip2 (for bzip2 format) be available on the system running libSBML, and that libSBML was configured with their support compiled-in. Please see the libSBML for more information about this. The methods SBMLWriter::hasZlib() and SBMLWriter::hasBzip2() can be used by an application to query at run-time whether support for the compression libraries is available in the present copy of libSBML.

Support for compression is not mandated by the SBML standard, but applications may find it helpful, particularly when large SBML models are being communicated across data links of limited bandwidth.

typedef class Species Species_t

Implementation of SBML's Species construct.

A species in SBML refers to a pool of entities that (a) are considered indistinguishable from each other for the purposes of the model, (b) participate in reactions, and (c) are located in a specific compartment. The SBML Species object class is intended to represent these pools.

As with other major constructs in SBML, Species has a mandatory attribute, "id", used to give the species type an identifier in the model. The identifier must be a text string conforming to the identifer syntax permitted in SBML. Species also has an optional "name" attribute, of type string. The "id" and "name" must be used according to the guidelines described in the SBML specifications.

The required attribute "compartment" is used to identify the compartment in which the species is located. The attribute's value must be the identifier of an existing Compartment object. It is important to note that there is no default value for the "compartment" attribute on Species; every species in an SBML model must be assigned a compartment explicitly. (This also implies that every model with one or more Species objects must define at least one Compartment object.)

The initial amount and concentration of a species

The optional attributes "initialAmount" and "initialConcentration", both having a data type of double, can be used to set the initial quantity of the species in the compartment where the species is located. These attributes are mutually exclusive; i.e., only one can have a value on any given instance of a Species object. Missing "initialAmount" and "initialConcentration" values implies that their values either are unknown, or to be obtained from an external source, or determined by an InitialAssignment or other SBML construct elsewhere in the model.

A species' initial quantity in SBML is set by the "initialAmount" or "initialConcentration" attribute exactly once. If the "constant" attribute is true, then the value of the species' quantity is fixed and cannot be changed except by an InitialAssignment. These methods differ in that the "initialAmount" and "initialConcentration" attributes can only be used to set the species quantity to a literal floating-point number, whereas the use of an InitialAssignment object allows the value to be set using an arbitrary mathematical expression (which, thanks to MathML's expressiveness, may evaluate to a rational number). If the species' "constant" attribute is false, the species' quantity value may be overridden by an InitialAssignment or changed by AssignmentRule or AlgebraicRule, and in addition, for t > 0, it may also be changed by a RateRule, Event objects, and as a result of being a reactant or product in one or more Reaction objects. (However, some constructs are mutually exclusive; see the SBML specifications for the precise details.) It is not an error to define "initialAmount" or "initialConcentration" on a species and also redefine the value using an InitialAssignment, but the "initialAmount" or "initialConcentration" setting in that case is ignored. The SBML specifications provide additional information about the semantics of assignments, rules and values for simulation time t $\leq$ 0.

SBML Level 2 additionally stipulates that in cases where a species' compartment has a "spatialDimensions" value of 0 (zero), the species cannot have a value for "initialConcentration" because the concepts of concentration and density break down when a container has zero dimensions.

The units of a species' amount or concentration

When the attribute "initialAmount" is set, the unit of measurement associated with the value of "initialAmount" is specified by the Species attribute "substanceUnits". When the "initialConcentration" attribute is set, the unit of measurement associated with this concentration value is {unit of amount} divided by {unit of size}, where the {unit of amount} is specified by the Species "substanceUnits" attribute, and the {unit of size} is specified by the "units" attribute of the Compartment object in which the species is located. Note that in either case, a unit of amount is involved and determined by the "substanceUnits" attribute. Note these two attributes alone do not determine the units of the species when the species identifier appears in a mathematical expression; that aspect is determined by the attribute "hasOnlySubstanceUnits" discussed below.

In SBML Level 3, if the "substanceUnits" attribute is not set on a given Species object instance, then the unit of amount for that species is inherited from the "substanceUnits" attribute on the enclosing Model object instance. If that attribute on Model is not set either, then the unit associated with the species' quantity is undefined.

In SBML Level 2, if the "substanceUnits" attribute is not set on a given Species object instance, then the unit of amount for that species is taken from the predefined SBML unit identifier "substance". The value assigned to "substanceUnits" must be chosen from one of the following possibilities: one of the base unit identifiers defined in SBML, the built-in unit identifier "substance", or the identifier of a new unit defined in the list of unit definitions in the enclosing Model object. The chosen units for "substanceUnits" must be be "dimensionless", "mole", "item", "kilogram", "gram", or units derived from these.

As noted at the beginning of this section, simply setting "initialAmount" or "initialConcentration" alone does not determine whether a species identifier represents an amount or a concentration when it appears elsewhere in an SBML model. The role of the attribute "hasOnlySubstanceUnits" is to indicate whether the units of the species, when the species identifier appears in mathematical formulas, are intended to be concentration or amount. The attribute takes on a boolean value. In SBML Level 3, the attribute has no default value and must always be set in a model; in SBML Level 2, it has a default value of false.

The units of the species are used in the following ways:

  • When the species' identifier appears in a MathML formula, it represents the species' quantity, and the unit of measurement associated with the quantity is as described above.

  • The "math" elements of AssignmentRule, InitialAssignment and EventAssignment objects referring to this species should all have the same units as the unit of measurement associated with the species quantity.

  • In a RateRule object that defines the rate of change of the species' quantity, the unit associated with the rule's "math" element should be equal to the unit of the species' quantity divided by the model-wide unit of time; in other words, {unit of species quantity}/{unit of time}.

The "constant" and "boundaryCondition" attributes

The Species object class has two boolean attributes named "constant" and "boundaryCondition", used to indicate whether and how the quantity of that species can vary during a simulation. In SBML Level 2 they are optional; in SBML Level 3 they are mandatory. The following table shows how to interpret the combined values of these attributes.

Interpretation of species' constant and boundaryCondition attributes.
constant
value
boundaryCondition
value
Can have
assignment
or rate rule?
Can be
reactant
or product?
Species' quantity
can be changed by
true true no yes (never changes)
false true yes yes rules and events
true false no no (never changes)
false false yes yes reactions or rules (but not both at the same time), and events

By default, when a species is a product or reactant of one or more reactions, its quantity is determined by those reactions. In SBML, it is possible to indicate that a given species' quantity is not determined by the set of reactions even when that species occurs as a product or reactant; i.e., the species is on the boundary of the reaction system, and its quantity is not determined by the reactions. The boolean attribute "boundaryCondition" can be used to indicate this. A value of false indicates that the species is part of the reaction system. In SBML Level 2, the attribute has a default value of false, while in SBML Level 3, it has no default.

The "constant" attribute indicates whether the species' quantity can be changed at all, regardless of whether by reactions, rules, or constructs other than InitialAssignment. A value of false indicates that the species' quantity can be changed. (This is also a common value because the purpose of most simulations is precisely to calculate changes in species quantities.) In SBML Level 2, the attribute has a default value of false, while in SBML Level 3, it has no default. Note that the initial quantity of a species can be set by an InitialAssignment irrespective of the value of the "constant" attribute.

In practice, a "boundaryCondition" value of true means a differential equation derived from the reaction definitions should not be generated for the species. However, the species' quantity may still be changed by AssignmentRule, RateRule, AlgebraicRule, Event, and InitialAssignment constructs if its "constant" attribute is false. Conversely, if the species' "constant" attribute is true, then its value cannot be changed by anything except InitialAssignment.

A species having "boundaryCondition"=false and "constant"=false can appear as a product and/or reactant of one or more reactions in the model. If the species is a reactant or product of a reaction, it must not also appear as the target of any AssignmentRule or RateRule object in the model. If instead the species has "boundaryCondition"=false and "constant"=true, then it cannot appear as a reactant or product, or as the target of any AssignmentRule, RateRule or EventAssignment object in the model.

The conversionFactor attribute in SBML Level 3

In SBML Level 3, Species has an additional optional attribute, "conversionFactor", that defines a conversion factor that applies to a particular species. The value must be the identifier of a Parameter object instance defined in the model. That Parameter object must be a constant, meaning its "constant" attribute must be set to true. If a given Species object definition defines a value for its "conversionFactor" attribute, it takes precedence over any factor defined by the Model object's "conversionFactor" attribute.

The unit of measurement associated with a species' quantity can be different from the unit of extent of reactions in the model. SBML Level 3 avoids implicit unit conversions by providing an explicit way to indicate any unit conversion that might be required. The use of a conversion factor in computing the effects of reactions on a species' quantity is explained in detail in the SBML Level 3 specification document. Because the value of the "conversionFactor" attribute is the identifier of a Parameter object, and because parameters can have units attached to them, the transformation from reaction extent units to species units can be completely specified using this approach.

Note that the unit conversion factor is only applied when calculating the effect of a reaction on a species. It is not used in any rules or other SBML constructs that affect the species, and it is also not used when the value of the species is referenced in a mathematical expression.

The speciesType attribute in SBML Level 2 Versions 2–4

In SBML Level 2 Versions 2–4, each species in a model may optionally be designated as belonging to a particular species type. The optional attribute "speciesType" is used to identify the species type of the chemical entities that make up the pool represented by the Species objects. The attribute's value must be the identifier of an existing SpeciesType object in the model. If the "speciesType" attribute is not present on a particular species definition, it means the pool contains chemical entities of a type unique to that pool; in effect, a virtual species type is assumed for that species, and no other species can belong to that species type. The value of "speciesType" attributes on species have no effect on the numerical interpretation of a model; simulators and other numerical analysis software may ignore "speciesType" attributes.

There can be only one species of a given species type in any given compartment of a model. More specifically, for all Species objects having a value for the "speciesType" attribute, the pair

("speciesType" attribute value, "compartment" attribute value)

must be unique across the set of all Species object in a model.

The spatialSizeUnits attribute in SBML Level 2 Versions 1–2

In versions of SBML Level 2 before Version 3, the class Species included an attribute called "spatialSizeUnits", which allowed explicitly setting the units of size for initial concentration. LibSBML retains this attribute for compatibility with older definitions of Level 2, but its use is strongly discouraged because many software tools do no properly interpret this unit declaration and it is incompatible with all SBML specifications after Level 2 Version 3.

Additional considerations for interpreting the numerical value of a species

Species are unique in SBML in that they have a kind of duality: a species identifier may stand for either substance amount (meaning, a count of the number of individual entities) or a concentration or density (meaning, amount divided by a compartment size). The previous sections explain the meaning of a species identifier when it is referenced in a mathematical formula or in rules or other SBML constructs; however, it remains to specify what happens to a species when the compartment in which it is located changes in size.

When a species definition has a "hasOnlySubstanceUnits" attribute value of false and the size of the compartment in which the species is located changes, the default in SBML is to assume that it is the concentration that must be updated to account for the size change. This follows from the principle that, all other things held constant, if a compartment simply changes in size, the size change does not in itself cause an increase or decrease in the number of entities of any species in that compartment. In a sense, the default is that the amount of a species is preserved across compartment size changes. Upon such size changes, the value of the concentration or density must be recalculated from the simple relationship concentration = amount / size if the value of the concentration is needed (for example, if the species identifier appears in a mathematical formula or is otherwise referenced in an SBML construct). There is one exception: if the species' quantity is determined by an AssignmentRule, RateRule, AlgebraicRule, or an EventAssignment and the species has a "hasOnlySubstanceUnits" attribute value of false, it means that the concentration is assigned by the rule or event; in that case, the amount must be calculated when the compartment size changes. (Events also require additional care in this situation, because an event with multiple assignments could conceivably reassign both a species quantity and a compartment size simultaneously. Please refer to the SBML specifications for the details.)

Note that the above only matters if a species has a "hasOnlySubstanceUnits" attribute value of false, meaning that the species identifier refers to a concentration wherever the identifier appears in a mathematical formula. If instead the attribute's value is true, then the identifier of the species always stands for an amount wherever it appears in a mathematical formula or is referenced by an SBML construct. In that case, there is never a question about whether an assignment or event is meant to affect the amount or concentration: it is always the amount.

A particularly confusing situation can occur when the species has "constant" attribute value of true in combination with a "hasOnlySubstanceUnits" attribute value of false. Suppose this species is given a value for "initialConcentration". Does a "constant" value of true mean that the concentration is held constant if the compartment size changes? No; it is still the amount that is kept constant across a compartment size change. The fact that the species was initialized using a concentration value is irrelevant.

In C, a SpeciesReference_t is actually a synonym for the SimpleSpeciesReference base class.

typedef class SpeciesType SpeciesType_t

Implementation of SBML Level 2's SpeciesType construct.

The term species type refers to reacting entities independent of location. These include simple ions (e.g., protons, calcium), simple molecules (e.g., glucose, ATP), large molecules (e.g., RNA, polysaccharides, and proteins), and others.

SBML Level 2 Versions 2–4 provide an explicit SpeciesType class of object to enable Species objects of the same type to be related together. SpeciesType is a conceptual construct; the existence of SpeciesType objects in a model has no effect on the model's numerical interpretation. Except for the requirement for uniqueness of species/species type combinations located in compartments, simulators and other numerical analysis software may ignore SpeciesType definitions and references to them in a model.

There is no mechanism in SBML Level 2 for representing hierarchies of species types. One SpeciesType object cannot be the subtype of another SpeciesType object; SBML provides no means of defining such relationships.

As with other major structures in SBML, SpeciesType has a mandatory attribute, "id", used to give the species type an identifier. The identifier must be a text string conforming to the identifer syntax permitted in SBML. SpeciesType also has an optional "name" attribute, of type string. The "id" and "name" must be used according to the guidelines described in the SBML specification (e.g., Section 3.3 in the Level 2 Version 4 specification).

SpeciesType was introduced in SBML Level 2 Version 2. It is not available in SBML Level 1 nor in Level 3.

See Also
Species
ListOfSpeciesTypes
CompartmentType
ListOfCompartmentTypes

Implementation of SBML Level 2's StoichiometryMath construct.

Stoichiometries in SBML Level 2

In SBML Level 2, product and reactant stoichiometries can be specified using either the "stoichiometry" attribute or a "stoichiometryMath" element in a SpeciesReference object. The "stoichiometry" attribute is of type double and should contain values greater than zero (0). The "stoichiometryMath" element is implemented as an element containing a MathML expression. These two are mutually exclusive; only one of "stoichiometry" or "stoichiometryMath" should be defined in a given SpeciesReference instance. When neither the attribute nor the element is present, the value of "stoichiometry" in the enclosing SpeciesReference instance defaults to 1.

For maximum interoperability, SpeciesReference's "stoichiometry" attribute should be used in preference to "stoichiometryMath" when a species' stoichiometry is a simple scalar number (integer or decimal). When the stoichiometry is a rational number, or when it is a more complicated formula, "stoichiometryMath" must be used. The MathML expression in "stoichiometryMath" may also refer to identifiers of entities in a model (except reaction identifiers). However, the only species identifiers that can be used in "stoichiometryMath" are those referenced in the enclosing Reaction's list of reactants, products and modifiers.

The "stoichiometry" attribute and the "stoichiometryMath" element, when either is used, is each interpreted as a factor applied to the reaction rate to produce the rate of change of the species identified by the "species" attribute in the enclosing SpeciesReference. This is the normal interpretation of a stoichiometry, but in SBML, one additional consideration has to be taken into account. The reaction rate, which is the result of the KineticLaw's "math" element, is always in the model's substance per time units. However, the rate of change of the species will involve the species' substance units (i.e., the units identified by the Species object's "substanceUnits" attribute), and these units may be different from the model's default substance units. If the units are different, the stoichiometry must incorporate a conversion factor for converting the model's substance units to the species' substance units. The conversion factor is assumed to be included in the scalar value of the "stoichiometry" attribute if "stoichiometry" is used. If instead "stoichiometryMath" is used, then the product of the model's "substance" units times the "stoichiometryMath" units must match the substance units of the species. Note that in either case, if the species' units and the model's default substance units are the same, the stoichiometry ends up being a dimensionless number and equivalent to the standard chemical stoichiometry found in textbooks. Examples and more explanations of this are given in the SBML specification.

The following is a simple example of a species reference for species "X0", with stoichiometry 2, in a list of reactants within a reaction having the identifier "J1":

<model>
    ...
    <listOfReactions>
        <reaction id="J1">
            <listOfReactants>
                <speciesReference species="X0" stoichiometry="2">
            </listOfReactants>
            ...
        </reaction>
        ...
    </listOfReactions>
    ...
</model>

The following is a more complex example of a species reference for species "X0", with a stoichiometry formula consisting of a rational number:

<model>
    ...
    <listOfReactions>
        <reaction id="J1">
            <listOfReactants>
                <speciesReference species="X0">
                    <stoichiometryMath>
                        <math xmlns="http://www.w3.org/1998/Math/MathML"> 
                            <cn type="rational"> 3 <sep/> 2 </cn>
                        </math>
                    </stoichiometryMath>
                </speciesReference>
            </listOfReactants>
            ...
        </reaction>
        ...
    </listOfReactions>
    ...
</model>

Additional discussions of stoichiometries and implications for species and reactions are included in the documentation of SpeciesReference class.

Stoichiometries in SBML Level 3

The StoichiometryMath construct is not defined in SBML Level 3 Version 1 Core. Instead, Level 3 defines the identifier of SpeciesReference objects as a stand-in for the stoichiometry of the reactant or product being referenced, and allows that identifier to be used elsewhere in SBML models, including (for example) InitialAssignment objects. This makes it possible to achieve the same effect as StoichiometryMath, but with other SBML objects. For instance, to produce a stoichiometry value that is a rational number, a model can use InitialAssignment to assign the identifier of a SpeciesReference object to a MathML expression evaluating to a rational number. This is analogous to the same way that, in Level 2, the model would use StoichiometryMath with a MathML expression evaluating to a rational number.

In SBML Level 2, the stoichiometry of a reactant or product is a combination of both a biochemical stoichiometry (meaning, the standard stoichiometry of a species in a reaction) and any necessary unit conversion factors. The introduction of an explicit attribute on the Species object for a conversion factor allows Level 3 to avoid having to overload the meaning of stoichiometry. In Level 3, the stoichiometry given by a SpeciesReference object in a reaction is a "proper" biochemical stoichiometry, meaning a dimensionless number free of unit conversions.

See Also
SpeciesReference
Reaction
typedef class Trigger Trigger_t

Implementation of SBML's Trigger construct for Event.

An Event object defines when the event can occur, the variables that are affected by the event, and how the variables are affected. The Trigger construct in SBML is used to define a mathematical expression that determines when an Event is triggered.

A Trigger object in SBML Level 2 and Level 3 contains one subelement named "math" containing a MathML expression. The expression must evaluate to a value of type boolean. The exact moment at which the expression evaluates to true is the time point when the Event is triggered. In SBML Level 3, Trigger has additional attributes that must be assigned values; they are discussed in a separate section below.

An event only triggers when its Trigger expression makes the transition in value from false to true. The event will also trigger at any subsequent time points when the trigger makes this transition; in other words, an event can be triggered multiple times during a simulation if its trigger condition makes the transition from false to true more than once. In SBML Level 3, the behavior at the very start of simulation (i.e., at t = 0, where t stands for time) is determined in part by the boolean flag "initialValue". This and other additional features introduced in SBML Level 3 are discussed further below.

Version differences

SBML Level 3 Version 1 introduces two required attributes on the Trigger object: "persistent" and "initialValue". The rest of this introduction describes these two attributes.

The "persistent" attribute on Trigger

In the interval between when an Event object triggers (i.e., its Trigger object expression transitions in value from false to true) and when its assignments are to be executed, conditions in the model may change such that the trigger expression transitions back from true to false. Should the event's assignments still be made if this happens? Answering this question is the purpose of the "persistent" attribute on Trigger.

If the boolean attribute "persistent" has a value of true, then once the event is triggered, all of its assignments are always performed when the time of execution is reached. The name persistent is meant to evoke the idea that the trigger expression does not have to be re-checked after it triggers if "persistent"=true. Conversely, if the attribute value is false, then the trigger expression is not assumed to persist: if the expression transitions in value back to false at any time between when the event triggered and when it is to be executed, the event is no longer considered to have triggered and its assignments are not executed. (If the trigger expression transitions once more to true after that point, then the event is triggered, but this then constitutes a whole new event trigger-and-execute sequence.)

The "persistent" attribute can be especially useful when Event objects contain Delay objects, but it is relevant even in a model without delays if the model contains two or more events. As explained in the introduction to this section, the operation of all events in SBML (delayed or not) is conceptually divided into two phases, triggering and execution; however, unless events have priorities associated with them, SBML does not mandate a particular ordering of event execution in the case of simultaneous events. Models with multiple events can lead to situations where the execution of one event affects another event's trigger expression value. If that other event has "persistent"=false, and its trigger expression evaluates to false before it is to be executed, the event must not be executed after all.

The "initialValue" attribute on Trigger

As mentioned above, an event triggers when the mathematical expression in its Trigger object transitions in value from false to true. An unanswered question concerns what happens at the start of a simulation: can event triggers make this transition at t = 0, where t stands for time?

In order to determine whether an event may trigger at t = 0, it is necessary to know what value the Trigger object's "math" expression had immediately prior to t = 0. This starting value of the trigger expression is determined by the value of the boolean attribute "initialValue". A value of true means the trigger expression is taken to have the value true immediately prior to t = 0. In that case, the trigger cannot transition in value from false to true at the moment simulation begins (because it has the value true both before and after t = 0), and can only make the transition from false to true sometime after t = 0. (To do that, it would also first have to transition to false before it could make the transition from false back to true.) Conversely, if "initialValue"=false, then the trigger expression is assumed to start with the value false, and therefore may trigger at t = 0 if the expression evaluates to true at that moment.

See Also
Event
Delay
EventAssignment
typedef class Unit Unit_t

Implementation of SBML's Unit construct.

The SBML unit definition facility uses two classes of objects, UnitDefinition and Unit. The approach to defining units in SBML is compositional; for example, meter second –2 is constructed by combining a Unit object representing meter with another Unit object representing second –2. The combination is wrapped inside a UnitDefinition, which provides for assigning an identifier and optional name to the combination. The identifier can then be referenced from elsewhere in a model. Thus, the UnitDefinition class is the container, and Unit instances are placed inside UnitDefinition instances.

A Unit structure has four attributes named "kind", "exponent", "scale" and "multiplier". It represents a (possibly transformed) reference to a base unit. The attribute "kind" on Unit indicates the chosen base unit. Its value must be one of the text strings listed below; this list corresponds to SBML Level 3 Version 1 Core:

amperefaradjouleluxradianvolt
avogadrogramkatalmetresecondwatt
becquerelgraykelvinmolesiemensweber
candelahenrykilogramnewtonsievert
coulombhertzlitreohmsteradian
dimensionlessitemlumenpascaltesla

A few small differences exist between the Level 3 list of base units and the list defined in other Level/Version combinations of SBML. Specifically, Levels of SBML before Level 3 do not define avogadro; conversely, Level 2 Version 1 defines Celsius, and Level 1 defines celsius, meter, and liter, none of which are available in Level 3. In libSBML, each of the predefined base unit names is represented by an enumeration value whose name begins with the characters UNIT_KIND_, discussed in a separate section below.

The attribute named "exponent" on Unit represents an exponent on the unit. In SBML Level 2, the attribute is optional and has a default value of 1 (one); in SBML Level 3, the attribute is mandatory and there is no default value. A Unit structure also has an attribute called "scale"; its value must be an integer exponent for a power-of-ten multiplier used to set the scale of the unit. For example, a unit having a "kind" value of gram and a "scale" value of -3 signifies 10 –3 $\times$ gram, or milligrams. In SBML Level 2, the attribute is optional and has a default value of 0 (zero), because 10 0 = 1; in SBML Level 3, the attribute is mandatory and has no default value. Lastly, the attribute named "multiplier" can be used to multiply the unit by a real-numbered factor; this enables the definition of units that are not power-of-ten multiples of SI units. For instance, a multiplier of 0.3048 could be used to define foot as a measure of length in terms of a metre. The "multiplier" attribute is optional in SBML Level 2, where it has a default value of 1 (one); in SBML Level 3, the attribute is mandatory and has not default value.

Unit identification codes

As discussed above, SBML defines a set of base units which serves as the starting point for new unit definitions. This set of base units consists of the SI units and a small number of additional convenience units.

As a consequence of the fact that libSBML supports models in all Levels and Versions of SBML, libSBML's set of UNIT_KIND_ values is a union of all the possible base unit names defined in the different SBML specifications. However, not every base unit is allowed in every Level+Version combination of SBML. Note in particular the following exceptions:

  • The alternate spelling "meter" is included in addition to the official SI spelling "metre". This spelling is only permitted in SBML Level 1 models.

  • The alternate spelling "liter" is included in addition to the official SI spelling "litre". This spelling is only permitted in SBML Level 1 models.

  • The unit "Celsius" is included because of its presence in specifications of SBML prior to SBML Level 2 Version 3.

  • The unit avogadro was introduced in SBML Level 3, and is only permitted for use in SBML Level 3 models.

The table below lists the unit constants defined in libSBML, and their meanings.

Enumerator Meaning
UNIT_KIND_AMPEREThe ampere unit.
UNIT_KIND_AVOGADROThe unit dimensionless multiplied by the numerical value of Avogadro's constant. (Only usable in SBML Level 3 models.)
UNIT_KIND_BECQUERELThe becquerel unit.
UNIT_KIND_CANDELAThe candela unit.
UNIT_KIND_CELSIUSThe Celsius unit. (Only usable in SBML Level 1 and SBML Level 2 Version 1 models.)
UNIT_KIND_COULOMBThe coulomb unit.
UNIT_KIND_DIMENSIONLESSA pseudo-unit indicating a dimensionless quantity.
UNIT_KIND_FARADThe farad unit.
UNIT_KIND_GRAMThe gram unit.
UNIT_KIND_GRAYThe gray unit.
UNIT_KIND_HENRYThe henry unit.
UNIT_KIND_HERTZThe hertz unit.
UNIT_KIND_ITEMA pseudo-unit representing a single "thing".
UNIT_KIND_JOULEThe joule unit.
UNIT_KIND_KATALThe katal unit.
UNIT_KIND_KELVINThe kelvin unit.
UNIT_KIND_KILOGRAMThe kilogram unit.
UNIT_KIND_LITERAlternate spelling of litre.
UNIT_KIND_LITREThe litre unit.
UNIT_KIND_LUMENThe lumen unit.
UNIT_KIND_LUXThe lux unit.
UNIT_KIND_METERAlternate spelling of metre.
UNIT_KIND_METREThe metre unit.
UNIT_KIND_MOLEThe mole unit.
UNIT_KIND_NEWTONThe newton unit.
UNIT_KIND_OHMThe ohm unit.
UNIT_KIND_PASCALThe pascal unit.
UNIT_KIND_RADIANThe radian unit.
UNIT_KIND_SECONDThe second unit.
UNIT_KIND_SIEMENSThe siemens unit.
UNIT_KIND_SIEVERTThe sievert unit.
UNIT_KIND_STERADIANThe steradian unit.
UNIT_KIND_TESLAThe tesla unit.
UNIT_KIND_VOLTThe volt unit.
UNIT_KIND_WATTThe watt unit.
UNIT_KIND_WEBERThe weber unit.
UNIT_KIND_INVALIDMarker used by libSBML to indicate an invalid or unset unit.

Implementation of SBML's UnitDefinition construct.

Units of measurement may be supplied in a number of contexts in an SBML model. The SBML unit definition facility uses two classes of objects, UnitDefinition and Unit. The approach to defining units in SBML is compositional; for example, meter second –2 is constructed by combining a Unit object representing meter with another Unit object representing second –2. The combination is wrapped inside a UnitDefinition, which provides for assigning an identifier and optional name to the combination. The identifier can then be referenced from elsewhere in a model. Thus, the UnitDefinition class is the container, and Unit instances are placed inside UnitDefinition instances.

Two points are worth discussing in the context of SBML units. First, unit declarations in SBML models are optional. The consequence of this is that a model must be numerically self-consistent independently of unit declarations, for the benefit of software tools that cannot interpret or manipulate units. Unit declarations in SBML are thus more akin to a type of annotation; they can indicate intentions, and can be used by model readers for checking the consistency of the model, labeling simulation output, etc., but any transformations of values implied by different units must be incorporated explicitly into a model.

Second, the vast majority of situations that require new SBML unit definitions involve simple multiplicative combinations of base units and factors. An example is moles per litre per second. What distinguishes these sorts of unit definitions from more complex ones is that they may be expressed without the use of an additive offset from a zero point. The use of offsets complicates all unit definition systems, yet in the domain of SBML, the real-life cases requiring offsets are few (and in fact, to the best of our knowledge, only involve temperature). Consequently, the SBML unit system has been consciously designed to simplify implementation of unit support for the most common cases in systems biology. The cost of this simplification is to require units with offsets to be handled explicitly by the modeler.

Summary of the UnitDefinition construct

UnitDefinition has two attributes and one subelement. The two attributes are "id" and "name", and the subelement is ListOfUnits.

The required attribute "id" and optional attribute "name" are both strings. The "id" attribute is used to give the defined unit a unique identifier by which other parts of an SBML model definition can refer to it. The "name" attribute is intended to be used for giving the unit definition an optional human-readable name. Please see the next section for information about the values permitted for "id".

A UnitDefinition must contain exactly one ListOfUnits, and this list must contain one or more Unit definitions; see the definitions of these other object classes for more information about them. The following example illustrates a complete unit definition (when written in XML) when they all the pieces are combined together. This defines "mmls" to be millimoles per litre per second.

<listOfUnitDefinitions>
    <unitDefinition id="mmls">
        <listOfUnits>
            <unit kind="mole"   scale="-3"/>
            <unit kind="litre"  exponent="-1"/>
            <unit kind="second" exponent="-1"/>
        </listOfUnits>
    </unitDefinition>
</listOfUnitDefinitions>

Special considerations for Unit object identifiers

The attribute "id" in UnitDefinition cannot be given simply any value, and the precise details of the values permitted differ slightly between Levels of SBML:

  • The "id" of a UnitDefinition must not contain a value from the list of SBML's predefined base unit names (i.e., the strings gram, litre, etc.). In SBML Level 3, this list consists of the following:

    amperefaradjouleluxradianvolt
    avogadrogramkatalmetresecondwatt
    becquerelgraykelvinmolesiemensweber
    candelahenrykilogramnewtonsievert
    coulombhertzlitreohmsteradian
    dimensionlessitemlumenpascaltesla

    This list of predefined base units is nearly identical in SBML Level 2 Version 4, the exception being that Level 2 does not define avogadro. SBML Level 2 Version 1 (and only this Level+Version combination) provides an additional predefined unit name, Celsius, not available in Level 3. Finally, SBML Level 1 Versions 2–3 provide two more additional predefined unit names, meter and liter. This is explained in somewhat greater detail in the description of the Unit class.

  • In SBML Level 2 (all Versions), there is an additional set of reserved identifiers: substance, volume, area, length, and time. Using one of these values for the attribute "id" of a UnitDefinition has the effect of redefining the model-wide default units for the corresponding quantities. The list of special unit names in SBML Level 2 is given in the table below:

    Identifier Possible scalable units Default units
    substancemole, item, gram, kilogram, dimensionlessmole
    volumelitre, cubic metre, dimensionlesslitre
    areasquare metre, dimensionlesssquare metre
    lengthmetre, dimensionlessmetre
    timesecond, dimensionlesssecond

    Also, SBML Level 2 imposes two limitations on redefining the predefined unit substance, volume, area, length, and time: (1) The UnitDefinition of a predefined SBML unit can only contain a single Unit object within it. (2) The value of the "kind" attribute in a Unit instance must be drawn from one of the values in the second column of the table above.

    The special unit names substance, volume, area, length, and time are not defined by SBML Level 3, which uses a different approach to setting model-wide inherited units.

Further comments about SBML's unit definition system

The vast majority of modeling situations requiring new SBML unit definitions involve simple multiplicative combinations of base units and factors. An example of this might be moles per litre per second. What distinguishes these sorts of simpler unit definitions from more complex ones is that they may be expressed without the use of an additive offset from a zero point. The use of offsets complicates all unit definition systems, yet in the domain of SBML the real-life cases requiring offsets are few (and in fact, to the best of our knowledge, only involve temperature). Consequently, the SBML unit system has been consciously designed in a way that attempts to simplify implementation of unit support for the most common cases in systems biology.

As of SBML Level 2 Version 2, Unit no longer has the attribute called "offset" introduced in SBML Level 2 Version 1. It turned out that the general case involving units with offsets was incorrectly defined, and few (if any) developers even attempted to support offset-based units in their software. In the development of Level 2 Version 2, a consensus among SBML developers emerged that a fully generalized unit scheme is so confusing and complicated that it actually impedes interoperability. SBML Level 2 Version 2, Version 3 and Version 4 acknowledge this reality by reducing and simplifying the unit system, specifically by removing the "offset" attribute on Unit and Celsius as a pre-defined unit.

The following guidelines suggest methods for handling units that do require the use of zero offsets for their definitions:

  • Handling Celsius. A model in which certain quantities are temperatures measured in degrees Celsius can be converted straightforwardly to a model in which those temperatures are in kelvin. A software tool could do this by performing a straightforward substitution using the following relationship: T kelvin = TCelsius + 273.15. In every mathematical formula of the model where a quantity (call it x) in degrees Celsius appears, replace x with xk+ 273.15, where xk is now in kelvin. An alternative approach would be to use a FunctionDefinition object to define a function encapsulating this relationship above and then using that in the rest of the model as needed. Since Celsius is a commonly-used unit, software tools could help users by providing users with the ability to express temperatures in Celsius in the tools' interfaces, and making substitutions automatically when writing out the SBML.

  • Other units requiring offsets. One approach to handling other kinds of units is to use a FunctionDefinition to define a function encapsulating the necessary mathematical relationship, then substituting a call to this function wherever the original quantity appeared in the model. For example, here is a possible definition for converting Fahrenheit to Celsius degrees:

    <functionDefinition id="Fahrenheit_to_kelvin">
        <math xmlns="http://www.w3.org/1998/Math/MathML">
            <lambda>
                <bvar><ci> temp_in_fahrenheit </ci></bvar>
                <apply>
                    <divide/>
                    <apply>
                        <plus/>
                        <ci> temp_in_fahrenheit </ci>
                        <cn> 459.67 </cn>
                    </apply>
                    <cn> 1.8 </cn>
                </apply>
            </lambda>
        </math>
    </functionDefinition>
    

  • An alternative approach not requiring the use of function definitions is to use an AssignmentRule for each variable in Fahrenheit units. The AssignmentRule could compute the conversion from Fahrenheit to (say) kelvin, assign its value to a variable (in Kelvin units), and then that variable could be used elsewhere in the model.

  • Still another approach is to rewrite the mathematical formulas of a model to directly incorporate the conversion formula wherever the original quantity appeared.

Please consult the SBML specifications for more information about this and other issues involving units.

Representation of attributes on an XML node.

This class of objects is defined by libSBML only and has no direct equivalent in terms of SBML components. This class is not prescribed by the SBML specifications, although it is used to implement features defined in SBML.

typedef class XMLError XMLError_t

Representation of errors, warnings and other diagnostics.

This class of objects is defined by libSBML only and has no direct equivalent in terms of SBML components. This class is not prescribed by the SBML specifications, although it is used to implement features defined in SBML.

LibSBML can be configured to use any of a number of XML parsers; at the time of this writing, libSBML supports Xerces versions 2.4 through 3.1, Expat version 1.95.x and higher, and libxml2 version 2.6.16 and higher. These parsers each report different status codes for the various exceptions that can occur during XML processing. The XMLError object class abstracts away from the particular diagnostics reported by the different parsers and presents a single uniform interface and set of status codes, along with operations for manipulating the error objects.

When the libSBML XML parser layer encounters an error in the XML content being processed, or when there is something else wrong (such as an out-of-memory condition), the problems are reported as XMLError objects. Each XMLError object instance has an identification number that identifies the nature of the problem. This error identifier is one of the constants listed in the next section below. Applications can use the error identifiers as a means of recognizing the error encountered and changing their behavior if desired.

Integer error codes are useful for software, but not so much for telling humans what happened. For this reason, XMLError also provides two text messages describing the nature of the error. These messages are accessible by means of the methods XMLError::getShortMessage() and XMLError::getMessage(). The method XMLError::getShortMessage() returns a very brief synopsis of the warning or error condition, whereas XMLError::getMessage() returns a longer explanation. These text strings are suitable for displaying to human users.

Each XMLError object also contains a category code; its value may be retrieved using the method XMLError::getCategory(). Category values are drawn from a set of constants whose names begin with the characters LIBSBML_CAT_, described below.  Categories are used by libSBML to provide more information to calling programs about the nature of a given error.

In addition to category codes, each XMLError object also has a severity code; its value may be retrieved using the method XMLError::getSeverity(). Severity code values are drawn from a set of constants whose names begin with the characters LIBSBML_SEV_, described below. Severity levels range from informational (LIBSBML_SEV_INFO) to fatal errors (LIBSBML_SEV_FATAL).

Finally, XMLError objects record the line and column near where the problem occurred in the XML content. The values can be retrieved using the methods XMLError::getLine() and XMLError::getColumn(). We say "near where the problem occurred", because many factors affect how accurate the line/column information ultimately is. For example, sometimes, the underlying XML parsers can only report such information for the parent XML element where an error occurs, and not for the specific point where the problem occurs. In other situations, some parsers report invalid line and/or column numbers altogether. If this occurs, libSBML sets the line and/or column number in the XMLError object to either 0 or the value of the maximum unsigned long integer representable on the platform where libSBML is running. The probability that a true line or column number in an SBML model would equal this value is vanishingly small; thus, if an application encounters these values in an XMLError object, it can assume no valid line/column number could be provided by libSBML in that situation.

Possible XMLError error codes. Depending on the programming language in use, the Enumerator values will be defined either as a value from the enumeration XMLErrorCode_t or as integer constants. To make this table more compact, we have shortened the identifiers for the category and severity codes to their essential parts. To get the actual names of the constants, prepend LIBSBML_CAT_ to the category names and LIBSBML_SEV_ to the severity names shown in the two right-hand columns.
Enumerator Meaning Category Severity
XMLUnknownErrorUnrecognized error encountered internallyINTERNALFATAL
XMLOutOfMemory Out of memorySYSTEMFATAL
XMLFileUnreadable File unreadableSYSTEMERROR
XMLFileUnwritable File unwritableSYSTEMERROR
XMLFileOperationErrorError encountered while attempting file operationSYSTEMERROR
XMLNetworkAccessErrorNetwork access errorSYSTEMERROR
InternalXMLParserErrorInternal XML parser state errorINTERNALFATAL
UnrecognizedXMLParserCodeXML parser returned an unrecognized error codeINTERNALFATAL
XMLTranscoderErrorCharacter transcoder errorINTERNALFATAL
MissingXMLDeclMissing XML declaration at beginning of XML inputXMLERROR
MissingXMLEncodingMissing encoding attribute in XML declarationXMLERROR
BadXMLDeclInvalid or unrecognized XML declaration or XML encodingXMLERROR
BadXMLDOCTYPEInvalid, malformed or unrecognized XML DOCTYPE declarationXMLERROR
InvalidCharInXMLInvalid character in XML contentXMLERROR
BadlyFormedXMLXML content is not well-formedXMLERROR
UnclosedXMLTokenUnclosed XML tokenXMLERROR
InvalidXMLConstructXML construct is invalid or not permittedXMLERROR
XMLTagMismatchElement tag mismatch or missing tagXMLERROR
DuplicateXMLAttributeDuplicate XML attributeXMLERROR
UndefinedXMLEntityUndefined XML entityXMLERROR
BadProcessingInstructionInvalid, malformed or unrecognized XML processing instructionXMLERROR
BadXMLPrefixInvalid or undefined XML namespace prefixXMLERROR
BadXMLPrefixValueInvalid XML namespace prefix valueXMLERROR
MissingXMLRequiredAttributeMissing a required XML attributeXMLERROR
XMLAttributeTypeMismatchData type mismatch for the value of an attributeXMLERROR
XMLBadUTF8ContentInvalid UTF8 contentXMLERROR
MissingXMLAttributeValueMissing or improperly formed attribute valueXMLERROR
BadXMLAttributeValueInvalid or unrecognizable attribute valueXMLERROR
BadXMLAttributeInvalid, unrecognized or malformed attributeXMLERROR
UnrecognizedXMLElementElement either not recognized or not permittedXMLERROR
BadXMLCommentBadly formed XML commentXMLERROR
BadXMLDeclLocationXML declaration not permitted in this locationXMLERROR
XMLUnexpectedEOFReached end of input unexpectedlyXMLERROR
BadXMLIDValueValue is invalid for XML ID, or has already been usedXMLERROR
BadXMLIDRefXML ID value was never declaredXMLERROR
UninterpretableXMLContentUnable to interpret contentXMLERROR
BadXMLDocumentStructureBad XML document structureXMLERROR
InvalidAfterXMLContentEncountered invalid content after expected contentXMLERROR
XMLExpectedQuotedStringExpected to find a quoted stringXMLERROR
XMLEmptyValueNotPermittedAn empty value is not permitted in this contextXMLERROR
XMLBadNumberInvalid or unrecognized numberXMLERROR
XMLBadColonColon characters are invalid in this contextXMLERROR
MissingXMLElementsOne or more expected elements are missingXMLERROR
XMLContentEmptyMain XML content is emptyXMLERROR
Enumerator Meaning
LIBSBML_CAT_INTERNAL A problem involving the libSBML software itself or the underlying XML parser. This almost certainly indicates a software defect (i.e., bug) in libSBML. Please report instances of this to the libSBML developers.
LIBSBML_CAT_SYSTEM A problem reported by the operating system, such as an inability to read or write a file. This indicates something that is not a program error but is outside of the control of libSBML.
LIBSBML_CAT_XML A problem in the XML content itself. This usually arises from malformed XML or the use of constructs not permitted in SBML.
Enumerator Meaning
LIBSBML_SEV_INFO The error is actually informational and not necessarily a serious problem.
LIBSBML_SEV_WARNING The error object represents a problem that is not serious enough to necessarily stop the problem, but applications should take note of the problem and evaluate what its implications may be.
LIBSBML_SEV_ERROR The error object represents a serious error. The application may continue running but it is unlikely to be able to continue processing the same XML file or data stream.
LIBSBML_SEV_FATAL A serious error occurred, such as an out-of-memory condition, and the software should terminate immediately.
typedef class XMLErrorLog XMLErrorLog_t

Log of errors and other events encountered while processing an XML file or data stream.

This class of objects is defined by libSBML only and has no direct equivalent in terms of SBML components. This class is not prescribed by the SBML specifications, although it is used to implement features defined in SBML.

The error log is a list. The XML layer of libSBML maintains an error log associated with a given XML document or data stream. When an operation results in an error, or when there is something wrong with the XML content, the problem is reported as an XMLError object stored in the XMLErrorLog list. Potential problems range from low-level issues (such as the inability to open a file) to XML syntax errors (such as mismatched tags or other problems).

A typical approach for using this error log is to first use getNumErrors() to inquire how many XMLError object instances it contains, and then to iterate over the list of objects one at a time using getError(unsigned int n) const. Indexing in the list begins at 0.

In normal circumstances, programs using libSBML will actually obtain an SBMLErrorLog rather than an XMLErrorLog. The former is subclassed from XMLErrorLog and simply wraps commands for working with SBMLError objects rather than the low-level XMLError objects. Classes such as SBMLDocument use the higher-level SBMLErrorLog.

Representation of XML Namespaces.

This class of objects is defined by libSBML only and has no direct equivalent in terms of SBML components. This class is not prescribed by the SBML specifications, although it is used to implement features defined in SBML.

This class serves to organize functionality for tracking XML namespaces in a document or data stream. The namespace declarations are stored as a list of pairs of XML namespace URIs and prefix strings. These correspond to the parts of a namespace declaration on an XML element. For example, in the following XML fragment,

<annotation>
    <mysim:nodecolors xmlns:mysim="urn:lsid:mysim.org"
         mysim:bgcolor="green" mysim:fgcolor="white"/>
</annotation>

there is one namespace declaration. Its URI is urn:lsid:mysim.org and its prefix is mysim. This pair could be stored as one item in an XMLNamespaces list.

XMLNamespaces provides various methods for manipulating the list of prefix-URI pairs. Individual namespaces stored in a given XMLNamespace object instance can be retrieved based on their index using XMLNamespaces::getPrefix(int index), or by their characteristics such as their URI or position in the list.

typedef class XMLNode XMLNode_t

Representation of a node in an XML document tree.

Beginning with version 3.0.0, libSBML implements an XML abstraction layer. This layer presents a uniform XML interface to calling programs regardless of which underlying XML parser libSBML has actually been configured to use. The basic data object in the XML abstraction is a node, represented by XMLNode.

An XMLNode can contain any number of children. Each child is another XMLNode, thereby forming a tree. The methods XMLNode::getNumChildren() and XMLNode::getChild() can be used to access the tree structure starting from a given node.

Each XMLNode is subclassed from XMLToken, and thus has the same methods available as XMLToken. These methods include XMLToken::getNamespaces(), XMLToken::getPrefix(), XMLToken::getName(), XMLToken::getURI(), and XMLToken::getAttributes().

Conversion between an XML string and an XMLNode

LibSBML provides the following utility functions for converting an XML string (e.g., <annotation>...</annotation>) to/from an XMLNode object.

The returned XMLNode object by XMLNode::convertStringToXMLNode() is a dummy root (container) XMLNode if the given XML string has two or more top-level elements (e.g., "<p>...</p><p>...</p>"). In the dummy root node, each top-level element in the given XML string is contained as a child XMLNode. XMLToken::isEOF() can be used to identify if the returned XMLNode object is a dummy node or not. Here is an example:

typedef class XMLToken XMLToken_t

Representation of a token in an XML stream.

This class of objects is defined by libSBML only and has no direct equivalent in terms of SBML components. This class is not prescribed by the SBML specifications, although it is used to implement features defined in SBML.

typedef class XMLTriple XMLTriple_t

Representation of a qualified XML name.

This class of objects is defined by libSBML only and has no direct equivalent in terms of SBML components. This class is not prescribed by the SBML specifications, although it is used to implement features defined in SBML.

A "triple" in the libSBML XML layer encapsulates the notion of qualified name, meaning an element name or an attribute name with an optional namespace qualifier. An XMLTriple instance carries up to three data items:

  • The name of the attribute or element; that is, the attribute name as it appears in an XML document or data stream;

  • The XML namespace prefix (if any) of the attribute. For example, in the following fragment of XML, the namespace prefix is the string mysim and it appears on both the element someelement and the attribute attribA. When both the element and the attribute are stored as XMLTriple objects, their prefix is mysim.

    <mysim:someelement mysim:attribA="value" />
    

  • The XML namespace URI with which the prefix is associated. In XML, every namespace used must be declared and mapped to a URI.

XMLTriple objects are the lowest-level data item in the XML layer of libSBML. Other objects such as XMLToken make use of XMLTriple objects.