nipype/pydra-fsl

pydra-fsl's Issues

Implement more string format parser in the converter

Need to handle:

• %g
• %f %f %f (up to obitory amount of the same format.)

Doc string not created correctly when quotation marks are present

See PR #11 interface FilterRegressor for example.

_______________________________ [doctest] fsl.utils.filterregressor.FilterRegressor _______________________________
077 
078     Example
079     -------
080     >>> task = FilterRegressor()
081     >>> task.inputs.in_file = "test.nii.gz"
082     >>> task.inputs.design_file = "design"
083     >>> task.inputs.filter_columns = "1,2,3"
084     >>> task.inputs.out_file = "test_filtered.nii.gz"
085     >>> task.cmdline
Expected:
    'fsl_regfilt -i test.nii.gz -o test_filtered.nii.gz -d design -f '1,2,3''
Got:
    "fsl_regfilt -i test.nii.gz -o test_filtered.nii.gz -d design -f '1,2,3'"

eddy cmdline choice

there are two cmdline choices in eddy, either eddy_openmp or eddy_cuda, which depend on the input use_cuda. @ghisvail, in your example here, you only used eddy. I also tried use eddy only when converting from nipyper to pydra with our converter, but it doesn't work. Do you have any ideas about how we should deal with eddy_openmp and eddy_cuda? Thank you!

CI Environments (container or conda env)

It will be useful to have a container with FSL for CI. For example, the test for Complex interface is failing, but it is running fine locally for me and Dorta. This should be a good issue to start with for more consistency.

Test data

FSL interfaces need some different type of test data, and they are not always a nifti file.
It would be useful to identify some light weight test data that already exist in nipype and migrate them here.

cc @effigies if you have a better idea.

adding readonly input fields to the input_spec

• allowing to add a completely new input fields as a part of inputs_metadata. This can be useful when complicated xor structure is required by the tool. Example would be fslroi that has three different option:

fslroi <input> <output> <xmin> <xsize> <ymin> <ysize> <zmin> <zsize>
fslroi <input> <output> <tmin> <tsize>
fslroi <input> <output> <xmin> <xsize> <ymin> <ysize> <zmin> <zsize> <tmin> <tsize>

Nipype has some xor structure that doesn't fully cover all usecases, see here.

In pydra we could probably handle this by adding readonly arguments like this:

  inputs_metadata:
    x-z_range:
      readonly: True
      argstr: "{x_min} {x_size} {y_min} {y_size} {z_min} {z_size}"
      requires: [x_min, x_size, y_min, y_size, z_min, z_size]
      position: 2

    t_range:
      readonly: True
      argstr: "{t_min} {t_size}"
      requires: [t_min, t_size]
      position: 3

this repo's data quota is used up

I can't push to the repository (I mean my fork, but it's the same).

batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.
Uploading LFS objects:   0% (0/2), 0 B | 0 B/s, done.

I think it's probably because our test data is too large. I need to find time to downsample those large files in our test data and to make things work again.

input_drops in yml file

hello @htwangtw I'm starting working on using the converter for interfaces in fsl.model.

In fsl_model_param.yml, I notice that there is a field called input_drops. You mentioned this field here #11 . What do you mean by not compatible with pydra?

I guess that inputs_drop is not mandatory, and I found one example here

pydra-fsl/specs/fsl_utils_param.yml

Line 88 in 094cec2

inputs_drop:

Do we have a criterion when two or more fields are exclusive, which one we choose to drop?

Thank you!

FNIRT output specification issues

@htwangtw - I was debugging failing tests and it looks like there are several field in the FNIRT output spec (e.g. field_file) that have in_file as the only requirements, but this is not right.
In nipype one can specify full name by providing a string or set it to True in order to use the default nipype template. @effigies suggested that we don't have to support both, we could just allow for some user defined template.

Let me know if you have thoughts about it. Don't remember if we discussed similar cases

fixing GA

Bug: ImageMaths in_file doesn't have help_string field

Just opening this issue to keep notes on things I came across.

Found a few issues while attempting the ImageMaths conversion:

• Unsure why help string was not compiled for ImageMaths with the converter
• Customised field in the nipype interface; probably need a separate option in the converter / yml

subfolder naming

Hello, should we follow the category from nipype to create subfolders as follows:

• aroma
• base
• epi
• fix
• maths
• model
• possum
• preprocess (done)
• utils (done)

Don't worry, I won't create all of them. I'll start with interfaces within maths, model, preprocess, and utils

Bug constructor BET

Hi,

I'm just learning to use Pydra and trying to do a similar wrapper for calling elastix executables for image registration.

While checking your code, I noticed that this line should be line = line, otherwise Pydra can only have one single "BET" node in the workflow as it does not allow more than one node with the same name :

pydra-fsl/preprocess/bet.py

Line 328 in 8168479

name="BET",

Cheers,

RaC

fixing tests in docker

as mentioned in #33 some tests are working locally but not in the container