SasView: Ticket Query
http://trac.sasview.org/query?status=!closed&component=sasmodels&order=priority
SasView - Open Source SAS Data Analysis Softwareen-USTrac 1.0.1
http://trac.sasview.org/ticket/1118
http://trac.sasview.org/ticket/1118#1118: middle level - sort out P(Q)S(Q) including beta(Q)Sun, 01 Jul 2018 21:29:03 GMTrichardh<p>
See general introduction to beta(Q) project in <a class="new ticket" href="http://trac.sasview.org/ticket/1096" title="defect: improve structure factor calculations with beta approximation (new)">#1096</a>
</p>
<p>
Need technical details here as to what to change in what order to develop product.py and other <img src="http://trac.sasview.org/chrome/wikiextras-icons-16/question.png" style="vertical-align: text-bottom" alt="(?)" /> routines to achieve immediate goals of simple sphere, cylinder & ellipsoid times simple S(Q) but keeping in mind some longer term goals for more options and improved usage of gpu (<a class="new ticket" href="http://trac.sasview.org/ticket/1091" title="enhancement: improve parallelism for 1D integration models (new)">#1091</a>, <a class="new ticket" href="http://trac.sasview.org/ticket/392" title="enhancement: use adaptive integration in sasmodels (new)">#392</a> )
</p>
<p>
Ideally any calculation of I(Q) should only have one "flat background" at the end, but we may have to stick with each P(Q) carrying a flat background around with it.
</p>
<p>
Some detail discussion and use cases are required here.
</p>
Resultshttp://trac.sasview.org/ticket/1118#changelog
http://trac.sasview.org/ticket/1063
http://trac.sasview.org/ticket/1063#1063: Need unit tests for combined models P(Q)S(Q) etcTue, 23 Jan 2018 15:28:30 GMTawashington<p>
The combined model code currently doesn't appear to have any unit tests. We should add some tests in to prevent future regressions.
</p>
Resultshttp://trac.sasview.org/ticket/1063#changelog
http://trac.sasview.org/ticket/1080
http://trac.sasview.org/ticket/1080#1080: Provide a multi-shell cylinder modelMon, 19 Mar 2018 14:27:21 GMTsmk78<p>
In the last 6 months Dave Adams (Glasgow), Jian Lu (Manchester) and Irena Levin (Technion) have all wanted a core-shell or core-shell-shell cylinder model.
</p>
<p>
The only fitting program with anything remotely like this model is Olivier Tache's pySAXS, but it is a less user-friendly, less robust, program than SasView and does not handle resolution or polydispersity smearing, nor orientation.
</p>
<p>
We should provide a better alternative.
</p>
Resultshttp://trac.sasview.org/ticket/1080#changelog
http://trac.sasview.org/ticket/1120
http://trac.sasview.org/ticket/1120#1120: beta(Q) approx models to editSun, 01 Jul 2018 21:35:14 GMTrichardh<p>
Need add lists here of high, medium and low priority models to edit.
</p>
<p>
Note unit tests for P(Q)S(Q) are part of <a class="new ticket" href="http://trac.sasview.org/ticket/1063" title="enhancement: Need unit tests for combined models P(Q)S(Q) etc (new)">#1063</a>
</p>
Resultshttp://trac.sasview.org/ticket/1120#changelog
http://trac.sasview.org/ticket/1121
http://trac.sasview.org/ticket/1121#1121: validation of beta(Q) and other calculations against external codeSun, 01 Jul 2018 21:39:33 GMTrichardh<p>
Please document here detail results of testing against sasfit, Fish, own matlab codes etc, especially noting where issue were found and how these were resolved.
</p>
<p>
This will provide background information for sasview & sasmodels documentation.
</p>
Resultshttp://trac.sasview.org/ticket/1121#changelog
http://trac.sasview.org/ticket/491
http://trac.sasview.org/ticket/491#491: adding support for F(Q) in sasmodelsSat, 19 Dec 2015 19:07:45 GMTbutler<p>
I(Q) is proportional to F(Q)<sup>2</sup> Hence our models return that. However there are times when it may be preferable to have access to the F(Q). For example it is required for the beta approximation (increasing the range of applicability for using most current interaction potentials) or if one wanted to use these as a library for building P(Q) for more complex shapes.
</p>
<p>
Providing a method to access the underlying F(Q) thus would be very useful.
</p>
Resultshttp://trac.sasview.org/ticket/491#changelog
http://trac.sasview.org/ticket/702
http://trac.sasview.org/ticket/702#702: Limiting cases of cylinder modelWed, 05 Oct 2016 19:03:01 GMTdirk<p>
The cylinder model should give the formfactor of a long, infinitely thin rod or thin disk if diameter or lengh is set to zero, respectively.
</p>
Resultshttp://trac.sasview.org/ticket/702#changelog
http://trac.sasview.org/ticket/707
http://trac.sasview.org/ticket/707#707: Boucher ModelWed, 05 Oct 2016 22:36:56 GMTdirk<p>
Would be nice to have the Boucher Model in SASView. The reference is B Boucher, P Chieux, P Convert, and M Tournarie. Small-angle neutron scattering determination of medium and long range order in the amorphous metallic alloy tbcu 3.54. Journal of Physics F:
Metal Physics, 13(7):1339, 1983.
</p>
Resultshttp://trac.sasview.org/ticket/707#changelog
http://trac.sasview.org/ticket/713
http://trac.sasview.org/ticket/713#713: Orientational Distribution for Magnetic ModelsThu, 06 Oct 2016 14:00:53 GMTdirk<p>
Magnetic models need the angular orientational distribution of magnetic moments around the magnetic field axis.
</p>
Resultshttp://trac.sasview.org/ticket/713#changelog
http://trac.sasview.org/ticket/716
http://trac.sasview.org/ticket/716#716: reuse computed I(qx,qy) values when computing 2D resolutionThu, 06 Oct 2016 16:25:53 GMTpkienzle<p>
sasmodels/resolution2D.py sets the calculated qx,qy points by drawing NR x NPHI points around each measured point qx,qy. This means that the 2D pattern is computed 12, 30, 60, or 200 times depending on the choice of accuracy.
</p>
<p>
Rather than blindly drawing this many points around each qx,qy, we should first check if there are enough points already being computed in the pattern, and only add points where more are needed. This has the potential for significant speedup of 2D calculations when the resolution is worse than the pixel spacing.
</p>
Resultshttp://trac.sasview.org/ticket/716#changelog
http://trac.sasview.org/ticket/721
http://trac.sasview.org/ticket/721#721: Compare Sasfit with Sasview modelsFri, 07 Oct 2016 13:34:27 GMTdirk<p>
Compare SASfit with SasView models and integrate missing SASfit models in SasView. A list of SasView vs. SASFit Models can be found under <a class="ext-link" href="https://ess-ics.atlassian.net/wiki/display/SAS/SasView-SasFit+Overlapping+Models"><span class="icon"></span>https://ess-ics.atlassian.net/wiki/display/SAS/SasView-SasFit+Overlapping+Models</a>.
</p>
Resultshttp://trac.sasview.org/ticket/721#changelog
http://trac.sasview.org/ticket/724
http://trac.sasview.org/ticket/724#724: Broad Peak ModelFri, 07 Oct 2016 15:26:40 GMTdirk<p>
Idea is to build a generalised Broad Peak Model with the following function: I(q) = scale_p/pow(q,exponent)+scale_l/pow((1.0 + pow((fabs(q-q_peak)*length_l),exponent_l) ),exponent_p)+ background
</p>
<p>
For qpeak = 0, m = 2 and p = 1 one gets the Lorentz model. For qpeak = 0, m = 2 and p = 2 The Broad-Peak model is identical to the Debye-
Anderson-Brumberger (dab) model. Like this you then can save these two models.
</p>
Resultshttp://trac.sasview.org/ticket/724#changelog
http://trac.sasview.org/ticket/725
http://trac.sasview.org/ticket/725#725: Core Shell Microgel ModelFri, 07 Oct 2016 15:30:58 GMTdirk<p>
The Core Shell Microgel Model does not exist in Sasview. It describes a core shell structure with fuzzy interfaces of core and shell. See:
Ingo Berndt, Jan Skov Pedersen, Peter Lindner, and Walter Richtering. Infuence of shell thickness and cross-link density on the structure of temperature-sensitive poly-n-isopropylacrylamidepoly-nisopropylmethacrylamide coreshell microgels investigated by small-angle neutron scattering. Langmuir, 22(1):459{468, 2006. PMID: 16378460.
</p>
<p>
Ingo Berndt, Jan Skov Pedersen, and Walter Richtering. Structure of multiresponsive intelligent? coreshell microgels. Journal of the American Chemical Society, 127(26):9372{9373, 2005. PMID:15984856.
</p>
<p>
Ingo Berndt, Jan Skov Pedersen, and Walter Richtering. Temperature-sensitive coreshell microgel particles with dense shell. Angewandte Chemie, 118(11):1769{1773, 2006.
</p>
Resultshttp://trac.sasview.org/ticket/725#changelog
http://trac.sasview.org/ticket/726
http://trac.sasview.org/ticket/726#726: Structur Factor of magnetic spin misalignmentFri, 07 Oct 2016 15:37:51 GMTdirk<p>
There exist magnetic structure factor model describing the magnetic misalignment in a ferromagnetic bulk material arising from particle with magnetocristalline anisotropy. Moreover there exist another magnetic structure factor decribing spin canting due to magnetostatic dipolar fields around mmagnetic inhomogeneities. See A. Michels, Magnetic small-angle neutron scattering of bulk ferromagnets, J. Phys.: Condens. Matter 26, 383201 (2014) (and references therein).
</p>
Resultshttp://trac.sasview.org/ticket/726#changelog
http://trac.sasview.org/ticket/727
http://trac.sasview.org/ticket/727#727: Check that Flexible Cylinders converges to cylinder modelFri, 07 Oct 2016 17:54:12 GMTdirk<p>
The Kuhn parameter <em>b</em> parametrizes the stiffness of the rod with length <em>L</em>. For a Kuhn parameter of <em>b</em>=2*<em>L</em> the result should converge to the simple cylinder model, but it does not. There seems to be a numerical issue such that an artefact bumb appears at low <em>q</em>.
</p>
Resultshttp://trac.sasview.org/ticket/727#changelog
http://trac.sasview.org/ticket/788
http://trac.sasview.org/ticket/788#788: cross check different implementations of the same shapeMon, 17 Oct 2016 18:15:13 GMTpkienzle<p>
There are many instances where the same shape can be described with two different models. For example,
</p>
<ul><li>core-shell models vs. core-only models with the sld of the shell matching the sld of the core and the radius of the core+shell matching the radius of the core,
</li></ul><ul><li>sphere:ellipsoid with r_major and r_minor equal to r,
</li></ul><ul><li>barbell:pearl_necklace with 2 pearls
</li></ul><ul><li>barbell:sphere with hemispherical bell and length 0 bar
</li></ul><ul><li>rectangular_prism:parallelepiped, one using ratios the other using lengths
</li></ul><ul><li>etc.
</li></ul><p>
Collect a list of these in sasmodels and check that the values correspond.
</p>
<p>
Furthermore, for oriented models, the 1-D model should match the orientation average of the 2-D model.
</p>
Resultshttp://trac.sasview.org/ticket/788#changelog
http://trac.sasview.org/ticket/791
http://trac.sasview.org/ticket/791#791: make fractal a structure factor modelThu, 20 Oct 2016 14:17:30 GMTpkienzle<p>
Currently <tt>fractal</tt> and <tt>core_shell_fractal</tt> are implemented as <tt>P(q) * S(q)</tt>, where <tt>P(q)</tt> is the sphere structure factor for fractal or the core shell sphere for core_shell_fractal and <tt>S(q)</tt> is the fractal structure factor.
</p>
<p>
Propose splitting the S(q) into its own structure factor model so that all variants of fractal clustering are supported at once.
</p>
Resultshttp://trac.sasview.org/ticket/791#changelog
http://trac.sasview.org/ticket/796
http://trac.sasview.org/ticket/796#796: Polydispersity limited to 4 dimensionsTue, 25 Oct 2016 18:21:38 GMTpkienzle<p>
Max 4 polydisperse parameters. Need warnings in GUI if more are selected.
</p>
<p>
Instead of increasing the number of PD loops in the kernel code, switch to Monte Carlo integration with importance sampling when more than 4 dimensions. Do not extend the code to contain one more loop. Not only will this be slower, but it will increase code size and possibly reduce the number of q values that can be evaluated in parallel.
</p>
<p>
Many 1D models are computed with numerical integrals over all orientations; these integrals can be incorporated into the Monte Carlo. Could also incorporate sampling from the resolution function.
</p>
<p>
Accuracy can be controlled by increasing the number of samples.
</p>
Resultshttp://trac.sasview.org/ticket/796#changelog
http://trac.sasview.org/ticket/807
http://trac.sasview.org/ticket/807#807: Failing sasmodels unit tests on Intel(R) Iris(TM) Graphics 6100Thu, 17 Nov 2016 13:08:08 GMTwojciech<p>
Three sasmodels unit tests are failing on my hardware: Intel® Iris™ Graphics 6100 Mac OSX 10.11. They work fine on CPU when compiled both with dll and opencl. I am running tests from sasmodels dir:
python -m sasmodels.model_test all
</p>
<p>
======================================================================
FAIL [0.016s]: test_core_shell_cylinder_opencl (<span class="underline">main</span>.<a class="missing wiki">ModelTestCase?</a>)
</p>
<hr />
<p>
Traceback (most recent call last):
</p>
<blockquote>
<p>
File "/Users/wojciechpotrzebowski/SASVIEW_WORKSPACE/sasmodels/sasmodels/model_test.py", line 181, in run_all
</p>
<blockquote>
<p>
self.run_one(model, test)
</p>
</blockquote>
<p>
File "/Users/wojciechpotrzebowski/SASVIEW_WORKSPACE/sasmodels/sasmodels/model_test.py", line 229, in run_one
</p>
<blockquote>
<p>
'invalid f(%s): %s' % (xi, actual_yi))
</p>
</blockquote>
</blockquote>
<p>
<a class="missing wiki">AssertionError?</a>: invalid f((0.1, 0.1)): nan Model: core_shell_cylinder, Kernel: OpenCL
</p>
<p>
======================================================================
FAIL [0.061s]: test_parallelepiped_opencl (<span class="underline">main</span>.<a class="missing wiki">ModelTestCase?</a>)
</p>
<hr />
<p>
Traceback (most recent call last):
</p>
<blockquote>
<p>
File "/Users/wojciechpotrzebowski/SASVIEW_WORKSPACE/sasmodels/sasmodels/model_test.py", line 181, in run_all
</p>
<blockquote>
<p>
self.run_one(model, test)
</p>
</blockquote>
<p>
File "/Users/wojciechpotrzebowski/SASVIEW_WORKSPACE/sasmodels/sasmodels/model_test.py", line 239, in run_one
</p>
<blockquote>
<p>
% (xi, yi, actual_yi))
</p>
</blockquote>
</blockquote>
<p>
<a class="missing wiki">AssertionError?</a>: f((-0.16022872310938674, 0.11969442882079129)); expected:0.00560296014; actual:0.001 Model: parallelepiped, Kernel: OpenCL
</p>
<p>
======================================================================
FAIL [0.014s]: test_raspberry_opencl (<span class="underline">main</span>.<a class="missing wiki">ModelTestCase?</a>)
</p>
<hr />
<p>
Traceback (most recent call last):
</p>
<blockquote>
<p>
File "/Users/wojciechpotrzebowski/SASVIEW_WORKSPACE/sasmodels/sasmodels/model_test.py", line 181, in run_all
</p>
<blockquote>
<p>
self.run_one(model, test)
</p>
</blockquote>
<p>
File "/Users/wojciechpotrzebowski/SASVIEW_WORKSPACE/sasmodels/sasmodels/model_test.py", line 229, in run_one
</p>
<blockquote>
<p>
'invalid f(%s): %s' % (xi, actual_yi))
</p>
</blockquote>
</blockquote>
<p>
<a class="missing wiki">AssertionError?</a>: invalid f(0.1): nan Model: raspberry, Kernel: OpenCL
</p>
<p>
</p>
Resultshttp://trac.sasview.org/ticket/807#changelog
http://trac.sasview.org/ticket/822
http://trac.sasview.org/ticket/822#822: Create proper Unit Testing directory structure for SasModelsTue, 06 Dec 2016 15:04:46 GMTpiotrResultshttp://trac.sasview.org/ticket/822#changelog
http://trac.sasview.org/ticket/845
http://trac.sasview.org/ticket/845#845: Fix volume normalisation on Raspberry modelTue, 07 Feb 2017 15:15:35 GMTajj<p>
As noted in <a class="closed ticket" href="http://trac.sasview.org/ticket/815" title="defect: check that integer parameters are handled properly (closed: fixed)">#815</a> the raspberry model needs to be doing volume calculation outside Iq function to get polydispersity working properly.
</p>
Resultshttp://trac.sasview.org/ticket/845#changelog
http://trac.sasview.org/ticket/871
http://trac.sasview.org/ticket/871#871: autogenerated plot in doc for rpa is not helpfulTue, 07 Mar 2017 06:25:38 GMTbutler<p>
The autogeneration of an example plot in sasmodel documentation based on default parameters is quite useful normally, it can be problematic for multiplicity models where all the parameters of the multiplicity have the same value. In particular the rpa has scattering length of each component as a multiplicity parameter so all are set equal to the one default. Unfortunately that means that I(Q)=0 at all Q. It would be nice if we could get a sensible plot in such, admittedly rare, cases.
</p>
Resultshttp://trac.sasview.org/ticket/871#changelog
http://trac.sasview.org/ticket/945
http://trac.sasview.org/ticket/945#945: autogenerate orientation parametersMon, 10 Apr 2017 10:21:59 GMTajj<p>
As discussed with Paul Kienzle, the orientation parameters should be autogenerated rather than specifying them in each model.
</p>
Resultshttp://trac.sasview.org/ticket/945#changelog
http://trac.sasview.org/ticket/979
http://trac.sasview.org/ticket/979#979: Resolve inconsistent naming of peak modelsWed, 26 Jul 2017 11:27:06 GMTsmk78<p>
<a class="missing wiki">SasView?</a> 4.1.1 appears to have a model with an inconsistent name. We have broad_peak and gaussian_peak, but then peak_lorentz!
</p>
Resultshttp://trac.sasview.org/ticket/979#changelog
http://trac.sasview.org/ticket/1002
http://trac.sasview.org/ticket/1002#1002: Implement multi-phase fractal modelWed, 27 Sep 2017 09:53:55 GMTsmk78<p>
The JINR folks have developed a model somewhat complementary to the Beaucage model. It handles the case of two co-existing fractal systems, separated or one inside the other.
</p>
Resultshttp://trac.sasview.org/ticket/1002#changelog
http://trac.sasview.org/ticket/1039
http://trac.sasview.org/ticket/1039#1039: more complete testing in sasmodelsThu, 30 Nov 2017 16:45:05 GMTpkienzle<p>
Current automated testing is only looking at models.
</p>
<ul><li>Should use nosetest on all of <tt></tt><tt>sasmodels/*.py</tt><tt></tt>.
</li></ul><ul><li>Use <tt></tt><tt>--with-doctest</tt><tt></tt> in case any functions come with doc tests.
</li></ul><ul><li>There may be doctests in the sphinx tree, which can be discovered with <tt></tt><tt>--doctest-extension=rst</tt><tt></tt>.
</li></ul><ul><li>Automate tests of the examples.
</li></ul><ul><li>Examples should be pulled into the docs, possibly using <tt></tt><tt>bumps/doc/pylit.py</tt><tt></tt> to convert a runnable example into an rst file.
</li></ul>Resultshttp://trac.sasview.org/ticket/1039#changelog
http://trac.sasview.org/ticket/1049
http://trac.sasview.org/ticket/1049#1049: use #include rather than source=[] for C librariesThu, 14 Dec 2017 20:56:33 GMTpkienzle<p>
Since OpenCL supports #include, we should set up the library functions so that they can be #included into the kernel source. Although it is still odd that we are including the .c files (normal includes are .h files giving the function signature, leaving it to the linker pulls the relevant object files from a library), it is a little less strange than the <tt>source=['lib/sasfile.c', ...]</tt> strategy that we are currently using.
</p>
<p>
All library files will need to have protection against multiple #includes.
</p>
<p>
A new dependency mechanism will be needed so that models are recompiled if an included file is updated, no matter how many levels deep the include occurs.
</p>
Resultshttp://trac.sasview.org/ticket/1049#changelog
http://trac.sasview.org/ticket/1078
http://trac.sasview.org/ticket/1078#1078: name collision on multiuser systemMon, 05 Mar 2018 23:40:20 GMTpkienzle<p>
On a linux system the compiled models are placed in <tt>/tmp/MODELNAME.so</tt>. If one user creates a model and another user updates it, there will be a permission collision.
</p>
<p>
Also, what happens to the .so if the plugin model has the same name as a builtin model?
</p>
Resultshttp://trac.sasview.org/ticket/1078#changelog
http://trac.sasview.org/ticket/1096
http://trac.sasview.org/ticket/1096#1096: improve structure factor calculations with beta approximationWed, 18 Apr 2018 15:08:39 GMTpkienzle<p>
Separate calculation of <tt>F</tt> so we can return <tt><F></tt> and <tt><F*F></tt> from the <tt>I(q)</tt> calculator. These will be used for an improved structure factor calculation with non-spherical particles. The average <tt><.></tt> is over size dispersity and orientation.
</p>
Resultshttp://trac.sasview.org/ticket/1096#changelog
http://trac.sasview.org/ticket/1126
http://trac.sasview.org/ticket/1126#1126: Passing additional computed, non-fitting, parameter values back from modelsTue, 03 Jul 2018 16:20:22 GMTrichardh<p>
Would be good for constraints on S(Q) radius and phi to be able to access ER and VR values from preceding P(Q) model, preferably without making models too much more complicated. Likely more than one possible type of ER, see <a class="new ticket" href="http://trac.sasview.org/ticket/780" title="enhancement: let the user set effective radius in P(Q)*S(Q) (new)">#780</a> and <a class="closed ticket" href="http://trac.sasview.org/ticket/1115" title="enhancement: qt5 user level S(Q) tab (closed: wontfix)">#1115</a>.
</p>
<p>
Would be good for some models to return usful information to users, e.g. Debye lengths from hayter_msa S(Q).
</p>
<p>
Paul K says that this might not be simple, but he has some ideas.
</p>
Resultshttp://trac.sasview.org/ticket/1126#changelog
http://trac.sasview.org/ticket/1154
http://trac.sasview.org/ticket/1154#1154: Refactor tests so that gui doesn't reload module each timeMon, 13 Aug 2018 20:27:45 GMTbutler<p>
The fundamental problem of not being able to use the model editors in SasView without throwing errors was fixed by SasView PR 161 for release 4.2. The problem was that when the sasmodels unit tests were loading the models twice. When they loaded the model the second time, the math globals were being overwritten so that rather than functions they become "None" objects for the first instance of that model. The error that was being thrown is
</p>
<pre class="wiki">File "sas\sascalc\data_util\calcthread.pyc", line 274, in _run
TypeError: unsupported operand type(s) for *: 'NoneType' and 'float'
</pre><p>
However, in that PR, Paul Kienzle suggests that this can be done more cleanly and points to his notes in the code itself documenting his ideas (reproduced below). Due to the increased complexity (and the fact that it touches both sasmodels and SasView) it was agreed to wait for 4.3 to implement. Note however that the sasmodels part has already been done and is sitting in the queue as a sasmodels PR 75 and includes notes on what to do in SasView to make the changes accessible to the SasView GUI.
</p>
<pre class="wiki"> # TODO: fix model caching
# model_test.run_one() is directly forcing a reload of the module, but
# sasview_model is caching models that have already been loaded.
# If the sasview load happens before the test, then the module is
# reloaded out from under it, which causes the global variables in
# the model function definitions to be cleared (at least in python 2.7).
# To fix the proximal problem of models failing on test, perform the
# run_one() tests first. To fix the deeper problem we should either
# remove caching from sasmodels.sasview_model.load_custom_model() or
# add caching to sasmodels.custom.load_custom_kernel_module(). Another
# option is to add a runTests method to SasviewModel which runs the
# test suite directly from the model info structure. Probably some
# combination of options:
# (1) have this function (check_model) operate on a loaded model
# so that caching isn't needed in sasview_models.load_custom_model
# (2) add the runTests method to SasviewModel so that tests can
# be run on a loaded module.
#
# Also, note that the model test suite runs the equivalent of the
# "try running the model" block below, and doesn't need to be run
# twice. The reason for duplicating the block here is to generate
# an exception that show_model_output can catch. Need to write the
# runTests method so that it returns success flag as well as output
# string so that the extra test is not necessary.
</pre>Resultshttp://trac.sasview.org/ticket/1154#changelog
http://trac.sasview.org/ticket/1171
http://trac.sasview.org/ticket/1171#1171: Expose volume calculation in SasModelsSat, 08 Sep 2018 13:21:25 GMTtoqduj<p>
McSAS relies on the ability to weigh the contributions based on their volume in its optimisation routine. This means that we need to be able to get a volume for a given contribution from <a class="missing wiki">SasModels?</a>.
</p>
<p>
At the moment, the kernel can be queried for the volume of the last-calculated iteration:
</p>
<pre class="wiki">kernel.result[kernel.q_input.nq]
</pre><p>
Paul Kienzle commented on this a while back:
"
For your case (without dispersion) the form_volume is already computed by the kernel and returned as the final element in the result. You should be able to grab it using kernel.result[kernel.q_input.nq] after calculating the kernel. This is a side-effect of the current implementation and not part of the formal interface; it will not work for pure python models, but should work for C models run as dll or as OpenCL.
</p>
<p>
[…]
</p>
<p>
If we were to make this a formal interface, we would need to generalize it to the case of dispersion-weighted volume average by additionally accumulating the sum of the weights in result[nq+1], then defining self.average_volume = result[nq]/result[nq+1]. Something similar could be done in the python kernel loop.
"
</p>
Resultshttp://trac.sasview.org/ticket/1171#changelog
http://trac.sasview.org/ticket/1172
http://trac.sasview.org/ticket/1172#1172: Allow "polydispersity" to be defined by series/sets of uncorrelated, discrete pointsSat, 08 Sep 2018 14:25:07 GMTtoqduj<p>
The output from a McSAS optimisation is a set of uncorrelated contributions, the sum of which comprises the scattered intensity.
</p>
<p>
As discussed during the <a class="missing wiki">SasView?</a> Code camp McSAS session, defining a parameter's polydispersity using either/or a classical definition and a freeform (e.g. McSAS) definition would require that the <a class="missing wiki">SasModels?</a> calculation can handle a range of freeform distributions.
</p>
<p>
While there is some sort of freeform distribution already implemented using a set of points and scaling factors (between which there is interpolation going on), The McSAS definition makes no assumption of the relationship between the points. For example, a set of ten McSAS cylinder contributions with a fixed length might (conceptually) look like this:
</p>
<ul><li>cylinder, diameter 3.4211
</li><li>cylinder, diameter 1.1235
</li><li>cylinder, diameter 2.1098
</li><li>cylinder, diameter 2.0983
</li><li>cylinder, diameter 4.0917
</li><li>cylinder, diameter 3.0918
</li><li>cylinder, diameter 1.091
</li><li>cylinder, diameter 2.901
</li><li>cylinder, diameter 2.998
</li><li>cylinder, diameter 3.116
</li></ul><p>
Note that a typical scattering pattern can easily be described using about 200 or 300 such contributions that make up a scattering pattern, when each contribution is scaled by its surface or volume, not the normal volume-squared scaling. This has the effect of suppressing the scattering of large contributions so that the smaller ones become visible, which is taken into account when visualising the result in a number- volume- or surface-weighted distribution.
</p>
<p>
Anyway, back to the topic. The idea during the <a class="missing wiki">SasView?</a> code camp was to enable a workflow that looked like this:
</p>
<ul><li>optimize a set of 1D or 2D model parameters using a classical optimisation
</li><li>pick one to three parameters to be optimised using a McSAS optimisation core, fixing all parameters except for the background- and scaling parameters (which are least-squares optimised for every McSAS iteration).
</li><li>get a coffee
</li><li>allow for re-optimization of the remaining model parameters using classical optimisation, fixing the McSAS-optimized parameter distributions
</li></ul><p>
Another aspect to note is that the uncertainties on the McSAS parameter distributions come from the analysis of variance from repeated, independent MC results in the optional histogramming (visualisation) phase. So, theoretically, you'd automatically repeat the above optimisation sequence a number of times to get a nice mean and standard error on the mean.
</p>
<p>
Back (again) to the topic at hand, for starters we would need a method that returns a calculated intensity as the sum (or average) of a set of individual contributions, each with its own parameters.
</p>
<p>
That's at least as far as I can imagine for now. This could be in <a class="missing wiki">SasModels?</a> or in <a class="missing wiki">SasView?</a>..
</p>
Resultshttp://trac.sasview.org/ticket/1172#changelog
http://trac.sasview.org/ticket/1198
http://trac.sasview.org/ticket/1198#1198: better gpu timeout selectionMon, 15 Oct 2018 17:46:53 GMTpkienzle<p>
When using a GPU device that is attached to a monitor, the OpenCL driver (and maybe the CUDA driver) will halt the calculation after a timeout even if it is not completed, with no indication that the computation timed out. On some platforms it has triggered a system reboot.
</p>
<p>
To prevent this, there is a timeout loop in sasmodels/kernelcl.py (and kernelcuda.py for the cuda-test branch) which breaks after every n kernel evaluations.
</p>
<p>
The problem is that there is no fixed value for "n" which is optimal for all models and all platforms. If the value is too low, there is significant overhead (30x slowdown on a GTX-1080 for example), but if the value is too high then some platforms might crash.
</p>
<p>
Need more control over this value. Ideally, ask the card to fail nicely, but otherwise provide a "computational power" scaling to the number of function evaluations allowed.
</p>
<p>
Could set the scale factor to infinite for headless GPUs (there is no timeout when a monitor is not attached to the card). That will interfere with Ctrl-C handling, but that should not be a problem for environments where a headless GPU is available.
</p>
Resultshttp://trac.sasview.org/ticket/1198#changelog
http://trac.sasview.org/ticket/1203
http://trac.sasview.org/ticket/1203#1203: OpenCL deprecated on MacFri, 26 Oct 2018 15:01:59 GMTpkienzle<p>
sasmodels on future macs
</p>
<p>
Apple has announced that OpenCL is deprecated as of Mojave <a class="ext-link" href="https://developer.apple.com/macos/whats-new/"><span class="icon"></span>https://developer.apple.com/macos/whats-new/</a>, however, there does seem to be an alternate path.
</p>
<p>
There is an OpenCL frontend in clang, triggered by "-x cl", as shown on <a class="ext-link" href="http://steckdenis.be/post-2011-05-02-using-clang-to-compile-opencl-kernels.html"><span class="icon"></span>this blog entry</a>, and which seems to work on my Mac. Khronos provides the <a class="ext-link" href="https://github.com/KhronosGroup/SPIRV-LLVM"><span class="icon"></span>LLVM to SPIR-V</a> translator and the <a class="ext-link" href="https://github.com/KhronosGroup/MoltenVK"><span class="icon"></span>MoltenVK</a> driver which takes SPIR-V and sends it to Apple's Metal framework.
</p>
<p>
So perhaps the problem will resolve itself, and a third party will put together the necessary toolchain in a nice anaconda package that we can supply with the mac distribution of sasview. Otherwise we will need to put together the pieces ourselves, or update kernel_iq.c to support Metal in addition to OpenCL and CUDA, and write a replacement for pyopencl/pycuda that targets Metal.
</p>
<p>
There is no answer yet on <a class="ext-link" href="https://stackoverflow.com/questions/51238079/is-there-a-vulkanpython-alternative-to-pyopencl-for-multiplatform-gpgpu-compute"><span class="icon"></span>stackoverflow</a>.
</p>
Resultshttp://trac.sasview.org/ticket/1203#changelog
http://trac.sasview.org/ticket/1231
http://trac.sasview.org/ticket/1231#1231: cross-check partially oriented 2D models against other softwareThu, 21 Feb 2019 03:31:29 GMTpkienzle<p>
There are at least two other packages that support 2D scattering patterns for partially oriented shapes. We could cross check our capabilities/results against these packages.
</p>
<p>
Scatter: <a class="ext-link" href="http://dx.doi.org/10.1107/S0021889810008289"><span class="icon"></span>http://dx.doi.org/10.1107/S0021889810008289</a>
</p>
<p>
SASET: <a class="ext-link" href="http://dx.doi.org/10.1107/S0021889813016658"><span class="icon"></span>http://dx.doi.org/10.1107/S0021889813016658</a>
</p>
Resultshttp://trac.sasview.org/ticket/1231#changelog
http://trac.sasview.org/ticket/1232
http://trac.sasview.org/ticket/1232#1232: canted particles in radial geometryThu, 21 Feb 2019 04:01:33 GMTpkienzle<p>
In the radial geometry the beam travels through the Couette cell, scattering from both left-to-right and right-to-left flow, so the particle needs to be modeled by adding forward and reverse scattering in equal portion; this will be particularly evident for canted particles, leading to a twinned image on the detector.
</p>
<p>
We should be able to handle this after the model is calculated using <tt>I(qx, qy) + I(-qx, qy)</tt>. This is pretty simple if the beam is centered on the detector because we can just add the computed image to its reverse. Any shift or rotation in the detector, though, makes it pretty messy. Easiest to just compute the pattern twice, once with <tt>+qx</tt> an again with <tt>-qx</tt> in that case, but this guarantees 2x cost. Otherwise we need to do a bunch of checks to select a set of qx-qy values to compute and interpolate within them for the <tt>qx,qy</tt> we need.
</p>
Resultshttp://trac.sasview.org/ticket/1232#changelog
http://trac.sasview.org/ticket/1234
http://trac.sasview.org/ticket/1234#1234: add orientation distributions for Jeffery orbitsMon, 25 Feb 2019 17:29:46 GMTpkienzle<p>
Ellipsoids in shear will exhibit tumbling with period related to the shear and aspect ratio. The distribution shape will change with aspect ratio.
</p>
<p>
Need to create theta and phi distribution functions that capture joint distribution and check that they are separable (or nearly so). If not, need to figure out how to handle joint distributions on theta and phi is sasmodels. The work-around is to implement an Iqxy function which has parameters for the Jeffery distribution, but we will need a separate one for each shape, so not a good long-term solution.
</p>
<p>
The following is a starting point:
</p>
<p>
[Stover1990]: Stover, C.A., Cohen, C., 1990. The motion of rodlike particles in the pressure-driven flow between two flat plates. Rheologica Acta 29, 192–203. <a class="ext-link" href="https://doi.org/10.1007/BF01331355"><span class="icon"></span>https://doi.org/10.1007/BF01331355</a>
</p>
Resultshttp://trac.sasview.org/ticket/1234#changelog
http://trac.sasview.org/ticket/1252
http://trac.sasview.org/ticket/1252#1252: Need to make easy to track different version of a model in the marketplaceThu, 21 Mar 2019 13:55:38 GMTbutler<p>
Replacing or deleting models from the marketplace is not appropriate since someone may have downloaded it, used it, and pointed to it in their paper. It should thus remain available. However as API's change and more so as users upload modifications (cleaner algorithms, faster integration, more precise results near zero, easier to understand names, etc etc) we need a way to both store this properly in the database and not have an overwhelming array of models many of which are really the same.
</p>
Resultshttp://trac.sasview.org/ticket/1252#changelog
http://trac.sasview.org/ticket/1264
http://trac.sasview.org/ticket/1264#1264: Form factor for two correlated spherical particlesThu, 28 Mar 2019 13:30:04 GMTTianfu<p>
If your system is made up by two particles with spherical shape(sphere, coreshell and so on), try this model.
</p>
Resultshttp://trac.sasview.org/ticket/1264#changelog
http://trac.sasview.org/ticket/1267
http://trac.sasview.org/ticket/1267#1267: OpenCL driver null when running GPU testFri, 29 Mar 2019 16:07:54 GMTwojciech<p>
When running GPU test OpenCL driver (clinfo) returns null. It seems like it is related to recent change in sasmodels.kernelcl.enviroment() change
</p>
Resultshttp://trac.sasview.org/ticket/1267#changelog
http://trac.sasview.org/ticket/542
http://trac.sasview.org/ticket/542#542: capped_cylinder & barbell docs and/or computations could be improvedSat, 19 Mar 2016 22:14:15 GMTrichardh<p>
capped_cylinder computations could be improved - see notes included in the .py file, current model requires user to keep cap radius > cylinder radius
</p>
<p>
ticket submitted by Richard, but assigned to PAK, who may know what to do.
</p>
Resultshttp://trac.sasview.org/ticket/542#changelog
http://trac.sasview.org/ticket/708
http://trac.sasview.org/ticket/708#708: Triaxial ellipsoidal core shellWed, 05 Oct 2016 23:05:50 GMTdirk<p>
Triaxial ellipsoidal core shell model is missing.
</p>
Resultshttp://trac.sasview.org/ticket/708#changelog
http://trac.sasview.org/ticket/782
http://trac.sasview.org/ticket/782#782: Performance tuning for 2D calculationsFri, 14 Oct 2016 15:00:42 GMTpkienzle<p>
Can save 6 trig functions 9 multiplications and 5 additions by precomputing the orientation info for each q point. In absolute terms, it is 325k operations on a 128x128 detector. In relative terms, the fcc mode uses an additional 4 special functions, 49 multiplications and 16 adds, so this could be a 25% speed up.
</p>
<p>
Need to transform:
</p>
<pre class="wiki"> q = sqrt(qx*qx + qy*qy);
const double qxhat = qx/q;
const double qyhat = qy/q;
double sin_theta, cos_theta;
double sin_phi, cos_phi;
double sin_psi, cos_psi;
SINCOS(theta*M_PI_180, sin_theta, cos_theta);
SINCOS(phi*M_PI_180, sin_phi, cos_phi);
SINCOS(psi*M_PI_180, sin_psi, cos_psi);
cos_alpha = cos_theta*cos_phi*qxhat + sin_theta*qyhat;
cos_mu = (-sin_theta*cos_psi*cos_phi - sin_psi*sin_phi)*qxhat + cos_theta*cos_psi*qyhat;
cos_nu = (-cos_phi*sin_psi*sin_theta + sin_phi*cos_psi)*qxhat + sin_psi*cos_theta*qyhat;
</pre><p>
Into a precompute phase:
</p>
<pre class="wiki"> double sin_theta, cos_theta;
double sin_phi, cos_phi;
double sin_psi, cos_psi;
SINCOS(theta*M_PI_180, sin_theta, cos_theta);
SINCOS(phi*M_PI_180, sin_phi, cos_phi);
SINCOS(psi*M_PI_180, sin_psi, cos_psi);
alpha_x = cos_theta*cos_phi;
alpha_y = sin_theta;
mu_x = -sin_theta*cos_psi*cos_phi - sin_psi*sin_phi;
mu_y = cos_theta*cos_psi;
nu_x = -cos_phi*sin_psi*sin_theta + sin_phi*cos_psi;
nu_y = sin_psi*cos_theta;
</pre><p>
and a compute phase:
</p>
<pre class="wiki"> q = sqrt(qx*qx + qy*qy);
const double qxhat = qx/q;
const double qyhat = qy/q;
cos_alpha = alpha_x*qxhat + alpha_y*qyhat;
cos_mu = mu_x*qxhat + mu_y*qyhat;
cos_nu = nu_x*qxhat + nu_y*qyhat;
</pre><p>
For polydisperse systems, need to precompute for each independent (theta,phi,psi) triple, but this can be done in parallel.
</p>
<p>
For polydisperse systems, can save a sqrt, 4 multiplies and an add by precomputing q, qxhat and qyhat for each point. Again, this can be done in parallel.
</p>
<p>
Could be implemented using global working memory (ticket <a class="new ticket" href="http://trac.sasview.org/ticket/679" title="enhancement: Allow kernels to use global working memory (new)">#679</a>).
</p>
Resultshttp://trac.sasview.org/ticket/782#changelog
http://trac.sasview.org/ticket/783
http://trac.sasview.org/ticket/783#783: Performance tuning for 1D calculationsFri, 14 Oct 2016 15:34:24 GMTpkienzle<p>
Many of the 1D calculations involve nested integrals over a fixed set of theta and phi values, with trig functions to turn these values into something useful for the kernel.
</p>
<p>
For example, the cylinder kernel, 2 trig operations, a multiply and an add can be replaced by two table lookups by converting:
</p>
<pre class="wiki"> const double zm = M_PI_4;
const double zb = M_PI_4;
double total = 0.0;
for (int i=0; i<76 ;i++) {
const double alpha = Gauss76Z[i]*zm + zb;
double sn, cn; // slots to hold sincos function output
// alpha(theta,phi) the projection of the cylinder on the detector plane
SINCOS(alpha, sn, cn);
total += Gauss76Wt[i] * square(fq(q, sn, cn, radius, length)) * sn;
}
return total*zm;
</pre><p>
into:
</p>
<pre class="wiki"> double total = 0.0;
for (int i=0; i<76 ;i++) {
total += Gauss76Wt_times_sin_alpha[i] * square(fq(q, sin_alpha[i], cos_alpha[i], radius, length));
}
return total*M_PI_4;
</pre><p>
To see if this might be worthwhile, I substituted Gauss76Z for the sin and Gauss76Wt for cos, and observed a 64% speedup. It had the wrong answer of course, but it does show that this approach could be worthwhile.
</p>
Resultshttp://trac.sasview.org/ticket/783#changelog
http://trac.sasview.org/ticket/790
http://trac.sasview.org/ticket/790#790: provide single and double precision versions of special functionsTue, 18 Oct 2016 15:58:10 GMTpkienzle<p>
For Si(x) in lib/Si.c the number of terms in the polynomials p and q, and the cutoff value for choosing between p(1/x) and q(x) are probably precision dependent. If not, this should be noted in the code.
</p>
<p>
Check that the remaining libraries use approximations suitable for the precision.
</p>
Resultshttp://trac.sasview.org/ticket/790#changelog
http://trac.sasview.org/ticket/812
http://trac.sasview.org/ticket/812#812: Provide model for the Pringle-Schmidt helical form factorThu, 24 Nov 2016 18:49:58 GMTsmk78<p>
Request from Ian Hamley (i.w.hamley@…):
</p>
<p>
Would be possible to incorporate the Pringle-Schmidt helical form factor into SasView? It is used in quite a few studies now. There are other helical form factors (see attached) but the Pringle-Schmidt form factor is more generally and more widely used.
</p>
<p>
I don’t have code although I know some people who might – Heinz Amenitsch or Pierre Terech. These two groups also have data and fits in their papers.
</p>
<p>
I have datasets waiting to be fitted, as does Daniel Hermida-Merino at the ESRF.
</p>
Resultshttp://trac.sasview.org/ticket/812#changelog
http://trac.sasview.org/ticket/859
http://trac.sasview.org/ticket/859#859: hayter_msa S(Q) - possible limitations or numerical instabilitiesWed, 22 Feb 2017 10:56:00 GMTrichardh<p>
This requires investigation. User Paul Fitzgerald (Univ Sydney) has supplied comprehensive examples, see below, and .xls on original email, attached here. NOTE that Steve Kline in March 2015 reported to Paul Butler, that sasview does have the rescaled MSA from Hayter.
</p>
<p>
Hello SASView help,
</p>
<p>
I've occasionally run into an instability in the Hayter_MSA routine (both in SASView and the original Igor routine), which I usually get around by fudging the ionic strength and charge. However, this is not possible with my current set of data where we intentionally and precisely controlled the ionic strength while looking at the particle charge.
</p>
<p>
Here is an example of the problem (more examples in the attached spreadsheet):
</p>
<p>
In hayter_msa if I set:
radius = 20Å
Temp = 298K
diel = 78
volfrac = 0.001
[salt] = 0.001 M
</p>
<p>
then vary the charge from 0 to infinity I get:
</p>
<p>
0-2 ⇒ all OK
3-32 ⇒ returns -1 for all values (error code -3)
33-115 ⇒ all OK
116-195 ⇒ returns -1 for all values (error code -3)
196-inf ⇒ all OK
</p>
<p>
The error comes from the sqcoeff(ir) function that handles rescaling. Note that this is for the Igor code - but not the compiled C version! I haven't been unable to find the HayterMSA code in the most recent version of the SASview source code so I don't know if it is the same function.
</p>
<p>
Can you tell me if
(a) the theory is just not applicable to my systems and I need to try something else, or
(b) if there is an implementation problem?
</p>
<p>
I did find the following in Hayter & Hensen's 1982 paper for rescaling (which I'm still trying to work through) but didn't know if it was applying to me or not:
In the weak screening limit, the MSA solution of Hayter & Penfold <a class="missing changeset" title="No changeset 3 in the repository">[3]</a> requires increasing computational precision because of the wide dynamic range of the coefficients. Under these conditions it is more efficient to use the simpler MSA solution for unscreened charged hard spheres <a class="missing changeset" title="No changeset 10 in the repository">[10]</a> as a reference system, and to treat the weak screening as a perturbation <a class="missing changeset" title="No changeset 16 in the repository">[16]</a>. The presence of the effective hard core allows an application of the 'optimized random phase approximation' (ORPA) <a class="missing changeset" title="No changeset 17 in the repository">[17]</a> to express the structure factor S(K) of the screened system in terms of the structure factor So(K) of the unscreened reference system. In practice, S(K) and So(K) turn out to be almost indistinguishable for Ka < 0.5.
</p>
<p>
That being said, even if it turns out that the theory is not applicable, I think that there is a problem in the way that SASview deals with this problem. When the hayter_msa returns values of -1 this is an error, but SASView returns (down in the bottom left corner) "Computation completed!" instead of "error".
</p>
<p>
From a fitting point of view, SASView just sees a massive increase in chi square and moves in the opposite direction. This can be a problem especially when the solution is on the other side of the instability, which can be narrow. For example, if you try the above settings with vol frac = 0.01 then the instability is only from 4 to 6.
</p>
<p>
I also think that once the underlying problem should be documented in the SASView help file. We've had students run into this problem and being completely lost as to what to do.
</p>
<p>
Sorry if this creates problems.
</p>
<p>
Regards,
</p>
<p>
Paul
</p>
Resultshttp://trac.sasview.org/ticket/859#changelog
http://trac.sasview.org/ticket/868
http://trac.sasview.org/ticket/868#868: validate the polymer_micelle modelTue, 28 Feb 2017 15:19:16 GMTrichardh<p>
This model needs validating, the meanings of some parameters are vague and the model can perhaps be improved. See comments in the .py file and the help.
</p>
Resultshttp://trac.sasview.org/ticket/868#changelog
http://trac.sasview.org/ticket/940
http://trac.sasview.org/ticket/940#940: fit_one_of function to avoid redundant parametersSun, 09 Apr 2017 08:07:16 GMTrichardh<p>
Could put some sort of function in model.py to identify which parameters should not all fit simultaneously, then flag to user as an issue.
</p>
<p>
e.g. for a simple particle:
</p>
<blockquote>
<p>
fit_one_of('scale', 'sld', 'sld_solvent')
</p>
</blockquote>
<p>
e.g. for a core-shell particle, think might need:
</p>
<blockquote>
<p>
fit_one_of('scale', 'sld_core'.AND.'sld_shell'.AND.'sld_solvent')
</p>
</blockquote>
<p>
There may be a better way to express this, or a clever way to to this automatically, certainly from the derivatives, or the correlation matrix. Also does not work always, e.g. if sld_shell is fixed at same as sld_solvent then the core/shell system beomes a simple particle, but could add extra logic for this???
</p>
Resultshttp://trac.sasview.org/ticket/940#changelog
http://trac.sasview.org/ticket/975
http://trac.sasview.org/ticket/975#975: bcc_paracrystal and fcc_paracrystal scaling, docs for all paracrystalWed, 07 Jun 2017 16:17:20 GMTrichardh<p>
Following some discussions with Prof. Gustavo González Gaitano, University of Navarra, Spain and some test calculations.
</p>
<p>
Given that the docs are already modified for the new "jitter" integrals (in progress??) which branch(es) should I use to fix the below please?
</p>
<p>
It now seems clear that:
</p>
<p>
1) The docs for all three paracrystal models talk about "nearest neighbour distances", but these should be lattice spacings, as previously noted in <a class="new ticket" href="http://trac.sasview.org/ticket/805" title="defect: improve accuracy of fcc/bcc/sc (new)">#805</a>
</p>
<p>
2) the Vlattice corrections mentioned in the docs seem wrong for BCC and FCC, and need to be changed there and in the code in order for fits to have the correct scale parameters.
</p>
<p>
I think that latticescale should be as for SC, but with the multiplicities in for FCC and BCC thus -
</p>
<p>
Instead of:
FCC const double s1 = dnn*sqrt(2.0);
</p>
<blockquote>
<p>
const double latticescale = 4.0*sphere_volume(radius/s1);
</p>
</blockquote>
<p>
BCC const double s1 = dnn/sqrt(0.75);
</p>
<blockquote>
<p>
const double latticescale = 2.0*sphere_volume(radius/s1);
</p>
</blockquote>
<p>
SC <em> NB: 4/3 pi r<sup>3 / dnn</sup>3 = 4/3 pi(r/dnn)<sup>3
</sup></em></p>
<blockquote>
<p>
const double latticeScale = sphere_volume(radius/dnn);
answer *= sphere_form(q, radius, sphere_sld, solvent_sld)*latticeScale;
</p>
</blockquote>
<p>
we need for FCC and BCC:
</p>
<p>
FCC
</p>
<blockquote>
<p>
const double latticescale = 4.0*sphere_volume(radius/dnn);
</p>
</blockquote>
<p>
BCC
</p>
<blockquote>
<p>
const double latticescale = 2.0*sphere_volume(radius/dnn);
</p>
</blockquote>
<p>
and in some other places for IQxy
</p>
Resultshttp://trac.sasview.org/ticket/975#changelog
http://trac.sasview.org/ticket/1001
http://trac.sasview.org/ticket/1001#1001: allow mixtures with some components being P*SMon, 25 Sep 2017 19:35:45 GMTpkienzle<p>
The following model is not parsed properly in sasmodels.core.load_model_info, and cannot be processed by sasmodels.mixture:
</p>
<p>
<tt></tt><tt>cylinder + core_shell_sphere@hardsphere</tt><tt></tt>
</p>
Resultshttp://trac.sasview.org/ticket/1001#changelog
http://trac.sasview.org/ticket/1020
http://trac.sasview.org/ticket/1020#1020: orientation - write a chapter for the general users docsFri, 27 Oct 2017 08:52:47 GMTrichardh<p>
orientation - write a chapter for the general users docs, that can be referenced from individual models. See also ticket <a class="closed ticket" href="http://trac.sasview.org/ticket/776" title="enhancement: angular dispersity (closed: fixed)">#776</a>
</p>
Resultshttp://trac.sasview.org/ticket/1020#changelog
http://trac.sasview.org/ticket/1040
http://trac.sasview.org/ticket/1040#1040: resolution documentation is in two placesThu, 30 Nov 2017 16:59:48 GMTpkienzle<p>
In the documentation for the resolution calculator (sasgui/perspectives/calculator/media) there are some diagrams that would be useful to include in the sasmodels description of resolution.
</p>
<p>
Check that these two docs are consistent, and maybe put the theory description entirely in sasmodels and reference it from the resolution calculator docs.
</p>
<p>
Similarly, <tt></tt><tt>gen_mag_pic.png</tt><tt></tt> in this directory is very similar to the <tt></tt><tt>M_angles_pic.png</tt><tt></tt> file in sasmodels. Maybe reference the magnetic scattering theory in sasmodels from sas_calculator_help? The general scattering theory would also be useful to have in sasmodels.
</p>
Resultshttp://trac.sasview.org/ticket/1040#changelog
http://trac.sasview.org/ticket/1056
http://trac.sasview.org/ticket/1056#1056: Check max_pd maximum number polydisperse parametersThu, 04 Jan 2018 16:38:06 GMTrichardh<p>
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:
</p>
<p>
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
</p>
<p>
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.
</p>
<p>
I have set Paul K as owner as he will likely spot an issue quickly.
Richard
</p>
Resultshttp://trac.sasview.org/ticket/1056#changelog
http://trac.sasview.org/ticket/1077
http://trac.sasview.org/ticket/1077#1077: model name must be a valid C identifierTue, 27 Feb 2018 22:34:39 GMTpkienzle<p>
Clean up model name/id/filename handling, and warn user cleanly if anything is amiss.
</p>
<p>
The sasmodels compiler raises an error when loading a plugin model with spaces in its name, but it reports as a missing semicolon in the kernel_iq.c file which the user did not touch. The real error is in the python file defining the model, so the message is confusing to the user.
</p>
<p>
The distinction between model name and model id has become muddy. Originally the id was to be the internal name that was a proper identifier and the name was the display name that was shown in the user interface. At some point the system evolved so that name is used for both and id is (mostly?) ignored. However, old code for generating a nice display name if one was not provided in the file is still active, which puts spaces between words and capitalization of the first word. The result is that if the name is not present, the model may give the missing semicolon error.
</p>
<p>
An additional wrinkle: the internal name must match the filename so we can find the model definition without having to load all models.
</p>
Resultshttp://trac.sasview.org/ticket/1077#changelog
http://trac.sasview.org/ticket/1100
http://trac.sasview.org/ticket/1100#1100: OpenMP is turned off in unixFri, 27 Apr 2018 22:17:49 GMTpkienzle<p>
Testing the following on unix:
</p>
<pre class="wiki"> python -m sasmodels.compare cylinder -2d -engine=double,double!
</pre><p>
the DLL pattern was showing excessive noise. Adding in <tt>-poly</tt> shows distinct banding patterns.
</p>
<p>
OpenMP is turned off in kerneldll.py until this can be resolved. Not sure how badly this affects performance since frame calculation times are inconsistent.
</p>
Resultshttp://trac.sasview.org/ticket/1100#changelog
http://trac.sasview.org/ticket/1107
http://trac.sasview.org/ticket/1107#1107: Doubts about Onion DocThu, 07 Jun 2018 09:07:58 GMTJoachim Wuttke<p>
quite generally:
to facilitate citation and discussion, I'd suggest to number equations
in doc pages that contain lots of them.
</p>
<p>
concerning <a class="ext-link" href="http://marketplace.sasview.org/models/73"><span class="icon"></span>http://marketplace.sasview.org/models/73</a>:
</p>
<p>
The introduction announces that the SLD of each shell may be »described
by an exponential, linear, or constant function«. In the following,
however, only only the exponential and the constant case are explicitly
covered. For a linear SLD, the reader is left with the hint that
the exponential function with small A is a good approximation.
</p>
<p>
rho_shell(r) is defined in terms of six parameters. One of them is redundant
since rho_in=B+C. The parameters B and C have no obvious physical meaning,
and they do not appear in the parameter list of Iq. Two equation blocks later,
the paremeter B is defined a second time, now in terms of rho_in, rho_out, and A.
This makes the logic very obscure.
</p>
<p>
I would suggest that rho_shell(r) be defined in terms of the parameters
A, rho_in, rho_out, r_in, r_out. Then one would introduce Delta t_shell,
B, and C as abbreviations, which makes them categorically distinct from
the API parameters.
</p>
<ul><li>Joachim
</li></ul>Resultshttp://trac.sasview.org/ticket/1107#changelog
http://trac.sasview.org/ticket/1158
http://trac.sasview.org/ticket/1158#1158: Inconsistent fuzzy or rough interfaces in fuzzy_sphere and core_shell_bicelle_elliptical_belt_roughTue, 21 Aug 2018 14:57:51 GMTrichardh<p>
Whilst dealing with <a class="closed ticket" href="http://trac.sasview.org/ticket/1160" title="defect: fix VR for core_shell_cylinder, fractal_core_shell and hollow_cylinder (closed: fixed)">#1160</a> beta(Q) model changes, Paul K noted that
</p>
<blockquote>
<p>
Fuzzy sphere is defined as
</p>
</blockquote>
<blockquote>
<blockquote>
<p>
P = (f * exp(-½ q^2 fuzziness^2))^2
</p>
</blockquote>
</blockquote>
<blockquote>
<p>
but core shell bicelle elliptical belt rough uses:
</p>
</blockquote>
<blockquote>
<blockquote>
<p>
P = f^2 * exp(-½ q^2 sigma^2)
</p>
</blockquote>
</blockquote>
<blockquote>
<p>
Are both of these correct? Or should the bicelle roughness term be squared?
</p>
</blockquote>
<blockquote>
<p>
Do these models work correctly with structure factors?
</p>
</blockquote>
<blockquote>
<p>
Does the fuzziness apply as usual for the calculation for beta?
</p>
</blockquote>
<blockquote>
<blockquote>
<p>
beta = < f exp(-q^2 s^2/2) >^2 / < f^2 exp(-q^2 s^2/2))^2 >
</p>
</blockquote>
</blockquote>
<p>
THIS REQUIRES FURTHER INPUT - HAS ANYONE ELSE SEEN PAPERS DERIVING DIFFUSE INTERFACES?
</p>
<p>
Email discussion summarised below …
</p>
<p>
Richard wrote: In both cases sasview follows the references given, so we either need to think harder or find some other references!
</p>
<blockquote>
<p>
The derivation for fuzziness goes something like this - at high Q the I(Q) is essentially a 1d Fourier transform of the sld profile normal to an interface.
</p>
</blockquote>
<blockquote>
<p>
If the features in the sld profile were to be convoluted with a Gaussian, then the convolution theorem tells us that we multiply the I(Q) by an exponential.
</p>
</blockquote>
<blockquote>
<p>
Thus strictly sigma in the Gaussian has to be very small compared to the radius of the particle (which is perhaps not always so in the Stieger paper, though they don't seem to give any values for sigma, just say that Rsans = R + 2*sigma).
</p>
</blockquote>
<blockquote>
<p>
Should we be multiplying F(Q) or P(Q) ? Squaring the exponential of course only rescales sigma by sqrt(2), so all depends on the precise definition of sigma.
</p>
</blockquote>
<blockquote>
<p>
Strey points (incorrectly) to a paper by Ruland (papers available from Richard) which does say Iobs = I. H^2 where H is the Fourier of the smoothing distribution. See also the discussion after eqn (3) in the Ciccariello paper (not that I in any way understand the details in the rest of that paper).
</p>
</blockquote>
<blockquote>
<p>
I could suggest that "fuzziness" ought only to be applied after everything else, including any S(Q) and beta(Q) as it ought only to work at very high Q, but in that case it should not affect results at smaller Q anyway, so I suppose that it could go into F or F^2.
</p>
</blockquote>
<blockquote>
<p>
What we should really be doing, at least for spherical particles, is to use a constrained multiple linear step sld profile, which would then work properly for all particle radii. Of course for elliptical bicelles this is not possible, so we have to resort to approximations like this.
</p>
</blockquote>
<blockquote>
<p>
Have any of you got any further references for diffuse or fuzzy interfaces?
</p>
</blockquote>
<p>
Yun wrote: Thanks Richard to dig out all the reference and provide detailed comments on this.
</p>
<p>
As for the calculation of the fuzzy ball, I agree with Richard's comments.
</p>
<p>
Overall, both equations are ok. But the definition of the fuzziness is slightly different.Personally, I prefer " P = (f * exp(-½ q^2 fuzziness^2))^2".
</p>
<p>
But since we need to have a reference for any model, I guess we can keep them as they are now since these are the "correct" equations from the references SASView provides.
</p>
<p>
For "P = (f * exp(-½ q^2 fuzziness^2))^2" (or other equation), it is used to describe a density convolution in 3D in the real space. However, due to the isotropic properties, it reduces to the 1D problem as pointed out by Richard.
</p>
<p>
It is indeed much better defined if sigma (or fuzziness) is relatively small. I feel that when the sigma is very large, its mathematical meaning can still hold. I did not read the paper by Stieger carefully yet so not sure if they discussed this.
</p>
<p>
As for the beta approximation, if there is a change (polydispersity) of size or sigma, I feel that the beta factor can be still calculated in the same way. What Paul K. proposed, "beta = < f exp(-q^2 s^2/2) >^2 / < f^2 exp(-q^2 s^2/2))^2 >", seems reasonable to me.
</p>
<p>
As long as the shape fluctuation is independent of the relative locations of the center of mass of all particles, the beta approximation would be still fine. (for the full Q range? not necessarily for high Q only? ) Of course, I am not sure when the beta approximation should fail for this case. This still needs more future work.
</p>
<p>
</p>
Resultshttp://trac.sasview.org/ticket/1158#changelog
http://trac.sasview.org/ticket/1216
http://trac.sasview.org/ticket/1216#1216: attribute checking in model definition fileThu, 15 Nov 2018 15:32:50 GMTpkienzle<p>
sasmodels enhancement.
</p>
<p>
Don't allow attributes to be added to the ModelInfo class. In the model definition file, don't allow attributes that are not in ModelInfo.
</p>
<p>
The first part can be done with the following method in the ModelInfo class:
</p>
<pre class="wiki"> def __setattr__(self, key, value):
# Check for class attr when setting; this is because hasattr on
# a property will return False if getattr on that property raises
# an exception. This means if you really want to sneak an
# attribute into the group from your data loader, you will have
# to populate it from the
if not key.startswith('_') and not hasattr(self.__class__, key):
raise AttributeError("Cannot add attribute %s to class %s"
% (key, self.__class__.__name__))
object.__setattr__(self, key, value)
</pre><p>
The second part will require an additional step at the bottom of <tt>modelinfo.make_model_info</tt> which scans the attributes of the definition module and makes sure they are in the ModelInfo class. Ignore names with leading underscore so that helper functions and variables can be defined.
</p>
<p>
By doing this, users will not be able to introduce typos into the model attribute definitions, or otherwise wish for capabilities that are not already there. For example, the model *multilayer_vescicle* defines the following, which looks like it should make *radius* and *n_pairs* polydisperse, but which in fact is completely ignored by sasmodels:
</p>
<pre class="wiki">polydispersity = ["radius", "n_pairs"]
</pre><p>
Split from ticket <a class="closed ticket" href="http://trac.sasview.org/ticket/829" title="enhancement: allow models to define ModelInfo directly (closed: fixed)">#829</a>.
</p>
Resultshttp://trac.sasview.org/ticket/1216#changelog
http://trac.sasview.org/ticket/1259
http://trac.sasview.org/ticket/1259#1259: Prefactor calculation when there are both P(Q) and S(Q)Tue, 26 Mar 2019 10:13:25 GMTyunliu<p>
The models for vesicle and sphere systems ( P(Q) ) with the hard sphere interaction ( S(Q) ) have two volume fraction: phi_PQ and phi_SQ.
phi_PQ is the volume fraction from the form factor.
phi_SQ is the volume fraction from the structure factor.
</p>
<p>
Based on the testing of the two models, the prefactor of the scattering intensity is currently set up to be proportional to scale*phi_PQ*phi_SQ.
</p>
<p>
If the scale is set up to one, the prefactor with the absolute intensity should be proportional to phi_PQ only.
It should not be phi_PQ*phi_SQ.
</p>
<p>
It is suggested to remove phi_SQ from the calculation of the prefactor.
</p>
Resultshttp://trac.sasview.org/ticket/1259#changelog
http://trac.sasview.org/ticket/1265
http://trac.sasview.org/ticket/1265#1265: Add superball form factorFri, 29 Mar 2019 12:14:08 GMTDomiDre<p>
A superball represents a cube with rounded edges and transforms from a sphere to a cube by a single parameter with the definition x<sup>(2p) + y</sup>(2p) + z<sup>(2p) ⇐ R</sup>(2p).
</p>
Resultshttp://trac.sasview.org/ticket/1265#changelog