Cones:

[SAnsell]

Introduction

Cones in MCNP (and other geometries codes) often support sheet cutting. This is when the two surfaces of cone -- see figure

Let us say the cone in the picture is along the z axis, and as long as it is along an axis you can represent it in MCNP as
kz Cx Cy Cz T flag

The Cx,Cy,Cz represent the centre of the double cone, T is the tan^2(theta), were theta is the angle the surface vector on the cone makes with the origin. Flag is the problem value, it is tri-state and takes three values either -1,0,1. If it is 0 then the kz surface represents a double-cone. If the value is +1 then the surface represents the positive side of z, (i.e. the cone is value only for z>cZ). and the converse for -1.

Issue

The problem comes that under rotation the code is not represented in MCNP by a vectorial axis cone. [CombLayer maintains the cone in this form but that is not mirrored in MCNP], so when the MCNP file is written the the cone must be written as a general quadratic surface, unless the principle axis is colinear to one the the master axis of the model. Ideally I would only support double surface cones, but in the early days of CombLayer, the read-model functions that we were using needed to allow the flag to be +/-1 and some support was provided (under the assumption that the user was responsible for not rotating).

Resolution

The obvious fix is to add generic cones to MCNP, because that would result in a large speed up relative to general surfaces. However, that isn't going to work well. I would like to remind everyone that ideally you don't use the cone cut, and if you do expect problems. I think I should remove it from the code. But I will give everyone a few (minutes :-) ) to think about that. I thought about the idea of adding an extra surface. This could be done as well. It is kind of messy but doable.