When working with a periodic boundary condition, OpenMC will warn the user if their periodic angle does not evenly divide into 360.
angle_ = compute_periodic_rotation(norm1[axis_2_idx_], norm1[axis_1_idx_],
norm2[axis_2_idx_], norm2[axis_1_idx_]);
// Warn the user if the angle does not evenly divide a circle
double rem = std::abs(std::remainder((2 * PI / angle_), 1.0));
if (rem > FP_REL_PRECISION && rem < 1 - FP_REL_PRECISION) {
warning(fmt::format(
"Rotational periodic BC specified with a rotation "
"angle of {} degrees which does not evenly divide 360 degrees.",
angle_ * 180 / PI));
}
}
I’m working on a 1/6th core model, and I got a warning
WARNING: Rotational periodic BC specified with a rotation angle of
299.99999999999994 degrees which does not evenly divide 360 degrees.
The compute_periodic_rotation function thinks I hit 300 degrees, which is 360-60, so it must be computing the angle that compliments my slice. I don’t think it’s an issue per se (which is why I’m here and not github). I’m aware of the surface.flip_normal() function, but when I tried that something very strange happened.
The warning goes away, but the physics of my problem is clearly not the same and it did something on a batch I’ve never seen before (below)
In the above image, the left side is what happens when I flip one of my normals. The right side is what happens without that / the normal model (that computes 300 degrees). I did not expect
flip_normal to cause this difference in results, so maybe I’m misunderstanding?
I’m not hitting lost particles, but something is very very wrong with the flip normal case. Maybe with a normal in the wrong direction the particle gets into an infinite loop where it gets transported back to where it started and keeps hitting the surface, as opposed to entering the other plane? I’m not sure openmc should fail, but it did have that warning so perhaps nothing needs to happen. I was just wondering if anyone has any explanation for my observation.