Fix slew rate calculations

[chaithyagr]

We have a minor bug in slew calculation, where we don't report the first slew we would observe. For now if we need constant 0.1T/m gradient, we report slew to always be 0. But in reality we could have 0.1T/m/10us of slew in the beginning and the end of the trajectory as the gradients start and end at zero

This will make our checks more robust. Also this issue has a wide implication that majority of our trajectory implementations don't account for this causing large slew violations.

[paquiteau]

I think it's a side effect of right/left-side (double) differentiation, and we need better boundary condition/hypothesis (i.e. how was the gradient waveform before we started the trajectory acquisition)

[chaithyagr]

Well mostly all current scenarios the gradient is 0 before and after. Regards Chaithya G R

…

On Mon, 19 May, 2025, 6:29 pm Pierre-Antoine Comby, < ***@***.***> wrote: *paquiteau* left a comment (mind-inria/mri-nufft#264) <#264 (comment)> I think it's a side effect of right/left-side (double) differentiation, and we need better boundary condition/hypothesis (i.e. how was the gradient waveform before we started the trajectory acquisition) — Reply to this email directly, view it on GitHub <#264 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBSZM5QETGBFMHK3FJ66IL27IBFFAVCNFSM6AAAAAB5OERWWKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQOJRGYYTQMRRG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Daval-G]

What part of the code is this about ?

[paquiteau]

Well mostly all current scenarios the gradient is 0 before and after.

Even in the context of out-in trajectories ? you have to move to the edge of k-space before playing the shot...

[chaithyagr]

Yup, the sequence always plays a pre-phasing gradient, which is trapezoidal which results in G=0 at the end of it.
It can be sub-optimal especially if we want to save time, where we can technically continue from the last gradient value, but that makes changes to the sequences also, I would prefer to keep things simple for now and just go with how most of current implementations are.

[chaithyagr]

What part of the code is this about ?

I think Yacine found this major bug so I am letting him make the PR, hopefully today

[Daval-G]

I would prefer to keep things simple for now and just go with how most of current implementations are.

I would suggest a discussion here, there are much simpler solutions

I think Yacine found this major bug so I am letting him make the PR, hopefully today

Could you answer my question prior to the MR ?

[Daval-G]

To summarize our call with @chaithyagr and @paquiteau, we need to add extra steps in MRI-NUFFT to avoid touching the trajectories during the readouts, but start slightly earlier to accelerate from |G|=0 and after the trajectory to reach |G|=0 and discard those extra points after. That is proposed because it is currently more challenging to encode that in our usual sequences than here.

Back to this issue, the observed problem is about mrinufft.trajectories.utils.convert_gradients_to_slew_rates where some people assume that trajectories are defined with starting |G| = 0, and therefore they expect an extra gradient point at the beginning to go from |G|=0 to the initial gradient strength. It also technically assumes that those functions are to be applied over whole trajectories only, and with our current specific way of handling sequences.

However those public functions are for the generic purpose of manipulating trajectory derivatives, potentially re-integrating them back, over chunks only if needed, maybe for checking constraints but not necessarily. That's up to the user and that's why those are public and not private functions.

If the user really wants to assume that prior to the trajectory |G| = 0, they can just make it true by duplicating the first point of the trajectory and call those functions without changing them internally.

TL;DR: instead of changing the function to fit one usage, just call the function in a way that fit that usage

[Daval-G]

Where in the code do we want to do that btw ? Let's fix that check where it is needed