Thanks for all the responses. It is always great to hear different opinions !
Roy, Thanks for the detailed response. I now understand that a Fully implicit coupled solve, if need be, has to be performed only by manually managing the libmesh objects (EquationSystems, Mesh and System). I also understand the problem with deriving the sparsity pattern for a given coupled equation system since this is something I've been working on for the past few weeks. >> 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. Yes. This is something I have to attack soon since non-overlapping meshes in different physics is inevitable in the problem I am solving and performance of the solution procedure is quite an important consideration. Also, thanks very much for pointing me to the MultiMesh. I will try to find out more about it and see how useful it is for my case. John, What you suggested is a perfect Operator-Splitting algorithm :-) and hence will have the stability limit and a first order in time penalty unless I iterate over the solution for each physics. I've already tried this before although not with Libmesh, and can tell you that this is not an option for problems I will be dealing with. I do plan to have that option open in order to be used for physics-based preconditioning to accelerate convergence of the fully implicit nonlinear solve/time step. Again, thanks for confirming that I need to maintain my own equationsystems and mesh ! Ben, Multi-physics problems usually have physics with different length scales and different time scales. It is necessary to use appropriate meshes depending on the physics to resolve the evolution of solution and using a single mesh (union of all physics meshes) will lead to a very high DoF than needed and I'll literally be overkilling the problem. The other issue you raise is a very valid one and interpolation error would reduce the spatial convergence to first order, if not done properly. There are several ways I think will preserve the spatial accuracy when coupling solutions on different meshes and this is currently a hot research topic in the multi-physics community. I will also be dealing with this very soon when my coupled diffusion code is ready and will let you know my findings. Everyone, thanks for all the suggestions and help in making me understand the capability and limitations of the current implementation of LibMesh. I am going to go ahead with the idea to maintain separate meshes for each physics, compute the residuals, and solve the nonlinear system with SNES manually. I will definitely have a lot of questions when I dig in more into this. Appreciate all the help and feel free to suggest alternative implementations. Vijay On Wed, Feb 20, 2008 at 7:31 PM, Roy Stogner <[EMAIL PROTECTED]> wrote: > > On Wed, 20 Feb 2008, Benjamin Kirk wrote: > > > If these truly need to be in the same implicit system, though, I cannot > > think of *why* you would want to have them on two separate > discretizations?? > > To use separate refinement patterns. For a simple example, the solute > layers you might want to adaptively resolve in a concentration > variable for a transport problem won't necessarily have anything to do > with the boundary layers and/or corner singularities in the > velocity/pressure variables. It's not a bad idea, it's just very hard > to do in such a way that the computational overhead of maintaining and > integrating on separate meshes doesn't overwhelm the computational > benefit of getting the same solution quality with fewer redundant > degrees of freedom. > --- > 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 > ------------------------------------------------------------------------- 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
