Opened 2 years ago

Closed 2 years ago

#858 closed defect (fixed)

hayter_msa S(Q) - error returns

Reported by: richardh Owned by: pkienzle
Priority: minor Milestone: SasView 4.1.0
Component: sasmodels Keywords:
Cc: Work Package: SasView Bug Fixing

Description (last modified by butler)

User Paul Fitzgerald (Univ Sydney) reports that the function returns a value -1 as an error code. Should this be say NAN to avoid confusing the fitting! Example cases below. Will put in another ticket to address the instability issue.

On Tue, Feb 21, 2017 at 8:31 PM, Paul FitzGerald ( paul.fitzgerald at ) wrote:

Hello SASView help,

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.

Here is an example of the problem (more examples in the attached spreadsheet):

In hayter_msa if I set:
radius = 20Å
Temp = 298K
diel = 78
volfrac = 0.001
[salt] = 0.001 M

then vary the charge from 0 to infinity I get:

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

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.

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?

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 [3] 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 [10] as a reference system, and to treat the weak screening as a perturbation [16]. The presence of the effective hard core allows an application of the 'optimized random phase approximation' (ORPA) [17] 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.

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".

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.

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.

Sorry if this creates problems.



Change History (4)

comment:1 Changed 2 years ago by pkienzle

  • Resolution set to duplicate
  • Status changed from new to closed

comment:2 Changed 2 years ago by pkienzle

  • Resolution duplicate deleted
  • Status changed from closed to reopened

comment:3 Changed 2 years ago by butler

  • Description modified (diff)

comment:4 Changed 2 years ago by GitHub <noreply@…>

  • Resolution set to fixed
  • Status changed from reopened to closed

In a3002beb646e39f8d84ce0ad3ede19e81903c009/sasmodels:

Merge pull request #32 from SasView?/ticket-858

ticket-858: hayter_msa should return NAN rather than -1 for bad model parameters. Closes #858

Note: See TracTickets for help on using tickets.