Magnus-based methods, RF reference frame, and block splitting

[cncastillo]

Fixes #583, instead of using sim_params["Nblocks"] (removed) a new variable sim_params["max_block_length"] is used to better control block size.

Before, if you had a block with 11 time points and wanted to devide it into 3 blocks you would get:

1:4, 5:8, 9:11

Now you define max_block_length = 5 and get:

1:5, 6:10, 11:11

Maximixing per-block GPU usage.

This block-size limit should only be relevant for precession blocks. If you want to split RF blocks (more kernel calls), use sim_params["max_rf_block_length"].

Another change is that the precense of an RF now is done by abs.(seqd.B1) > 0.0 instead of a very small number, like 1e-9.

• Update CPU-based methods
  • BlochCPU
  • BlochSimple
  • BlochDict
• Update GPU-based methods
  • BlochGPU
  • BlochSimple
  • BlochDict

---

As the fix of this bug was related to some issues with time-stepping, I also implemented a new experimental Magnus-based method that takes advantage of having the information of the current and next time point.

Right now, this is only compatible with CPU-based simulations, and there are some issues that need to be fixed.

If you want to try this PR:

Install this PR

pkg> add https://github.com/JuliaHealth/KomaMRI.jl:KomaMRIBase#fix-sim-block-issue
pkg> add https://github.com/JuliaHealth/KomaMRI.jl:KomaMRICore#fix-sim-block-issue
pkg> add KomaMRI

[Tooine]

Thank you for the bug investigation @cncastillo!

I do not understand what was the problem with the use of sim_params["Nblocks"] regarding #583. Could you briefly explain? In your example, why is it better to get 1:5, 6:10, 11:11 instead of 1:4, 5:8, 9:11? Thanks!

[cncastillo]

Hi, I'm not really sure if this is a fix yet, I think the problem is related to some blocks having length 1 - 2. The way blocks were split before was kind of random (the position in the arrays where things were split). Now, most blocks will use the max GPU group size, and GPU memory usage is easier to control (by changing this new param). So it was a change I wanted to do anyway.

We can still have length 1 - 2 blocks, so I need check this further. I also saw a similar error for block_length of 2. I restricted it to be set to values more than 5, but it will probably change.

[codecov]

Codecov Report

❌ Patch coverage is 96.07143% with 11 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.91%. Comparing base (2cd4411) to head (d5b57b0).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
KomaMRICore/src/simulation/SimulatorCore.jl	92.59%	4 Missing ⚠️
...re/src/simulation/SimMethods/Bloch/gpu/BlochGPU.jl	0.00%	3 Missing ⚠️
KomaMRIPlots/src/ui/DisplayFunctions.jl	89.65%	3 Missing ⚠️
...e/src/simulation/SimMethods/BlochDict/BlochDict.jl	92.30%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #612      +/-   ##
==========================================
- Coverage   89.85%   88.91%   -0.94%     
==========================================
  Files          70       74       +4     
  Lines        4966     5115     +149     
==========================================
+ Hits         4462     4548      +86     
- Misses        504      567      +63     

Flag	Coverage Δ
base	86.89% <100.00%> (+0.26%)	⬆️
core	80.95% <96.11%> (-7.82%)	⬇️
files	95.04% <100.00%> (+0.02%)	⬆️
komamri	88.23% <100.00%> (+0.09%)	⬆️
plots	90.88% <89.65%> (-0.12%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
KomaMRIBase/src/datatypes/Sequence.jl	91.07% <100.00%> (+0.05%)	⬆️
...IBase/src/datatypes/simulation/DiscreteSequence.jl	93.10% <100.00%> (-6.90%)	⬇️
KomaMRIBase/src/timing/KeyValuesCalculation.jl	87.17% <100.00%> (+3.05%)	⬆️
KomaMRIBase/src/timing/TimeStepCalculation.jl	100.00% <100.00%> (ø)
KomaMRICore/src/KomaMRICore.jl	100.00% <100.00%> (ø)
KomaMRICore/src/callbacks/Callback.jl	100.00% <100.00%> (ø)
KomaMRICore/src/callbacks/progress_callback.jl	100.00% <100.00%> (ø)
...re/src/simulation/SimMethods/Bloch/cpu/BlochCPU.jl	100.00% <100.00%> (ø)
...ation/SimMethods/BlochMagnus/cpu/BlochMagnusCPU.jl	100.00% <100.00%> (ø)
...c/simulation/SimMethods/BlochSimple/BlochSimple.jl	100.00% <100.00%> (ø)
... and 9 more

... and 8 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

KomaMRI Benchmarks

Details

Benchmark suite	Current: 95f41ee	Previous: 8b62195	Ratio
MRI Lab/Bloch/CPU/2 thread(s)	343531668 ns	328508190 ns	1.05
MRI Lab/Bloch/CPU/4 thread(s)	276532377 ns	225624482 ns	1.23
MRI Lab/Bloch/CPU/8 thread(s)	150655666 ns	163355495 ns	0.92
MRI Lab/Bloch/CPU/1 thread(s)	556857950.5 ns	548280455 ns	1.02
MRI Lab/Bloch/GPU/CUDA	22142265 ns	22724945 ns	0.97
MRI Lab/Bloch/GPU/oneAPI	75084170 ns	77230670 ns	0.97
MRI Lab/Bloch/GPU/Metal	89922270.5 ns	96602916.5 ns	0.93
MRI Lab/Bloch/GPU/AMDGPU	20495279 ns	22289157 ns	0.92
Slice Selection 3D/Bloch/CPU/2 thread(s)	1558788300 ns	1558872240 ns	1.00
Slice Selection 3D/Bloch/CPU/4 thread(s)	898089106 ns	859609769 ns	1.04
Slice Selection 3D/Bloch/CPU/8 thread(s)	652087225 ns	522488232.5 ns	1.25
Slice Selection 3D/Bloch/CPU/1 thread(s)	2984269895 ns	3010268970 ns	0.99
Slice Selection 3D/Bloch/GPU/CUDA	34803377 ns	32524226 ns	1.07
Slice Selection 3D/Bloch/GPU/oneAPI	136108698.5 ns	123943367 ns	1.10
Slice Selection 3D/Bloch/GPU/Metal	143251417 ns	116308437.5 ns	1.23
Slice Selection 3D/Bloch/GPU/AMDGPU	35018165.5 ns	31118611 ns	1.13

This comment was automatically generated by workflow using github-action-benchmark.