Completed on 27 Sep 2017 by Krzysztof Jacek Gorgolewski .
Login to endorse this review.
Endorsed by 1 person.
Porcupine by van Mourik et al. is extensible cross platform desktop application that allow users to quickly design neuroimaging data workflows via a graphical user interface. Lack of graphical user interface has been a deeply needed feature for Nipype and Porcupine fills this gap.
Porcupine is designed in a very smart and flexible way allowing it to be extended to new code generation backends. Furthermore, since the output is the source code of the pipeline the processing can be customized via editing the code. Reproducibility of the produced pipelines is increased, by the generation of Dockerfiles.
It’s hard to understate this contribution since Porcupine since it will expose a large community of researchers that prefer graphical interfaces to reproducible neuroimaging pipelines.
Author response is in blue.
- The manuscript at some point mentions saving MATLAB code, but I don’t believe such plugin exists yet.
Yes, it was sloppy from our part that we released a version with this feature only a couple of days after the BioRxiv publication. It's on there now and produces MATLAB code for my own (laminar) fMRI toolbox, https://github.com/TimVanMourik/OpenFmriAnalysis. We are indeed a bit vague about this part, and need to clear this up in the manuscript.
- It might be worth mentioning NIAK as potential output plugin.
I was not aware of this and will look into it straight away. Thanks for the suggestion.
- In context of computational clusters it might be worth clarifying that Docker images can be run via singularity.
As our work doesn't touch on singularity straight away, we initially did not feel the need to mention. But it might indeed be a good addition, for example in relation to the BIDS app.
- “Nypipe” -> “Nipype”
- It’s unclear why the user is required to make modifications to the output Dockerfile – it seems that it should be possible to generate a complete Dockerfile without a need for any modifications.
Well, a Docker file is built from the ground up, by referring to online or on-disk resources. As the generated code is neither, we felt the need to explicitly mention this as a modification to the Docker file. The alternative would be not to make changes to the Docker file, but forcing the user to save it with a certain file name. We did decide to move the explanation to the appendix, as the details are not necessary for the main text.
- “It should be noted that Porcupine is not meant for low-level functionality, such as file handling and direct data operations.” What does that mean? Could you give an example?
Yes, that's a poor description, thanks for pointing out. The distinction between low and high level functionality is more a practical one without there being a fundamental conceptual difference. We're going to think about this line a bit better.
- In context of graphical workflow systems: did you mean JIST instead of CBS Tools?
Right, the JIST part is indeed the pipeline environment, CBS Tools the MRI analysis toolbox from Pierre-Louis Bazin et al. Thanks for pointing this out.
- “providing a direct way of creating this is high on the feature list of Porcupine” –> “planned features list”?
We'll revise the wording.
- The license under which Porcupine is distributed is not listed in the manuscript
That's indeed an important point that we'll add this to the manuscript.