This is inevitable, but may still not resolve anything. I'm sure Matt will correct whatever below is incorrect. The main question is whether to promote PetscSection to a PetscObject or to hide/replace it with something else.<div>
<br></div><div>So PetscSection is an unloved (by most) beastie that is sort of intermediate between an IS and a DM. Its core functionality is to provide indirect indexing with variable block sizes. It consists of two parts, the first of which is less than a PetscLayout.<br>
<br><div><font face="courier new, monospace">struct _n_PetscUniformSection {</font></div><div><font face="courier new, monospace"> MPI_Comm comm;</font></div><div><font face="courier new, monospace"> PetscInt pStart, pEnd; /* The chart: all points are contained in [pStart, pEnd) */</font></div>
<div><font face="courier new, monospace"> PetscInt numDof; /* Describes layout of storage, point --> (constant # of values, (p - pStart)*constant # of values) */</font></div><div><font face="courier new, monospace">};</font></div>
</div><div><br></div><div>numDof is always 1 and PetscUniformSection is never referenced from a *.c file so this is really just a range of valid "point" values [pStart...pEnd).</div><div><br><div><font face="courier new, monospace">struct _n_PetscSection {</font></div>
<div><font face="courier new, monospace"> struct _n_PetscUniformSection atlasLayout; /* Layout for the atlas */</font></div><div><font face="courier new, monospace"> PetscInt *atlasDof; /* Describes layout of storage, point --> # of values */</font></div>
<div><font face="courier new, monospace"> PetscInt *atlasOff; /* Describes layout of storage, point --> offset into storage */</font></div><div><br></div><div>^^ These two fields are the essential part. Each index in [pStart,pEnd) is mapped to a block of size atlasDof[p-pStart] located at atlasOff[p-pStart]. Matt composes these indirect maps for storing meshes and other indexing tasks. This "unsorted offset mapping" is indeed used frequently in PETSc, though outside of Matt's code, it's just raw arrays.<br>
<br>User's primarily encounter PetscSection when accessing unstructured meshes or any time the number of degrees of freedom or locations of each "point" (topological entity in the mesh) is not uniform. DMs do a similar thing (provide more logical access to a Vec), but DMDAVecGetArray() is of course only natural for a structured grid.</div>
<div><br>At the user interface level, provided the user doesn't need low-level access to topology, I think there are three possibilities.</div><div><br></div><div><b>1.</b> To compute a residual at a cell, user does<br>
<br>VecGetArray(F,&f); // normal access to the Vec</div><div>DMComplexGetHeightStratum(dm,0,&cstart,&cend); // "height 0" is like codimension 0 with respect to the maximum topological dimension. Matt and I have have a philosophical debate over whether users prefer to think in "strata" (that can skip dimensions, so "height 1" could be a face, an edge, or a vertex depending on what is stored in the mesh) or in "topological dimensions" (where codim=1 is a "face" for a 3D mesh and an edge for a 2D mesh).</div>
<div><br>DMGetDefaultSection(dm,§ion);</div><div>for (c=cstart; c<cend; c++) {</div><div> PetscInt off;</div><div> PetscSectionGetOffset(section,c,&off);</div><div> f[off+0] = residual of first equation at this cell;</div>
<div> f[off+1] = residual of second equation;<br> // brushing under the rug how we access neighbor values</div><div>}</div><div><br></div><div>The above is basically the current model. Matt has DMComplexGet/SetClosure(), but that interface carries a sleeper reference to the Vec's array and he says he plans to remove it.</div>
<div><br></div><div><b>2.</b> Add DMComplex-specific access routines so the user does not need to see the PetscSection. Presumably this would be something like<br>DMComplexGetPointOffset(dm,c,&offset); // offset into owned part of global vector?<br>
DMComplexGetPointOffsetLocal(dm,c,&loffset); // offset into local vector</div><div><br></div><div><b>3.</b> Access cursors (another object).<br>DMComplexGetCursors(dm,Vec U,3,&uface,&ucellL,&ucellR);</div>
<div>// similar for F</div><div>DMComplexGetHeightStratum(dm,1,&fstart,&fend);</div><div>for (f=fstart; f<fend; f++) {</div><div> const PetscInt *c;</div><div> const PetscScalar *uL,*uR,*uF;</div><div> DMComplexGetSupport(dm,f,&c); // left and right cells<br>
DMCursorGetValues(uface,f,&uF); // only used for staggered/mixed discretization</div><div> DMCursorGetValues(ucellL,c[0],&uL);</div><div> DMCursorGetValues(ucellR,c[1],&uR);</div><div> // Solve Riemann problem with "face" values uF[] (if using a staggered discretization), uL[], and uR[].<br>
DMCursorRestoreValues(uface,f,&uF); // ...</div><div><br></div><div>The "advantage" of the cursors here is that DMComplex doesn't need to hold the context manager itself (perhaps for multiple threads), the code dealing with the number of concurrent accesses is outside the inner loop, and the implementations of these accessors are trivial (offset). I think it's still not compelling for the sketched discretization above, but consider also FEM methods where we need to access all degrees of freedom on the closure of an element. The following packs a buffer with the closure (because it's not contiguous in memory).</div>
<div><br> DMCursorGetClosure(cell,c[0],&uc);</div><div><br></div><div><br></div><div><b>4.</b> Alternative suggestions?</div><div><br></div><div><br></div><div>I'm so sick of the name DMComplex. Let's just rename to DMPlex. It's shorter and doesn't have a double-meaning. Or pretty much any other name but "Complex".</div>
<div><br></div><div>For completeness, the last bit of _n_PetscSection:</div><div><br></div><div><font face="courier new, monospace"> PetscInt maxDof; /* Maximum dof on any point */</font></div>
<div><font face="courier new, monospace"> PetscSection bc; /* Describes constraints, point --> # local dofs which are constrained */</font></div><div><font face="courier new, monospace"> PetscInt *bcIndices; /* Local indices for constrained dofs */</font></div>
<div><br></div><div>These BC fields are for doing masked updates, such as VecSetValuesSection() which ignores constrained dofs.</div><div><br></div><div><font face="courier new, monospace"> PetscInt refcnt; /* Vecs obtained with VecDuplicate() and from MatGetVecs() reuse map of input object */</font></div>
<div><font face="courier new, monospace"> PetscBool setup;</font></div><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace"> PetscInt numFields; /* The number of fields making up the degrees of freedom */</font></div>
<div><font face="courier new, monospace"> const char **fieldNames; /* The field names */</font></div><div><font face="courier new, monospace"> PetscInt *numFieldComponents; /* The number of components in each field */</font></div>
<div><font face="courier new, monospace"> PetscSection *field; /* A section describing the layout and constraints for each field */</font></div><div><font face="courier new, monospace">};</font></div>
</div><div><br></div>