Chronological Thread 

< Chronological >      < Thread >

---

Hi Andrew,

> > I ran one of my CellML files using the default (i.e. Implicit
> > Runge-Kutta
> > (2) with solve) and it was *extremely* slow. After a couple
> of minutes
> > I had to kill PCEnv, as it was slowing down my computer to
> the point
> > where I could barely use it (and couldn't cancel the integration!).
> It seems that cancel integration never got implemented. I
> have opened a bug on this at http://www.cellml.org/tools/pcenv/bugs/18
>
> I'm not sure what is causing your speed issue without looking
> at your model. What process is using 100% CPU, PCEnv or
> cellml_corba_server? You mention below you tried this on
> Linux, did you get the same performance issues there?

Please find attached a ZIP file that contains my model. Otherwise, the
process that was taking 100% of the CPU was cellml_corba_server. Regarding
Linux, I got exactly the same behaviour, but as I said I only tried with one
integrator (Implicit Gear (M=1)).

> Did you define any graphs first? (PCEnv plots data as it
> comes in, rescaling as required, which can slow things down a
> lot for large data sets. If you don't want this performance
> hit, turn graphs off in the key until your data is all in).

I did define one graph indeed. Still, this should not be a performance hit.
COR graphically outputs data too (and does some rescaling too) and it's
still very fast indeed. The figures I gave you were with graphical output.
Raw computational time was much smaller.

> > By that time, it had
> > only managed to compute 3 s worth of cardiac activity. Just for
> > comparison, using COR, I can compute that same model for 10
> s in less
> > than a second (with graphical output and everything) using CVODE
> > (BDF/Newton). Using an explicit Runge-Kutta (2), it takes
> less than 13 seconds to compute.
> >
> > After that, I restarted PCEnv, reopened my CellML file and
> it opened
> > 'fine', except that I couldn't see anything in the 'middle'
> window. I
> > could, however, run it, which I did using Implicit Gear (M=1). This
> > turned out to be much faster, but still very slow compared with COR
> > (even compared with an
> I have found that the implicit Gear methods are usually
> slower even than the implicit Runge-Kutta methods, so it
> could be something specific to your model that is getting
> handled inefficiently. If you could send me your model, it
> would help to figure out what is going on there.

I don't think the model I use is that specific at all (not in cardiac
electrophysiological terms at least). Also, I am not familiar with the Gear
integrator, but I was under the impression that it is good for stiff
problems, which cardiac electrophysiological problems are.

> > explicit RK2 integrator). Also, once the computation is finished, I
> > don't seem able to rerun the model anymore (the integration
> button is gone!).
> >
> This is by design, because each entry in the model selector
> (left pane) is supposed to correspond to one integration run.

As a user, I find this to be a big limitation. Modellers like to be able to
rerun a model either from its intial conditions or current conditions. This
is what they do all the time. What do they have to do in PCEnv to achieve
that? Also, what about, for instance, pausing a simulation, changing some of
its parameters and resuming the simulation?

> Once a model has been run, it is 'frozen', which means that
> you can't change anything in that copy of the model (this
> ensures there is no confusion about which parameters /
> initial conditions were used to generate the result).

Again, I am not sure I like that. I think people who do cellular modelling
might find this very constraining.

> If you change anything, e.g. an initial_value attribute, or
> an integrator parameter, it should prompt you to 'clone' the
> model (you can also manually clone by right clicking on the
> model in the model selector, and choosing 'Clone' from the
> menu). The clone is no longer frozen and can be run again.

I think I am starting to see the logic in your approach. Still, I am not
sure the implementation is right or whether it should even be implemented in
the first place. At the end of the day, from a modeller's viewpoint, the
user will still have to keep a record f what the different 'instances' of
their model relate to or do you have a mechanism that can tell the user that
this or that 'instance' is equivalent to the control model + this or that
modification?

> > I also tried Implicit Gear (M=2) and nothing happened...
> Implicit B-S
> > B-D worked, but was extremely slow (same order of magnitude as
> > Implicit RK2, but then got stuck after 3 ms).
> I believe that the speed is probably normal for this
> algorithm (at least for the GSL implementation). I guess that
> it doesn't really get stuck, it just slows down to the point
> that you can never reasonably expect it to complete around
> some parts of the model. It is worth noting that the GSL
> requires B-S B-D be given a Jacobian function (presumably
> they want an analytic Jacobian, which CCGS doesn't provide,
> so instead, I have given it a numerical Jacobian. I suspect I
> might be able to optimise this somewhat, as well) .

Well, whatever the case, it is very slow indeed and wouldn't be useable for
me or, I think, anyone in our group.

Just out of curiosity, I have run the attached model for 1,000 seconds and
plotted its trans-membrane potential against time. It took, on my laptop (a
2-year old laptop with a 2 GHz processor), 60.884 s for the simulation to
complete (incl. graphical output), of which 37.787 s were used for the
computation of the model itself. I would be curious to know how long it
takes using PCEnv. Maybe performances will be better when using
Windows/Linux 'natively' as opposed to from within VMWare, even though I can
barely notice the difference when running COR under Windows within VMWare.

Alan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zhang_SAN_model_2000_all.zip
Type: application/x-zip-compressed
Size: 9272 bytes
Desc: not available
Url :
http://www.cellml.org/pipermail/cellml-discussion/attachments/20061024/c1636abc/attachment-0001.bin

---

• [cellml-discussion] Binary and source snapshots for PCEnvonWin32and Linux, Andrew Miller, 10/25/2006
  • [cellml-discussion] Binary and source snapshots for PCEnvonWin32and Linux, Alan Garny, 10/25/2006
    • [cellml-discussion] Binary and source snapshots for PCEnvonWin32and Linux, Andrew Miller, 10/25/2006
    • [cellml-discussion] Binary and source snapshots for PCEnvonWin32and Linux, Andrew Miller, 10/25/2006
      • [cellml-discussion] Binary and source snapshots for PCEnvonWin32and Linux, Alan Garny, 10/25/2006

---

Archive powered by MHonArc 2.6.18.