[petsc-dev] PetscSection

[Blaise A Bourdin]

Sorry, for the empty message earlier. Fat fingers on a small keyboard...


On Fri, Nov 9, 2012 at 10:20 PM, Blaise A Bourdin <bourdin at lsu.edu<mailto: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...

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.
Fine.  It should be done from the DM anyways.



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.

Great




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.

That's pretty much what I do now. With DMMesh, it required quite a bit of work. It looks much easier with DMComplex

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?

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.

Blaise
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20121110/6c3a76bf/attachment.html>