> I don't disagree that the optimal mesh for each component would be great to > have, but I just hope you aren't underestimating the overhead involved in > seeking that composite mesh. This is *especially* true in the transient > case. When you add it all together the transient+adaptive+nonlinear+linear > nested looping really can get out of control.
Yes, I understand the complications this is going to involve. That is why I am planning to attack this one step at a time. I already have the code in place to solve a single physics (diffusion-reaction) with transient+nonlinear+linear loops in place, where I manually create and use my SNES object and application context. I personally think that the nonlinear solver in Libmesh needs more work in terms of providing routines to set different options that PETSc SNES object exposes. But then again, this might be specific to my current implementation and hence don't want to generalize this. Anyway, the next step would be to design a custom interface to deal with the different physics and implement the coupling in a consistent way, so as to not lose the spatial accuracy, while using different meshes. If all those work according to plan, then adaptivity in space will be included and then later adaptivity in time using higher order IRK schemes. That way, I will be able to test all the solution procedure thoroughly and have confidence in the final solution. I am curious as to what kind of multiphysics problems you have solved with Libmesh before and what kind of approach you took for those. I gather you used a single mesh for both the physics but where you able to preserve the accuracy of the coupled solution in space and time ? And did you use Operator-splitting with iterations over the coupled physics ? ~Vijay On Wed, Feb 20, 2008 at 9:57 PM, Benjamin Kirk <[EMAIL PROTECTED]> wrote: > > > 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. > > I don't disagree that the optimal mesh for each component would be great to > have, but I just hope you aren't underestimating the overhead involved in > seeking that composite mesh. This is *especially* true in the transient > case. When you add it all together the transient+adaptive+nonlinear+linear > nested looping really can get out of control. > > My experience with a number of transient multiphysics problems has shown > this repeatedly. The "optimal" mesh in a transient reactive problem is > elusive -- it will be different at each timestep! Sure, the DOF count may > be lower, but when you roll it all together my tried and true approach is to > throw more mesh than you need at the current timestep but then go a while > before refining (and reallocating (and repartitioning (and projecting > ...))). I can almost guarantee much faster walltime with this approach. If > the implicit system gets big you can run on a bigger machine, right? ;-) > > -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
