Custom Query (780 matches)
Results (16 - 18 of 780)
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. |