Chronological Thread 

< Chronological >      < Thread >

---

Alan Garny wrote:
> 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)).
>
>
It seems it is spending most of the time computing numerical Jacobians,
no matter what integrator is being used. I will look into optimising
this process (I am profiling it now).
>> 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.
>
I probably just need to cache data for longer (I think it is rescaling
too often) before updating, and the impact of updating the graphical
data live on the performance should be mitigated somewhat.

However, the problem for this model is definitely on the computation
side, not the graphical side.
>
>>> 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.
>
I believe it generally gives good results for stiff problems, but it is
slow.
>
>>> 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?
If you haven't changed anything, why would you want to re-run in the
same session? If you want to change the model, the clone functionality
is what you want.
> Also, what about, for instance, pausing a simulation, changing some of
> its parameters and resuming the simulation?
>
mozCellML used to deal with this by letting you create a new model based
parameterised by the state of the model at a given time, but people
found it too complex. This could be added into PCEnv if it anyone thinks
it is worth it.
>
>> 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?
>
Right click on the model in the model selector, and choose 'Rename', and
you can give your model clones whatever name you like. Also, the model
selector lets you view your models as a hierarchy based on changes(that
is the default, and sounds like what you want), or as a flat list based
on creation time, or as a list of the latest versions for each loaded
model file (use the drop-down box above the model selector tree to
change between the views).
>
>>> 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.
>
This is not the default algorithm, so if one algorithm is too slow for a
particular type of model, just avoid it (it may be useful for some other
users, so I don't think we should remove it).

Best regards,
Andrew

---

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