User Frank Kilian reported that the documentation for the solid Prism model does not match the code. Further he suggests it be made more clear (particularly for new users) where the terms in Af come from (presumably a version of the usual sin(qR)/qR found in many form factors).
Looking more carefully this warrants I think a bit of a deeper dive before fixing. In fact a look at all the parallelepiped models for consistency would seem appropriate. Some problems already spotted:
all three terms int the model identified at the top cannot be q cos theta (nor are they for the other prims models).
The documentation says the the angle definitions are different that the "usual ones." This does not make too much sense to me since I would expect that those are defined by the sasmodels infrastructure for all shapes in order to be able to apply orientational distributions.
If there is a difference then the transformation should be documented so that people trying to read the code in the future know that the parameters as defined in the model are not the ones used in the calculation and what the transformation is. Alternatively, if the angles are defined as all angles are this statement should be removed or completely rephrased. That said, the definition does in fact seem to be the standard one after all - still should be checked.
The three angles are defined as parameters. However they do not seem to be passed unless one is applying oriented models. Looking at some other models in the parallelepiped series some have the angles defined as parameters and others do not. I believe the sasmodels infrastructure takes care of adding those parameters when applying the oriented model in which case those should be removed. Otherwise I guess they should be added to the models that do not have them.
Finally at least one model, such as the hollow_rectangular_prism_thin_walls says that it is only defined for 1D (and thus does not have the angles as parameters) but the equations in the docs look like this could easily be made to support oriented objects using the sasmodels infrastructure. If so we should do that.
Once some of this is sorted out, it may be that several new tickets should be generated based on the findings and this ticket closed.
User Frank Kilian reported that the documentation for the solid Prism model does not match the code. Further he suggests it be made more clear (particularly for new users) where the terms in Af come from (presumably a version of the usual sin(qR)/qR found in many form factors).
Looking more carefully this warrants I think a bit of a deeper dive before fixing. In fact a look at all the parallelepiped models for consistency would seem appropriate. Some problems already spotted:
Once some of this is sorted out, it may be that several new tickets should be generated based on the findings and this ticket closed.