Alan Garny wrote: > As you know, there is a CellML 1.0 version of the epicardial version of the > ten Tusscher model, which we have. I computed that model for one-second > worth of cardiac activity, plotting the trans-membrane potential. From > there, we could extrapolate to 70 minutes by saying that the frequency of > the stimulus is 1 Hz. Like David, I have set the maximum time step to 0.1 > ms. Here are some rough figures: > > Simulation time: 1037.4 s (i.e. ~17 min 17 sec) > Computation time: 684.6 s (i.e. ~11 min 24 sec)
so the total (predicted) wall clock run time is 17minutes? or 28minutes? any chance you could run something longer than a 1s simulation and extrapolate from there, if not run a whole 70minutes worth? If not, I guess I can run it next time I'm on a windows machine ;) > The computer on which I have run this is an IBM ThinkPad T42p (2 GHZ > processor with 2 GB of RAM). These figures can obviously vary quite a bit, > since it's based on a one-second simulation and is subject to whatever my > system does at the time... Still, that should give you a rough idea > indeed... > > Alan. > >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of >> David Nickerson >> Sent: 30 October 2006 10:14 >> To: For those interested in contributing to the development of CellML. >> Subject: Re: [cellml-discussion] pcenv development priorities >> >> Just thought it might be useful to establish some benchmarks >> for comparison of performance amongst the various tools. >> >> 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 s >> CPU 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: >>>> 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. >>>> >>> Please refer to my messages on the 27th of this month, >> where I discuss >>> the results of profiling it in callgrind. >>> >>> 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] >> > > _______________________________________________ > 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] _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
