[petsc-dev] PetscSection

[Matthew Knepley]

On Sat, Nov 10, 2012 at 12:04 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> On Sat, Nov 10, 2012 at 10:40 AM, Blaise A Bourdin <bourdin at lsu.edu> wrote:
>>
>> On Fri, Nov 9, 2012 at 10:20 PM, Blaise A Bourdin <bourdin at lsu.edu> wrote:
>>>
>>> A DM does double duty by describing the geometry of the mesh, and the
>>> data layout associated with the finite element space. I liked the model
>>> where the mesh geometry and the data layout on the mesh was split in two
>>> objects, but I understand the convenience of having everything in the DM,
>>> and DMClone works just fine. Since I may have to handle scalar, vector, 2nd
>>> and 4th order tensor on 2 different finite element spaces, in an assembly
>>> loop, I may end up dealing with as many as 8 DM. I stick all these DM's in
>>> the user context of each DM associated with a unknown (a Vec on which I may
>>> have to call SNESSolve or TSSolve), hoping that this is not creating some
>>> aliasing problem which as  a fortran programmer I can not possibly
>>> understand.
>>
>>
>> ;-)
>>
>>
>> Actually, I am really not sure if passing a dm and a pointer to a user
>> context containing this dm is legit or not...
>
>
> Ah, okay. To confirm, you have a DM that you are solving for, and in its
> user context, you have several other DMs, each with a Vec, describing the
> "problem data" like coefficients, forcing terms, and internal
> discontinuities? That is completely fine, and not "aliasing", but it does
> not play well with geometric multigrid because coarse grids reference the
> same application context. We have a system of hooks for managing such
> resolution-dependent data, though only with a C interface so far. (We needed
> this to get geometric multigrid and FAS to work with TS. Most non-toy
> applications need it too.)
>
> I'm not sure if there is a way to make this easier. We have been using
> PetscObjectCompose() to attach things to the DM on different levels. We
> could have a slightly friendlier "user" interface for that.
>
> So keeping those things in the app context is just fine, but if you want to
> use geometric multigrid, you'll have to take them out of the app context and
> put them in a different structure attached to the DM that is not
> transparently propagated under coarsening and refinement. If you think you
> might do this eventually, I recommend commenting/organizing your app context
> so that resolution-dependent stuff is easily identifiable.
>
>>
>> I don't mind that, but can't you have an index set describing the codim 0
>> elements (maybe all of them) and another index set for the codim 1 elements
>> on the features you care about? You can take their union (or concatenate)
>> for your assembly loop if you like. Is there something wrong with this
>> approach?
>>
>>
>> Thats a very good point. In the end it doesn't really matter. As far as I
>> remember, the main reason I ended with my current scheme is that DMMesh did
>> not play well with partially interpolated meshes. I don't know what the
>> current status of DMComplex is.
>
>
> Okay, I think it's important to eventually support partially interpolated
> meshes to avoid using a lot of memory when used with low-order
> discretizations. I see no reason why there can't also be a direct cache for
> closure. For a P1 basis, that amounts to a point range
>
> [cells, boundary faces, vertices]
>
> closure: [cells -> vertices, faces -> vertices]
>
> So cell -> face need not be stored anywhere. Presumably there is a reason
> why Matt didn't write it this way. Is it just uniformity of data structure?

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.

   Matt

--
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