Derek Gaston wrote: > On Oct 15, 2008, at 2:33 AM, Norbert Stoop wrote: > > Parallel is where the issue is... and is why I haven't enabled that > capability yet. I haven't yet done the work to make EpetraMatrix work > in parallel like I did for EpetraVector.
What exactly is the missing functionality there? If I understand correctly, libmesh is already using the FECrsMatrix, so summation of the off-processor contributions should be taken care of already, or am I missing something? > But if you have it working in serial... by all means send a patch. Ok, I'll do that as soon as I have made some more tests. >> I understand that Trilinos support is unofficial and work in progress. I >> am still new to libmesh, and Trilinos in particular, but will invest >> some more hours into this problem. Not sure if that will be of any help, >> though... > > Any help is appreciated... I'm currently being pulled in about 7 > different directions.... so even if small progress is being made in this > direction... that will be better than none. > >> What puzzles me is that the error is already fully present after the >> first nonlinear iteration, ie. after solving the linearized system. > > Yes... if there is a problem in parallel then you probably aren't > getting the correct summations of off-processor contributions when you > do a residual evaluation.... so you would see it _immediately_. Your > very first residual evaluation would be wrong. Sorry, it seems I was somewhere else with my thoughts when I wrote this - it's quite obvious, as you point out, that the problem must be in the summation. I was only wondering why the linear problems do not suffer from the same bug. Now, it seems like the only difference between ex4, which works fine, and the nonlinear one is that ex4 makes no calls to inputNonlocalValue(), while ex19 does. If I understand correctly, GlobalAssemble should then update the overlap, right? > Like I say though.... that shouldn't be broken anymore (for pure matrix > free). Are you sure you've updated your libMesh? There was a small bug > where closing the EpetraVector was not calling GlobalAssemble... but I > think I committed the fix for that a little bit ago. Ah, ok, so the resolution is ridiculously simple: Parallel summation seems to be just fine (I did not check all of the code, mainly the nonlocal values stuff), it's just that the residual vector is never closed in the computeF callback! Doing so (like in the petsc version) resolves everything! Had I only read through the petsc_nonlinear_solver.C more carefully... Norbert ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
