magneticresonanceimaging / blochsim.jl Goto Github PK

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

There are both method ambiguities and unbound arguments.

@JuliaRegistrator register

The rotatetheta function seems to give different results from the formula on Brian Hargreaves site. I may be too ignorant to know what the difference is, but I can't figure it out.

Is there a reference for the formulas used in rotatetheta! ?
https://github.com/StevenWhitaker/BlochSim.jl/blob/c67624e03f3422cb3157bc6dce20e0d4d48f6c7b/src/excite.jl#L153

@JuliaRegistrator register

@JuliaRegistrator register

@JuliaRegistrator register

@JuliaRegistrator register

@JuliaRegistrator register

We call it a "magnetization vector" but spin.M currently is not very Vector like.
The following methods help. Perhaps making it a subtype of AbstractVector would help even more...

Base.length(::Magnetization) = 3
Base.ndims(::Magnetization) = 1
Base.getindex(M::Magnetization, i) = i == 1 ? M.x : i == 2 ? M.y : i == 3 ? M.z : throw("bad index $i")
Base.iterate(M::Magnetization, i = 1) = i > 3 ? nothing : (M[i], i + 1)
Base.:*(a::Number, M::Magnetization) = Magnetization(M.x * a, M.y * a, M.z * a)

@JuliaRegistrator register

@JuliaRegistrator register

It is OK that SpinMC expects τ but stores r internally, but this makes it hard to make a copy of one of those and change something other than r.

There could be an inner constructor that takes r directly, and an outer convenience constructor that lets the user use τ.

Or there should be a method that recreates the original τ from spin.r, to use to construct a new SpinMC.

@JuliaRegistrator register

In the long run, it could be useful to have a subtype of AbstractSpin for semi-solid pools where T2 is essentially 0 so all that is needed is the z-component, i.e., x and y components are wired to 0.
Inspired by:
http://doi.org/10.1002/nbm.3237
and
https://www.cest-sources.org/doku.php?id=bm_sim_fit

@JuliaRegistrator register

Julia is especially optimized for tuples (I've read), so I wonder if it would be more efficient for Position and Gradient to be aliases for NTuple{3,T} instead of custom structs. Did you ever try that?