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 PR-BC 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 PR-BC 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 PR-BCs. 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
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
