David Knezevic writes: > 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? >
You might store a std::vector per Elem with the tau_data (vector is indexed by quadrature point) and keep all those vectors in a std::map or another vector as a member variable of the N-S System. If memory is an issue, you could store only the values required for local assembly of the N-S System ... one std::vector for each active local Elem on each CPU most likely. I don't think you'd have any tricky parallel communication to do. In this case, the map<vector> makes more sense, using the Elem ids as the keys. Roy has contributed a mapvector class to LibMesh you could look into. -J ------------------------------------------------------------------------- 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
