epfid2d1_60 (base resolution 60) does not work on R016

[eshoko]

Hi,

After updating to R016 Prisma (VD13D) a base resolution lower than 64 is not supported on Multi-Band and Multi-Band Multi-Echo sequences.

Here are the original parameters before upgrade:

sequence name: epfid2d1_60 (converted to epfid2d1_128) MB Factor: 4 TR: 385 ms Echo Time: 30 ms Flip Angle: 40 Base Resolution: 60 Bandwidth: 2380 Phase Encoding Steps: 53 Echo Train Length: 53 Percent field of view: 100% FOV: 192 Slice Thickness: 3.9 mm Number of Slices: 32

The same issue exist for epfid 2d3_60 sequence.

Any insight would be really appreciated.

Thanks!

[eauerbach]

Unfortunately this was the cause of #175: the Siemens UI is unstable if the base resolution is allowed to be less than 64, and several users were noticing that it was changing the phase FOV % in their protocols silently without their knowledge. In discussions internally and with outside users we decided that it was critical to fix that bug, and it seemed extremely unlikely that anyone was actually using readouts of less than 64 points... So we changed the minimum base resolution from the previous unstable value of 32 to 64 (same as the product).

I'm sorry this wasn't made clear in the release notes. I can look again to see if there is a workaround. Maybe it is possible to lower it just a bit to 60 without causing the error condition, or maybe another option can be made available.

[eshoko]

Thank you very much for clarifying the cause. I hope that there would be at least a short term solution. We did benefit in tSNR from the larger voxel dimensions offered by a lower base resolution, particularly in the subcortical areas. For your reference, we have primarily two sequences that are affected by this, with base resolutions of 60 and 38.

Many thanks for looking into this.

[BenInglis]

Hi Neuroscan, it's not identical, but have you considered using partial Fourier of 7/8ths, then setting the flag that discards late lines of k-space to get the time saving in TR? This should put all temporal parameters close to your prior settings, while the intrinsic smoothing produced by zero-filling the omitted k-space will net you higher SNR. These aren't specific to SMS but the principles will hold:

https://practicalfmri.blogspot.com/2013/08/the-experimental-consequences-of-using.html

https://practicalfmri.blogspot.com/2013/12/using-partial-fourier-epi-for-fmri.html

[eshoko]

Hi Ben, Thank you for the helpful suggestion and links. Sorry I did not clarify before but we have been using partial Fourier of 7/8ths. Do you suggest using lower values? It is definitely an option to consider if reviving the legacy base resolution is not possible at all. Our paradigm involved 8 variants of base resolution 60 (2 multi-echo versions X 4 multi-band factors) and one variant with base resolution 38. I am afraid that changing the partial Fourier may complicate the interpretation of differences in our design.

[BenInglis]

Lower values can work, but I wonder if there's a near workaround. I think Siemens simply zero fills the omitted k-space, no conjugate recon or whatever. Right now the default for partial Fourier is to omit the early echoes, and Eddie instigated a flag to allow selection of late echoes instead. I wonder if a "both" option would work, but leave the minimum matrix at 64. A "both" with 6/8ths partial Fourier would be equivalent to the central 32 echoes. That's closer to your target.

But perhaps this also suggests another option: maintain the minimum 64 point recon but somehow allow a smaller acquired matrix, and simply zero fill the rest. It might fix your problem and leave #175 fixed at the same time.

[julfou81]

Hi,

Thank you Eddie for the clarification! I was also going to write a post about this issue, as we are using protocols with resolution of 56x56 for fMRI in preclinical studies (on monkeys) and these protocols will need to be adapted for the newer version of MB sequence. If you find a quick workaround we are also interested about it!

[eauerbach]

Well, I can offer a solution: an .ini-file parameter that you can define to specify a lower limit for the base resolution on a systemwide basis. It will bring back the phase FOV % UI bug that was "solved" by raising the limit, but you can decide whether the lower limit is more important to you than this particular bug, which actually doesn't appear for all protocols (although it does notably appear for the common HCP protocols with 104 points).

On versions prior to VE11 this bug isn't too bad (only if you explicitly reduce the phase FOV % you may not be able to set it back to 100%), which is probably why nobody noticed it. However, since VE11C at least (not sure about VE11A/B), the UI will change the phase FOV % silently even if you don't touch it.

For what version(s) would this change be most useful? VD13D?

[eshoko]

Hi Eddie, Many thanks. This solution will be useful on our VD13D. Also, thank you Ben for the insightful workaround suggestions.

[eshoko]

Hi Eddie,

I was going over the sequence directory and was not able to find any .ini-file along with the 'cmrr_mbep2d_bold.dll'. Would your solution include loading a recompiled 'cmrr_mbep2d_bold.dll' that reads the .ini-file?

[eauerbach]

Yes, this will come in a R016a update shortly (a couple other bugs to round up before it is ready).

[eshoko]

Thank you. Looking forward to it.

[eauerbach]

R016a is released; instructions for setting the ini file are on the wiki page.

[eshoko]

Thank you very much for your help with this. I appreciate it. Will let you know if we have more questions.