On Wed, 20 Feb 2008, Vijay S. Mahadevan wrote: > For simplification, consider 2 physics on the same domain: Consider > the 3-D heat conduction and a neutron diffusion model (both are > nonlinear diffusion-reaction equations) which are described over the > same 3D domain. Now, can I get away with using a single > EquationSystems object with a single mesh even though the element > sizes used for different physics could be different ? And since I > would define 'mesh' to be the representation of the domain using > different elements, and since the elements used in terms of size and > type could be different for different physics, these would be > different meshes. Does that make sense ?
This makes sense, but I don't think it's a situation that we're currently set up to handle well. If you want to do explicit or decoupled implicit solves then you're probably okay with using multiple EquationSystems with a different Mesh on each (although you might have to pay more attention to quadrature than usual). But, if you want to mix physics from different meshes and solve a linear system for all variables at once, the problem is more complex than just storing a different mesh for each variable. Just getting the sparsity pattern right would be a non-trivial task, if you're concerned with memory use then you'll want to use a complex data structure which "shares" common elements between meshes yet allows indpendent adaptivity of each, and if you're concerned with performance then you'll need to create (and maintain through adaptivity) lookup tables to quickly find elements in one mesh which overlap an element in another. libMesh does none of those things. I think I've only seen one code designed with fully coupled multiphysics on indpendently refined meshes in mind; a presenter at last year's Finite Element Rodeo called it "MultiMesh" if I remember correctly. I don't know if it's public or what it's other drawbacks were, but you might see what you can find online. --- 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
