Couldn't find periodic neighbors!

[ahmad681]

Hi there, for an polycrystalline RVE that I generate from EBSD data, that looks like:

using Dream3D gmsh pipeline, I generate the gmsh.msh file, and here's a visual,

this mesh should be 32x32x32.
I made sure it is periodic mesh too.

The orientation file that I am giving in eulerangles in degrees.

Using manual translation of the periodic BC, as following:

[./Periodic]
[./x]
variable = disp_x
primary = 3
secondary = 1
translation = '32 0 0'
[../]

[./y]
  variable = disp_y
  primary = 2
  secondary = 4
  translation = '0 32 0'
[../]

[./z]
  variable = disp_z
  primary = 5
  secondary = 6
  translation = '0 0 32'
[../]

[../]

[./y_pull_function]
type = PresetVelocity
variable = disp_z
boundary = zp_face
function = pull
[../]
[]

after setting up in moose, I get an error that I tried my best to resolve, but no luck:

*** Info ***
For side dimension 1 we did not find paired boundaries (sidesets) in X due to the presence of 0 -X normal and 0 +X normal boundaries.

*** Info ***
For side dimension 1 we did not find paired boundaries (sidesets) in Y due to the presence of 0 -Y normal and 0 +Y normal boundaries.

*** Info ***
For side dimension 1 we did not find paired boundaries (sidesets) in Z due to the presence of 0 -Z normal and 0 +Z normal boundaries.

*** Info ***
For side dimension 2 we did not find paired boundaries (sidesets) in X due to the presence of 2 -X normal and 2 +X normal boundaries.

*** Info ***
For side dimension 2 we did not find paired boundaries (sidesets) in Y due to the presence of 2 -Y normal and 2 +Y normal boundaries.

*** Info ***
For side dimension 2 we did not find paired boundaries (sidesets) in Z due to the presence of 2 -Z normal and 2 +Z normal boundaries.

*** Warning ***
/depot/aelazab/apps/Ahmad/projects/editrhocp/examples/BCC_EBSD_T91steel/tstBC1discp/test_gmsh/new_cp_bcc_3D.i:5.1:
The following warning occurred in the MooseMesh 'mesh' of type MeshGeneratorMesh.

Could not find a match between boundary 'front' and 'bottom_center' to set periodic boundary conditions for variable (index:2) in either the X, Y or Z direction. The periodic dimension of the mesh for this variable will not be stored.

*** ERROR ***
Periodic boundary neighbor not found
[9] ../src/base/periodic_boundaries.C, line 107, compiled Jun 9 2025 at 16:28:57

The weird thing is when I also try the auto-detect of the PBC,
[BCs]
[./Periodic]
[./all]
variable = 'disp_x disp_y disp_z'
auto_direction = 'x y z'
[../]
[../]

[./y_pull_function]
type = PresetVelocity
variable = disp_z
boundary = zp_face
function = pull
[../]
[]

I get different error

*** Info ***
For side dimension 2 we did not find paired boundaries (sidesets) in X due to the presence of 2 -X normal and 2 +X normal boundaries.

*** Info ***
For side dimension 2 we did not find paired boundaries (sidesets) in Y due to the presence of 2 -Y normal and 2 +Y normal boundaries.

*** Info ***
For side dimension 2 we did not find paired boundaries (sidesets) in Z due to the presence of 2 -Z normal and 2 +Z normal boundaries.

*** ERROR ***
/depot/aelazab/apps/Ahmad/projects/editrhocp/examples/BCC_EBSD_T91steel/tstBC1discp/test_gmsh/new_cp_bcc_3D.i:342.5:
The following error occurred in the Action 'all' of type AddPeriodicBCAction.

Couldn't auto-detect a paired boundary for use with periodic boundary conditions in the 'x' direction

I tried the two meshing method, either gmsh, or GeneratedMeshGenerator, and neither does work!

[Mesh]
construct_side_list_from_node_list = true

[./emg]

type = FileMeshGenerator

file = gmsh.msh

[]

[./emg]
type = GeneratedMeshGenerator
dim = 3
elem_type = HEX8
xmin = 0.0
xmax = 32.0
ymin = 0.0
ymax = 32.0
zmin = 0.0
zmax = 32.0
nx = 32
ny = 32
nz = 32
[../]
[./bottom_center]
type = ExtraNodesetGenerator
new_boundary = bottom_center
#use_closest_node=true
coord = '0 0 0'
input = emg
[../]
[./add_side_sets]
type = SideSetsFromNormalsGenerator
normals = '1 0 0
0 1 0
0 0 1
-1 0 0
0 -1 0
0 0 -1'
fixed_normal = false
new_boundary = 'xp_face yp_face zp_face xn_face yn_face zn_face'
input= bottom_center
[../]
#[./bottom_nodes]
#type = BoundingBoxNodeSetGenerator
#input = add_side_sets
#new_boundary = bottom_nodes

bottom_left = '-2467.5 0.0 0.0'

top_right = '-2467.5 0.0 2.0'

#bottom_left = '15.0 0.0  0.0'
#top_right = '15.0 0.0  5.0'

#bottom_left = '675.0 0.0  0.0'
#top_right = '675.0   0.0  15.0'

#[../]
[]

I am employing the rhoCP package: https://github.com/apatra6/rhocp

I don't think this inherit problem with rhoCP, because with I try different BC like non-periodic:

[BCs]
[./y_roller]
type = DirichletBC
variable = disp_y
boundary = yn_face
value = 0.0
[../]
[./x_roller]
type = DirichletBC
variable = disp_x
boundary = xn_face
value = 0.0
[../]

[./z_roller]
type = DirichletBC
variable = disp_z
boundary = zn_face
value = 0.0
[../]

[./y_pull_function]
type = PresetVelocity
variable = disp_z
boundary = zp_face
function = pull
[../]
[]

the code works just fine only with the genaratedmeshgenerator, but with the gmsh mesh, it throws out the following:
Warning, Exodus files cannot have titles longer than 80 characters. Your title will be truncated.

Time Step 1, time = 0.0001, dt = 0.0001

Skipping predictor this step

Currently Executing
Computing Residual...... [ 36.09 s] [ 568 MB]
Computing Jacobian...... [ 36.11 s] [ 568 MB]
Computing Residual...

Matrix on-diagonal entry 6 was exactly zero during LU factorization in MatrixTools::inverse.
To recover, the solution will fail and then be re-attempted with a reduced time step.

Finished Computing Residual                                                          [ 24.81 s] [  649 MB]

Nonlinear solve did not converge due to DIVERGED_FNORM_NAN iterations 0
Finished Solving [ 98.52 s] [ 650 MB]

Solve Did NOT Converge!

Aborting as solve did not converge

Time Step 1, time = 5e-05, dt = 5e-05

Skipping predictor this step

Computing Residual......                                                             [ 36.30 s] [  650 MB]
Computing Jacobian......                                                             [ 36.08 s] [  650 MB]
Computing Residual...

Matrix on-diagonal entry 5 was exactly zero during LU factorization in MatrixTools::inverse.
To recover, the solution will fail and then be re-attempted with a reduced time step.

Finished Computing Residual                                                          [ 24.11 s] [  663 MB]

Nonlinear solve did not converge due to DIVERGED_FNORM_NAN iterations 0
Finished Solving [ 98.00 s] [ 663 MB]

Solve Did NOT Converge!

Aborting as solve did not converge

Time Step 1, time = 2.5e-05, dt = 2.5e-05

Skipping predictor this step

so this tells me something is wrong with .msh file. But with GeneratedMeshGenerator, the solver works just fine.

I am attaching everything you may need in helping addressing this issue. Thanks a lot.

Ahmad
orientations.txt

the correct extension should be .in
bcc_props_steel.txt

the correct extension should be .in

the correct extension should be .i
bcc_slip_sys.txt
n
new_cp_bcc_3D.txt

the correct extension should be .msh
gmsh.txt

[ahmad681]

also all of these are ran using the following command:

mpirun -np 64 /path_to/projects/editrhocp/rhocp-opt -i new_cp_bcc_3D.i

[GiudGiud]

Hello

variable = disp_x
primary = 3
secondary = 1
translation = '32 0 0'

which one is 3? The front one or the back one?
The translation should be from primary to secondary i think

Does the automatic mode work for the periodic BCs? This is a simple case it might be able to figure it out

the code works just fine only with the genaratedmeshgenerator, but with the gmsh mesh, it throws out the following:

Does the GMSH mesh pass the diagnostics from the meshDiagnosticsGenerator?
https://mooseframework.inl.gov/source/meshgenerators/MeshDiagnosticsGenerator.html

[Ttw0626]

hi, moose developers,

same issue as ahmad, it seems like the tolerance for the boundary pair detec is too restrict.
especially for the coarse input mesh file.

Could u give me some suggestions about correctly periodic boundary condition with input mesh file ?

tianwen

[GiudGiud]

please make your own thread and include enough details. Notably the simulation log, the input etc