Ok - I have some preliminary results suggesting that this change _completely_ does away with the memory oscillation. Memory now stays within a couple of megabytes during the entire solve process (after it gets ramped up of course).
After I do a bit more testing I'll work up a patch and get it committed tomorrow (Ben, do you want to see the patch first?). Thanks to everyone for their input today! Next thing to tackle is _not_ creating a Matrix for _Matrix Free_ computations.... Derek On Tue, Jun 24, 2008 at 4:24 PM, Derek Gaston <[EMAIL PROTECTED]> wrote: > On Jun 24, 2008, at 4:14 PM, Roy Stogner wrote: > >> >> The DiffSystem::assembly() call in PetscDiffSolver uses >> current_local_solution to plug into the weighted residual equations, >> thus ensuring that DoFs which are owned by another processor have >> correct values. How does that work here? When you swap the solution >> out again, the current_local_solution doesn't come with it - you're >> still passing to residual() a vector that only has locally owned DoFs, >> right? >> > > Thanks Roy... that gave me the little kick I needed. All I need to do was > pass current_local_solution instead of X_global.... like this: > > solver->residual (*sys.current_local_solution.get(), R); > > That runs anyway... I've yet to be able to run a test to see if that takes > care of the memory oscillation. I'll get back to you guys on that (with a > patch if it works). > > Derek > ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
