Ben, The penalty of using operator-splitting is that you end up with a discrete system that has only conditional stability in time integration since the coupling is explicit. If you do iterate between the different operators at each time step, such an issue can be avoided but at the increased cost of coupled physics iterations/time step.
My goal is to perform fully implicit coupling (without operator splitting) of 2 different physics and use the SNES Petsc object to solve the nonlinear system. I guess from your previous answer I glean that this is currently not possible due to the issue with the association of the mesh to EquationSystems. I was thinking about a "hack" to simulate such a behavior by creating a dummy EquationSystems object/System (Nonlinear or Linear) and associate a corresponding mesh to the EquationSystems object. But my question then is whether this would entail excessive overhead say in creating 2-3 such Systems and managing them manually to interface and control the interactions. On a sidenote, it seems to be an odd design decision in Libmesh IMHO to associate the mesh to EquationSystems rather than System. Since EquationSystems is a collection of different Systems that can reside on different meshes individually, and no one other than the system managing the solution needs to know about the computational mesh for the different variables. If this was the case, you could create meshes for each system, associate it with the unknown variables and add them to a collection, the EquationSystems object. And that makes a lot of sense to me. Also I would like to know the reason for such a design and if it is something that is necessary in the solution procedure. If I have naively overlooked important aspects in my statement, feel free to set me straight ! Thanks for all the help. Vijay On Feb 18, 2008 11:05 AM, Benjamin Kirk <[EMAIL PROTECTED]> wrote: > > > Assume that a multi-physics problem or a problem with single system on > > a staggerred grid (velocity, pressure on different meshes) needs to be > > solved. Since the Mesh is always associated with EquationSystems and > > the association of a LinearImplicitSystem or NonlinearImplicitSystem > > to the EquationSystems is how the description of the problem mesh is > > made, you can quickly see that without a constructor for the System > > class to take its own mesh object, there is an inherent difficulty in > > associating 2 meshes to the same problem. I hope that wasn't > > confusing. > > Splitting the discrete operator into two systems will force you to solve > them iteratively in a decoupled fashion -- so long as you are OK with this > then you could effectively accomplish the same thing with two > EquationSystems objects, each one containing its own distinct mesh and > System. I have not tried it, but I would think that should work fine. > > If it does not work then that should probably be considered a bug and get > fixed. > > -Ben > > ------------------------------------------------------------------------- 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
