leonarski_f
54f2de31bb
A grid scan is a set of stills at a stationary spindle, and the angle it stood at is what relates one grid to another taken elsewhere on the circle. Users were finding an all-zero omega in the file and concluding the angle could not be recorded at all. It already can, and has since the goniometer and the grid scan stopped being alternatives: send the axis with step 0 and its start angle, and that angle is written per image into the NXmx sample chain, read back by reader/, and taken by dials.import as a set of stills. Measured on a generated 12-image grid: the placeholder file carries omega = 0 x 12, the same file with the axis sent at step 0 carries omega = 90 x 12, and dials.import reports "still: 1, sweep: 0" for both. Nothing in the code needed changing, so nothing was; what was missing was that nobody could tell, and that no test held the behaviour down. So: the API and the HDF5 documentation now say it in as many words, and three tests pin the three legs the value crosses - the OpenAPI request (which used to drop the grid scan whenever an axis was present, unpinned until now), the CBOR start message, and the file round trip. Also corrects a claim two comments and the HDF5 page were making. NXmx can express "no rotation" perfectly well - a sample may depend_on "." - so the placeholder is not there for the standard's sake. It is there because dxtbx cannot read a sample chain of translations alone: strip the rotation axis from a grid scan master and dials.import dies in get_dxtbx_goniometer with a matmul dimension mismatch. Recorded so nobody removes the placeholder on the strength of the standard. One thing the change does not fix, because it cannot: a stationary angle is invisible to DIALS when a grid scan is present. dxtbx picks the first varying axis as the scan axis, which is a grid translation, so the oscillation reads (0, 0); and with exactly one rotation axis in the chain it builds a single-axis goniometer whose fixed rotation is the identity, never consulting the angle. The same angle IS visible when it is the only candidate (oscillation reads (90, 0)) or when a Smargon head puts a second rotation axis in the chain (the setting rotation then carries it). The value is in the file and correct either way.
1.5 KiB
1.5 KiB
RotationAxis
Definition of a crystal rotation axis
Properties
| Name | Type | Description | Notes |
|---|---|---|---|
| name | str | Name of rotation axis (e.g., omega, phi) | [optional] [default to 'omega'] |
| step | float | Angle step (per image) in degrees. 0 for an axis that does not turn: the axis then records the angle the spindle stood at, which is how a grid scan or a set of stills states its head position. | |
| start | float | Start angle in degrees | [optional] [default to 0] |
| vector | List[float] | Rotation axis | |
| helical_step_um | List[float] | Translation (per image) for helical scan | [optional] |
| screening_wedge_deg | float | Wedge angle value; used if rotation per image is smaller than increment between images (so particularly in screening) | [optional] |
Example
from jfjoch_client.models.rotation_axis import RotationAxis
# TODO update the JSON string below
json = "{}"
# create an instance of RotationAxis from a JSON string
rotation_axis_instance = RotationAxis.from_json(json)
# print the JSON string representation of the object
print(RotationAxis.to_json())
# convert the object into a dict
rotation_axis_dict = rotation_axis_instance.to_dict()
# create an instance of RotationAxis from a dict
rotation_axis_from_dict = RotationAxis.from_dict(rotation_axis_dict)