Chronological Thread 

< Chronological >      < Thread >

---

On 14/12/11 06:05, Alan Garny wrote:
>
> Hi there,
>
> Trying to find my way around the CellML API (C++ binding), I have two
> main questions at this stage:
>
> -Is there a way to tell whether a model needs a 'simple' ODE solver
> (e.g. CVODE
> <https://computation.llnl.gov/casc/sundials/description/description.html#descr_cvode>)
>
> or a DAE solver (e.g. IDA
> <https://computation.llnl.gov/casc/sundials/description/description.html#descr_ida>)
>
> to be computed? It seems to me, from looking at the source code of
> both the CellML API and OpenCell, that there might not be. I mean, I
> couldn't find anything in the CellML API while, in OpenCell,
> generation of ODE or DAE code seems to be based on the choice of
> integration scheme (i.e. IDA or not). This being said, could
> CodeInformation::algebraicIndexCount()
> <http://cellml-api.sourceforge.net/latest-release/interfacecellml__services_1_1_code_information.html#a6c71ad34951cb150a7f89d2252a848ec>
>
> be a way to determine what I am after?
>

Hi Alan,

The CCGS and CIS do not provide any mechanism to only solve ODE systems;
DAE systems can be solved using CVODE by solving for the algebraic
equations through decomposition into systems that can be solved; for
example, if you have a simple DAE system:
y = 2x
dx/dt = y
Then asking for code to solve it with CVODE will generate a function for
solving for the rates by computing the algebraic variables ('y') first,
and then computing the rates needed.

If you have a more complex DAE system:
0 = sin(y + 2x)
dx/dt = y
then the solver won't be able to work out analytically how to compute y
from x, so the function to compute rates will include a call to a
non-linear solver; however, from the perspective of CVODE, it is still a
function that takes the state variables and computes the rate.

IDA code generation, on the other hand, will make x and y variables in
the system. Therefore, both methods will allow the above two systems to
be solved.

The code generation will give an error if it can't generate code of the
appropriate type; if you really want ODEs only, you can use
algebraicIndexCount as you mention. OpenCell put the choice of
integrator up to the user, had a default (which I think was to always
use IDA in the final release), but would support nearly all models using
either CVODE or IDA.

> -I need to convert CellML models to binary code (using the LLVM
> <http://www.llvm.org/>-JIT AP), so I don't think I can rely on the
> CeLEDS and CeLEDSExporter services for this task? Ideally, there would
> be a way, using the CellML API, to get a procedural representation of
> the model, making it 'easy' then to generate binary code. Right now, I
> am thinking of writing my own code based on that of
> CodeGenerationState::GenerateCode(), but needless to say that I would
> rather not go that route. So, have I missed something or should I sit
> down and get coding...?
>
Going directly to binary procedural code using the API has not been
tested; in theory, there should be no limits on the code that can be
generated, but I think in practice there are a few places where we call
C functions / pass strings in null-terminated form (e.g. in libxml if
you are using CeLEDS), which will make embedding null bytes in the
output difficult - something that is essential for generating machine
code directly.

I'd suggest generating some kind of plain-text intermediate procedural
language - I don't see any fundamental reason why it wouldn't be
possible to generate LLVM Assembly using CeLEDS and CeLEDSExporter, you
would just need to create an XML file describing the transformation.

That said, I'm not sure why you aren't just using CIS, which does
everything automatically, compiling via C, so all you have to do is make
sure gcc is available (with linking on Mac being the only tricky part,
and one that looks like it can be easily overcome).

Best wishes,
Andrew

> Cheers, Alan.
>
>
> _______________________________________________
> cellml-tools-developers mailing list
> cellml-tools-developers at cellml.org
> http://lists.cellml.org/mailman/listinfo/cellml-tools-developers

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.cellml.org/pipermail/cellml-tools-developers/attachments/20111214/afaf03af/attachment.htm>

---

• [cellml-dev] A couple of CellML API questions, Alan Garny, 12/14/2011
  • [cellml-dev] A couple of CellML API questions, Andrew Miller, 12/14/2011
    • [cellml-dev] A couple of CellML API questions, Alan Garny, 12/14/2011

---

Archive powered by MHonArc 2.6.18.