In that sense of "unstructured", strong enforcement of periodic
boundaries would lead to "locking". Imagine piecewise linear or
bilinear elements, with nodes like:
A----B--C------D--E-F
on one side of the boundary and
G-H---I-----J---K---L
on the other.
Side AB forces GH and HI to have the same tangential gradient, HI
forces AB and BC to have the same, BC forces HI and IJ to have the
same, IJ forces BC and CD to have the same, and so on, until instead
of having six degrees of freedom on that boundary you have only 2.
Do a uniform refinement and instead of 12 degrees you'll still have 2.
And so on.
---
Roy
On Tue, 7 Aug 2018, Paul T. Bauman wrote:
Posting reply to list.
On Tue, Aug 7, 2018 at 9:40 AM Bailey Curzadd <bcurza...@gmail.com> wrote:
That's correct.
Paul T. Bauman <ptbau...@gmail.com> schrieb am Di., 7. Aug. 2018, 15:32:
To clarify, do you mean unstructured here in the sense that the two
boundaries that are to be periodic are not simply a translation of one
another? E.g. nodes do not match up?
On Tue, Aug 7, 2018 at 9:08 AM Bailey Curzadd <bcurza...@gmail.com>
wrote:
Hi there,
I'm using libMesh to calculate the homogenized properties of
microstructures with cuboid unit cells. To do this, the boundaries of the
unit cell require periodic boundary conditions. As far as I can tell,
though, the PeriodicBoundary class only works with structured meshes,
which
isn't really a feasible option for me. Is this really the case, or have I
just missed something in my implementation?
Currently, I am manually mapping each constrained node on the "far"
boundary to an element/side pair on the "near" boundary using
PointLocatorBase and Elem::side_ptr()->contains_point(). Then, I use the
penalty method to apply a constraint equation with coefficients found
using
FE<2,LAGRANGE>::shape().
The issue I have at the moment most likely concerns preallocation of the
system matrix. Calls to matrix->add_matrix() are taking a very long time,
since the DofMap would obviously not expect a node on one side of the
mesh
to be coupled with the nodes on the opposite side. Is there a convenient
way to make libMesh preallocate extra space beforehand, or does this need
to be done manually? I'm using PETSc, but I'd like the code to stay
solver-independent if possible.
I've considered switching to the Lagrange multiplier method using 2
additional field variables as was suggested for a question I posted
earlier
for a different project. However, this would add 2 DOFs to each node, and
I'm not even sure this would circumvent the preallocation problem I have
for the penalty method. Any suggestions concerning the best way to use
libMesh for this problem would be appreciated.
- Bailey C
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users
