Opened 8 years ago
Last modified 8 years ago
#717 new defect
calculate all I(q) values needed for 1D resolution in one call
Reported by: | pkienzle | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | SasView Next Release +1 |
Component: | SasView | Keywords: | |
Cc: | Work Package: | SasView Bug Fixing |
Description
When I(q) is computed with resolution, the theory values are first computed for the measured points, then another call is made to compute the points before the first measured point and another call is made to compute the points after the last measured point. This will significantly slow down the throughput on the GPU for simple models, where the overhead of three calls will be larger than cost of the calls.
This is one step toward refactoring the fitting perspective to more cleanly separate computation from user interface.
See code in:
sas.sascalc.data_util.qsmearing.PySmear.apply
called from:
sas.sasgui.perspectives.fitting.model_thread.Calc1D.compute sas.sascalc.fit.AbstractFitEngine.FitData1D.residuals
Change History (2)
comment:1 Changed 8 years ago by pkienzle
comment:2 Changed 8 years ago by pkienzle
With q_calc completely independent of q we can increase the sampling density between q values as needed for the resolution. See ticket #715.
Maybe put oversampling under user control. If fitting a system of large mono-disperse particles, we ought to sample q more densely than the fringe spacing in the model when computing the resolution. This allows users to work around the issue that sasmodels does not do adaptive integration for resolution. See ticket #392.
Also, separate model setup from model call so that model+q is initialized before fit and reused for each step of the computation. In sasmodels.sasview_model.SasviewModel.calculateIq the model is being loaded from file and released each call (DLL), and a new q vector is being created each call (OpenCL).