<br><br><div class="gmail_quote">On Wed, Dec 14, 2011 at 9:56 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@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="gmail_quote"><div class="im">On Wed, Dec 14, 2011 at 19:52, Dmitry Karpeev <span dir="ltr"><<a href="mailto:karpeev@mcs.anl.gov" target="_blank">karpeev@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">


I guess I'm missing something: why would you add pressure to the set of conservative variables?  It's redundant, as it can be obtained at any time via the equation of state. The only reason to add it is to impose a bound constraint on it and use it to monitor for departures from the feasible set.</blockquote>


<div><br></div></div><div>This is exactly the reason. I'm saying that since it is defined by the equation of state, we might be able to avoid adding it explicitly.</div><div><br></div><div>Note that in DG, it will be evaluated at quadrature points, and would thus break the block structure satisfied by the conservative variables. This likely also makes it more difficult to eliminate (while using to impose constraints).</div>

</div></blockquote><div>If you don't care about the extra storage, you could put the conserved variables and the  "constraint variables" in separate splits, make the Jacobian a MatNest and solve with the consevative subblock most of the time (away from the feasible set boundary).  That submatrix would retain the nice structure and all.  I'm thinking about adding "bounded variables" to libMesh in that way. </div>

</div><br>