From: Roy S. <roy...@ic...> - 2018-08-07 15:25:20
|
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 <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 >>>> >>> > ------------------------------------------------------------------------------ > 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 > > |