Skip to content
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

Open
thberry opened this issue Jun 9, 2021 · 5 comments
Open

Single-cone surfaces inconsistent between MCNP and OpenMC #59

thberry opened this issue Jun 9, 2021 · 5 comments

Comments

@thberry
Copy link

thberry commented Jun 9, 2021

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.

@BorORNL
Copy link

BorORNL commented Jan 31, 2023

Tom, did you ever find a workaround to this?
I guess adding a surface at the origin of the cone to only account for a single cone is a solution, but not a very elegant one. As far as I understand, OpenMC doesn't have the option specify the "directionality" (+/- 1 parameter in MCNP) of a cone, right?

@makeclean
Copy link
Owner

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.

@BorORNL
Copy link

BorORNL commented Feb 1, 2023

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!

@egor1abs
Copy link

Hello!
Are there any changes related to the one-side cones?
I've encountered this problem too and don't really understand how to solve it yet, given that ZConeOneSided is a two-surface structure.

@makeclean
Copy link
Owner

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....

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants