<br><br><div class="gmail_quote">On Sat, Feb 25, 2012 at 12:18 PM, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Sat, Feb 25, 2012 at 12:13 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br></div><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">[migrating from petsc-maint]</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Sat, Feb 25, 2012 at 11:45, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>> I agree, but it would be quite helpful to refactor DM_DA have a section<br>
> that holds topology and geometry, plus the (very small) extra information<br>
> that depends on the number of dofs per point. Then the common part could be<br>
> shared, making all the DMDAs coming out of the split easier to work with.<br>
><br>
<br>
</div> this is true but completely irrelevent here<br></blockquote><div><br></div><div>My understanding is that much of the reason Matt wants to use PetscSection in places is because he feels like the DM implementation is quite heavy, so if you want to address a subset, making a new DM would involve heavy copies. I don't want PetscSection because I think the algebraic components should have access to the richer information in a DM, but I also don't want full copies of heavy DMs. If we can implement topology/geometry sharing without much complexity, we shouldn't need to use PetscSection.</div>
</div></blockquote><div><br></div></div><div>This is incorrect. I want to use PetscSection because DM just cannot do arbitrary data layout. </div></div></blockquote><div><br></div><div>I would argue that generating arbitrary layouts belongs in particular DM implementations, but the generic interface has to allow for split retrieval so that they can be used by various PCs (PCFieldSplit, PC(G)ASM) and even SNES (splitting primal and dual variables in versions of SNESVI).</div>
<div><br></div><div>Dmitry.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>Can we please</div><div>stop making examples with vertex unknowns on structures meshes? They have nothing left to tell us.</div>
<div><br></div><div> Matt</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> What interface are we going to use for splitting out a DM for a vector<br>
> field in a larger system? How do we get the bs=2 velocity DM out of the<br>
> lid-driven cavity's bs=4 velocity, vorticity, and temperature DM?<br>
><br>
<br>
</div> again this is irrelevent here because the same issue is true for the ISs.<br>
<br>
But<br>
<br>
I explained this in my previous email: DMPushSubDMType(DM,"name of a type of splitting like u,v,p or velocity,p"); DMPopSubDMType(); it is not perfect but a start. See that email for more details.</blockquote>
</div><div><br></div>// Conservative gas dynamics with fields ordered as [rho, rho*u, rho*v, rho*w, E]<br><div>DMGetFieldSplitting(dm,"conservative-vector",&fscons); // creates if it doesn't exist</div>
<div>
DMFieldSplittingAddField(dm,fscons,"rho",{0});</div><div>DMFieldSplittingAddField(dm,fscons,"momentum",{1,2,3});</div><div>DMFieldSplittingAddField(dm,fscons,"Energy",{4});</div><div><br></div>
<div>DMGetFieldSplitting(dm,"primitive-vector",&fsprim);</div><div>DMFieldSplittingSetPF(dm,fsprim,UserEquationOfStatePF,UserEquationOfStateInversePF);</div><div>DMFieldSplittingAddField(dm,fsprim,"velocity",{0,1,2});</div>
<div>DMFieldSplittingAddField(dm,fsprim,"pressure",{3});</div><div>DMFieldSplittingAddField(dm,fsprim,"Temperature",{4});</div><div><br></div><div>If a transform is not specified, the indices would address the original state variables.</div>
<div><br></div><div>Then PCFieldSplit and eventual nonlinear and time-stepping splitting methods would call</div><div><br></div><div>DMGetFieldSplitting(dm,&nsplits,&splits);</div><div>// choose split number to use</div>
<div>split = splits[splitidx];</div><div>DMFieldSplittingGetName(dm,split,&splitname);</div><div>DMFieldSplittingGetFields(dm,split,&pf,&pfinv,&nfields,&isfields,&dmfields);</div><div><br></div><div>
If pf is not NULL, apply PF to the state variables, then isfields[i] denotes what to extract in order to live in dmfields[i], pfinv is needed to put a contribution back into the coupled dm.</div>
</blockquote></div></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener<br>
</font></span></blockquote></div><br>