libSBML Perl API  libSBML 5.17.2 Perl API
sbmlfwd.h File Reference

Forward declarations for all opaque C types. More...

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 AlgebraicRule AlgebraicRule_t
 {core} More...
 
typedef class AssignmentRule AssignmentRule_t
 {core} More...
 
typedef class ASTNode ASTNode_t
 {core} More...
 
typedef class Compartment Compartment_t
 {core} More...
 
typedef class CompartmentType CompartmentType_t
 {core} More...
 
typedef class Constraint Constraint_t
 {core} More...
 
typedef class ConversionOption ConversionOption_t
 
typedef class ConversionProperties ConversionProperties_t
 
typedef class CVTerm CVTerm_t
 {core} More...
 
typedef class Date Date_t
 {core} More...
 
typedef class Delay Delay_t
 {core} More...
 
typedef class ElementTransformer ElementTransformer_t
 
typedef class Event Event_t
 {core} More...
 
typedef class EventAssignment EventAssignment_t
 {core} More...
 
typedef class ExpectedAttributes ExpectedAttributes_t
 
typedef class FunctionDefinition FunctionDefinition_t
 {core} More...
 
typedef class IdentifierTransformer IdentifierTransformer_t
 
typedef class InitialAssignment InitialAssignment_t
 {core} More...
 
typedef class KineticLaw KineticLaw_t
 {core} More...
 
typedef class L3ParserSettings L3ParserSettings_t
 
typedef class List List_t
 {core} More...
 
typedef class ListOf ListOf_t
 {core} More...
 
typedef class LocalParameter LocalParameter_t
 {core} More...
 
typedef class Model Model_t
 {core} More...
 
typedef class ModelCreator ModelCreator_t
 {core} More...
 
typedef class ModelHistory ModelHistory_t
 {core} More...
 
typedef class ModifierSpeciesReference ModifierSpeciesReference_t
 {core} More...
 
typedef class Parameter Parameter_t
 {core} More...
 
typedef class Priority Priority_t
 {core} More...
 
typedef class RateRule RateRule_t
 {core} More...
 
typedef class Reaction Reaction_t
 {core} More...
 
typedef class Rule Rule_t
 {core} More...
 
typedef class SBase SBase_t
 {core} More...
 
typedef class SBaseExtensionPoint SBaseExtensionPoint_t
 {core} More...
 
typedef class SBasePlugin SBasePlugin_t
 
typedef class SBasePluginCreatorBase SBasePluginCreatorBase_t
 
typedef class SBMLDocument SBMLDocument_t
 {core} More...
 
typedef class SBMLDocumentPlugin SBMLDocumentPlugin_t
 {core} More...
 
typedef class SBMLError SBMLError_t
 {core} More...
 
typedef class SBMLExtension SBMLExtension_t
 {core} More...
 
typedef class ISBMLExtensionNamespaces SBMLExtensionNamespaces_t
 {core} More...
 
typedef class SBMLNamespaces SBMLNamespaces_t
 {core} More...
 
typedef class SBMLReader SBMLReader_t
 {core} More...
 
typedef class SBMLWriter SBMLWriter_t
 {core} More...
 
typedef class Species Species_t
 {core} 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
 {core} More...
 
typedef class StoichiometryMath StoichiometryMath_t
 {core} More...
 
typedef class Trigger Trigger_t
 {core} More...
 
typedef class Unit Unit_t
 {core} More...
 
typedef class UnitDefinition UnitDefinition_t
 {core} More...
 
typedef class XMLAttributes XMLAttributes_t
 {core} More...
 
typedef class XMLError XMLError_t
 {core} More...
 
typedef class XMLErrorLog XMLErrorLog_t
 {core} More...
 
typedef class XMLNamespaces XMLNamespaces_t
 {core} More...
 
typedef class XMLNode XMLNode_t
 {core} More...
 
typedef class XMLToken XMLToken_t
 {core} More...
 
typedef class XMLTriple XMLTriple_t
 {core} More...
 

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.

Macro Definition Documentation

◆ CLASS_OR_STRUCT

#define CLASS_OR_STRUCT   class

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

Typedef Documentation

◆ AlgebraicRule_t

{core}

An SBML algebraic rule representing 0 = f(W).

The rule type AlgebraicRule is derived from the parent class Rule. It is used to express equations that are neither assignments of model variables nor rates of change. AlgebraicRule does not add any attributes to the basic Rule; its role is simply to distinguish this case from the other cases.

In the context of a simulation, algebraic rules are in effect at all times, t $\geq$ 0. For purposes of evaluating expressions that involve the delay "csymbol" (see the SBML specification), algebraic rules are considered to apply also at t $\leq$ 0. Please consult the relevant SBML specification for additional information about the semantics of assignments, rules, and entity values for simulation time t $\leq$ 0.

An SBML model must not be overdetermined. The ability to define arbitrary algebraic expressions in an SBML model introduces the possibility that a model is mathematically overdetermined by the overall system of equations constructed from its rules, reactions and events. Therefore, if an algebraic rule is introduced in a model, for at least one of the entities referenced in the rule's "math" element the value of that entity must not be completely determined by other constructs in the model. This means that at least this entity must not have the attribute "constant"=true and there must also not be a rate rule or assignment rule for it. Furthermore, if the entity is a Species object, its value must not be determined by reactions, which means that it must either have the attribute "boundaryCondition"=true or else not be involved in any reaction at all. These restrictions are explained in more detail in the SBML specification documents.

In SBML Levels 2 and 3, Reaction object identifiers can be referenced in the "math" expression of an algebraic rule, but reaction rates can never be determined by algebraic rules. This is true even when a reaction does not contain a KineticLaw object. (In such cases of missing kinetic law definitions, the model is valid but incomplete; the rates of reactions lacking kinetic laws are simply undefined, and not determined by the algebraic rule.)

In SBML Level 2 and Level 3 Version 1, the "math" subelement of the AlgebraicRule is required. In SBML Level 3 Version 2, this rule is relaxed, and the subelement is optional. If an AlgebraicRule with no "math" child is present in the model, no additional mathematical constraints on the model are added by the rule. This may represent a situation where the model itself is unfinished, or the missing information may be provided by an SBML Level 3 package.

Finally, any symbol that appears as the target of a rateOf csymbol (

◆ AssignmentRule_t

{core}

An SBML assignment rule representing x = f(Y).

The rule type AssignmentRule is derived from the parent class Rule. It is used to express equations that set the values of variables. The left-hand side (the attribute named "variable") of an assignment rule must refer to the identifier of a Species, SpeciesReference (in SBML Level 3), Compartment, or global Parameter object in the model (but not a Reaction). In SBML Level 3 Version 2, it may also refer to the SId of an element defined in an SBML Level 3 package with mathematical meaning and the ability to be assigned. The entity identified must have its "constant" attribute set to false. The effects of an assignment rule construct are in general terms the same, but differ in the precise details depending on the type of SBML component being set:

  • In the case of a species, an SBML assignment rule sets the referenced species' quantity (whether a "concentration" or "amount") to the value determined by the formula in the MathML subelement "math". The unit associated with the value produced by the "math" formula should (in SBML Level 2 Version 4 and in SBML Level 3) or must (in SBML releases prior to Level 2 version 4) be equal to the unit associated with the species' quantity. Restrictions: There must not be both an AssignmentRule "variable" attribute and a SpeciesReference "species" attribute having the same value in a model, unless the referenced Species object has its "boundaryCondition" attribute set to true. In other words, an assignment rule cannot be defined for a species that is created or destroyed in a reaction unless that species is defined as a boundary condition in the model.

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

  • In the case of a compartment, an SBML assignment rule sets the referenced compartment's size to the value determined by the formula in the "math" subelement of the AssignmentRule object. The overall units of the formula in "math" should (in SBML Level 2 Version 4 and in SBML Level 3) or must (in SBML releases prior to Level 2 version 4) be the same as the units of the size of the compartment.

  • In the case of a parameter, an assignment rule sets the referenced parameter's value to that determined by the formula in the "math" subelement of the AssignmentRule object. The overall units of the formula in the "math" subelement should (in SBML Level 2 Version 4 and in SBML Level 3) or must (in SBML releases prior to Level 2 version 4) be the same as the units defined for the parameter.

  • (For SBML Level 3 Version 2 only) In the case of an object from an SBML Level 3 package, an AssignmentRule sets the referenced object's value (as defined by that package) to the value of the formula in math. The unit of measurement associated with the value produced by the formula should be the same as that object's units attribute value (if it has such an attribute), or be equal to the units of model components of that type (if objects of that class are defined by the package as having the same units).

In SBML Level 2 and Level 3 Version 1, the "math" subelement of the AssignmentRule is required. In SBML Level 3 Version 2, this rule is relaxed, and the subelement is optional. If an AssignmentRule with no "math" child is present in the model, the value of its referenced "variable" is undefined. This may represent a situation where the model itself is unfinished, or the missing information may be provided by an SBML Level 3 package.

If the variable attribute of an AssignmentRule object references an object in an SBML namespace not understood by the interpreter reading a given SBML document (that is, if the object is defined by an SBML Level 3 package that the software does not support), the assignment rule must be ignored–the object's value will not need to be set, as the interpreter could not understand that package. If an interpreter cannot establish whether a referenced object is missing from the model or instead is defined in an SBML namespace not understood by the interpreter, it may produce a warning to the user. (The latter situation may only arise if an SBML package is present in the SBML document with a package:required attribute of "true".)

In the context of a simulation, assignment rules are in effect at all times, t $\geq$ 0. For purposes of evaluating expressions that involve the delay "csymbol" (see the SBML Level 2 specification), assignment rules are considered to apply also at t $\leq$ 0. Please consult the relevant SBML specification for additional information about the semantics of assignments, rules, and entity values for simulation time t $\leq$ 0.

A model must not contain more than one AssignmentRule or RateRule object having the same value of "variable"; in other words, in the set of all assignment rules and rate rules in an SBML model, each variable appearing in the left-hand sides can only appear once. This simply follows from the fact that an indeterminate system would result if a model contained more than one assignment rule for the same variable or both an assignment rule and a rate rule for the same variable.

Similarly, a model must also not contain both an AssignmentRule and an InitialAssignment definition for the same variable, because both kinds of constructs apply prior to and at the start of simulation time, i.e., t $\leq$ 0. If a model contained both an initial assignment and an assignment rule for the same variable, an indeterminate system would result.

The value calculated by an AssignmentRule object overrides the value assigned to the given symbol by the model component defining that symbol. For example, if a Compartment object's "size" attribute value is set in its definition, and the model also contains an AssignmentRule object having that compartment's "id" as its "variable" value, then the "size" assigned in the Compartment object definition is ignored and the value assigned based on the computation defined in the AssignmentRule. This does not mean that a definition for a given symbol can be omitted if there is an AssignmentRule object involving it. For example, there must be a Parameter object definition for a given parameter if there is an AssignmentRule definition for that parameter. It is only a question of which value definition takes precedence.

◆ ASTNode_t

typedef class ASTNode ASTNode_t

{core}

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).

The set of possible ASTNode types

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(x) or log(10, x)
pow(x, y)power(x, y)
sqr(x)power(x, 2)
sqrt(x)root(x) or 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.

◆ Compartment_t

typedef class Compartment Compartment_t

{core}

An SBML compartment, where species are located.

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 object 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 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" is optional, and has a default value of true. In SBML Level 3, there is no default value for the "constant" attribute, and it is required.

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 (in Level 2 Versions 1-3) or should (in Level 2 Version 4) 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 (in Level 2 Versions 1–3) or should (in Level 2 Version 4) be identical to the compartment's units (whether defined by the "units" attribute or by taking the default value from the Model) 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 structure 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 a given Compartment's "units" are left unset and the "spatialDimensions" either has a value other than 1, 2, or 3 or is left unset itself (as it has no default value), 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. 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.

◆ CompartmentType_t

{core}

A compartment type in SBML Level 2.

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. A CompartmentType has no mathematical meaning in SBML—it has 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

◆ Constraint_t

typedef class Constraint Constraint_t

{core}

An SBML constraint, for stating validity assumptions.

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 subelement, "math", containing a MathML formula defining the condition of the constraint. This formula will 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.

In SBML Level 2 and SBML Level 3 Version 1, the "math" subelement is required, and its formula must be a Boolean value. In SBML Level 3 Version 2, these restrictions were relaxed: the "math" subelement is optional, and numeric values are allowed in Boolean contexts (a '0' is interpreted as false, and all other values are interpreted as true). If a Constraint with no "math" is present in a Model, no restriction on the Model's behavior is implied or enforced.

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.

◆ ConversionOption_t

◆ ConversionProperties_t

◆ CVTerm_t

typedef class CVTerm CVTerm_t

{core}

A MIRIAM-compliant controlled vocabulary term.

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. A small change was introduced in SBML Level 2 Version 5 and SBML Level 3 Version 2 to permit nested annotations: lower Versions of the SBML specifications did not explicitly allow this. We first describe the different parts of SBML annotations in XML form for SBML Level 2 below Version 5 and SBML Level 3 below Version 2:

<SBML_ELEMENT +++ metaid="meta id" +++>
  +++
  <annotation>
    +++
    <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             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). Note that these namespace URIs are only labels, and not actual Web locations, which means you cannot visit an address such as "http://biomodels.net/model-qualifiers" in your browser or try to have your application access it.

The URI is a required data value that uniquely identifies a resource and data within that resource to which the annotation refers. Again, being URIs, these do not refer to physical Web locations; nevertheless, applications will often want a means of finding the resource to which a given URI refers. Providing the facilities for this task is the purpose of MIRIAM Resources, described in detail online at http://biomodels.net/miriam) and also in the paper "MIRIAM Resources: tools to generate and resolve robust cross-references in Systems Biology", BMC Systems Biology, 58(1), 2007.

Finally, the following is the same template as above, but this time showing the nested content permitted by the most recent SBML specifications (SBML Level 2 Version 5 and Level 3 Version 2):

<SBML_ELEMENT +++ metaid="meta id" +++>
  +++
  <annotation>
    +++
    <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             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" />
            NESTED_CONTENT
            ...
          </rdf:Bag>
        </RELATION_ELEMENT>
        ...
      </rdf:Description>
      +++
    </rdf:RDF>
    +++
  </annotation>
  +++
</SBML_ELEMENT>

The placeholder NESTED_CONTENT refers to other optional RDF elements such as "bqbiol:isDescribedBy" that describe a clarification or another annotation about the RELATION_ELEMENT in which it appears. Nested content allows one to, for example, describe protein modifications on species, or to add evidence codes for an annotation. Nested content relates to its containing RELATION_ELEMENT, not the other way around. It qualifies it, but does not change its meaning. As such, ignoring a NESTED_CONTENT does not affect the information provided by the containing RELATION_ELEMENT.

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. The relation-resource pairs discussed in the previous section are the "controlled vocabulary" terms that CVTerm is designed to store and manipulate. 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://co.mbine.org/standards/qualifiers.

◆ Date_t

typedef class Date Date_t

{core}

A MIRIAM-compliant date representation.

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, with a range of 0–12.
  • minute offset: an unsigned int representing the time zone's minute offset from GMT, with a range of 0–59.

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>

◆ Delay_t

typedef class Delay Delay_t

{core}

A delay on the time of execution of an SBML 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, 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 an SBML Level 3 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>

Restrictions relaxed in SBML Level 3 Version 2

In SBML Level 3 Version 2, the requirement that a Delay have a "math" subelement was relaxed, making it optional. In this case, the Delay remains undefined, and unless that information is provided in some other form (such as with an SBML Level 3 package), the Event behaves as if it had no Delay.

◆ ElementTransformer_t

typedef class ElementTransformer ElementTransformer_t

◆ Event_t

typedef class Event Event_t

{core}

A discontinuous SBML event.

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.

SBML Level/Version differences

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, or after any other simultaneous event may have been executed and changed the model state). In SBML Level 2 Version 4 and in Level 3, the attribute "useValuesFromTriggerTime" on Event was added to allow a model to indicate the time at which the event's assignments are to be calculated, whether at the moment the event is triggered (if the value of the attribute is true), or at the moment of execution (if "useValuesFromTriggerTime"=false). If the event has a delay, the "useValuesFromTriggerTime" is likely to make a significant difference in the values used in the assignment, but the possibility of simultaneous events mean that even zero-delay events can have different results depending on the value of this attribute.

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.

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 and had a default value of true);
  • 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).
  • In SBML Level 3 Version 2, the Trigger object became optional. An Event with no Trigger will simply not fire.

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

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.

Restrictions relaxed in SBML Level 3 Version 2

In SBML Level 3 Version 2, several restrictions were lifted that have the potential to affect the semantics of an Event:

  • The Trigger subobject of an Event is optional. If missing, an Event is never triggered, unless an alternate triggering scheme is introduced by an SBML Level 3 package.

  • The "math" subelements of an Event Trigger, Delay, Priority, and EventAssignment are all optional. If any of these elements lack a "math" subelement, and that information is not supplied in an SBML Level 3 package, it is mathematically equivalent to the Trigger, Delay, Priority, or EventAssignment not being present at all.

  • The ListOfEventAssignments may be empty, which is mathematically equivalent to the Event not having a ListOfEventAssignments at all.

  • Any "math" subelement may return a Boolean or a numeric value in any context. If a numeric value is used in a Boolean context, a "0" is interpreted as false, and all other values are interpreted as true. If a Boolean value is used in a numeric context, a true is interpreted as a 1, and a false is interpreted as a 0. This means (for example) that a Trigger value that changes from 0.0 to anything else is equivalent to changing from false to true.
See also
Trigger
Priority
Delay
EventAssignment

◆ EventAssignment_t

{core}

An assignment to a variable by an SBML 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. In SBML Level 3 Version 2, this list was expanded to include identifiers of SBML Level 3 package variables that have both mathematical meaning and the ability to be assigned. 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. In SBML Level 2 and SBML Level 3 Version 1, only species, species references, compartment and parameter values may be set by an Event. In SBML Level 3 Version 2, the "variable" attribute may also be the identifier of an SBML Level 3 package element with mathematical meaning and the ability to be assigned a value. This situation may only arise if the SBML package is present in the SBML document with a package:required attribute of true

  • 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.)

If the variable attribute of an EventAssignment object references an object in an SBML namespace that is not understood by the interpreter reading a given SBML document (that is, if the object is defined by an SBML Level 3 package that the software does not support), the event assignment must be ignored–the object's value will not need to be set, as the interpreter could not understand that package. If an interpreter cannot establish whether a referenced object is missing from the model or instead is defined in an SBML namespace not understood by the interpreter, it may produce a warning to the user. (The latter situation may only arise if an SBML package is present in the SBML document with a package:required attribute of "true".)

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.

SBML Level/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.

  • (For SBML Level 3 Version 2 only) In the case of an object from an SBML Level 3 package, an EventAssignment sets the referenced object's value (as defined by that package) to the value of the formula in "math". The unit of measurement associated with the value produced by the formula should be the same as that object's units attribute value (if it has such an attribute), or be equal to the units of model components of that type (if objects of that class are defined by the package as having the same units).

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.

Restrictions relaxed in SBML Level 3 Version 2

In SBML Level 3 Version 2, the requirement that an EventAssignment have a "math" subelement was relaxed, making it optional. In this case, the EventAssignment remains undefined, and unless that information is provided in some other form (such as with an SBML Level 3 package), the Event behaves as if it had no EventAssignment.

See also
Event

◆ ExpectedAttributes_t

typedef class ExpectedAttributes ExpectedAttributes_t

◆ FunctionDefinition_t

{core}

A user-defined function in an SBML model.

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 "math" subelement containing a MathML expression defining the function body. In SBML Level 2 and SBML Level 3 Version 1, that "math" subelement is required; in SBML Level 3 Version 2, this restriction was relaxed, making the "math" subelement optional. 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.

In SBML Level 3 Version 2, if no math element is present in the FunctionDefinition, the function has no mathematical meaning defined in SBML Level 3 Core. This situation may arise when models are incomplete, or when additional meanings are provided by an SBML Level 3 package.

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.)

◆ IdentifierTransformer_t

typedef class IdentifierTransformer IdentifierTransformer_t

◆ InitialAssignment_t

{core}

An SBML initial assignment, evaluated once only.

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, SpeciesReference (in SBML Level 3), global Parameter, or (as of SBML Level 3 Version 2) the identifier of a SBML Level 3 package element with mathematical meaning. 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 "math" subelement that contains a MathML expression used to calculate the value of the constant or the initial value of the variable. This subelement is required in SBML Level 2 and SBML Level 3 Version 1, but the requirement was relaxed in SBML Level 3 Version 2, making it optional. 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, global Parameter, SpeciesReference (in Level 3), and SBML Level 3 package elements (in Level 3 Version 2), 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.

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

  • (For SBML Level 3 Version 2 only) In the case of an object from an SBML Level 3 package, an InitialAssignment sets the referenced object's initial value (however such values are defined by the package) to the value of the formula in math. The unit of measurement associated with the value produced by the formula should be the same as that object's units attribute value (if it has such an attribute), or be equal to the units of model components of that type (if objects of that class are defined by the package as having the same units).

If the symbol attribute of an InitialAssignment object references an object in an SBML namespace that is not understood by the interpreter reading a given SBML document (that is, if the object is defined by an SBML Level 3 package that the software does not support), the assignment must be ignored–the object's initial value will not need to be set, as the interpreter could not understand that package. If an interpreter cannot establish whether a referenced object is missing from the model or instead is defined in an SBML namespace not understood by the interpreter, it may produce a warning to the user. (The latter situation may only arise if an SBML package is present in the SBML document with a package:required attribute of "true".)

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 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.

◆ KineticLaw_t

typedef class KineticLaw KineticLaw_t

{core}

The rate expression for an SBML reaction.

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 (required through SBML Level 3 Version 1, but optional as of SBML Level 3 Version 2) 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 (or, as of SBML Level 3 Version 2, only visible within the parent Reaction); 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.

SBML Level/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.

In SBML Level 3 Version 2, the scope of the LocalParameter was expanded to the entire Reaction, instead of just the KineticLaw. This introduced a single new restriction: an L3v2 LocalParameter may not now shadow the id of any Species referenced by a SpeciesReference in the same Reaction. Other than that, there is no difference in any core construct. However, packages may take advantage of this new scope by adding elements to the Reaction that may now reference a LocalParameter defined in the same Reaction.

◆ L3ParserSettings_t

◆ List_t

typedef class List List_t

{core}

Simple, plain, generic lists.

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.

◆ ListOf_t

typedef class ListOf ListOf_t

{core}

Parent class for libSBML's "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.

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.

Whether a given ListOf element may be empty or not depends on the element in question, and on what level and version of SBML it is being used for. For ListOf elements in SBML Level 3 Version 1 and prior, no core list and few package lists could be empty. As of SBML Level 3 Version 2, the rules were relaxed, and lists were allowed to be empty. In libSBML, documents created for Level 3 Version 2 will be written with empty ListOf's if that ListOf contains some other 'extra' information: an attribute such as metaid or sboTerm, a child '<notes>' or '<annotation>', or information from a SBML Level 3 package.

The various ListOf___ classes in SBML are merely containers used for organizing the main components of an SBML model. In libSBML's implementation, ListOf___ classes are derived from the intermediate utility class ListOf, which is not defined by the SBML specifications but serves as a useful programmatic construct. ListOf is itself is in turn derived from SBase, which provides all of the various ListOf___ classes with common features defined by the SBML specification, such as "metaid" attributes and annotations.

The relationship between the lists and the rest of an SBML model is illustrated by the following (for SBML Level 2 Version 4):

SBML Level 3 Version 1 has essentially the same structure as Level 2 Version 4, depicted above, but SBML Level 3 Version 2 allows containers to contain zero or more of the relevant object, instead of requiring at least one. As such, libsbml will write out an otherwise-empty ListOf___ element that has any optional attribute set (such as 'id' or 'metaid'), that has an optional child (such as a 'notes' or 'annotation'), or that has attributes or children set from any SBML Level 3 package, whether or not the ListOf___ has any other children.

Readers may wonder about the motivations for using the ListOf___ containers in SBML. A simpler approach in XML might be to place the components all directly at the top level of the model definition. The choice made in SBML is to group them within XML elements named after ListOfClassname, in part because it helps organize the components. More importantly, the fact that the container classes are derived from SBase means that software tools can add information about the lists themselves into each list container's "annotation".

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

◆ LocalParameter_t

{core}

A parameter inside an SBML reaction definition.

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.

In SBML Level 3 Version 2, the scope of the LocalParameter was expanded slightly to officially encompass the entire Reaction instead of just the KineticLaw in which it appears. This has no effect on models using only SBML Level 3 Core constructs, but has the potential to allow SBML Level 3 Packages to include elements in a Reaction that could reference a LocalParameter from that Reaction's KineticLaw. It also means that no LocalParameter may have the same "id" as a referenced Species in any SimpleSpeciesReference in that Reaction.

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

◆ Model_t

typedef class Model Model_t

{core}

An SBML model.

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.17.2 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, 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).

Consistency and adherence to SBML specifications

To make it easier for applications to do whatever they need, libSBML version 5.17.2 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. 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 specifications provide 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 specifications.

◆ ModelCreator_t

{core}

MIRIAM-compliant data about a model's creator.

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.

◆ ModelHistory_t

{core}

MIRIAM-compliant data about a model's history.

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.

See also
ModelCreator
Date

◆ ModifierSpeciesReference_t

{core}

A reference to an SBML modifier species.

Sometimes a species appears in the kinetic rate formula of a reaction but is itself neither created nor destroyed in that reaction (for example, because it acts as a catalyst or inhibitor). In SBML, all such species are simply called modifiers without regard to the detailed role of those species in the model. The Reaction structure provides a way to express which species act as modifiers in a given reaction. This is the purpose of the list of modifiers available in Reaction. The list contains instances of ModifierSpeciesReference structures.

The ModifierSpeciesReference structure inherits the mandatory attribute "species" and optional attributes "id" and "name" from the parent class SimpleSpeciesReference. See the description of SimpleSpeciesReference for more information about these.

The value of the "species" attribute must be the identifier of a species defined in the enclosing Model; this species is designated as a modifier for the current reaction. A reaction may have any number of modifiers. It is permissible for a modifier species to appear simultaneously in the list of reactants and products of the same reaction where it is designated as a modifier, as well as to appear in the list of reactants, products and modifiers of other reactions in the model.

◆ Parameter_t

typedef class Parameter Parameter_t

{core}

An SBML parameter: a named symbol with a value.

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.

In SBML Level 3 Version 2, many restrictions were lifted requiring only Boolean values in Boolean contexts, and numeric values in numeric contexts. This means that a Parameter may now be used as a Boolean, despite canonically having a numeric value. To be consistent, one should always assign it a value of true or false, and use it in Boolean contexts exclusively. It would be appropriate to give it an SBO value of 602 ('Logical parameter') if one chooses to do this.

See also
ListOfParameters

◆ Priority_t

typedef class Priority Priority_t

{core}

The priority of execution of an SBML 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 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.

Restrictions relaxed in SBML Level 3 Version 2

In SBML Level 3 Version 2, the requirement that a Priority have a "math" subelement was relaxed, making it optional. In this case, the Priority remains undefined, and unless that information is provided in some other form (such as with an SBML Level 3 package), the Event behaves as if it had no Priority.

See also
Event
Delay
EventAssignment

◆ RateRule_t

typedef class RateRule RateRule_t

{core}

An SBML rate rule representing dx/dt = f(Y).

The rule type RateRule is derived from the parent class Rule. It is used to express equations that determine the rates of change of variables. The left-hand side (the "variable" attribute) can refer to the identifier of a species, compartment, or parameter (but not a reaction). The entity identified must have its "constant" attribute set to false. The effects of a RateRule are in general terms the same, but differ in the precise details depending on which variable is being set:

  • In the case of a species, a RateRule sets the rate of change of the species' quantity (concentration or amount of substance) to the value determined by the formula in the "math" subelement of the RateRule object. The overall units of the formula in "math" should (in SBML Level 2 Version 4 and in SBML Level 3) or must (in SBML releases prior to Level 2 version 4) be equal to the unit of species quantity divided by the model-wide unit of time. Restrictions: There must not be both a RateRule "variable" attribute and a SpeciesReference "species" attribute having the same value, unless that species has its "boundaryCondition" attribute is set to true. This means a rate rule cannot be defined for a species that is created or destroyed in a reaction, unless that species is defined as a boundary condition in the model.

  • (For SBML Level 3 only) In the case of a species reference, a RateRule sets the rate of change of the stoichiometry of the referenced reactant or product to the value determined by the formula in "math". The unit associated with the value produced by the "math" formula should be consistent with the unit "dimensionless" divided by the model-wide unit of time.

  • In the case of a compartment, a RateRule sets the rate of change of the compartment's size to the value determined by the formula in the "math" subelement of the RateRule object. The overall units of the formula should (in SBML Level 2 Version 4 and in SBML Level 3) or must (in SBML releases prior to Level 2 version 4) be the units of the compartment's size divided by the model-wide unit of time.

  • In the case of a parameter, a RateRule sets the rate of change of the parameter's value to that determined by the formula in the "math" subelement of the RateRule object. The overall units of the formula should (in SBML Level 2 Version 4 and in SBML Level 3) or must (in SBML releases prior to Level 2 version 4) be the Parameter object's "unit" attribute value divided by the model-wide unit of time.

  • (For SBML Level 3 Version 2 only) In the case of an object from an SBML Level 3 package, a RateRule sets the rate of change of the referenced object's value (as defined by that package) to the value of the formula in "math". The unit of measurement associated with the value produced by the formula should be the same as that object's units attribute value (if it has such an attribute) divided by the model-wide unit of time, or be equal to the units of model components of that type (if objects of that class are defined by the package as having the same units) divided by the model-wide unit of time.

In SBML Level 2 and Level 3 Version 1, the "math" subelement of the RateRule is required. In SBML Level 3 Version 2, this rule is relaxed, and the subelement is optional. If a RateRule with no "math" child is present in the model, the rate at which its referenced "variable" changes over time is undefined. This may represent a situation where the model itself is unfinished, or the missing information may be provided by an SBML Level 3 package.

If the variable attribute of a RateRule object references an object in an SBML namespace that is not understood by the interpreter reading a given SBML document (that is, if the object is defined by an SBML Level 3 package that the software does not support), the rate rule must be ignored–the object's value will not need to be set, as the interpreter could not understand that package. If an interpreter cannot establish whether a referenced object is missing from the model or instead is defined in an SBML namespace not understood by the interpreter, it may produce a warning to the user. (The latter situation may only arise if an SBML package is present in the SBML document with a package:required attribute of "true".)

In the context of a simulation, rate rules are in effect for simulation time t > 0. Please consult the relevant SBML specification for additional information about the semantics of assignments, rules, and entity values for simulation time t $\leq$ 0.

As mentioned in the description of AssignmentRule, a model must not contain more than one RateRule or AssignmentRule object having the same value of "variable"; in other words, in the set of all assignment rules and rate rules in an SBML model, each variable appearing in the left-hand sides can only appear once. This simply follows from the fact that an indeterminate system would result if a model contained more than one assignment rule for the same variable or both an assignment rule and a rate rule for the same variable.

◆ Reaction_t

typedef class Reaction Reaction_t

{core}

An SBML reaction between species in an SBML model.

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 objects in SBML, Reaction has a mandatory attribute, "id", used to give the reaction 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.

  • For SBML Levels 1, 2, and SBML Level 3 Version 1, 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.) In SBML Level 3 Version 2, this requirement was dropped, allowing the creation of reactions with neither reactants nor products.

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). In SBML Level 3 Version 2, a value of true for the "fast" attribute is deprecated in favor of all reactions having a "fast" value of false. 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. 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, 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.

◆ Rule_t

typedef class Rule Rule_t

{core}

Parent class for SBML rules in libSBML.

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 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.

◆ SBase_t

typedef class SBase SBase_t

{core}

SBML's SBase class, 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 2, SBase 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". More details can be found in SBML specifications for Level 2 Version 2 and above.

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.

◆ SBaseExtensionPoint_t

{core}

Base class for extending SBML components

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.

◆ SBasePlugin_t

typedef class SBasePlugin SBasePlugin_t

◆ SBasePluginCreatorBase_t

◆ SBMLDocument_t

{core}

Overall SBML container object.

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()

It should be noted that as of SBML Level 3 Version 2, the Model became an optional child of SBMLDocument, instead of being required. This means that one can no longer use SBMLDocument::getModel() as a cheap method of checking if an SBML document was read in properly: the more robust getError methods detailed above must be used instead.

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.

◆ SBMLDocumentPlugin_t

{core}

Base class for extending SBMLDocument in packages.

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 SBMLDocumentPlugin class is a specialization of SBasePlugin designed specifically for extending SBMLDocument. All package extensions must extend SBMLDocument to implement support for SBML Level 3 packages; these extensions can be subclasses of this class or from a derived class of this class.

All packages must additionally define a required flag named required, which indicates whether that package's constructs can be used to change the core mathematics of the <model> child of the <sbml> element. If they can, this attribute must be set true, and if they cannot, this attribute must be set false.

◆ SBMLError_t

typedef class SBMLError SBMLError_t

{core}

An error, warning or other diagnostic.

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.

◆ SBMLExtension_t

{core}

Base class for SBML Level 3 package plug-ins.

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 SBMLExtension class is a component of the libSBML package extension mechanism. It is an abstract class that is extended by each package extension implementation.

Special handling for SBML Level 2

◆ SBMLExtensionNamespaces_t

{core}

Set of SBML Level + Version + namespace triples.

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.

SBMLExtensionNamespaces is a template class. It is extended from SBMLNamespaces and is meant to be used by package extensions to store the SBML Level, Version within a Level, and package version of the SBML Level 3 package implemented by a libSBML package extension.

◆ SBMLNamespaces_t

{core}

Set of SBML Level + Version + namespace triples.

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.

◆ SBMLReader_t

typedef class SBMLReader SBMLReader_t

{core}

File and text-string SBML reader.

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, {readSBML, String} and {readSBMLFromString, String}. They are equivalent to creating an SBMLReader object and then calling the and methods, respectively.

Support for reading 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 and

will automatically decompress and compress the file while reading and writing 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 installation instructions 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.

◆ SBMLWriter_t

typedef class SBMLWriter SBMLWriter_t

{core}

File and text-string SBML writer.

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 an output stream or 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.

◆ Species_t

typedef class Species Species_t

{core}

An SBML species – a pool of entities.

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.

Finally, it is worth clarifying that while the constant and boundaryCondition attributes restrict whether and how the species amount changes, the same is not true of a species' concentration. In SBML, the concentration of a species is a quantity that depends on the size of the compartment in which it is located. A compartment's size may change, and therefore, so can the concentration of a species even if the amount of the species remains unchanged. A species' concentration may therefore vary even if the Species object's constant attribute is set to true in a 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.

◆ SpeciesReference_t

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

◆ SpeciesType_t

typedef class SpeciesType SpeciesType_t

{core}

A species type in SBML Level 2.

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

◆ StoichiometryMath_t

{core}

Stochiometry expressions in SBML Level 2 reactions.

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. 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

◆ Trigger_t

typedef class Trigger Trigger_t

{core}

The trigger expression for an SBML 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 is evaluated as 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.

In SBML Level 2 and SBML Level 3 Version 1, the "math" subelement is required, and it must evaluate to a boolean expression. In SBML Level 3 Version 2, those restrictions are relaxed: the "math" element is optional, and numeric values are allowed in Boolean contexts (a '0' is interpreted as false, and all other values are interpreted as true). If a Trigger with no "math" is present in an Event, that Event will never trigger, unless that missing information is included in an SBML Level 3 package.

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

◆ Unit_t

typedef class Unit Unit_t

{core}

A single unit referenced in an SBML unit definition.

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 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:

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 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 no 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 2.

  • 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.

◆ UnitDefinition_t

{core}

A definition of a unit used in an SBML model.

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 may contain exactly one ListOfUnits, and this list may contain one or more Unit definitions; see the definitions of these other object classes for more information about them. In SBML Level 2 and SBML Level 3 Version 1, if the ListOfUnits was present, it must have one or more Unit definitions. In SBML Level 3 Version 2, this restriction was relaxed, and a ListOfUnits was allowed to be empty. In either case, if a UnitDefinition had no child Unit elements, the unit was considered to be undefined.

The following example illustrates a complete unit definition (when written in XML) when 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:

    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.

◆ XMLAttributes_t

{core}

A list of attributes on an XML element.

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.

In libSBML's XML interface layer, attributes on an element are stored as a list of values kept in an XMLAttributes object. XMLAttributes has methods for adding and removing individual attributes as well as performing other actions on the list of attributes. Classes in libSBML that represent nodes in an XML document (i.e., XMLNode and its parent class, XMLToken) use XMLAttributes objects to manage attributes on XML elements.

Attributes on an XML element can be written in one of two forms:

  • name="value"
  • prefix:name="value"

An attribute in XML must always have a value, and the value must always be a quoted string; i.e., it is always name="value" and not name=value. An empty value is represented simply as an empty string; i.e., name="".

In cases when a prefix is provided with an attribute name, general XML validity rules require that the prefix is an XML namespace prefix that has been declared somewhere else (possibly as an another attribute on the same element). However, the XMLAttributes class does not test for the proper existence or declaration of XML namespaces—callers must arrange to do this themselves in some other way. This class only provides facilities for tracking and manipulating attributes and their prefix/URI/name/value components.

Note
Note that although XMLAttributes provides operations that can manipulate attributes based on a numerical index, XML attributes are in fact unordered when they appear in files and data streams. The XMLAttributes class provides some list-like facilities, but it is only for the convenience of callers. (For example, it permits callers to loop across all attributes more easily.) Users should keep in mind that the order in which attributes are stored in XMLAttributes objects has no real impact on the order in which the attributes are read or written from an XML file or data stream.
See also
XMLTriple
XMLNode
XMLToken

◆ XMLError_t

typedef class XMLError XMLError_t

{core}

XML-level 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 (

◆ XMLErrorLog_t

typedef class XMLErrorLog XMLErrorLog_t

{core}

Log of diagnostics reported during XML processing.

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.

◆ XMLNamespaces_t

{core}

An XML Namespace.

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.

◆ XMLNode_t

typedef class XMLNode XMLNode_t

{core}

A node in libSBML's XML document tree.

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:

◆ XMLToken_t

typedef class XMLToken XMLToken_t

{core}

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.

The libSBML XML parser interface can read an XML file or data stream and convert the contents into tokens. The tokens represent items in the XML stream, either XML elements (start or end tags) or text that appears as content inside an element. The XMLToken class is libSBML's low-level representation of these entities.

Each XMLToken has the following information associated with it:

  1. Qualified name: every XML element or XML attribute has a name (e.g., for the element <mytag>, the name is "mytag"), but this name may be qualified with a namespace (e.g., it may appear as <someNamespace:mytag> in the input). An XMLToken stores the name of a token, along with any namespace qualification present, through the use of an XMLTriple object. This object stores the bare name of the element, its XML namespace prefix (if any), and the XML namespace with which that prefix is associated.
  2. Namespaces: An XML token can have one or more XML namespaces associated with it. These namespaces may be specified explicitly on the element or inherited from parent elements. In libSBML, a list of namespaces is stored in an XMLNamespaces object. An XMLToken possesses a field for storing an XMLNamespaces object.
  3. Attributes: XML elements can have attributes associated with them, and these attributes can have values assigned to them. The set of attribute-value pairs is stored in an XMLAttributes object stored in an XMLToken object. (Note: only elements can have attributes—text blocks cannot have them in XML.)
  4. Line number: the line number in the input where the token appears.
  5. Column number: the column number in the input where the token appears.

The XMLToken class serves as base class for XMLNode. XML lends itself to a tree-structured representation, and in libSBML, the nodes in an XML document tree are XMLNode objects. Most higher-level libSBML classes and methods that offer XML-level functionality (such as the methods on SBase for interacting with annotations) work with XMLNode objects rather than XMLToken objects directly.

See also
XMLNode
XMLTriple
XMLAttributes
XMLNamespaces

◆ XMLTriple_t

typedef class XMLTriple XMLTriple_t

{core}

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. Triples by themselves are not entities in an XML stream—they are not, for example, elements or attributes; rather, XMLTriple is used in libSBML to construct these other kinds of objects.

An XMLTriple instance carries up to three data items:

  1. The name of the attribute or element; that is, the attribute name as it appears in an XML document or data stream;
  2. 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" />
    
  3. 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.

See also
XMLToken
XMLNode
XMLAttributes
XMLNamespaces