Skip to content
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

transform_coords building blocks for gravity correction in theta vs wavelength transformations #50

Open
wants to merge 11 commits into
base: main
Choose a base branch
from

Conversation

OwenArnold
Copy link
Contributor

Aim is to put generic building blocks in place rather than wire it in. transform_coords became available in scipp 0.8 and is the new generic mechanism.

Effectively does this
image

See non transform_coords implementation https://scipp.github.io/ess-notebooks/reflectometry/amor_reduction_detailed.html#Theta-calculation-and-gravity-correction

This implementation produces identical for input data that @arm61 uses:
image

Copy link
Member

@SimonHeybrock SimonHeybrock left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some comments below. Should we drop the to_ prefixes, we don't use prefixes much elsewhere?

Comment on lines 6 to 7
return sc.to_unit(h / (wavelength * neutron_mass), sc.units.m / sc.units.s,
copy=False)
Copy link
Member

@SimonHeybrock SimonHeybrock Sep 27, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rewrite this to do large operations last. As written here we first create multiple large intermediates, consuming a lot of memory and compute. Rewrite to multiply with wavelength as the very last step. Also to_unit could be done before.



# Derivative of y with respect to z
def to_y_dash(wavelength, sample_position, detector_position):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this use scattered_beam instead of the two positions?

Comment on lines 18 to 19
return (-0.5 * sc.norm(gy)
* diff.fields.z / velocity_sq) + (diff.fields.y / diff.fields.z)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is bound to break since it hard-codes the direction of gravity. I would recommend to require a g coordinate that is defined as a vector with every data array. Essentially this vector would replace (parts of) what Mantid defines as "reference frame".

Comment on lines 22 to 28
def to_scattering_angle(w, wavelength, detector_id, position, sample_position):
z_origin = sample_position.fields.z
y_origin = sample_position.fields.y
z_measured = position.fields.z
y_dash = to_y_dash(wavelength, sample_position, position)
height = y_dash * (z_measured - z_origin) + y_origin
return sc.atan2(y=height, x=z_measured) - w
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hard coding some directions as well? Can we define/require, e.g., a sample-normal vector instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, fully agree. Would be much happier if we did this with configurable beam and sample normal (up) directions.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would not call it up though, since there are reflectometry beamlines where "up" is not the sample normal, since the beamline "lies" on its side.

Calculations previously assumed forward beam direction z and vertical in y.


def _angle(a, b):
return sc.acos(sc.dot(a, b) / (sc.norm(a) * sc.norm(b)))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Those functions will be provided by scippneutron. I think we should prefer finding a good API there and using that here. ess should only provide specialised building blocks that can be added to or replace components of graphs in scippneutron.

@nvaytet
Copy link
Member

nvaytet commented Dec 14, 2021

The use of transform_coords has been implemented in #61 , but I feel like the unit tests here should still make it into the codebase.

@SimonHeybrock
Copy link
Member

The use of transform_coords has been implemented in #61 , but I feel like the unit tests here should still make it into the codebase.

Yes, but I think we should also avoid testing transform_coords, and rather focus on testing the graph building blocks directly. Otherwise tests get unnecessarily complex.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants