Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimize ArbitraryMotion (continuation) #408

Merged
merged 115 commits into from
Jun 27, 2024
Merged

Conversation

pvillacorta
Copy link
Collaborator

Continuation of #396

This was referenced Jun 14, 2024
Copy link
Member

@cncastillo cncastillo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, please add the changes introduced by @rkierulf (currently in dev).

The SimpleMotion is having some weird issues with Metal, so we are skipping those tests (not sure if this is already in dev).

If this is not solved we should remove the simple motion example, as tutorials should work everywhere.

Copy link

codecov bot commented Jun 15, 2024

Codecov Report

Attention: Patch coverage is 89.22156% with 18 lines in your changes missing coverage. Please review.

Project coverage is 90.45%. Comparing base (56fcedc) to head (5dcc8b8).

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #408      +/-   ##
==========================================
+ Coverage   89.19%   90.45%   +1.26%     
==========================================
  Files          49       51       +2     
  Lines        2803     2796       -7     
==========================================
+ Hits         2500     2529      +29     
+ Misses        303      267      -36     
Flag Coverage Δ
base 88.02% <87.94%> (+1.60%) ⬆️
core 90.37% <ø> (+4.69%) ⬆️
files 93.55% <100.00%> (-0.15%) ⬇️
komamri 93.98% <ø> (ø)
plots 89.30% <80.00%> (+0.03%) ⬆️

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

Files Coverage Δ
KomaMRIBase/src/KomaMRIBase.jl 100.00% <ø> (ø)
KomaMRIBase/src/datatypes/Phantom.jl 85.10% <100.00%> (+0.24%) ⬆️
...maMRIBase/src/datatypes/phantom/motion/NoMotion.jl 70.00% <100.00%> (-7.78%) ⬇️
...datatypes/phantom/motion/simplemotion/HeartBeat.jl 93.54% <100.00%> (+0.69%) ⬆️
...s/phantom/motion/simplemotion/PeriodicHeartBeat.jl 93.54% <100.00%> (+93.54%) ⬆️
...es/phantom/motion/simplemotion/PeriodicRotation.jl 91.66% <100.00%> (+1.19%) ⬆️
...phantom/motion/simplemotion/PeriodicTranslation.jl 85.71% <100.00%> (+3.89%) ⬆️
.../datatypes/phantom/motion/simplemotion/Rotation.jl 91.66% <100.00%> (+1.19%) ⬆️
...tatypes/phantom/motion/simplemotion/Translation.jl 85.71% <100.00%> (+3.89%) ⬆️
KomaMRIBase/src/timing/UnitTime.jl 100.00% <100.00%> (ø)
... and 10 more

@pvillacorta
Copy link
Collaborator Author

I have just included the changes by @rkierulf in #406. I have removed adapts for ArbitraryMotion and NoMotion, but I did nothing to SimpleMotion, so these problems with Metal would still remain. I do not know a way of solving this, and I cannot test it since an Apple computer is needed, right?
Cheers

KomaMRIBase/src/KomaMRIBase.jl Outdated Show resolved Hide resolved
KomaMRIBase/src/KomaMRIBase.jl Outdated Show resolved Hide resolved
@cncastillo
Copy link
Member

Related #407.

@cncastillo
Copy link
Member

cncastillo commented Jun 25, 2024

I will ask about these "bugs" in a Interpolations.jl issue

Can you point to the issue when you submit it?

I think it is a reasonable solution if we don't use ranges and the performance is not impacted.

At this point, I think it will be faster to look for other options like https://docs.sciml.ai/DataInterpolations/dev/#DataInterpolations.jl than fixing all the bugs with Interpolations.jl. This package also accepts non-uniformly sampled data. As the interface is simpler it would be easier to debug. But also has some problems evaluating GPU arrays.

I wonder if just implementing this ourselves with KernelAbstractions.jl, just for linear interpolations, is better (like we discussed some time ago).

image

Hopefully, we will find an easy solution to this (even better if Interpolations.jl works).

@pvillacorta
Copy link
Collaborator Author

pvillacorta commented Jun 26, 2024

I did a lot of commits in order to get the simplest reproducible code that gives the error that we have.

Can you point to the issue when you submit it?

See JuliaMath/Interpolations.jl#597.

Last commit leaves everything like it was before:

  • ArbitraryMotion with vectors (it works)
  • The test error that, in fact, does not only affect simplemotion, but also arbitrary:
Bloch SimpleMotion: Test Failed at /Users/julia/.julia/scratchspaces/a66863c6-20e8-4ff4-8a62-49f30b1f605e/agent-cache/default-macmini-aarch64-4.0/build/default-macmini-aarch64-4-0/julialang/komamri-dot-jl/KomaMRICore/test/runtests.jl:308
  Expression: NMRSE(sig, sig_jemris) < 1
   Evaluated: 146.28461709358785 < 1
Bloch ArbitraryMotion: Test Failed at /Users/julia/.julia/scratchspaces/a66863c6-20e8-4ff4-8a62-49f30b1f605e/agent-cache/default-macmini-aarch64-4.0/build/default-macmini-aarch64-4-0/julialang/komamri-dot-jl/KomaMRICore/test/runtests.jl:328
  Expression: NMRSE(sig, sig_jemris) < 1
   Evaluated: 146.28461709358785 < 1 

But, even with this error, I would merge this PR soon anyway, since simulation speed for ArbitraryMotion, compared to master, has been significantly increased:
0.149650 seconds (136.50 k allocations: 4.911 MiB, 2.40% gc time) (This is for the code in #396 (comment))

We have also solved the errors with view and some typos in the docstrings.

In the meantime, I am still investigating the reason for the error in the test and looking for better solutions for the interpolation.
Cheers

Copy link
Member

@cncastillo cncastillo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor comments before merging.

KomaMRICore/test/runtests.jl Outdated Show resolved Hide resolved
KomaMRICore/src/simulation/Functors.jl Show resolved Hide resolved
KomaMRIBase/test/runtests.jl Outdated Show resolved Hide resolved
Comment on lines +106 to +107
id = similar(motion.dx, Ns); copyto!(id, collect(range(oneunit(T), T(Ns), Ns)))
t = similar(motion.dx, Nt); copyto!(t, collect(range(zero(T), oneunit(T), Nt)))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
id = similar(motion.dx, Ns); copyto!(id, collect(range(oneunit(T), T(Ns), Ns)))
t = similar(motion.dx, Nt); copyto!(t, collect(range(zero(T), oneunit(T), Nt)))
id = similar(motion.dx, Ns); id .= range(oneunit(T), T(Ns), Ns)
t = similar(motion.dx, Nt); t .= range(zero(T), oneunit(T), Nt)

Is id .= 1:Ns not enough?
Are the copyto!(collect( necessary? They are a little bit ugly.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like metal and oneAPI don't have this operation defined for ranges or something like that.
When assigning wit =. and a range, the following error appears (see this):

ERROR: LoadError: InvalidIRError: compiling MethodInstance for (::Metal.var"#broadcast_linear#202")(::Metal.MtlDeviceVector{Float32, 1}, ::Base.Broadcast.Broadcasted{Metal.MtlArrayStyle{1, Metal.MTL.Private}, Tuple{Base.OneTo{Int64}}, typeof(identity), Tuple{Base.Broadcast.Extruded{StepRangeLen{Float32, Float64, Float64, Int64}, Tuple{Bool}, Tuple{Int64}}}}) resulted in invalid LLVM IR

From here, it looks like =. is defined for assigning scalars, but I think it's not the case for ranges.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I think submitting a few issues to Metal/OneAPI would be good. I don't know what the MWE is, @rkierulf says these work

julia> using Metal

julia> A = ones(Float32, 4)
4-element Vector{Float32}:
 1.0
 1.0
 1.0
 1.0

julia> B = convert(MtlArray,A)
4-element MtlVector{Float32, Private}:
 1.0
 1.0
 1.0
 1.0

julia> B .= range(1,4) # Error 1: id .= range(oneunit(T), T(Ns), Ns)
4-element MtlVector{Float32, Private}:
 1.0
 2.0
 3.0
 4.0

julia> B .+ B' # Error 2: xt, yt, zt = x .+ 0*t, y .+ 0*t, z .+ 0*t
4×4 MtlMatrix{Float32, Private}:
 2.0  3.0  4.0  5.0
 3.0  4.0  5.0  6.0
 4.0  5.0  6.0  7.0
 5.0  6.0  7.0  8.0
  • Error 1: id .= range(oneunit(T), T(Ns), Ns)
  • Error 2: xt, yt, zt = x .+ 0*t, y .+ 0*t, z .+ 0*t

@pvillacorta
Copy link
Collaborator Author

pvillacorta commented Jun 27, 2024

I think all the comments are solved.
Things to do for the next PR:

@cncastillo cncastillo merged commit 3128e9f into master Jun 27, 2024
18 checks passed
@cncastillo cncastillo deleted the optimize-arbitrary-view branch June 27, 2024 23:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Re-use weights in interpolation for ArbitraryMotion Simplify ArbitraryMotion struct
3 participants