makeclean
Single-cone surfaces inconsistent between MCNP and OpenMC
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.
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?
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! 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.
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....