-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Single-cone surfaces inconsistent between MCNP and OpenMC #59
Comments
Tom, did you ever find a workaround to this? |
Ah I need to fix this, thanks for the reminder - originally I had made a modification to OpenMC to allow this, but it had some numerical issues that I never got to the bottom of. However, there is an easier - though dirtier method that can do the job. I'll push a fix when I can, in essence one would do as you say, an ambiguity surface is added at the apex. |
Andy, after I posted this yesterday, I noticed that the OpenMC API now has "one sided" cones (i.e. openmc.model.YConeOneSided). All it does, as far as I understand, is it automatically creates an ambiguity surface - I don't know if that could help with the translation process or not. Thanks for looking in to it! |
Hello! |
Yes, I need to fix this, originally I had a seperate C++ implementation for OpenMC for a one sided cone, but I never got it merged in, I should replicate what the OpenMC python API does - I think thats actually what I did for FLUKA.... |
MCNP defines cone surfaces (K/X, KX etc.) with an origin, a gradient (t^2) and optionally a +/-1 specifier for single cones (as opposed to double cones). When converting single-cone surfaces from MCNP to OpenMC using csg2csg the +/-1 is kept as a parameter in geometry.xml, but OpenMC rejects this input because it doesn't allow single cones.
Removing the +/-1 parameter during conversion could cause geometry issues in OpenMC, unless another surface is added to the cell definitions to split the double cone.
The text was updated successfully, but these errors were encountered: