general-discussion > Restart a stage
Showing 1-7 of 7 posts
Results per page:
Apr 8, 2011  07:04 AM | Kevin Larcher
Restart a stage
Hi everyone,
Is there way to reset the pipeline from a specific stage ?

Apr 8, 2011  09:04 AM | Pierre Bellec
RE: Restart a stage
Dear Kevin,

If you want to restart the stage callled NAME_STAGE, use the following option :

opt.psom.restart = {'NAME_STAGE'};

Note that any stage that contains the string NAME_STAGE will be restarted. So :

opt.psom.restart = {'motion_Wrun_subject1_session1_run1'}

will restart only one job, while

opt.psom.restart = {'motion_Wrun_subject1'}

will restart all within-run motion correction jobs for subject 1, and

opt.psom.restart = {'motion_Wrun'}

will restart all within-run motion correction jobs for every subjects.

Just in case, I am going to explain how to use that to solve a specific issue. Say the T1-fMRI coregistration has done a really poor job, and you came up with a manual transformation. You can replace the trasnformation estimated by anat2func by overwritting the following file (found in anat/subject1/) :


Then you restart the jobs that come after the anat2func :

opt.psom.restart = {'mask_ind_stereolin_subject1','concat_transf_nl_subject1'};

Note that this trick will only work if "size_output" is all . Otherwise the pipeline is going to re-run most of the pipeline for subject1 (because the intermediate outputs have been cleaned up), including the anat2func. In this case I'd recommend to run the pipeline with the 'all' size ouptut only for subject1 in a separate folder than the rest of the subjects of the study.

In the future I want to develop simpler ways to implement semi-automated pipeline execution, but right now that's the best way to do it.

I hope this helps, 

Apr 11, 2011  08:04 AM | Kevin Larcher
RE: Restart a stage
Hi Pierre,
Thanks a lot. I am sorry for replying so late.
You gave more explanations than I expected about using other transformations estimated for the T1-fMRI coregistration (great). However, I have 2 runs for each subject. In this case, how the frmi data are coregistered onto the structural image ? Does niak coregister T1 onto run1 first, then run1 onto run2 ? How can I reset the coregistration stage for the both runs ?
Finally, how to display the dependences between the stages, in order to select the one need to be restarted ?

Apr 11, 2011  11:04 AM | Kevin Larcher
RE: Restart a stage
I actually realized that the dependencies can be looked by loading the file "deps" in the log directory.
Apr 11, 2011  07:04 PM | Pierre Bellec
RE: Restart a stage
Hi Kevin,

You can have a look at the graph of dependencies using the command PSOM_VISU_DEPENDENCIES

You need to generate the pipeline structure first :

>> opt.flag_test = true;
>> pipeline = niak_fmri_preprocess(files_in,opt)
>> psom_visu_dependencies(pipeline)

However, for your problem I think there is a simpler solution. Change the initial transformation of the anat2func job :

>> pipeline.anat2func_subject1.files_in.transformation_init = '/path_data/my_transf_stereolin2func.xfm';

There is a flag to invert this transformation, which by default is true and you may want to turn false :

>> pipeline.anat2func_subject1.opt.flag_invert_transf_init = true;

If the initial transform is good, the algo should converge in the right place. Also, please be aware that this transformation needs to go from the T1 image *in stereotaxic space* (after linear transform) to the functional native space. 

Have a nice data preprocessing,

Apr 13, 2011  08:04 AM | Kevin Larcher
RE: Restart a stage
Hi Pierre,
Thanks for explaining how to display the dependences graph.
However, I don't know how the functional images are coregisted to the structural image, in particular if there are 2 (or more) runs for each subject. Actually, I added the flags to include an initial transformation and to restart the stages, the coregistration is improved only on the first run, but the issue is still there for the others runs.

Apr 13, 2011  08:04 AM | Pierre Bellec
RE: Restart a stage
Hi Kevin,

The coregistration T1-EPI is done on the average of all functional sessions/runs, after correction for motion correction. So the same transformation applies to all run. If one run is better coregistered than others, that means that it is actually the motion correction that did not work properly. You can have a look at the folder quality_control//motion_correction . The file tab_coregister_motion.csv contains some info about the between-runs motion correction. The only time I've seen that step fail, the investigator had actually mixed up the datasets from two different subjects. If you actually found that that the datasets are correct and this step failed, please send me an email with the location of the database so I can have an in-depth look at it, I'd be really interested in understanding what went wrong.