Thanks for the reply Roy... On Jun 2, 2008, at 9:45 AM, Roy Stogner wrote:
>> > It would be nice to set up some sort of sneaky strong typing to > prevent this sort of mistake in the long run. Maybe: A Number times a > SideReal gives a SideNumber. A Number times an InteriorReal gives an > InteriorNumber. Trying to multiply an InteriorNumber (like > phi[i][qp]) and a SideNumber (like JxW_face[i][qp]) without an > explicit cast gives a compiler error. In this case the problem wasn't so much that I was multiplying by an interior shape function... it was that I wasn't multiplying by _any_ shape function ;-) But this typing doesn't sound like too bad of an idea anyway... > Although, when I change the FEMSystem interface to be threadable, > it'll fix this problem for those users as a side effect; you'll only > have access to an interior FE object when computing interior terms, > and you'll only have access to a side FE object when computing side > terms. What advantages does FEMSystem have over using Ben's NonlinearImplicit system stuff using SNES? I've used both, but I don't really see the difference. For us, we're using the NonlinearImplicit system because we hope to fill out the Trilinos interfaces at some point and use NOX instead... >> > It's been a while since I looked at this. From what I remember, the > penalty *looks* like it should affect the convergence rate strongly, > since it can blow up the condition number of your matrix. But what it > really ends up giving you is a nice set of clustered eigenvalues that > are just really far-removed from your normal eigenvalues, and in my > experience that gets nicely fixed up by even the most basic > preconditioning methods. Yeah - see my recent reply to John. I don't think it's necessarily having convergence "problems"... but the convergence tolerances might not be right. > I think the combination of a too-large penalty value and floating > point error can get you in trouble, but usually you have to get up > near 10^15 for that to happen. I usually just pull "10^10" out of a > hat and get good results. Yeah - I don't think I'm hitting floating point problems > You can weakly enforce boundary conditions with terms based on > Nitsche's method or on DG methods; I've never tried it, but that > supposedly has benefits for conditioning and error estimation too. If we stick to this path we might look at these... thanks for the info. > You can extend our DofMap constraints code to allow Dirichlet boundary > conditions to be applied strongly. Right now we only support > "constrained_dof_i = sum(coefficient_ij*otherdof_j)" sorts of > constraints, > but it wouldn't be too hard to add a "plus constant_i" term to that. This might be where we go long term. I was talking to my group earlier about this and they were talking about doing just this. I, myself, would rather not. I'd really rather see the BC's directly in the residual calculation (to make them very plug-and-playable)... but we'll see. For now, I'm happy with how the code is working... just wanted some input from you guys. Thanks again for the great reply. 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
