Alan Garny wrote:
> Hi Andrew,
>
>
>> I have been trying to reproduce the issue you reported,
>> without much success (I have now tried on a Win32 box with no
>> MingW / Cygwin on it as well). It would be useful if you could state:
>> 1) What version of Win32 you are running this on.
>> 2) What model(s) you are trying to load. If they aren't in
>> the CellML model repository, sending me the model would also help.
>> 3) Whether or not you enabled
>> javascript.options.showInConsole first, as discussed in my
>> e-mail to Andre earlier. By default (in Mozilla), the
>> Javascript console hides chrome errors (the idea being that
>> most users debug Javascript in webpages, rather than the
>> Mozilla / Firefox UI).
>> However, this doesn't apply for PCEnv, so I have turned
>> javascript.options.showInConsole on by default now. This will
>> appear in the next snapshot to be released. Until then, you
>> can manually turn it on by editing <install
>> directory>/defaults/preferences/prefs.js and adding:
>> pref("javascript.options.strict", true);
>>
>
> I have just downloaded today's snapshot and it is now working fine. I don't
> know what was responsible for the problem(s) I experienced, but you
> obviously fixed it/them.
>
> 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?
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).
> 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.
> 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. 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).
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 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) .
Best regards,
Andrew
_______________________________________________
cellml-discussion mailing list
[email protected]
http://www.cellml.org/mailman/listinfo/cellml-discussion
