Panzer: Wedge periodic boundaries

[delcmo]

Hello,

we have been trying to use the wedge periodic capability available in Panzer without success. We usually generate meshes with Cubit and it has been working fine with periodic boundaries in 2D and 3D (xz-all, yz-all, ...). For wedge periodic boundaries, we looked at the example https://github.com/trilinos/Trilinos/blob/master/packages/panzer/adapters-stk/example/main_driver/periodic_wedge.xml to understand the nomenclature and the associated orientation of the geometry. We reproduced the same mesh in Cubit but were not able to run it with our Trilinos-based code.

create Cylinder height 10 radius 0.5
brick x 1 y 3 z 20
move Volume 2 x -0.5 include_merged 
subtract volume 2 from volume 1 
brick x 3 y 1 z 20
move Volume 3 y -0.5 include_merged 
subtract volume 3 from volume 1 
curve 36 38 40 interval 8
Surface 20 23 scheme map
mesh Surface 24
mesh Surface 20
copy mesh surface 20 onto surface 23 source curve 33 source vertex 24 target curve 33 target vertex 24
mesh volume 1

sideset 1 add surface 22
sideset 1 name "inlet"
sideset 2 add surface 24
sideset 2 name "outlet"
sideset 3 add surface 20
sideset 3 name "xz"
sideset 4 add surface 23
sideset 4 name "yz"
sideset 5 add surface 21
sideset 5 name "wall"
set duplicate block elements off
block 1 add volume 1
block 1 name "block-1"
block 1 element type hex8

The matcher returns an error message:

p= 4 | Not all sides matched expect failure:
p= 4 | /home/mxd/software/air_gap_rel0.18_update/Trilinos-trilinos-release-13-2-0/packages/panzer/adapters-stk/src/stk_interface/Panzer_STK_PeriodicBC_Matcher_impl.hpp:317:
p= 4 |
p= 4 | Throw number = 1
p= 4 |
p= 4 | Throw test that evaluated to true: checkProb
p= 4 |
p= 4 | getLocallyMatchedSideIds: checkProb failed
p= 5 | Not all sides matched expect failure:
p= 5 | /home/mxd/software/air_gap_rel0.18_update/Trilinos-trilinos-release-13-2-

1. Has anyone used a Cubit mesh with wedge periodic boundaries in Panzer?
2. What are the mesh requirements of the two periodic faces? I assume they have to be identical.
3. Any recommendations on how to debug and try to identify the issue(s)?

Thanks,

Marco

[ccober6]

@trilinos/panzer @rppawlo

[rppawlo]

@delcmo - we do routinely use cubit meshes for the wedge periodic boundary condition in applications based on panzer. The node matching is very sensitive to how the mesh is constructed. The "copy mesh surface" is typically what we use to map things over, so at first glance it looks like you are doing the right thing. Ideas:

1. The mesh has to be symmetric over the xz or yz plane and you need to tell the matcher over which plane your mesh is mirrored. You might just have to rotate the entire mesh. I ran the cubit input above through cubit 16.18 and it does not look like the mesh is aligned with either plane.
2. Check the tolerance for the matcher. If the tolerance in the matcher is too tight, it may not find any nodes and if it is too loose, it may find multiple nodes. The tolerance is very mesh dependent.

I'll try to get a unit test with a cubit mesh into panzer, but probably won't happen until next month.

[delcmo]

Thanks Roger for your help. I have a few follow-up questions:

• Does the angle between the two faces to match have to be 90 degree, or can it be an arbitrary angle?
• When you write The mesh has to be symmetric over the xz or yz plane, do you mean the xz plane has to be located between the two faces to match and at equal distance from the two faces?

Marco

[rppawlo]

It can be any angle although I don't think we've tested larger than 120 degrees.
Yes - the xz or the yz plane must be located between and at equal distance from the two faces. I believe the centerline/axis of rotation of the wedge must also align with the z axis, but would have to check that.

[delcmo]

We were able to get it to work with an angle of 90 degrees but we cannot get a converged solution yet. We will keep playing with it but I think this issue can be resolved.

Thanks for the help.

Marco

[delcmo]

We have been playing a bit more with the wedge condition and the numerical solution is not stable. I am trying to understand how variables are being treated at the wedge boundaries. Since I am solving for velocity where each component is treated as a scalar, how is each component treated at the wedge boundary?

Marco

[rppawlo]

Hi @delcmo - The periodic BCs in panzer are handled in the connection manager. The connection manager supplies the GIDs and element connectivity to the panzer DOF manager. The STK derived class for the conn manager replaces the global gids for matching element entities so that they are the same on each face. The implementation is here:

Trilinos/packages/panzer/adapters-stk/src/Panzer_STKConnManager.cpp

Line 299 in 3e7486f

void STKConnManager::applyPeriodicBCs(const panzer::FieldPattern & fp, GlobalOrdinal nodeOffset, GlobalOrdinal edgeOffset,

I'd be happy to hop on teams to discuss this more if you are around today.

[mperego]

@delcmo It might not be relevant for this, but when working with wedges we noted that it's better to avoid using a cubature rule of order 3. This is likely because the cubature rule of order 3 for triangles have negative weights.