Hard coded values for sampling and gradient dwell time in sync_traj_and_data! function

[aTrotier]

Hi,
First of all great work!
I am trying to apply it to a pulseq spiral and I am taking a look at the package.

Is that normal to have hard-coded values in the sync_traj_and_data! function

GIRFReco.jl/src/utils/utils.jl

Line 209 in 34c9f0f

dt_s = 2 * 10^(-6) # [s]

Thanks

[alexjaffray]

Thanks @aTrotier for picking that up, definitely it is not normal to have hard-coded values, it would be ideal to have the user be able to pass in parameters for the dwell times for their trajectory and data. I will work on a feature branch with the change, I think it should be straightforward.

[nbwuzhe]

Hi, First of all great work! I am trying to apply it to a pulseq spiral and I am taking a look at the package.

Is that normal to have hard-coded values in the sync_traj_and_data! function

GIRFReco.jl/src/utils/utils.jl

Line 209 in 34c9f0f

dt_s = 2 * 10^(-6) # [s]

Thanks

Thank you @aTrotier for bringing this up. Do you know whether this dwell time is included somewhere in the MRD header? It would be ideal to have it passed automatically.

[aTrotier]

The dwell time is available in each profiles in the MRD format (RawAcquisitionData) according to : https://ismrmrd.readthedocs.io/en/stable/mrd_raw_data.html

raw_temp.profiles[1].head.sample_time_us

But weirdly It gives me 3.3 for your spiral datasets.

[aTrotier]

You also have other hard coded value in another function :

GIRFReco.jl/src/utils/utils.jl

Line 257 in 34c9f0f

dt_s = 2 * 10^(-6) # [s]

[alexjaffray]

@aTrotier the 3.3 us dwell time in the ismrmrd header comes from the fact that the Siemens .dat to .mrd converter creates an incorrect header entry

[aTrotier]

Ok, in my case my conversion from pulseq to mrd seems to work correctly. I can share my xsl/xml parameters maps if you need it.

[alexjaffray]

Glad to hear that your Pulseq conversion to mrd is correct, we don't use Pulseq to program the spiral. @nbwuzhe can you comment on if the inaccurate MRD header is still an issue with current versions of our spiral implementations? Or would we be able to start trusting the header parameters in the mrd file?

[nbwuzhe]

Hi @aTrotier @alexjaffray
Sorry for the late response. This discrepancy in ADC dwell time is because we manually adjusted the ADC sampling rate, while the header was calculated from the given UI values (Base Resolution in unit of px, and Bandwidth in unit of Hz/px), which were not adopted in the actual acquisition. The conversion in SIEMENS_TO_ISMRMRD is correct.

I can correct this UI issue in the next version of the sequence.

Best regards,

Tim