Re: [Libmesh-users] Periodic BCs for unstructured mesh

[Paul T. B. <ptb...@gm...>]

Posting reply to list.

On Tue, Aug 7, 2018 at 9:40 AM Bailey Curzadd <bcu...@gm...> wrote:

> That's correct.
>
> Paul T. Bauman <ptb...@gm...> 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 <bcu...@gm...>
>> 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
>>> Lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>>>
>>