<br><br><div class="gmail_quote">On Thu, Jun 7, 2012 at 6:21 PM, 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 class="im"><br>
On Jun 7, 2012, at 6:17 PM, Dmitry Karpeev wrote:<br>
<br>
> In the short run, however, we need to agree on an API for defining splits that have an input and output<br>
> space.  In the code the splits already carry row and col ISs, but there is no way to set them separately,<br>
> at least not for IS-defined splits.  Should we add something like<br>
> PCFieldSplitSetSplit(PC pc, const char* name, IS rowis, IS colis, DM subDM)<br>
> or similar?  PCFieldSplitSetIS() will continue to work as before defining a "diagonal" split with rowis == colis,<br>
> and DMCreateFieldDecomposition() can be changed to<br>
<br>
</div>  No way. Better to just change the old interface to support passing in the two IS. (for people who want "diagonal" just pass the same is twice).<br></blockquote><div>So,  </div><div>PCFieldSplitSetIS(PC pc, const char* name, IS rowis, IS colis)?</div>

<div>That's fine with me.  DMCreateFieldDecomposition() will have to change accordingly to return two IS lists, but that's consistent with the above.</div><div><br></div><div>Dmitry.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<span class="HOEnZb"><font color="#888888"><br>
   Barry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> DMCreateFieldDecomposition(DM dm, PetscInt *numsplits, char **splitnames, IS *rowislist, IS *colislist, DM *dmlist)<br>
><br>
> Dmitry.<br>
><br>
> On Wed, Jun 6, 2012 at 8:54 PM, Jed Brown <<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>> wrote:<br>
> On Wed, Jun 6, 2012 at 6:54 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
> No you don't get back a pair of subDMS, you get a DM that goes from one state space to "a different" residual space. Normally one would not need this though it does come up in the VI stuff.<br>
><br>
> For a low temperature/rarefied gas, total energy and density (residuals in two of your conservation equations) are nearly parallel and point in a very different direction from the primitive variables pressure and energy. (Never mind that primitive variables would be a very bad formulation here.) For high temperature and low velocity, total energy is essentially proportional to pressure and density is proportional to p/T. The point here is that in different nonlinear regimes, the conditioning of a given diagonal block can change substantially. You could say that one should just choose conservative variables so that at least the residual and the state use the same units, but that produces a very ill-conditioned basis in the low-Mach limit.<br>


><br>
> > The reason this works for PCASM is that we demand that the input/output spaces are nested (e.g., the output space for RASM is a subspace of the input).<br>
><br>
>   Actually RASM has an option where the output space is larger than the input space. (The subproblems are defined as extending the right hand side by zero, solving the subproblem and then keeping the entire solution (on the overlapped region).<br>


><br>
> Well, I'm not sure that it makes sense to express RAS and ASH (AS with harmonic extension) that way. For example, DMCreateMatrix() for that problem needs to address the whole overlapping space. You solve it by restricting the input or restricting the output, but the mechanics of the solve needs the whole overlapping region.<br>


><br>
><br>
<br>
</div></div></blockquote></div><br>