[petsc-dev] attempt at understanding PetscFEM

Jed Brown jedbrown at mcs.anl.gov
Mon Nov 18 18:39:55 CST 2013


Geoffrey Irving <irving at naml.us> writes:

> The seems to be a typo in the abstract:
>
>     This effect typically limits order to at most *quadratic*, despite
> the favorable accuracy and stability properties offered by *quadratic*
> and higher order discretization

I guess it sounds funny, but quadratic is the crossover point: too
expensive according to many people, but required by others.

> The index notation was the whole point, incidentally, since it
> transparently defines the order of array dimensions in the code.

Okay, that is a convention that I think you got right, but there are
vectorization reasons to change it in some settings, so if you're going
to build something significant, it would be worth hedging against index
ordering changes.

> With the current setup I think they need to be arrays of function
> pointers since different fields can live in different function spaces
> and have different quadrature rules.  However, the g0,g1,g2,g3 could
> be single arrays, and you could merge all f0,f1,g0,g1,g2,g3,g4 into a
> single array of function pointers for simultaneous residual+Jacobian
> evaluation.  Compacting it into a single function pointer always would
> require forcing the use of a single global quadrature rule.  I don't
> know if that would ever be a problem.

Terms would be grouped by quadrature rules, with one function per
quadrature rule.  The user would be free to split that evaluation into
parts.  If you have two quadrature rules and both need the material
properties, the properties need to be evaluated at both quadrature
rules.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20131118/efd11a23/attachment.sig>


More information about the petsc-dev mailing list