I see what you mean. In the meantime, I worked out how to automatically
generate meshes where the boundary faces have a matching discretization,
and I'm trying to work with PeriodicBoundary. However, I always get a
"Periodic boundary neighbor not found" error. I thought the matched-face
meshing might not have worked correctly, so I did some manual checks
with PointLocatorBase. Maybe you guys could make sense of what's happening,
because I am very confused. Here's a chunk of my code that manually looks
for a matching node on the "far" face:
dims.a = maxX - minX;
Point pbc_a(dims.a, 0.0, 0.0);
unique_ptr<PointLocatorBase> plt =
PointLocatorBase::build(PointLocatorType::TREE, *mesh);
vector<dof_id_type> nodeIDs;
vector<boundary_id_type> bndIDs;
bndInfo.build_node_list(nodeIDs, bndIDs);
double my_tol = 1e-3;
vector<dof_id_type>::const_iterator nidit = nodeIDs.begin();
vector<boundary_id_type>::const_iterator bit = bndIDs.begin();
for (; nidit != nodeIDs.end(); nidit++, bit++) {
const Node& n = mesh->node_ref(*nidit);
if (*bit == bid_Xn) {
Point nx = n + pbc_a;
const Node* match_x = plt->locate_node(nx, nullptr, my_tol);
if (match_x == nullptr) {
cout << "\nReference node " << *nidit << " for X PBC missing
partner node!\n - Should match at:\t";
nx.print();
}
Point target(5e-4, 1.04416e-4, 1.06315e-4);
Point residual = nx - target;
cout << "\n\nDeviation: ";
residual.print();
cout << "\nResidual = " << residual.norm() << "\n";
cout << "\n\"The Node\" (tol = " << my_tol << "):\n";
const Node* try_again = plt->locate_node(target, nullptr, my_tol);
if (try_again != nullptr) {
cout << "Found on second try:\t";
try_again->print();
cout << "\nNode id = " << try_again->id() << endl;
} else
cout << "Still no match.\n\n";
}
}
I got really confused when I found that the PointLocatorBase fails to find
the matching node on the first try, but finds it on the second try using
the Point literal coordinates. Here's the output for the relevant node:
Reference node 1117 for X PBC missing partner node!
- Should match at: (x,y,z)=( 0.0005, 0.000104416, 0.000106315)
Deviation: (x,y,z)=(4.79554e-10, 4.20976e-10, -1.2105e-10)
Residual = 6.49497e-10
"The Node" (tol = 0.001):
Found on second try: (x,y,z)=( 0.0005, 0.000104416, 0.000106315)
Node id = 242
No choice of tolerance value produces a match on the first try, but there
is a point where the tolerance is small enough that it never finds the
node. I'm not really sure what to make of this.
- Bailey
On Tue, Aug 7, 2018 at 5:25 PM, Roy Stogner <royst...@ices.utexas.edu>
wrote:
>
> 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
>
------------------------------------------------------------------------------
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
