<div class="gmail_quote">On Tue, Nov 16, 2010 at 00:38, Edward Bueler <span dir="ltr"><<a href="mailto:elbueler@alaska.edu">elbueler@alaska.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":150">Did not need the norm for the solvers, actually.<br>
<br>
I wrote a scaling/descaling "shell" around the residual evaluation<br>
routine, so the latter could be dimensional. At this early, prototype<br>
stage, where I am at on my code, I don't want the "clutter" of<br>
nondimensionalizing PDEs if I am familiar with them in dimensional<br>
units.<br></div></blockquote><div><br></div><div>Understood, I just type</div><div><br></div><div>printf("velocity %g m/s\n",velocity * units->meter/units->second);</div><div><br></div><div>which I find fairly intuitive.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div id=":150">
> ... nondimensionalizing (in the sense of ex48, not in terms on<br>
> nondimensional numbers ...) ...<br>
<br>
ex48.c is heavy-going if what one wants is an example showing how<br>
PETSc can help with scaling the residual and Jacobian for better<br>
conditioning.<br></div></blockquote><div><br></div><div>Understood, a slightly shorter code, albeit with more complicated physics, is in src/ts/examples/tutorials/ex10.c (only petsc-dev). I'll keep your comment in mind and make a simple example handling dimensional issues at some point.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div id=":150">
Related question: Is it true that an instance of DALocalFunction1<br>
will cause trouble if it modifies the solution array? (The values<br>
supplied in the "Field *u" argument?) It seems that this is so, which<br>
I did not expect for this call-back.<br></div></blockquote><div><br></div><div>In general, this is not right/doesn't make sense. It certainly causes problems with finite differencing. Are you asking about enforcing special constraints (like positivity)? The right thing is probably to use the variational inequality stuff in petsc-dev, but I think it would be useful for PETSc to make a clear statement about if and when the "simple hack" of projecting the trial state into the feasible set is acceptable. It may need to be implemented as a separate callback to work correctly with TS.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div id=":150">
Related comment: There is no man page on DALocalFunction1, I think.</div></blockquote></div><br><div>Thanks for pointing this out, DASetLocalFunction does not even document the calling convention (though it is in the user's manual, mildly obfuscated). DALocalFunction1 is a funny beast that does not distinguish between the LocalFunction and LocalJacobian calling conventions (both just void*). The use of void* is because the user typically has a multi-component problem in which case arrays of PetscScalar are clunky since they want arrays of some struct, thus always requiring an explicit cast. But passing a Mat in through the same void* is just disgusting.</div>
<div><br></div><div>As a petsc-dev issue, now that SNES holds a reference to the DM, perhaps SNES should hold the "local" function pointer. I think it's not so weird to want to solve different systems with the same DM. Having access to subdomain residuals and Jacobians would be useful for less synchronous nonlinear solvers.</div>
<div><br></div><div>Jed</div>