Derek Gaston wrote: > On Oct 16, 2008, at 9:16 AM, Norbert Stoop wrote: > >> 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? > > The issue is that NOX _doesn't_ use FECrsMatrix... and instead just uses > a CrsMatrix. The trouble with this is that when they give you back a > pointer to the jacobian to fill... it comes through as a CrsMatrix which > has no parallel summation capability. With FEVector this was > particularly bad because there was no way to create an FEVector from an > EpetraVector. This is why we now _don't_ use FEVector... and instead go > to great lengths to work directly with an EpetraVector and do the > off-processor summations external to the object itself. > > Now... from what I've seen of FECrsMatrix it _does_ have the "View" > capability.... I was hoping to exploit that to create a "View" of the > data in the CrsMatrix that NOX passes us back.... and then still use > FECrsMatrix's off-processor summing capabilities. But I don't know yet > whether or not this will work. If it doesn't... then we're in the same > place we were with FEVector... we'll do all of the off-processor > summation work ourselves and just use a CrsMatrix instead of an > FECrsMatrix. > > Hope that makes sense.
Hm, so let me see if I can spend some time to get into this, since I'd really like to have Trilinos/NOX working in libmesh. As a matter of coordination: Did you already put some code together? >> Ok, I'll do that as soon as I have made some more tests. > > As long as you're making tests... can you turn that LaplaceYoung example > into a _real_example (just clean it up a bit). We really need to get > that thing committed so that people have something to look at for how to > use the NonlinearSolver classes. Sure, just give me until next week for that (too many other things to do). I agree, this should go into SVN the sooner the better. >> 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... > > Great! So maybe I did forget to commit that fix... doh. Sorry about > that. If you could include that in your patches I would appreciate it! No problem. At least it made me take a closer look at the underlying details. I'll prepare a patch for this together with the single CPU jacobian solver support... sometime tomorrow, I hope. 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-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
