From: <luthi@gi...>  20040512 17:48:34

Thanks, John and Ben Maybe I understood the explanation (at least it makes sense to me). Doxygen seems to forget about base classes (or interfaces?). I tried to find something like local_solution, but could not find it in http://libmesh.sourceforge.net/doxygen/classTransientSystemmembers.html Martin KIRK, BENJAMIN (JSCEG) (NASA) writes: > should probably be like this: > > *stokes_system.old_local_solution = *stokes_system.current_local_solution; > > > (the current_local_solution is exactly what you mean by local_solution). > > The basic idea is this: system.solution is a parallel, distributed vector. > Each processor *only* holds those components for which it is responsible. > system.current_local_solution is a serial vector. This vector should > contain the same data as the local part of system.solution and any > additional values required by this processor, as specified in the DofMap > send_list. > > The system.solution is really only used to interface with the linear solver, > and then can (and should) be localized into the > system.current_local_solution). Then, if the processor needs individial > solution values (i.e. to compute a nonlinear matrix contribution), it should > get them from the system.current_local_solution. > > (Note that in ex13 the system.solution is also used to compute the > deltanorm from the last solution in order to terminate the nonlinear > iteration. This is perfectly acceptable since the norm can be calculated in > parallel, with each processor only accessing its local piece. The send_list > is irrelevant). Clear as mud? 