Hey Derek, I'm sure you already have it, but I just wanted to say: be sure to multiply by the test function (in Libmesh "phi_face[i]" or "phi_side[i]"). I just remembered we had forgotten to do this once before in the Laplace-Young application :-)
On Mon, Jun 2, 2008 at 8:45 AM, Derek Gaston <[EMAIL PROTECTED]> wrote: > Oops... you're right about the Neumann condition... I forgot that I get a > boundary term out of the integration by parts that I can just use for this > purpose... > > I still don't quite know about the Dirichlet condition though. Yes, I am > enforcing it essentially as a penalty... but that penalty just goes into the > residual and is finite differenced like the rest of it. If the residual Right. Another way to think of it: the analytical jacobian contribution from the standard Dirichlet penalty term is a mass matrix "phi[i]*phi[j]" multiplied by the penalty parameter. Likewise, when you finite difference this term you should get something proportional to the penalty. If "u-BC" differs appreciably from zero, the residual contributions from this term will be large. We typically use a value on the order of 10^10. What value are you using? > goes to zero... then it shouldn't matter if there is a multiplier on the > penalty or not. The only question is of convergence. Or do you think it's > the rest of the normal stuff in the residual for a boundary DOF that's > screwing it up... and that's why I need the multiplier? I don't *think* the penalty should affect the convergence rate strongly. But I don't have a lot of experience with the matrix-free Newton-Krylov techniques so I can't say for sure. > Hmmmm.... I guess that makes sense. So, any guidance on choosing a > multiplier? The problem is obviously sensitive to it... because if I make > it too large I get the wrong answer just as easily as making it too small > (and I do get good answers when I get the multiplier in the right range > BTW). AFAIK, the solution should not be sensitive to the size of the penalty, provided it's large enough. Could be something else wrong with your residual assembly code? -J > > Thanks, > Derek > > On Jun 1, 2008, at 10:39 PM, John Peterson wrote: > >> On Sun, Jun 1, 2008 at 10:51 PM, Derek Gaston <[EMAIL PROTECTED]> wrote: >>> >>> So... I've been working with the NonlinearImplicit system... solving >>> jacobian free problems using Petsc SNES. Everything is going pretty >>> well (Ben's interface is great!)... but I've hit a bit of a snag on >>> the boundary conditions. I would really like to impose both Dirichlet >>> and Neumann conditions similarly... by integrating their residual >>> contributions over the boundary. So for instance for a Dirichlet >>> condition I have something like this: >>> >>> Intg_boundary( u - BC ) >> >> Hey Derek, >> >> Are you doing a penalty formulation for the Dirichlet BC? You'll need >> to multiply by a large penalty for this condition to be enforced. >> >>> and similarly for Neumann: >>> >>> Intg_boundary( grad_u - BC ) >> >> Here I don't think you subtract... you just replace du/dn with >> whatever the BC is (it may depend on u, it may be nonlinear) and then >> add that term to your weighted residual statement. >> >> -J >> >>> The trouble that I'm running into is that these residual contributions >>> seem to be too small... and are only very loosely satisfied by SNES. >>> For instance, solving u''=0 on [0,1]x[0,1] with u=0 at x=0 and u=1 at >>> x=1... I end up with u actually being .3333 at x=0 and .6666 at x=1. >>> Of course I can dial down the residual tolerances for snes... but this >>> only gets me so much closer. The other thing I've tried is to put a >>> multiplier in front of the boundary integral (like 1e7 or so)... this >>> ends up working well for satisfying the boundary conditions... but >>> then the interior residuals are swamped out... meaning they aren't >>> well resolved. >>> >>> So, I'm wondering if anyone has any better ideas? Is there a good way >>> to choose the correct multiplier? Am I going about the whole thing >>> incorrectly? >>> >>> Thanks for any help... >>> >>> Derek >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> _______________________________________________ >>> Libmesh-users mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/libmesh-users >>> > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
