search

OpenCMISS / cm

www.opencmiss.org
60 stars 93 forks source link

Implementing SUNDIALS BDF Solver through PETSc #204

Closed nickerso closed 9 years ago

nickerso commented 9 years ago

Replacing Vijay's original pull request #201 with the same code but now in my branch in which I will address the review comments from #201 and any others that crop up. See tracker item 3913 (https://tracker.physiomeproject.org/show_bug.cgi?id=3913).

chrispbradley commented 9 years ago

@nickerso what is the decision with this? Clearly there is going to be a problem using PETSc for this. Shall we just pull this as is for the current merge and then fix it all up later?

nickerso commented 9 years ago

@chrispbradley if you are happy to merge it as is, then we should go ahead with this implementation with the acknowledgement that it is not the most optimal solution. We can then come up with a plan on how to enable more integrators in an efficient manner.

This does seem to work (for the limited testing I have done in "single cell" simulations), and presumably it was sufficient for @vraj004 needs. So I think its ok as a first step toward support for more useful integrators.

vraj004 commented 9 years ago

Hi guys, sorry I haven't been able to respond as quickly as might have been useful. Can you update me on why you don't want to use PETSc?? Its one of the linked libraries and SUNDIALS has several integrators - not just BDF - that would be useful to link with opencmiss. I also did a test with the SUNDIALS Euler to check that it gives the same answers as the Euler that has been implemented in the CMISS_LIBRARY. I have tested my BDF implementation on several examples and can say that it is correct.

vraj004 commented 9 years ago

ps: there were several inconsistencies in the cmiss-petsc-wrapper routines that I had to fix to ensure that cmiss calls matched the petsc library calls. Also, you may wish to upgrade the PETSc and SUNDIALS libraries because the interface routines have changed considerably in the latest versions by these external developers.

chrispbradley commented 9 years ago

Hi Vijay, The problem is that PETSc is not really set up to handle problems like the ones we need to solve. It is set up to solve a single set (single state vector etc) of ODEs like the ones that derive from FEM. The situation we have is a large number of ODEs which would give something like a matrix of state vectors. To get around this you resetup the PETSc problem for every dof for every time step. We may be able to optimise this a little and have, say, a single PETSc TS object but we would still need PETSc Vec objects for every dof (very wasteful for a large number of dofs). Thus the PETSc implementation is very inefficient in terms of memory and time. It may be better for us to directly call something like CVODE which would enable us to optimise memory and inefficiencies etc.

vraj004 commented 9 years ago

Aah, thanks for that explanation, Chris. This helps me understand your thought process and for future reference when I implement more features.