[petsc-dev] PetscSection

[Jed Brown]

On Sat, Nov 10, 2012 at 11:57 AM, Blaise A Bourdin <bourdin at lsu.edu> wrote:

> Yes, but because of the structure of my problem, the application context
> also contains a link to the original DM.
> Think solving F(u,v) = 0 where and v don't have the same layout, or the
> same dimensionality, without field split.
> My iterate is
> u_{n+1} = argmin_w F(w,v_n)
>    v_{n+1} = argmin_w F(u_{n+1},w)
> The DM associated with u is DMu and the one with v is DMv
> For the application context, I can either a create AppCtx with components
> (pointer to u, pointer to v, pointed to DMu, pointer to DMu), or
> AppCtxu with components (pointer to v, pointer to DMv) and AppCtxv with
> components (pointer to u, pointer to DMu)
> In this setting, is calling SNESSolve with Vec u and Application Context
> AppCtx legal, or do I have to use AppCtxu / AppCtxv?
>

Either is okay (and neither is okay for FAS).


>  Can you point me to an example? Are interfaces C only because nobody has
> ever needed fortran versions, or is there a technical reason.
>

SNES ex48 does this, also look at any use of DMCoarsenHookAdd(). There is
no fundamental issue, it just requires custom function pointer juggling
which is messy and really needs to be tested.


>
>
 I had not thought about it, but it is quite feasible. I store all
> coefficients that are constant per block of cells or Dof in PetscBags, and
> everything that has variation at the scale of the finite element space in
> Vecs.  How would the creation of the coarse DMs be handled, though? The
> geometry part is trivial to propagate using DMClone, but you may need to
> user feedback for the data layout part, unless you have a scheme that
> describes it (i.e. for this IS of cells, n dof at the vertices, p at the
> faces etc)
>

You get to implement these two callbacks to create and update data for the
coarse grid problem:

http://www.mcs.anl.gov/petsc/petsc-dev/docs/manualpages/DM/DMCoarsenHookAdd.html


> Do we mean the same by partially interpolated mesh? What I mean is a mesh
> the only faces that are explicitly stored are the one we are interested in
> (typically the boundary mesh). For P1 elements, we need only to know of
> [cells, some faces, vertices].
>

Yup, same thing.


>  I tried to manually build partially interpolated sieves with only some of
> the faces, and distribution would fail. That's how I ended up with a mix of
> cells of co-dimension 0 and 1. If one wants access to ALL faces / edges or
> none of them, there is no problem in the current implementation.
>

Right, I think of this as having a bunch of codim 0 and a few codim 1. As a
user, we call Closure, not Cone, so we go directly to the points from
either. But we would get the points to loop over by requesting codim 0 and
codim 1 separately. I'd expect that in principle, you likely have multiple
groups of codim 1 things that get treated differently. Of course you can
lump them all in one bigger index set and have an if statement, though it's
not as vectorization-friendly so Matt doesn't like that. I would not mind
having an interface for requesting points of multiple dimensions at once
(codim in {0,1}).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20121110/44352272/attachment.html>