> It would be fantastic if your physics *could* be tested by the
> library, but automatically generating f doesn't do it. Imagine that
> instead of implementing R_normal you implemented R_broken. Then the
> library would be evaluating
>
> f = -R_broken(u_mf)
>
> and (unless R_broken is extremely broken) R_mf(u) will still converge
> to a zero at u = u_mf. The broken residual would be hidden
> automatically by the forcing function.
Well, the saving grace might be that we would *require* R_strong which is
separate and distinct from R_weak where the errors you are looking for may
lie. Of course, you can still break R_strong and screw yourself, but as
McLay says "genius has its limits, but stupidity knows no bounds...".
If nothing else, when coding R_strong there is no reference to shape
functions, quadrature, anything... You go straight from u and its
derivatives to the residual you think you are solving. In terms of syntax
it should be very clear, and you are *not* inheriting errors from your
discretized residual if the strong form of the residual is required as a
separate function.
I am thinking something like
Real R_strong (...)
{
const Real factor = ...;
const Real u = u_exact(xyz,t);
const Real u_xx = d2u_exact(xyz,t);
const Real R_strong_homogeneous_helmholtz = factor*u - u_xx;
return R_strong_homogeneous_helmholtz;
}
-Ben
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Libmesh-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
