-
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120225/17a3a4dd/attachment.html>
On Feb 25, 2012, at 3:50 PM, Matthew Knepley wrote:
> On Sat, Feb 25, 2012 at 3:27 PM, Barry Smith wrote:
>
> Let's back up a step before everyone gets totally confused (and worry less
> about exact syntax to use instead focus on concepts)
>
> Proposal 1: Jed
>
>// Conservative gas dyn
m and dm can share common data structures, as arranged by
> the particular DM implementation.
> > The advantage of this approach over push/pop is that we can
> simultaneously use different splits of the same topology.
> >
> > It is rather easy to apply the same scheme and have DMs serve up
> (overlapping) domain decompositions useful for (G)ASM.
> > I'm now implementing both of these schemes (fieldsplit and subdomains)
> on top of libMesh, but the code resides in the libMesh source tree to avoid
> a circular dependence: as designed right now libMesh depends on PETSc. The
> API has to live in DM, though.
> >
>
>
--
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120225/afc3c9bd/attachment.html>
Let's back up a step before everyone gets totally confused (and worry less
about exact syntax to use instead focus on concepts)
Proposal 1: Jed
// Conservative gas dynamics with fields ordered as [rho, rho*u, rho*v,
rho*w, E]
DMGetFieldSplitting(dm,"conservative-vector",&fscons); //
to avoid a
> circular dependence: as designed right now libMesh depends on PETSc. The
> API has to live in DM, though.
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120225/50e5b222/attachment.html>
gt;
Push/pop is fine with me. But note that the GUI should be able to get a
list of options at any level in which a decision makes sense. It's possible
that we would want to split in terms of different variables in that
PCComposite+2*PCFieldSplit example.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120225/2ea1413b/attachment.html>
original
>> state variables.
>>
>> Then PCFieldSplit and eventual nonlinear and time-stepping splitting
>> methods would call
>>
>> DMGetFieldSplitting(dm,&nsplits,&splits);
>> // choose split number to use
>> split = splits[splitidx];
>>
> know its name (sort of like your "default" split) but the push allows
> changing the default. You kind of assume that the guts is suppose to know
> what name to use? // choose split number to use how is some PC deep inside
> suppose to know this?
>
> I realize my proposal was not complete on detail. I'm suggesting changes
> to your detail.
>
> Barry
>
> >
> > 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.
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120225/e9ec26c8/attachment.html>
On Feb 25, 2012, at 12:13 PM, Jed Brown wrote:
> [migrating from petsc-maint]
>
> > What interface are we going to use for splitting out a DM for a vector
> > field in a larger system? How do we get the bs=2 velocity DM out of the
> > lid-driven cavity's bs=4 velocity, vorticity, and temperature
to be implemented using DMXXXSet*
methods.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120225/346cd01a/attachment.html>
variables. This is unfortunate because many
important preconditioning methods operate in different variables than the
nonlinear system is defined in.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120225/41c48d58/attachment.html>
&pf,&pfinv,&nfields,&isfields,&dmfields);
>
> 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.
>
--
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120225/ea3051ed/attachment.html>
&pf,&pfinv,&nfields,&isfields,&dmfields);
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.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120225/2649aeb5/attachment.html>
13 matches
Mail list logo
