dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Jul 21, 2011 at 12:02:23AM -0700, Johan Hake wrote:
> > > Hello!
> > >
> > > I know this has been discussed earlier, but I cannot find a bug or
> > > blueprint reported for it.
> > >
> > > Let say I have a MixedSpace containing several global dofs (Real spaces)
> > > and one CG. Even if I define a form using functions defined only on the
> > > CG space it takes literally forever to assemble... This is because for
> > > each cell, a bunch of zeros are added to the global matrix, as the
> > > dofmap which defines the element matrix, is based on the whole
> > > MixedSpace. It would be _really_ nice if the size of the element matrix
> > > was based on the actuall dofs that get assembled.
> >
> > As a quick fix, try using the Epetra backend. My experience is that it's
> > much faster for this type of case. It must use a different search method
> > for insertion than PETSc.
>
> That helped _a lot_! Unfortunatly it looked like some assert kicked in when
> using the NewtonSolver:
>
> python: /usr/include/boost/smart_ptr/shared_ptr.hpp:412: typename
> boost::detail::shared_ptr_traits<T>::reference boost::shared_ptr< <template-
> parameter-1-1> >::operator*() const [with T = Epetra_FECrsMatrix]: Assertion
> `px != 0' failed.
> [bamse:25675] *** Process received signal ***
> [bamse:25675] Signal: Aborted (6)
> [bamse:25675] Signal code:  (-6)
> [bamse:25675] [ 0] /lib/libpthread.so.0(+0xfb40) [0x7ff3bf52ab40]
> [bamse:25675] [ 1] /lib/libc.so.6(gsignal+0x35) [0x7ff3be34bba5]
> [bamse:25675] [ 2] /lib/libc.so.6(abort+0x180) [0x7ff3be34f6b0]
> [bamse:25675] [ 3] /lib/libc.so.6(__assert_fail+0xf1) [0x7ff3be344a71]
> [bamse:25675] [ 4]
> /home/hake/bzr/fenics/dolfin/work/build/dolfin/libdolfin.so.0.9(_ZN6dolfin12EpetraMatrixaSERKS0_+0x156)
> [0x7ff3b983d7a6]
> [bamse:25675] [ 5]
> /home/hake/bzr/fenics/dolfin/work/build/dolfin/libdolfin.so.0.9(_ZN6dolfin12EpetraMatrixaSERKNS_13GenericMatrixE+0x52)
> [0x7ff3b983da12]
> [bamse:25675] [ 6] /home/hake/local/lib/python2.6/site-
> packages/dolfin/_cpp.so(+0xe0f23) [0x7ff3b9d4df23]
> [bamse:25675] [ 7] python(PyEval_EvalFrameEx+0x5ca4) [0x4a5ce4]
> [bamse:25675] [ 8] python(PyEval_EvalCodeEx+0x911) [0x4a6bd1]
> [bamse:25675] [ 9] python() [0x535b50]
> [bamse:25675] [10] python(PyObject_Call+0x47) [0x41c9d7]
> [bamse:25675] [11] python() [0x42570f]
> [bamse:25675] [12] python(PyObject_CallMethodObjArgs+0x1e4) [0x4209c4]
> [bamse:25675] [13] /home/hake/local/lib/python2.6/site-
> packages/dolfin/_cpp.so(_ZN29SwigDirector_NonlinearProblem1JERN6dolfin13GenericMatrixERKNS0_13GenericVectorE+0xfe)
> [0x7ff3b9d3a3be]
> [bamse:25675] [14]
> /home/hake/bzr/fenics/dolfin/work/build/dolfin/libdolfin.so.0.9(_ZN6dolfin12NewtonSolver5solveERNS_16NonlinearProblemERNS_13GenericVectorE+0x180)
> [0x7ff3b9936b00]
> [bamse:25675] [15] /home/hake/local/lib/python2.6/site-
> packages/dolfin/_cpp.so(+0x1402e8) [0x7ff3b9dad2e8]
> [bamse:25675] [16] python(PyEval_EvalFrameEx+0x5ca4) [0x4a5ce4]
> [bamse:25675] [17] python(PyEval_EvalFrameEx+0x5a70) [0x4a5ab0]
> [bamse:25675] [18] python(PyEval_EvalCodeEx+0x911) [0x4a6bd1]
> [bamse:25675] [19] python(PyEval_EvalFrameEx+0x4d19) [0x4a4d59]
> [bamse:25675] [20] python(PyEval_EvalFrameEx+0x5a70) [0x4a5ab0]
> [bamse:25675] *** End of error message ***
> Aborted
>
> Have any one used Epetra backend for hand cooked NonlinearProblems in Python.
> It looks like somehting might happen with the director typemap here...

You should file a bug report. Maybe our Python maintainer will look at
it. He's an expert in typemaps and directors... ;-)

--
Anders


> > > Garth has previously mentioned that this is done to simplify the assemble
> > > interface, which is understandable. However, beside fixing assemble of
> > > global dofs in paralell this is my biggest wish for ufc/ffc/dolfin at
> > > the moment :)
> > >
> > > Unfortunatly I know to little about the ufc/ffc part of FEniCS to say
> > > anything useful about what it would take to implement, but I would like
> > > to here what others think.
> >
> > I vaguely recall a blueprint on identifying in the generated code global
> > dofs. I think that this is necessary in order to handle parallel
> > assembly, etc, of global dofs.
>
> Me too, but I could not find it.
>
> Johan
>
> > Garth
> >
> > > Best regards,
> > >
> > > Johan
> > >
> > > _______________________________________________
> > > Mailing list: https://launchpad.net/~dolfin
> > > Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> > > Unsubscribe : https://launchpad.net/~dolfin
> > > More help   : https://help.launchpad.net/ListHelp
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~dolfin
> > Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~dolfin
> > More help   : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp