Chronological Thread 

< Chronological >      < Thread >

---

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!). 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.
>
Hi Alan,

I have been putting some work into improving the performance of PCEnv. I
now only compute the variables that can affect the rates when computing
the Jacobian (but this doesn't make any difference for the Zhang SAN
model, because it uses all variables to compute the rates, directly or
indirectly). I also got about a 20% performance increase by compiling
the generated code with -ffast-maths, which would be giving similar
machine code to what you are writing (it makes things less IEEE754
compliant, but CIS still works without it).

You didn't say what error control parameters you were using. I presume
you are running this with error controls in PCEnv matched to the ones
used in COR?
> 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 think this is a metadata related issue which only happens on Win32. I
will look into why this is happening.
> 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
The GSL developers have tried hard to make their GEAR1 accurately
reproduce the results (and algorithm) from the original GEAR1.F
integrator, so I don't think we can expect it to match the improved
BDF/Newton algorithm from CVODE. I will look into how hard it would be
to produce a derivative of the GSL Gear module which behaves like the
CVODE version.

Best regards,
Andrew

---

• [cellml-discussion] Binary and source snapshots for PCEnv on Win32 and Linux, Andrew Miller, 10/27/2006
  • [cellml-discussion] Binary and source snapshots for PCEnv on Win32 and Linux, Alan Garny, 10/27/2006
  • [cellml-discussion] Binary and source snapshots for PCEnv onWin32 and Linux, David Nickerson, 10/27/2006

---

Archive powered by MHonArc 2.6.18.