I have attached my version of the ten Tusscher et. al (2004) human ventricular cell electrophysiology model, its in CellML 1.1 and uses relative URIs for all the imports. If there was an easy way to flatten the model Alan could try it in COR and we could also give it a go in JSim....and others...
If you extract the attached file, there is a CellML model model/2004_tenTusscher/experiments/increasing-frequency-epicardial.xml which describes the boundary conditions etc. and simulation metadata for a simulation running the epicardial variant of the ten Tusscher model for 70 minutes with a periodic stimulus protocol with a frequency that varies from 0.25 to 3Hz.
I run this simulation as specified in the simulation metadata using the BDF multistep method with Newton iteration from the CVODES integrator (using the dense direct linear solver). The full solution (every time varying variable) is saved every 1ms and the integration has a maximum time step of 0.1ms. My resulting HDF5 data file is 2.9GB and the timing, memory usage, and integrator stats were:
Wall clock time : 1.57464269e+03 sCPU time : 1.54678467e+03 s (user 1.52703543e+03/system 1.97492340e+01)
Total allocated space: 22786048 bytes
in use: 22362384 bytes
free: 423664 bytes
Final integrator statistics for this run:
(MM: BDF; IM: Newton; LS: Dense; max-step: 1.0000e-01)
CVode real workspace length = 266
CVode integer workspace length = 62
Number of steps = 44973141
Number of f-s = 47068790
Number of setups = 3852394
Number of nonlinear iterations = 47068785
Number of nonlinear convergence failures = 19131
Number of error test failures = 283742
Linear solver real workspace length = 578
Linear solver integer workspace length = 17
Number of Jacobian evaluations = 814797
Number of f evals. in linear solver = 13851549
I also used the Unix command time to get total execution time:
1530.279u 19.817s 26:18.03 98.2% 0+0k 0+0io 0pf+0w
So it took just almost 26.5 minutes to run this simulation (the
difference between the time command output and the times reported above
is the setup time prior to the integration loop - i.e. generating and
compiling the C code).
Hopefully this proves useful in establishing some idea of the relative performance of various tools/integrators.
David.PS - the attached model seems to work for me, but its possible I have either missed some relative links or left out some required files...
Andrew Miller wrote:
David Nickerson wrote:Please refer to my messages on the 27th of this month, where I discuss the results of profiling it in callgrind.Hi all,From today's meeting minutes the following priorities were set for the development of pcenv:1. Make an official release of what we have now, instead of just snapshot releases. 2. Try to improve integration performance, by using CVODE from the SUNDIALS project. 3. Investigate the possibility of getting Mac OSX support - Intel only to start with.4. Get editing support for MathML and the CellML structure working.5. Add CellML Metadata support to the backend, and editing support for this to the UI.I'm just wondering if 2 is more important than 1?From feedback so far, the performance of pcenv is very poor compared to other tools. There is currently (to my knowledge) no firm idea if this is due to the underlying technology being used by pcenv, or simply due to the numerical integrators being used not being as good as what most people are currently using.The major performance bottleneck is the the evaluation of the Jacobian function (I use the standard O(n^2) method for generating a dense Jacobian in an array, and most of the time is spent evaluating the variables). Although COR is closed source and so I cannot see exactly what it is doing. Given that COR apparently isn't doing any optimisation here, it must be taking a comparable amount of time per Jacobian computation, so the difference must be in the number of calls to compute the Jacobian.Seems it would be good to address this question now, because if using something like CVODE still results in the same poor performance then I think some serious thinking needs to be done about the underlying technology before an official release of pcenv should be made.I understand that you already have CVODE working with CCGS, so perhaps you can give some indication of how well CCGS generated code works with CVODE?Best regards, Andrew _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
-- David Nickerson, PhD Research Fellow Division of Bioengineering Faculty of Engineering National University of Singapore Email: [EMAIL PROTECTED]
2004_tenTusscher.tar.gz
Description: GNU Zip compressed data
_______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
