Open mzaiss opened 1 year ago
hotfix in pulseq library by more digits but should be reimplemented using gamma_hz
Hi,
I noticed two things using the pulseqCEST toolbox with low B1rms. For a one pool system using only water, the water peak is asymmetric when the Z-spectrum is being shifted by B0. This varies by varying precision of gamma in the .yaml files. This behavior can be also observed when a glucose and MTC pool is being added. With this also the water peak is asymmetric without shifting. I added some slides illustrating asymmetric behavior, as well as the code including the sequence and .yaml files.
Attached presentation: github_issue#22.pdf
Hi @PatrickatMRI,
Moritz forwarded me your mail and I already investigated the Issue. We are 99.9% that we found the "error":
the precision of the RF frequency offset in the pulseq files is just 3 digits in Hertz. For the simulated inhomogeneity in pulseq-cest/bmctool, we use the gamma value from the yaml file and use the full precision of float values. This means that for some offsets, the actual shift is slightly larger than the nominal shift, for others its slightly smaller.
I just tried to adjust the precision of the calculation in the simulation and it changes the results.
I am busy now, but will keep you updated!
yes, rounding in the seq file changes you actuall ppm value. you can try to recalculate ppm value from the freqs given in each pulse. then use this as a shift.
Patrick Schuenke @.***> schrieb am Di., 14. Nov. 2023, 16:36:
Hi @PatrickatMRI https://github.com/PatrickatMRI,
Moritz forwarded me your mail and I already investigated the Issue. We are 99.9% that we found the "error":
the precision of the RF frequency offset in the pulseq files is just 3 digits in Hertz. For the simulated inhomogeneity in pulseq-cest/bmctool, we use the gamma value from the yaml file and use the full precision of float values. This means that for some offsets, the actual shift is slightly larger than the nominal shift, for others its slightly smaller.
I just tried to adjust the precision of the calculation in the simulation and it changes the results.
I am busy now, but will keep you updated!
— Reply to this email directly, view it on GitHub https://github.com/kherz/pulseq-cest/issues/22#issuecomment-1810472473, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB7RKGUDDILKIBNUFAK3563YEOFXPAVCNFSM6AAAAAA62ZT6HGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJQGQ3TENBXGM . You are receiving this because you authored the thread.Message ID: @.***>
yes, rounding in the seq file changes you actuall ppm value. you can try to recalculate ppm value from the freqs given in each pulse. then use this as a shift.
I calculated the real ppm values and added them in the google spreadsheet that I used to collect the data. You find the values in column "L" in this spreadsheet
Could you share a script on how to do this recalculation of the ppm values in pulseq, when using b0_inhom in the .yaml file?
i think you can calc you ppm values to hz using freq, them round to 4 digits, and then go back to ppm. right Patrick S.?
PatrickatMRI @.***> schrieb am Sa., 18. Nov. 2023, 12:45:
Could you share a script on how to do this recalculation of the ppm values in pulseq, when using b0_inhom in the .yaml file?
— Reply to this email directly, view it on GitHub https://github.com/kherz/pulseq-cest/issues/22#issuecomment-1817486525, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB7RKGQQ5NFRDK35FQYLRELYFCNVNAVCNFSM6AAAAAA62ZT6HGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJXGQ4DMNJSGU . You are receiving this because you authored the thread.Message ID: @.***>
I work completely in Python (using PyPulseq 1.40 from GitHub), but similar code should work in MATLAB as well.
First, I extracted the actual frequency offsets used in pulseq (seq is (Py)Pulseq Sequence object):
offsets_hz = []
for n in range(len(seq.rf_library.data)):
offsets_hz.append(seq.rf_library.data[n + 1][5])
Than I convert the values from Hz to ppm using the definitions from the yaml file:
offsets_ppm = (
np.array(offsets)
/ params.scanner["b0"]
/ params.scanner["gamma"]
* 2
* np.pi
)
IMO, these values should NOT be rounded again, because in the simulations (both in MATLAB pulseq-cest and BMCTool in Python), we use full precision.
I am still not 100% sure if this solves the Issue completely, because positive and negative offsets should have the same absolute values, but I will continue my investigations as soon as I find the time.
267.5154109