This section documents the following known problems, limitations, and possible pitfalls in using libSBML:

- Name collisions in mathematical expressions
- Differences in mathematical formula syntax
- Differences in XML parser behavior
- Potential for language bindings to link old versions of libSBML by accident
- Possible unexpected `make uninstall` behavior
- Java exceptions when running in stock Tomcat 6 under Ubuntu "Intrepid"
- Conversion to/from SBML Level 1 Version 1 is not supported
- Warnings during creation of documentation

## Name collisions in mathematical expressions

In the C-like, text-based, formula expression syntax supported by libSBML and used in SBML Level 1, four constants are reserved words: `true`, `false`, `exponentiale` and `pi`. Most of them will not easily lead to a name collision, but unfortunately, the character sequence `pi` is also sometimes used as a species identifier by biological modelers (e.g., to use "Pi" to represent a phosphate ion). If the string "`pi`" or "`Pi`" appears in a text string passed to a libSBML method that interprets formulas, it will be interpreted as the mathematical constant π (pi). For example, the expression 2 * Pi will yield

    <math xmlns="http://www.w3.org/1998/Math/MathML">
      <apply>
        <times/>
        <cn type="integer"> 2 </cn>
        <pi/>
      </apply>
    </math>

This problem exists for all four of the constants mentioned above, but is most commonly encountered in the context of "pi". Currently, the only ways to avoid this problem are either to avoid using the strings "pi" and "Pi" in this context, or to avoid using the text-string expressions altogether and instead use ASTs. All libSBML methods that accept text-string mathematical formulas have variants that accept ASTs instead.

## Differences in mathematical formula syntax

The functions `char* SBML_formulaToString(const ASTNode* tree)` and `ASTNode* SBML_parseFormula(const char* formula)` can be used to convert mathematical formulas to/from a text-string format. However, MathML (the XML encoding format used in SBML Level 2 for mathematical formulas) does not have a defined standard text-string representation. LibSBML arbitrarily uses the syntax defined by SBML Level 1 (which used a text-string representation of formulas and not MathML). For the most part, this syntax maps directly to MathML, but there are differences in a few of the symbols used to represent the common mathematical functions. In particular, in the text-string syntax, `log(x)` represents the natural logarithm, whereas in MathML, the natural logarithm is `<ln/>`. Application writers are urged to consult the documentation for `SBML_formulaToString()` and `SBML_parseFormula()`, and to be careful when translating between text forms and MathML forms (especially if their application provides a direct text-string input facility to users).

## Differences in XML parser behavior

The different parsers supported by libSBML (Xerces, Expat, libxml2) behave slightly differently when reading files, and the differences are difficult for libSBML to hide. The following are the differences of which we are currently aware:

1. Libxml2 version 2.6.16 on MacOS X, which is the default version of libxml installed on Macs in /usr/lib up through at least 10.5.1, fails to report uses of undefined namespaces in an XML document. This means that a construct such as `n:attribute`, where `n` is a namespace prefix that is not defined, will be silently ignored. As a result, libSBML cannot catch and report this error when libSBML has been configured with this version of libxml2. We know of no workaround at this time except to compile your own copy of libxml2 or use another parser library. (Incredibly enough, libxml 2.6.16 built from original sources on a Mac does report the error. The only explanation is that that Apple is shipping a modified version of libxml 2.6.16.)
2. Expat and libxml2 tend to quit earlier than Xerces when they encounter an XML error in an input stream, whereas Xerces tends to process the input further and report an error as being on the element in which the XML error occurs. The result is that the first error reported by libSBML is sometimes different depending on which of the underlying XML parsers is being used. In our tests, this affects almost exclusively low-level XML syntax errors (such as start/end tag mismatches, unterminated strings) and not SBML errors per se, although a basic XML error can of course mask other, more substantive errors. The exceptional cases (the reason for the "almost" in the previous sentence) concern SBML Level 2 Versions 3 and 4 validation rules 10309 (detection of metaid syntax), and rules 10802, 10803, 21004 and 21005 (detection of disallowed XML constructs inside `<notes>` and `<annotation>` elements).

## Potential for language bindings to link old versions of libSBML by accident

At application run-time, the language bindings for C#, Java, Python, Perl and others must be able to dynamically link the core libSBML library file (i.e., `libsbml.so`, `libsbml.dylib` or `libsbml.dll`, depending on your operating system). If a user's environment includes an old version of this library file, and it is picked up at run-time instead of the correct library version, linking may fail with mysterious errors about undefined symbols. Users and developers are cautioned to make sure that their installations have matched versions of libSBML components and are free of older versions that may be picked up inadvertently.

## Possible unexpected `make uninstall` behavior

The libSBML `make uninstall` command on Linux, MacOS, Cygwin, and Solaris only knows about the features most recently configured into libSBML. If you run `configure`, then `make install`, then run `configure` again with different options, and finally try `make uninstall`, the result will be to attempt removing the files implied by the most recent run of `configure`, not the files installed by the original `make install`.

## Java exceptions when running in stock Tomcat 6 under Ubuntu "Intrepid"

(Thanks to Allyson Lister for reporting and solving the following.) For reasons that remain a mystery, attempting to use the libSBML Java interface from within an application installed as a war file in the stock version of Tomcat v.6 under the Ubuntu "Intrepid" release will result in exceptions such as the following:

     java.lang.UnsatisfiedLinkError:
     org.sbml.libsbml.libsbmlJNI.new_SBMLReader()J

The cause appears to be unrelated to libSBML. Users are advised to uninstall the stock tomcat6 package that comes from running the command `sudo apt-get install tomcat6`, and instead install the latest version of Tomcat. The following detailed recipe comes from Allyson Lister:

1. Run `sudo apt-get remove tomcat6` followed by `sudo apt-get autoremove` to remove the copy of Tomcat that came with the Ubuntu installation.
2. Download the latest version of Tomcat (6.0.18) from the Tomcat website, and unpack it into a location of your choosing.
3. Open `bin/catalina.sh` in an editor and add the following line to the beginning of the file (after the main comments section at the top of the file):

          JAVA_OPTS="$JAVA_OPTS -Djava.library.path=/usr/local/lib"

4. Start Tomcat and load your war file. The application should now be able to access all the native libraries from libSBML.

## Conversion to/from SBML Level 1 Version 1 is not supported

The method `SBMLDocument::setLevelAndVersion()` performs conversion between versions and levels of SBML (to the extent possible within technical and practical limits). However, conversion to/from SBML Level 1 Version 1 is not supported.

## Warnings during creation of documentation

If you run the commands to generate the libSBML documentation, there will be warnings printed for all except the C++ documentation. These warnings still exist as of version 3.1 of libSBML. Most of the warnings are known incompatibilities that are next to impossible to resolve between the different tools used to generate different versions of the API documentation. It is probably safe to ignore them. Hopefully the warnings will be eliminated in a future version of libSBML.