On Tue, 8 Feb 2011, Derek Gaston wrote:
> On Feb 8, 2011, at 1:20 PM, Derek Gaston wrote: > >> So while I have you looking at this piece of code.... how would I go about >> injecting things into the send_list? I won't know what the dofs are to >> inject until after distribute_dofs... but that doesn't give me a chance to >> do it before prepare_send_list() gets called and the solution vectors get >> initialized. >> >> Can I do it after System::init() and then call something to reinitialize the >> vectors? Cody has a patch aimed at allowing you to have fully ghosted >> vectors for everything in your system (including rhs and solution).... maybe >> I should get him to add a "reinitialize_vectors()" function to go with it >> that will roll through all the vectors and resize them. > > > Hmmm.... looks like I might be able to just inject stuff into the > send_list then call init() again... do you see any problems with > that? Won't System::init() end up reinitializing the DofMap (which clears and reconstructs the send_list) and wiping out whatever you've injected? Calling System::reinit() again (on each System, without calling it on the EquationSystems) might work... of course, depending on what you're trying to do this might not be enough, e.g. if you need a constrained dof communicated, might you also need the constraint and other dofs that may get used to update it in between communication steps? But that leads to a more general note: You haven't yet posted to the list what you're trying to do. This makes it hard to give advice; the exception is that you've told us it's going to require more application access to multiple low-level internals, which makes my primary piece of advice "please branch before committing this to svn, then wait until it's all working before we look at merging to trunk". I'm vaguely reminded of past conversations with people who really thought they wanted to have arbitrary data attached to elements, but hadn't yet considered storage in fields or subdomains... with the irony that in that case you've often been the first person to jump in and point out the high-level approach along with its advantages for adaptivity, parallelism, etc. The delay in those cases was always in getting users to realize that their requirements weren't really quite as arbitrary and thus didn't need to be quite as low level as they assumed. I'd hope that's the case here, too, in which case it's imaginable that we could design a single API for the user to deal with that would add any necessary extra communication in NumericVector send lists and in SparseMatrix sparsity patterns and in ParallelMesh communications and in DofConstraint enforcement and in anywhere else we haven't considered (or haven't fully parallelized... ErrorVector?) yet. Maybe that sort of library-level design can't work in your case, but (from my out-of-the-loop perspective, anyway) it does feel like you're sprinting past the possibility. --- Roy ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
