Check max_pd maximum number polydisperse parameters (Trac #1056)

[RichardHeenan]

Whilst trying to break 2d fitting with oriented elliptical cylinder, which has 6 possible levels of polydispersity integration, three in geometry and three orientation angles, I noted that:

Asking for all 6 gives a "too many polydisperse parameters" message from details.py line 202, (which is fair enough, though perhaps we could increase the allowance). This uses MAX_PD=5 from modelinfo.py

However, asking for 5 levels of integration does not give an error message, but alas plainly does not work, seems to return zero or close to zero from the integrations. Is there a bug somewhere in details.py regarding the buffer spaces or similar. 4 levels of integration seems to work fine.

I have set Paul K as owner as he will likely spot an issue quickly. Richard

Migrated from http://trac.sasview.org/ticket/1056

{
    "status": "new",
    "changetime": "2018-02-13T02:19:08",
    "_ts": "2018-02-13 02:19:08.981115+00:00",
    "description": "Whilst trying to break 2d fitting with oriented elliptical cylinder, which has 6 possible levels of polydispersity integration, three in geometry and three orientation angles,\u00a0I noted that:\n\nAsking for all 6 gives a \"too many polydisperse parameters\" message from details.py line 202, (which is fair enough, though perhaps we could increase the allowance). This uses MAX_PD=5 from modelinfo.py\n\nHowever, asking for 5 levels of integration does not give an error message, but alas plainly does not work, seems to return zero or close to zero from the integrations. Is there a bug somewhere in details.py regarding the buffer spaces or similar. 4 levels of integration seems to work fine.\n\nI have set\u00a0Paul K\u00a0as owner as he will likely spot an issue quickly.\nRichard",
    "reporter": "richardh",
    "cc": "",
    "resolution": "",
    "workpackage": "SasView Bug Fixing",
    "time": "2018-01-04T16:38:06",
    "component": "sasmodels",
    "summary": "Check max_pd maximum number polydisperse parameters",
    "priority": "minor",
    "keywords": "",
    "milestone": "SasView 4.3.0",
    "owner": "pkienzle",
    "type": "defect"
}

[butlerpd]

Trac update at 2018/02/13 02:18:52: butler commented:

That's interesting -- I thought Paul had set the maximum to 4 not 5. I believe the reason had to do not only with how slow it gets and unhelpful the answers might be but with some assumptions made in later calculations? Definitely need to engage Paul K. on this.

[butlerpd]

Trac update at 2018/02/13 02:19:08: butler changed milestone from "SasView 4.2.0" to "SasView 4.3.0"

[pkienzle]

sasmodels/kernel_iq.c has hard-coded five nested loops, so that is an upper limit on how many simultaneous pd parameters we can support. [We could support an arbitrary number if we switch to monte carlo integration with importance sampling beyond 4 dimensions, or so, but that would be another ticket.]

sasmodels.modelinfo.MAX_PD is indeed set to 5. The info.max_pd for the individual model is the minimum of the num. pd parameters in the model and MAX_PD. Product and mixture models override this since the limitation applies only to compute kernels, not composite kernels. [Should check a mixture of two cylinders, with all pds selected from one cylinder: the max_pd of the composite is 10, but only five will be sent to either sub model, with the rest trimmed in order of decreasing number of pd points.]

sasmodels.details.make_details is using the max_pd of the model, which should be 5 for cylinder. So from the cursory code examination, everything ought to work, and testing it with sascomp it appears to be doing appropriate things. It works when I test from the GUI as well.

My guess is that you are seeing some sort of weirdness from the OpenCL driver, where it returns a partly computed pattern if it runs out of time before calculation is complete. Try setting the number of polydispersity points to 3 for everything except phi, which is either 2 (if you want it to be on the outermost loop) or 4 (if you want it to be on the innermost loop).

If this works and the other fails, that means the code which is allowing the computation to yield after intermediate results is too ambitious about the amount of work that can be performed each cycle, and needs to be reduced:

https://github.com/SasView/sasmodels/blob/d0b0f5dc53598d975457f876ef61fcca6a6ac12a/sasmodels/kernelcl.py#L611