[petsc-users] dof>1 vector tools

[Jed Brown]

On Tue, Nov 16, 2010 at 00:38, Edward Bueler <elbueler at alaska.edu> wrote:

> Did not need the norm for the solvers, actually.
>
> I wrote a scaling/descaling "shell" around the residual evaluation
> routine, so the latter could be dimensional.  At this early, prototype
> stage, where I am at on my code, I don't want the "clutter" of
> nondimensionalizing PDEs if I am familiar with them in dimensional
> units.
>

Understood, I just type

printf("velocity %g m/s\n",velocity * units->meter/units->second);

which I find fairly intuitive.


> > ... nondimensionalizing (in the sense of ex48, not in terms on
> > nondimensional numbers ...) ...
>
> ex48.c is heavy-going if what one wants is an example showing how
> PETSc can help with scaling the residual and Jacobian for better
> conditioning.
>

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.


> Related question:  Is it true that an instance of DALocalFunction1
> will cause trouble if it modifies the solution array?  (The values
> supplied in the "Field *u" argument?)  It seems that this is so, which
> I did not expect for this call-back.
>

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.


> Related comment:  There is no man page on DALocalFunction1, I think.
>

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.

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.

Jed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20101116/ceac1768/attachment.htm>