# Just Launched: You can now import projects and releases from Google Code onto SourceForge

We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps.

## libmesh-users

 [Libmesh-users] about conjugate heat transfer problem From: luyi - 2008-07-31 08:01:32 ```hello,ben, Some one had asked you about the multi-physical problems using libmesh, and you tell us you are working the conjugate heat transfer problem. As the question "Associating more than one mesh to EquationSystems", I want to perform fully implicit coupling(without operator splitting) and use the Newton-Krylov method to solve conjugate heat transfer problem, the difference is that I am not using stagger mesh, only one mesh departed to domain A and domain B, the variables in domain A are rho,u,v,w,E,k,w and in domain B only T, and I want to assemble the Jacobian matrix and the rhs together, can I using only one EquationSystems and one mesh to implement this? Best regards! Luyi -- Gas Turbine Research Center email: luyi06@... ```
 Re: [Libmesh-users] about conjugate heat transfer problem From: Roy Stogner - 2008-07-31 13:09:12 ```On Thu, 31 Jul 2008, luyi wrote: > Some one had asked you about the multi-physical problems using libmesh, > and you tell us you are working the conjugate heat transfer problem. > > As the question "Associating more than one mesh to EquationSystems", I > want to perform fully implicit coupling(without operator splitting) and > use the Newton-Krylov method to solve conjugate heat transfer problem, > the difference is that I am not using stagger mesh, only one mesh > departed to domain A and domain B, the variables in domain A are > rho,u,v,w,E,k,w and in domain B only T, and I want to assemble the > Jacobian matrix and the rhs together, can I using only one > EquationSystems and one mesh to implement this? At the moment I think the answer is "not efficiently". Although our meshes can be flagged with subdomain ids, our DofMap still assumes that every subdomain in the mesh has the same variables defined on it. What we need is an API for the user to say "this variable only exists on subdomains 1, 5, and 13", as well as the DofMap code to respect those requests. Unless you want to dig into the library source code and add that feature (for which a patch would be much appreciated, naturally), I think the best you can do for a fully coupled solve is define all variables everywhere, then manually restrict T to be 0 on domain A and all the other variables to be 0 on domain B. --- Roy ```
 Re: [Libmesh-users] about conjugate heat transfer problem From: luyi - 2008-08-01 06:01:46 ```Hello, Roy, Thank you for your reply. Because I want to use Jacobian_free Newton_Krylov method to solve the problem, if I setup two EquationSystems for each domain, I will get two rhs and connect them, with a matrix_free preconditioner I can get the full implicit solver, is that advisable? If it is OK, the only thing I need to do is write a suitable send_list for parellel like the unconformed mesh? By the way, because my implicit discontinuous code need so much memory, so I want to use Jacobian_free Newton_Krylov method and write a matrix free preconditioner, can you give me some suggestions about this? Do I need to write a JFNK_systems inherit from the class "explicit_system"? Thank you very much! Best regards! Luyi 在 2008-07-31四的 08:09 -0500，Roy Stogner写道： > moment I think the answer is "not efficiently". Although our > meshes can be flagged with subdomain ids, our DofMap still assumes > that every subdomain in the mesh has the same variables defined on it. > What we need is an API for the user to say "this variable only exists > on subdomains 1, 5, and 13", as well as the DofMap code to respect > those requests. Unless you want to dig into the library source code > and add that feature (for which a patch would be much appreciated, > naturally), I think the best you can do for a fully coupled solve is > define all variables everywhere, then manually restrict T to be 0 on > domain A and all the other variables to be 0 on domain B. -- Gas Turbine Research Center email: luyi06@... ```
 Re: [Libmesh-users] about conjugate heat transfer problem From: Roy Stogner - 2008-08-01 13:00:49 ```On Fri, 1 Aug 2008, luyi wrote: > Because I want to use Jacobian_free Newton_Krylov method to solve the > problem, if I setup two EquationSystems for each domain, I will get two > rhs and connect them, with a matrix_free preconditioner I can get the > full implicit solver, is that advisable? Hmmm.. That is an interesting idea, anyway. No need to worry about whether the sparsity pattern is constructed correctly if you're not using a sparse matrix. > If it is OK, the only thing I need to do is write a suitable send_list > for parellel like the unconformed mesh? I don't think you can do this with just a send_list. Both systems will assume that the DofMap has told them about every degree of freedom they need to directly worry about, and you can't construct a proper send_list when your systems are giving you rhs vectors that aren't even the proper size. You'd have to do the parallel synchronization yourself, and considering that the partitionings of each mesh aren't guaranteed to correspond to each other in any way, I think it could get tricky. On the other hand, doing things Jacobian-free makes my "define all variables everywhere" suggestion slightly less retarded; the memory waste in your vectors might be tolerable with no waste in a sparse matrix to worry about. And of course, the "right" thing to do is still to modify DofMap to handle different variables on different subdomains, but I completely understand if you don't want to try to figure out *that* code. I could do it myself, but I don't know when my schedule will permit. I'd also need to know what sort of API/representation to use. Assume when variables are created that they're defined everywhere, but let users "turn off" variables on certain subdomains before initialization? Store the "turned off" data as a set of pairs of subdomain id and variable number? > By the way, because my implicit discontinuous code need so much memory, > so I want to use Jacobian_free Newton_Krylov method and write a matrix > free preconditioner, can you give me some suggestions about this? Do I > need to write a JFNK_systems inherit from the class "explicit_system"? You might want to talk to Derek Gaston. He's started using JFNK, although I think he's currently keeping the sparse matrix around to fill with an inexact Jacobian for preconditioning. I believe he's using NonlinearImplicitSystem and PetscNonlinearSolver to do it. The trouble with that is the dependency on NonlinearImplicitSystem, which inherits from ImplicitSystem and which therefore will construct a memory-hogging matrix whether you plan to use it or not. But looking over the code, I don't see any reference to a NonlinearImplicitSystem which couldn't be replaced with a reference to System without breaking anything. You could just make those replacements, then create a NonlinearExplicitSystem which has the same sort of NonlinearSolver member and ::solve() behavior as NIS. --- Roy ```
 Re: [Libmesh-users] about conjugate heat transfer problem From: luyi - 2008-08-05 01:59:53 ```在 2008-08-01五的 08:00 -0500，Roy Stogner写道： > On Fri, 1 Aug 2008, luyi wrote: > > > Because I want to use Jacobian_free Newton_Krylov method to solve the > > problem, if I setup two EquationSystems for each domain, I will get two > > rhs and connect them, with a matrix_free preconditioner I can get the > > full implicit solver, is that advisable? > > Hmmm.. That is an interesting idea, anyway. No need to worry about > whether the sparsity pattern is constructed correctly if you're not > using a sparse matrix. > > > If it is OK, the only thing I need to do is write a suitable send_list > > for parellel like the unconformed mesh? > > I don't think you can do this with just a send_list. Both systems > will assume that the DofMap has told them about every degree of > freedom they need to directly worry about, and you can't construct a > proper send_list when your systems are giving you rhs vectors that > aren't even the proper size. You'd have to do the parallel > synchronization yourself, and considering that the partitionings of > each mesh aren't guaranteed to correspond to each other in any way, I > think it could get tricky. > > On the other hand, doing things Jacobian-free makes my "define all > variables everywhere" suggestion slightly less retarded; the memory > waste in your vectors might be tolerable with no waste in a sparse > matrix to worry about. > > And of course, the "right" thing to do is still to modify DofMap to > handle different variables on different subdomains, but I completely > understand if you don't want to try to figure out *that* code. I > could do it myself, but I don't know when my schedule will permit. > I'd also need to know what sort of API/representation to use. Assume > when variables are created that they're defined everywhere, but let > users "turn off" variables on certain subdomains before > initialization? Store the "turned off" data as a set of pairs of > subdomain id and variable number? Because the JFNK method, if I can define different variables on different subdomains, and the dof_map can set the rhs arrangement like this : [rhs(fluid),rhs(heat transfer)]', then the matrix-free preconditioner will sweep elem by elem, fluid subdomain and heat transfer subdomain can be handled by different methods. As you said, it is difficult for me to modify "dof_map.C",haha, I am impassioned if libmesh can deal with this in future. > > > By the way, because my implicit discontinuous code need so much memory, > > so I want to use Jacobian_free Newton_Krylov method and write a matrix > > free preconditioner, can you give me some suggestions about this? Do I > > need to write a JFNK_systems inherit from the class "explicit_system"? > > You might want to talk to Derek Gaston. He's started using JFNK, > although I think he's currently keeping the sparse matrix around to > fill with an inexact Jacobian for preconditioning. I believe he's > using NonlinearImplicitSystem and PetscNonlinearSolver to do it. > > The trouble with that is the dependency on NonlinearImplicitSystem, > which inherits from ImplicitSystem and which therefore will construct > a memory-hogging matrix whether you plan to use it or not. But > looking over the code, I don't see any reference to a > NonlinearImplicitSystem which couldn't be replaced with a reference to > System without breaking anything. You could just make those > replacements, then create a NonlinearExplicitSystem which has the same > sort of NonlinearSolver member and ::solve() behavior as NIS. > --- > Roy > Thank you for your suggestion! Luyi -- Gas Turbine Research Center email: luyi06@... ```