On Tue, 11 May 2010, David Knezevic wrote:
>>> So now I'm getting mesh motion, though if GMV is to be believed it's >>> only the outermost layer of elements that are moving. I'll have a >>> closer look at what's happening... >> >> Thanks! > > Oh, my mistake, I just needed to add system.mesh_position_set() after > system.time_solver->advance_timestep(). It works nicely now, cool! No, that's not your mistake, that's mine - mesh_position_set() ought to be handled transparently by the library. The trick is trying to figure out how to do that most modularly. Doing it in advance_timestep() is out because we want it to work right in steady solves too. Doing it in FEMSystem::solve() is probably most reasonable; I'm just not 100% sure that won't mess up the way TwoStepTimeSolver works. But hey, since ALE is in a known broken state anyway we might as well move it to "less broken". I'll add the mesh_position_set() to SVN now. Next step is getting it working with MPI on SerialMesh. If we construct a SERIAL vector in mesh_position_set, localize solution onto it, swap it with current_local_solution, and then swap it back and let it destruct when we're done, that ought to be a sufficient hack... But what I'd rather do is fix it for SerialMesh and ParallelMesh at once. Change mesh_position_set to work only on local active elements, do a Parallel::sync_dofobject_data_by_id to grab the new locations for every other node, then loop over nonlocal nodes to set them. I ought to have some time to try this out next week. The final step is getting it working with Threads. I suspect that the best way to do that is to actually construct copies of Elem and Node objects as they're being used for evaluations, and move the copies. This way you can have two neighboring elements moving independently on different threads. This would require some extra hassle to handle neighboring elements if dof_map.use_coupled_neighbor_dofs(mesh) is true... but that could wait, and even that hassle would probably be exceeded by the hassle of doing locking properly and efficiently otherwise. Perhaps I should have done the TimeSolver integration on global vectors rather than per-element, so we'd be moving the whole mesh at once rather than one element at a time. The way I do it uses less memory and is faster for non-ALE codes, but it's definitely made the code more convoluted. Premature optimization is the root of something something... --- Roy ------------------------------------------------------------------------------ _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
