Hi all,
To what extent is it ok to use data that was preprocessed with RC_3 and then run the tracking with the latest version of MRTrix?
I know that moving between versions is a bad idea (especially since the latest RC had some significant changes). But do you recommend that we re-preprocess the data if we want to use a feature from the latest rolling release on GitHub?
Claude
That depends what you mean by the latest version. RC3 is the latest release, and anything that’s been committed to the master branch since then will consist only of bug fixes. We reserve anything that changes behaviour for the dev branch – that’s the code that will eventually become the next release. So I don’t think there would be any issue upgrading to the latest master. But things may have changed on dev…
Incidentally, what feature are you after? I’d be surprised to find new features on master that weren’t already in RC3…?
Thanks, that answers it. I was not looking for a feature per se, was just thinking about installing MRtrix on a new machine for a student to run some tractography and was wondering wheather I had to use the same commit that the preprocessing was done with or if the latest master would be fine.
However, there was a feature that I had discussed a while back with Rob that made the amp2response faster for HCP data that is on the dev branch (it was taking much too long with the current - or the then current master branch) so I had no option but to use the dev branch for the response function (and carried through to the CSD generation). I am hoping that there wasn’t any major issues there that invalidates the work! (I doubt it though since I had done a few tests before I ran it and the results looked very similar).
This fix is now in the master branch but wasn’t when I was doing my analysis (and it is too big to just redo unless there is an extremely good reason)
@rsmith may be in a better position to confirm, but as far as I’m aware, that fix was a pure performance enhancement, with no detectable difference in output – at least that’s what the corresponding discussion suggests…
@rsmith may be in a better position to confirm, but as far as I’m aware, that fix was a pure performance enhancement, with no detectable difference in output
That’s not typically the sort of thing that would get pushed to master, but in this case we made an exception since the performance difference was so large with no difference in outcomes.
Whenever anyone moves to a branch such as dev in order to access a new feature, there is a chance that that branch will also contain changes elsewhere in the software that may affect outcomes. However the myriad tools within git are all applicable here. There’s always a way to get your hands on whatever version / features you want (e.g. effectively master but including some change or new feature); it all depends on exactly what you need.