From: KIRK, BENJAMIN (JSCEG) (NASA) <benjamin.kirk1@na...>  20040512 19:27:43

Oh... the problem is that the documentation is generated for the = templated class TransientSystem<T>. You are correct, there is no current_local_solution in the TransientSystem<>. It is in the SteadySystem<>. However, in Example 13 we solve a = TransientImplicitSystem which is something like this: typedef TransientSystem<ImplicitSystem> TransientImplicitSystem; Then the TransientSystem is derived from the implicit system... This significantly reduces code reuse, but unfortunately the documentation = gets a little screwey. Bottom line is that the TransientImplicitSystem is = derived from the System, so the current_local_solution is available... Ben Original Message From: Martin L=FCthi [mailto:luthi@...]=20 Sent: Wednesday, May 12, 2004 12:49 PM To: KIRK, BENJAMIN (JSCEG) (NASA); libmeshusers@... Subject: RE: [Libmeshusers] Example 13 again 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: >=20 > *stokes_system.old_local_solution =3D *stokes_system.current_local_solution; >=20 >=20 > (the current_local_solution is exactly what you mean by = local_solution). >=20 > 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. >=20 > 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. >=20 > (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? 