On Tue, Nov 19, 2013 at 1:23 PM, Matthew Knepley <[email protected]> wrote: > On Tue, Nov 19, 2013 at 3:19 PM, Geoffrey Irving <[email protected]> wrote: >> >> On Tue, Nov 19, 2013 at 1:14 PM, Matthew Knepley <[email protected]> >> wrote: >> > On Tue, Nov 19, 2013 at 1:14 PM, Geoffrey Irving <[email protected]> wrote: >> >> >> >> It looks like when ex12 clones the DM, it reuses the mesh data >> >> structure but copies the coordinate vector. Is there a reason it >> >> can't reuse that storage? Given that the PetscFEM routines accept the >> >> same position array for dependent and auxiliary fields, does it even >> >> make sense to have distinct coordinate arrays? >> > >> > >> > Yes, this is lazy. It could be replaced by >> > >> > DMGetCoordinateSection(dm, &s) >> > DMGetCoordinatesLocal(dm, &c) >> > DMSetCoordinateSection(dmAux, s) >> > DMSetCoordinatesLocal(dmAux, c) >> >> Does it matter that dm's section knows about boundary conditions, and >> dmAux's currently doesn't? This change would mean that both sections >> know about boundary conditions. > > > The coordinate section is a different thing which describes coordinate layout. > There are no BC in the coordinate sections, only in the default sections. > The aux has a different default section for the layout of the coefficient.
Right, sorry for the noise. Obviously the coordinate section is completely different, since it has one entry per vertex as opposed to one entry per finite element. >> Should I make this change to ex12 and remove the SetupMaterialSection >> function entirely, or should I only use it in my own code? > > We still need SetupMaterialSection() if we are running with a material > coefficient. Geoffrey
