On Sat, 19 Jan 2008, David Knezevic wrote:
> Roy and John: Thanks for the suggestions. > >>> Would it be possible to get all the values you'll need from tau_system >>> before-hand? Depending on the size of the problem, and assuming you >>> could also need multiple values per quadrature point, that might not be >>> feasible. I'm not sure how you'd store them all either. >>> >>> The benefit would be you wouldn't have to worry about the initialization >>> states of two different systems at the same time... > > In my case it would be possible to store the tau solution data in a > vector. I'm not sure of the best way to index that vector within > element_time_derivative though. Assuming the same quadrature rule is > used in both systems, I suppose one could keep a counter (as a member > variable in NavierSystem) that is incremented at each new quadrature > point, and use that to index the tau data? Only if you're very clever or very lucky. Half the point of breaking out element_time_derivative, element_constaint, etc. from a global assembly function is that library code is no longer limited to calling them once per element in order. A trapezoidal rule time integration calls each _time_derivative once at both the beginning and the end of the timestep, for example; you'd have to somehow realize that you were hitting each point twice. --- Roy ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
