From: robert <libmesh@ro...>  20111007 14:47:07

Hi, I am doing solid mechanics calculations with FEMSystem and a moving mesh and need periodic boundary conditions. As the PRBC code in libmesh only works for unmodified meshes, I wrote some thing similar which saves a mapping of the nodes on the positive side to the nodes of the negative side in the first timestep (on the unmodified mesh) and uses this mapping in all following timesteps to impose the periodic boundary conditions. As especially the PRBC causes entries in "unusual" regions of the system matrix, I have currently a rather large performance issue due to the resorting of the matrix while adding the PRBCs. So how can I influence the default sparsity pattern used to create the system matrix to avoid these performance issues? Robert 
From: Roy Stogner <roystgnr@ic...>  20111007 15:24:09

On Fri, 7 Oct 2011, robert wrote: > I am doing solid mechanics calculations with FEMSystem and a moving mesh > and need periodic boundary conditions. As the PRBC code in libmesh only > works for unmodified meshes, I wrote some thing similar which saves a > mapping of the nodes on the positive side to the nodes of the negative > side in the first timestep (on the unmodified mesh) and uses this > mapping in all following timesteps to impose the periodic boundary > conditions. What's your definition of an "unmodified mesh"? If you're modifying the mesh via AMR, the periodic BC code should be keeping up with that correctly; we do that in one of the examples. If you're modifying the mesh via element removal or node movement, then even in that case the periodic BC code should be okay just as long as the periodic boundaries are always translations of each other by a constant vector. Even if you're doing a more complex relation between moving boundaries you ought to be able to pull that off with the library by subclassing PeriodicBoundary and overriding get_corresponding_pos(). > As especially the PRBC causes entries in "unusual" regions of the system > matrix, I have currently a rather large performance issue due to the > resorting of the matrix while adding the PRBCs. So how can I influence > the default sparsity pattern used to create the system matrix to avoid > these performance issues? Forget about performance issues; you may have *correctness* issues, when you try to run in parallel and the ghosted vectors use a send_list which doesn't take into account that a processor on one side of the boundary needs degree of freedom coefficients from the other side. If your periodic BCs can be expressed homogeneously (e.g. left side = multiple of right side) then you can probably write them as constraint equations, then add them as user constraints. The library then makes sure that the sparsity pattern and ghost dof sets are large enough to handle the resulting requirements.  Roy 
From: robert <libmesh@ro...>  20111010 12:33:31

Hi, On Fri, Oct 07, 2011 at 10:23:57AM 0500, Roy Stogner wrote: > > On Fri, 7 Oct 2011, robert wrote: > > > I am doing solid mechanics calculations with FEMSystem and a moving mesh > > and need periodic boundary conditions. As the PRBC code in libmesh only > > works for unmodified meshes, I wrote some thing similar which saves a > > mapping of the nodes on the positive side to the nodes of the negative > > side in the first timestep (on the unmodified mesh) and uses this > > mapping in all following timesteps to impose the periodic boundary > > conditions. > > What's your definition of an "unmodified mesh"? If you're modifying > the mesh via AMR, the periodic BC code should be keeping up with that > correctly; we do that in one of the examples. If you're modifying the > mesh via element removal or node movement, then even in that case the > periodic BC code should be okay just as long as the periodic > boundaries are always translations of each other by a constant vector. I just modify the mesh by changing the coordinates of the nodes. So my unmodified mesh is the generated by e.g. MeshTools::Generation::build_square. If the periodic BC are working correctly, the boundaries should just be translated by a vector. But my primary variables are coordinates (x,y,z) of the nodes and not the displacements. I am doing this to get the various derivations of the shape functions at the boundary sides without having to reinit something. So with coordinates as primary variable the constrains for periodic BCs looks like: \vec{x^{+}}  \vec{x^{}} = \vec{d} (With x+ a point on the positive side, x the corresponding point on the negative side and d the constant vector between the two boundaries) >From what you said below and some looking around in the code I guess, that the library can just process conditions like: \vec{x^{+}} = \vec{x^{}} > Even if you're doing a more complex relation between moving boundaries > you ought to be able to pull that off with the library by subclassing > PeriodicBoundary and overriding get_corresponding_pos(). > > > As especially the PRBC causes entries in "unusual" regions of the system > > matrix, I have currently a rather large performance issue due to the > > resorting of the matrix while adding the PRBCs. So how can I influence > > the default sparsity pattern used to create the system matrix to avoid > > these performance issues? > > Forget about performance issues; you may have *correctness* issues, > when you try to run in parallel and the ghosted vectors use a > send_list which doesn't take into account that a processor on one side > of the boundary needs degree of freedom coefficients from the other > side. Currently I am not running it in parallel, as I was not able to get the solutions of all processors into one exodusII or vtk file, but that is another, independent problem. > If your periodic BCs can be expressed homogeneously (e.g. left side = > multiple of right side) then you can probably write them as constraint > equations, then add them as user constraints. The library then makes > sure that the sparsity pattern and ghost dof sets are large enough to > handle the resulting requirements. As I wrote above, I can not express them homogeneously. Do you have a suggestion beside using the homogeneous ones and try to add the rhs of the constrain manually to the global rhs vector? Robert >  > Roy 