On Jun 24, 2008, at 12:50 PM, Roy Stogner wrote: > First order elements?
Yep > Define "communication steps" - I assume you're not talking about > synching up ghost DoFs during a solve? I really haven't looked into it. It's more of a "feeling" you can watch the cpu's peg out for a few seconds... then they all go crazy and the network traffic spikes. It could be something specific to the way the NonlinearSystem solve progresses.... maybe syncing the global solution so that it can pass it into compute_residual()? I don't know. > Are you doing mesh refinement at each oscillation? If that's it, then > there's two likely culprits, but I don't know if they're sufficient > explanation: > > We still use global error vectors; these need to be (optionally) moved > to a mapvector sort of structure just like the mesh node and element > vectors were. A single-precision float per element would be 40MB on > each node for 10 million elements. > > We use serialized DoF vectors in System::project_vector(). This is > even worse because of the double precision; each vector must cost 80MB > for 10 million DoFs. There is no refinement happening at all (well, beyond the initial uniform refinements to get up to the problem size I want). I'm not even looping around "system.solve()". This is just one big solve. > But even that adds up to only 120MB; if you're seeing ~500MB usage > jumps, I'm not sure where the rest is coming from. I don't suppose > you can pin down exactly where the memory's being allocated? I'm not exactly sure how to even start down that path. John suggested mpip to get some info out. Do you have an idea of how to find out what the memory swings are? I'm probably just going to start with print statements and see if I can "see" when the memory spikes are occurring. Derek ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
