[petsc-dev] PetscSection

[Jed Brown]

On Sat, Nov 10, 2012 at 12:45 PM, Matthew Knepley <knepley at gmail.com> wrote:

> It just depends on what you want your assumptions to be. I am all for
> experimenting. The
> foregoing strategy is good because closure continues to work as
> advertised, and all our
> integration code is still dim-independent, but the assumption that
> height 0 things are all
> cells breaks down. This is not so bad, since we usually want to group
> cells by material
> anyway, using a Label, so I am fine with this.
>

Okay, my complaint is that "stratum" is an additional concept that has no
established use in the current lexicon and the generality of which doesn't
really help the user because they have to do different things for codim 0
and codim 1 anyway. If we are not causing extreme hardship or irreparably
crippling the flexibility of their code, I think the interface should give
access to by codim instead of by stratum.

Now in the P1 case, the faces do not store any data, therefore
closure(some_cell) returns the same thing going directly to vertices as if
the intermediate dimensions were populated. I think that by definition,
this sort of mesh does not support getting faces of a cell, therefore it's
correct to not store the cell -> boundary-face relation. The user can ask
to interpolate the mesh if they want.

I'm not sure about the multi-domain case where the user wants a high-order
discretization in one domain and a P1 with non-interpolated mesh in
another. The benefit of non-interpolated doesn't seem so clear in this case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20121110/19d3e759/attachment.html>