There appears to be a bug when merging analysis in mrTools. Here's one scenario that one can create the (undesired) result: 1) generate two scans in a group; 2) using the GUI, run one event-related analysis on the first scan; 3) again using the GUI, run another event-related analysis on the second scan. When prompted at the end, choose "Merge". This will save to disk the analysis. However, when inspecting the saved results, you will see that two fields are packed in the reverse order. Assuming you use the default name erAnal, then check erAnal.params.scanNum, and erAnal.params.tseriesFile, and you will find these fields are in a reverse order (i.e., scanNum=[2 1]). However, other structures in the erAnal, e.g., erAnal.params.scanParams, erAnal.d are packed in the normal order. This will cause some problem if one access those fields packed in the reverse order. Hope this can be fixed soonish.
In the mean time, one probably should not rely on the Merge functionality (I only tested this with event-related analysis so do not know how this behaves using other analyses). One possible work around is to always conduct the multiple analysis in a single shot (i.e., do step 1 and 2 together). MLR can handle different parameter settings for different scans, if needed. Just uncheck the box that says using the same setting for all scans (in the event-related analysis interface, at least).
Thank you for looking into this.
There appears to be a bug when merging analysis in mrTools. Here's one scenario that one can create the (undesired) result: 1) generate two scans in a group; 2) using the GUI, run one event-related analysis on the first scan; 3) again using the GUI, run another event-related analysis on the second scan. When prompted at the end, choose "Merge". This will save to disk the analysis. However, when inspecting the saved results, you will see that two fields are packed in the reverse order. Assuming you use the default name erAnal, then check erAnal.params.scanNum, and erAnal.params.tseriesFile, and you will find these fields are in a reverse order (i.e., scanNum=[2 1]). However, other structures in the erAnal, e.g., erAnal.params.scanParams, erAnal.d are packed in the normal order. This will cause some problem if one access those fields packed in the reverse order. Hope this can be fixed soonish.
In the mean time, one probably should not rely on the Merge functionality (I only tested this with event-related analysis so do not know how this behaves using other analyses). One possible work around is to always conduct the multiple analysis in a single shot (i.e., do step 1 and 2 together). MLR can handle different parameter settings for different scans, if needed. Just uncheck the box that says using the same setting for all scans (in the event-related analysis interface, at least).
Thank you for looking into this.