-
Notifications
You must be signed in to change notification settings - Fork 3
Simplify AMOR/reflectometry workflow #107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
0703e10
3776e33
320ecd2
47dd79f
74d6b66
0e17ad5
5f9c989
840dbab
a414155
8fafbe3
a613608
5015491
9afa893
48d6313
57217ab
acfcc05
514df9b
375b979
459b459
d8319fa
28ac9f7
1d81812
afd5ce9
c0bef22
c0ce521
6eed68b
59b5a0a
efe8434
c65c39e
9b28032
c43c854
33d832b
a9b25fd
a206792
f399b6a
3abbe62
b76dadd
b9eae74
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -5,23 +5,30 @@ | |
| import sciline | ||
| import scipp as sc | ||
|
|
||
|
|
||
| from ..reflectometry import providers as reflectometry_providers | ||
| from ..reflectometry import supermirror | ||
| from ..reflectometry.types import ( | ||
| BeamSize, | ||
| DetectorSpatialResolution, | ||
| Gravity, | ||
| NeXusDetectorName, | ||
| RunType, | ||
| SamplePosition, | ||
| BeamDivergenceLimits, | ||
| ) | ||
| from . import conversions, load, orso, resolution, utils, figures | ||
| from . import ( | ||
| conversions, | ||
| load, | ||
| orso, | ||
| resolution, | ||
| utils, | ||
| figures, | ||
| normalization, | ||
| workflow, | ||
| ) | ||
| from .instrument_view import instrument_view | ||
| from .types import ( | ||
| AngularResolution, | ||
| Chopper1Position, | ||
| Chopper2Position, | ||
| ChopperFrequency, | ||
| ChopperPhase, | ||
| QThetaFigure, | ||
|
|
@@ -42,10 +49,11 @@ | |
| *reflectometry_providers, | ||
| *load.providers, | ||
| *conversions.providers, | ||
| *resolution.providers, | ||
| *normalization.providers, | ||
| *utils.providers, | ||
| *figures.providers, | ||
| *orso.providers, | ||
| *workflow.providers, | ||
| ) | ||
| """ | ||
| List of providers for setting up a Sciline pipeline. | ||
|
|
@@ -61,12 +69,14 @@ def default_parameters() -> dict: | |
| supermirror.Alpha: sc.scalar(0.25 / 0.088, unit=sc.units.angstrom), | ||
| BeamSize[RunType]: 2.0 * sc.units.mm, | ||
| DetectorSpatialResolution[RunType]: 0.0025 * sc.units.m, | ||
| Gravity: sc.vector(value=[0, -1, 0]) * sc.constants.g, | ||
| SamplePosition[RunType]: sc.vector([0, 0, 0], unit="m"), | ||
| NeXusDetectorName[RunType]: "detector", | ||
| ChopperPhase[RunType]: sc.scalar(7.0, unit="deg"), | ||
| ChopperFrequency[RunType]: sc.scalar(8.333, unit="Hz"), | ||
| BeamDivergenceLimits: (sc.scalar(-0.7, unit='deg'), sc.scalar(0.7, unit='deg')), | ||
| BeamDivergenceLimits: ( | ||
| sc.scalar(-0.75, unit='deg'), | ||
| sc.scalar(0.75, unit='deg'), | ||
| ), | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is not very user friendly. Ideally, the code that uses these should convert to the unit it needs.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On the other hand it's messy and somewhat error prone to have unit conversion code all over the package (forgetting a unit conversion somewhere might lead to It's easiest to have unit conversion code on the boundaries of the application and only work with a set of predetermined units in the "internal" code. One way to achieve that would be to create a separate provider just for converting the unit of the input to the common unit. But doing that for every input would clutter the workflow graph and make it considerably less readable.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I disagree. It is often very difficult to understand which units are required by any given piece of code. And we don't encode them in our interfaces.
Yes, the same as using an incorrect unit in a parameter. Except that the latter
True. That is a tradeoff. But we accepted that tradeoff in ScippNeutron in favour of reducing the number of user-facing I don't expect the same amount of care in all code. But I do think that users should not have to know which units are required. Especially given that the requirements are not document anywhere. |
||
| } | ||
|
|
||
|
|
||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.