Custom Query (780 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (16 - 18 of 780)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Ticket Resolution Summary Owner Reporter
#1205 fixed 4.2 set weighting choice seems to be ignored. mathieu richardh
Description

Comparing fit results between 4.2 and 5.0, noticed (see #1204) that the set weighting option in 4.2 has no effect on the fit results, whereas it does in 5.0

Further investigation required.

#1202 fixed beta approx branch doesn't support ER/VR tests GitHub <noreply@…> pkienzle
Description

sasmodels 1.0 beta

Since we have restructured effective radius and form:shell volume ratio, the ER and VR tests no longer work.

Instead of using calculator() in direct_model.call_kernel, can use calculator.Fq() to return (F, Fsq, effective_radius, shell_volume, volume_ratio).

Because calculator.Fq() needs a q value, we can modify the test syntax from

tests = [
    ...
    ({}, 'ER', Reff),
    ({}, 'VR', form_to_shell),
    ...
]

to

tests = [
    ...
    ({'radius_effective_type': 1}, 0.1, None, Reff, form_to_shell),
    ...

That is, if the test uses 5 columns rather than three, then the last two columns will be ER and VR.

Is this too obscure? Do we also want to test F and Fsq outputs?

Maybe specify outputs as a dict, with missing entries not tested:

    ({radius_effective_type: 1}, 0.1, 
     {'F': F, 'Fsq': F*F, 'Reff': Reff, 'Vr': form_to_shell})

—-

A further issue is that there are now multiple effective radius types in some models.

It is probably good enough to treat each one as an independent test in the file.

For example, for cylinder, using the list form for specifying test results:

# Default radius and length
radius, length = parameters[2][2], parameters[3][2]
tests = [
    ...
    ({'radius_effective_type': 1}, 0.1, None, (0.75*radius**2*length)**(1./3.), None),
    ({'radius_effective_type': 2}, 0.1, None, radius, None),
    ({'radius_effective_type': 3}, 0.1, None, length/2., None),
    ({'radius_effective_type': 4}, 0.1, None, min(radius, length/2.), None),
    ({'radius_effective_type': 5}, 0.1, None, max(radius, length/2.), None),
    ({'radius_effective_type': 6}, 0.1, None, sqrt(4*radius**2 + length**2)/2., None),
]

#1201 fixed default effective radius type GitHub <noreply@…> pkienzle
Description

In sasmodels, all platforms.

For the beta_approx branch we are using a default of 0 as the effective radius type (i.e., use the value from the parameter table instead of the form factor calculation) rather than whatever the model was returning before.

Do we want this as the default?

Or should we set the default to 1 and make sure that is the "best" effective radius to use when computing P@S?

There is also an issue with reloading a saved P@S fit from 4.2 and earlier, which all implicitly use old ER radius type.

Do we try to set the equivalent effective radius type parameter in the model?

Or do we let it silently use the default value for radius_effective from S?

Note: if the old ER is not the first effective radius type for any model then conversion with need a table for each model giving the number to use. Not difficult, but a detail to test if we decide to support correct reloading of old P@S models.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Note: See TracQuery for help on using queries.