[petsc-dev] PetscSection

[Jed Brown]

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

;-)

Everything is an IS. I suspect that this means that the Set/GetCone,
>

I think these just return a range or (offset,size).


> Set/GetClosure operations
>

Closure needs to do orientation, so it's not direct access from the Vec.
Regardless, I don't think the plan would be to create an IS for that
granularity.


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

I think these are DMCompletVecGet/SetClosure.


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

I think you would get an index set for those points on the feature you
wanted to do something special for.


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

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20121110/d04a3fd5/attachment.html>