Trajectory rotation only rotates positions

[amruthesht]

Bug description and Actual behavior

The Trajectory rotation transofrmation and its asociated rotate methods seem to only rotate positions while ignoring velocities and forces tied to the simulation frame/trajectory. Related AtomGroup methods like rotate() and rotateby() also have a similar issue.
However, most scientific contexts require rotation of most simulation frame vector attributes like positions, velcoties, and forces.

Expected accurate behavior

All roatation based functions and modules should rotate other simulation frame/trajectory attributes like velocities and forces using a similar (mathematical) rotation formulism (and maybe have an optional paramter switches to do so or not for velocities and forces)

Current version of MDAnalysis

• Issue current as of MDA v2.10

[ParthUppal523]

Hi @amruthesht, I would love to work on this issue! I've been looking through the codebase and I have a few quick technical questions to make sure my PR aligns with your expectations:

1. Backward Compatibility: Regarding the optional parameter switches for velocities and forces (e.g., rotate_velocities), should their default values be set to True (to ensure physical accuracy by default) or False (to preserve backward compatibility for users who might be relying on the old behavior)?
2. Implementation Architecture: I noticed that AtomGroup.rotateby() delegates its math to transform(), and transform() simply chains self.rotate(R).translate(t). Because spatial translations shouldn't apply to pure directional vectors, I plan to keep translate() unchanged. Therefore, I plan to implement the actual velocity/force matrix multiplication exclusively within the rotate() method. I will add the rotate_velocities and rotate_forces arguments to rotateby() and transform() purely to pass the user's choices down the chain to rotate(). Does this sound architecturally correct to you?
3. Transformation Architecture (transformations/rotate.py): For the trajectory transformation, I plan to add the same kwargs to the rotateby class initialization. Since rotateby inherits from TransformationBase, I will inject the matrix multiplication and NoDataError safety net directly inside its _transform(self, ts) method so it applies to the velocities and forces of each Timestep.
4. Missing Data Handling: If a user sets rotate_velocities=True but the underlying trajectory doesn't contain velocity data, I plan to catch the NoDataError and pass silently so the coordinates still rotate without crashing. Does this sound like the preferred behavior?

Your suggestions will be helpful!

[orbeckst]

1. We don't need switches — the velocities and forces need to be rotated because anything else is wrong.
2. Changing rotate() to also rotate velocities and forces sounds correct.
3. Look at transformations and the analysis.align code.
4. N/A – no rotate_velocities needed.

[ParthUppal523]

Thank you for your response, @orbeckst.

Based on your inputs, I will start working on the PR.

[pranjali2076]

Hi @qiyunzhu and @AnkurBambhrolia!

I noticed this issue has hit a bit of a wall with _ingest_table coercing alternative data backends (like PyTorch/Polars) back into standard NumPy arrays. I would love to jump in and help unblock this by refactoring the ingestion logic to leverage the internal array_backends helper utilities as suggested.

May I take over this thread to get the mixup functions fully Array API-compatible?

[orbeckst]

@pranjali2076 i don’t understand your comment. How does what you’re saying refer to the issue at hand??