[petsc-dev] PetscSection

[Blaise A Bourdin]

Hi,

Let me make sure I understand the consensus, since I have a vested interest in the unstructured mesh business:

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. 

Everything is an IS. I suspect that this means that the Set/GetCone, Set/GetClosure operations would return an IS that could be used in VecSetValuesIS, but may not even be needed if an equivalent of  DMMesh' SectionRealRestrict / RestrictClosure /Update / UpdateCLosure is implemented

Setting Values is good, but getting values is needed too! 

Also, in addition to the Barry's simple pseudo-code, I need to be able to get an IS for the i^th dof of a field at a given point (think of applying a Dirichlet boundary conditions to only one component of a field, for instance). It's always been the messy part. How would that fit within the proposed model?

Finally, just a comment on stratum vs topological dimension. There is no reason why all elements in a mesh should have the same topological dimension. I actually find it much easier to have a single mesh where some sets of elements have codimension 0 and others codimension 1 and dispatching my assembly depending on the physics associated with each block, and the codimension of the element rather than having to deal with side sets / boundary mesh / whatever you want to call it.

Blaise

On Nov 9, 2012, at 9:02 PM, Barry Smith <bsmith at mcs.anl.gov>
 wrote:

> 
>  We have a users manual?
> 
> On Nov 9, 2012, at 8:56 PM, Matthew Knepley <knepley at gmail.com> wrote:
> 
>> On Fri, Nov 9, 2012 at 9:46 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>>> 
>>> On Nov 9, 2012, at 8:42 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>>> 
>>>> On Fri, Nov 9, 2012 at 8:39 PM, Matthew Knepley <knepley at gmail.com> wrote:
>>>> You are both right :) I don't care where we put them, but I want BCs
>>>> and fields. However, this is no problem.
>>>> Right now I do BCs and fields as PetscSections held inside the primary
>>>> section. If IS can do what PetscSection
>>>> can do, I can jsut use another IS for each one.
>>>> 
>>>> Convergence!
>>>> 
>>> 
>>>  Write it up!   :-)
>> 
>> In the manual section on Unstructured Grids :)
>> 
>>  Matt
>> 
>>>> 
>>>> I actually like it where it is. Stick with DMComplexVecGetClosure()
>>>> with no section argument, and then
>>>> the DM holds an IS++.
>>>> 
>>>> Cool, now the "normal" user doesn't even see the ++IS.
>>> 
>> 
>> 
>> 
>> --
>> 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
> 
> 

-- 
Department of Mathematics and Center for Computation & Technology
Louisiana State University, Baton Rouge, LA 70803, USA
Tel. +1 (225) 578 1612, Fax  +1 (225) 578 4276 http://www.math.lsu.edu/~bourdin