tool is not shimming as expected

[rpeltekov]

the tool simply does not perform the way it computes that it should be able to... shimming results are always very far off the center frequency that they show...

the center frequency is always off from what it says it should be able to achieve. the overwrite button procedure always seems to oscillate back and forth... and the results it is getting are just not satisfactory...

very useful might be to get a cli interface alongside the gui, so that you can manually make things happen that are not yet implemented in the gui....

development will be done in junction with #16

Things to try:

1. manually move the center frequency?
2. solve with and without the center frequency
3. characterize the centerfrequency adjustment maybe??? does this work as you expect it to? it is changing the cf of the whole volume but maybe not the slice that we expect?
4. maybe all the reference tests should be done based on the volume shimming???
5. lower the limit on the gradients to apply within the solution (the cap should be at 100 after application)

things to fix:

• [x] get the interactive shell to also launch alongside the gui
• [ ] the calibration sequence needs to be figured out how to move the center position
• [ ] the overwrite button needs to link with the correct "view background button sequence on the main tab"

[rpeltekov]

trying: manually move the center frequency?

now that i have the interactive shell, I am able to set the center frequency, and i was able to move it so that the mean goes essentially to zero. not exactly but almost there....

[rpeltekov]

for trying #2:

could follow what people do here: "(Calculation) Following the B0 acquisition, slice-dependent center frequency (CF) and in-plane linear shim values were calculated on the fly with B0 maps, slice locations, and shim ROI as inputs. The linear shim values were determined using the “fminsearch” function from Matlab (Mathworks, Natick, MA, USA), whereby the cost function for minimization was defined as the standard deviation of the shimmed B0 map for each slice. The intersection of the shim ROI and an image intensity mask defined a region in which the cost function was calculated. Since the shim ROI is in general not centered at the gradient isocenter, application of shim gradients tends to offset the mean resonance frequency in the ROI. This was corrected by CF adjustment. The CF for each slice was calculated as the average of the predicted, shimmed B0 distribution in the ROI. The computation of the slice-dependent center frequency and shims was done by a compiled Matlab code on the scanner host computer and took less than 5 seconds."

[rpeltekov]

for trying #2:

could follow what people do here: "(Calculation) Following the B0 acquisition, slice-dependent center frequency (CF) and in-plane linear shim values were calculated on the fly with B0 maps, slice locations, and shim ROI as inputs. The linear shim values were determined using the “fminsearch” function from Matlab (Mathworks, Natick, MA, USA), whereby the cost function for minimization was defined as the standard deviation of the shimmed B0 map for each slice. The intersection of the shim ROI and an image intensity mask defined a region in which the cost function was calculated. Since the shim ROI is in general not centered at the gradient isocenter, application of shim gradients tends to offset the mean resonance frequency in the ROI. This was corrected by CF adjustment. The CF for each slice was calculated as the average of the predicted, shimmed B0 distribution in the ROI. The computation of the slice-dependent center frequency and shims was done by a compiled Matlab code on the scanner host computer and took less than 5 seconds."

this is irrelevant to try. doing least squares as I have been doing arrives at the exact same argmin...

[rpeltekov]

did a lot of debugging work, and found that it was not the center frequency being changed that was causing the issue at hand. nor was it the z gradient. it was actually mostly the y gradient from the looks of it:

Comparing expected - applied results for GRADIENT X
Difference Statistics:
Mean:  -6.157825716572735
Std Dev:  1.9161495844826566

Comparing expected - applied results for GRADIENT Y
Difference Statistics:
Mean:  32.87884034745493
Std Dev:  39.11627657151613

 Comparing expected - applied results for GRADIENT Z
Difference Statistics:
Mean:  -5.4946215129599025
Std Dev:  2.5578813476821947

And from this you could see the phase unwrapping algorithm was adding an extra phase wrap when it was in fact not supposed to for the y gradient.

I fixed this by simply decreasing the gradient used to obtain the basis maps and then checking these matters again with the python notebook i made seemed to clear some things up...