Make formfactor parameters more consistent

Make formfactor parameters more consistent. Avoid negative lengths. Stay coordinate free; don't refer to the coordinate origin or particle center.

At this occasion, also correct names of some classes and parameters.

• Sphere: R
• Spheroid: R_xy and R_z
• Ellipsoid: R_x, R_y and R_z
• SphereSlice: R, trunc_bottom, trunc_top
• SpheroidSlice: R_xy, R_z, trunc_bottom, trunc_top
• EllipsoidSlice: R_x, R_y, R_z, trunc_bottom, trunc_top
• HorizontalCylinder: R, L (length, not height H !), trunc_bottom, trunc_top

HorizontalCylinder has no unsliced variant because the entire need for this formfactor only comes from the fact that the usual (vertical) cylinder does not support rotation in the presence of slicing.

Redraw all cuts. For the time being, hand drawn and scanned would be good enough.

In perspective, take truncation out of formfactor constructors (#279).

added URGENT formfactor labels

changed title from Horizontal cylinder: change cut-off parameters to Make formfactor parameters more consistent

changed the description

My proposal.

Current FFs:

• fullsphere
• fullspheroid
• hemiellipsoid
• horizontalCylinder
• truncatedSphere
• truncatedSpheroid

We can diminish number of formfactor names allowing few constructors for each FF. It will also bring system to the shape names: no more "spherical segments", "truncated spheres", "full spheres", "hemiellipsoids", "truncated ellipsoids" etc.

New FFs:

Spheres

• FormFactorSphere(R)
• FormFactorSphere(R, trunc_bottom)
• FormFactorSphere(R, trunc_bottom, trunc_top)

Spheroids

• FormFactorSpheroid(R, H)
• FormFactorSpheroid(R, H, trunc_bottom)
• FormFactorSpheroid(R, H, trunc_bottom, trunc_top)

Ellipsoids

• FormFactorEllipsoid(R_a, R_b, H)
• FormFactorEllipsoid(R_a, R_b, H, trunc_bottom)
• FormFactorEllipsoid(R_a, R_b, H, trunc_bottom, trunc_top)

Horizontal Cylinders

• FormFactorHorizontalCylinder(R, L)
• FormFactorHorizontalCylinder(R, L, trunc_bottom)
• FormFactorHorizontalCylinder(R, L, trunc_bottom, trunc_top)

changed the description

For sphere, spheroid, ellipsoid, we have an analytical formfactor. When truncated, we need numeric integration. Of course we could handle this with a simple conditional. In principle, we could also handle sphere and spheroid as special cases of ellipsoid.

There are two questions here:

• Which constructors our users shall choose from?
• Which classes do we use internally?

From a C++/Py perspective, both questions could be discussed separately. In the GUI, however, things get ugly or complicated unless there is a neat correspondence between constructor and internal representation.

HorizontalCylinders now have a condition for analytical/numerical cases. See no disadvantages in this. It can be repeated for other FFs.

1. Q: Which constructors our users shall choose from? All three constructors will be mentioned in documentation. Moreover, all three can be mentioned in example scripts and 2 out of 3 would be commented out.

In GUI we should add the most general FF, with truncations explicitly set to 0 by default. It won't be ugly. Again, as it is already done for HorizontalCylinders (except for parameters chosen)

changed the description

@m.svechnikov, thanks for your input which led me to some modifications of my proposal. For a more fundamental approach to truncation (and rotation), see the new issue #279.

changed the description

Note: Truncation won't be the most frequent modification of an ellipsoid. There is rarely a reason why an ellipsoid should have axis aligned with instrument-given x and y. In many cases, an ellipsoid will be rotated, or have a distribution of orientations.

Therefore it would be more natural for an ellipsoid to have a rotation parameter omega rather than slicing parameters trunc_bottom, trunc_top. Solution: #279. Here, for the time being, let's stay close to what we have.

changed the description

removed URGENT label

added API label