[petsc-dev] questions about PetscFEIntegrateResidual_Basic

Matthew Knepley knepley at gmail.com
Thu Jan 23 08:48:06 CST 2014


On Wed, Jan 22, 2014 at 2:29 PM, Geoffrey Irving <irving at naml.us> wrote:

> On Tue, Jan 21, 2014 at 10:12 AM, Geoffrey Irving <irving at naml.us> wrote:
> > PetscFEIntegrateResidual_Basic seems to have a redundant argument
> > list.  It takes a single PetscFE, an array of PetscFE's, and a field
> > index into the array.  The single PetscFE argument is ignored.  I
> > would imagine that either the field index or the single PetscFE should
> > be eliminated.
> >
> > Also, PetscFEIntegrateResidual_Basic allocates the f0 array with size
> >
> >     quad.numPoints * (spatial dimension of fe[0])
> >
> > but accesses it as if it had size
> >
> >     quad.numPoints * (number of components of fe[field])
> >
> > Am I reading this right?
>
> Correction: the single PetscFE is currently used to look up
> integration routines, so is far from unused.  However, it might be
> possible to look up these routines in the other PetscFE objects, and
> we might also want to verify that all PetscFE's have the same type to
> avoid corrupt behavior (not sure if that would be a problem or not).
>
> I still think we allocate f0 as the wrong size, though.


This is correct. The origin of the bug is a little obscure. I wanted
everything in this
interior function to be static (and I still think this would be nice). I
had #defined
the dimension, so if I assumed the numComp <= dim, this could happen. I
messed up
the conversion when I dropped the static allocation.

   Matt


>
> Geoffrey
>



-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20140123/61b0e659/attachment.html>


More information about the petsc-dev mailing list