Opened 4 years ago

Closed 3 years ago

#1030 closed defect (fixed)

volume normalization for hollow shapes is different from solvent-filled shapes

Reported by: pkienzle Owned by: GitHub <noreply@…>
Priority: major Milestone: SasView 4.2.0
Component: SasView Keywords:
Cc: Work Package: SasView Bug Fixing


The current volume normalization algorithm is suspicious. The hollow models (cylinder, rectangular prism) exclude the core volume but the corresponding core-shell models do not, even if the core sld is set to solvent sld.

Perhaps the normalization term should include a contrast factor? This would cancel for simple models with only one contrast, but would allow core-shell models with solvent cores to match hollow models.

Does anyone have a reference for the current volume normalization algorithm?

Change History (4)

comment:1 Changed 4 years ago by richardh

The hollow_particle models do exactly what they should, they are mostly only needed so that the "scale" the user fits is the "shell volume". This is useful if for example a known concentration of lipid produces a hollow tube with solvent inside.

A further reason is that specifically the hollow_cylinder does not have end caps (though the user docs are a little vague here and need improving) whilst core_shell_cylinder does have flat end caps, so gives different results when sld_core = sld_solvent.

We should not modify the current core_shell_particle models to include a contrast dependent volume scaling, as conventional least squares would fail miserably if the volume parameter suddenly changed at a delta function point when the shell diasappeared (though a fit would be unlikely to hit this precisely enough). In any case the shell might actually be matched to the solvent, but still be there, so to properly "ignore" it the shell thickness should be also be set to near zero, in which case the total volume would be correct.

What would be very good however would be non-fitting flags in the core_shell_particle models to:

(1) decide whether "scale" is the volume fraction for the core, the shell or the whole particle, as users may often know a different one of these depending on the system. The conversion from one to the other can be tricky to get right, for example if the shell contains some solvent, or one of the regions is a mixture of components.

(2) decide for example which flat end caps of cylinders, or corner regions of boxes, are included or not.

(3) decide which volume (whole particle volume as default, or optionally the core volume if the shell really has zero thickness) should be used for any S(Q), or add a "free fit" of an effective S(Q) volume fraction.

All of the above would both reduce the number of models needed, and give users more freedom to fit or fix variables in ways that are relevant to their science.

(At some point I do want to add models that specifically deal with case where "wet" shells contain an  adjustable amount of solvent, but users can still fix or fit the "dry" volume fraction. For some other related ideas see )

comment:2 Changed 4 years ago by butler

Agreed. That is the main reason for two different models! Otherwise a a hollow cylinder would be pointless. The ideas Richard suggests however for maybe addressing that in a way that does not require another model is intriguing — would have to see whether it helps or confuse the "average" user (whoever that is).

There is also an old ticket, #366, for building an infrastructure with a simple GUI interface to easily re-parameterize a model to do something like Richard suggests, for example fitting to the solvent content of the shell rather than the SLD. However Andrew and I were discussing at code camp in Copenhagen that with the new model architecture and the model marketplace it is now quite simple to do this by downloading the model in question and simply changing the parameters in the python file then adding a few lines to "convert" those new parameters into the model parameters in the C or python code for Iq (or Iqxy). We will be publishing an example of this soon in Protein Science and upload that model to the marketplace as part of the publication process.

Thus the question may be whether it is the best use of our limited resources to build such an infrastructure rather than just let people provide whatever variations they need. Probably worth a discussion if we ever get to a point where someone has time to tackle this?

comment:3 Changed 3 years ago by pkienzle

  • Milestone changed from SasView 5.0.0 to SasView 4.2.0

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

  • Owner set to GitHub <noreply@…>
  • Resolution set to fixed
  • Status changed from new to closed

In 1a3c0c633570d13536dbdfce519aa921ffbff3fe/sasmodels:

Merge pull request #78 from SasView?/ticket-1160-VR

Ticket 1160 vr

Besides fixing the VR (removing from core_shell models and fixing hollow_cylinder) cleaned up a bunch of model documentation. Also realized that the 3 issues raised in ticket 1030 were mostly addressed so fixed last small docs issue as per Richard Heenan in order to close both tickets at once.

Closes #1160; closes #1030

Note: See TracTickets for help on using tickets.