ENH: Standalone CLI now estimates fieldmaps

[oesteban]

The previous behavior (just "finding" estimators) is maintained with the argument --dry-run.

[codecov]

Codecov Report

Attention: 219 lines in your changes are missing coverage. Please review.

Comparison is base (53482c1) 80.59% compared to head (a77775f) 76.66%.

❗ Current head a77775f differs from pull request most recent head a682abe. Consider uploading reports for the commit a682abe to get more accurate results

Files	Patch %	Lines
sdcflows/config.py	73.83%	72 Missing and 12 partials ⚠️
sdcflows/cli/main.py	40.00%	47 Missing and 4 partials ⚠️
sdcflows/cli/parser.py	64.00%	30 Missing and 6 partials ⚠️
sdcflows/workflows/fit/base.py	8.33%	22 Missing ⚠️
sdcflows/cli/workflow.py	13.33%	13 Missing ⚠️
sdcflows/utils/telemetry.py	37.50%	10 Missing ⚠️
sdcflows/fieldmaps.py	71.42%	0 Missing and 2 partials ⚠️
sdcflows/_warnings.py	92.30%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #408      +/-   ##
==========================================
- Coverage   80.59%   76.66%   -3.93%     
==========================================
  Files          26       32       +6     
  Lines        2293     2824     +531     
  Branches      291      373      +82     
==========================================
+ Hits         1848     2165     +317     
- Misses        401      593     +192     
- Partials       44       66      +22     

Flag	Coverage Δ
unittests	∅ <ø> (∅)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[oesteban]

Well, at df93c7b, this is surprisingly executing the estimation of GRE fieldmaps. EPI fieldmaps failed in the robust average, so I'll need to check what went wrong.

[effigies]

Is it needed to separate this, if you've already initialized the process pool?

[oesteban]

We could send it to the pool, that'd be fine. However, it's working this way in MRIQC.

[effigies]

My point was the pool is initialized, so isn't it safe to do this in the main process at this point? These managers tend to make debugging trickier, so if we can avoid it, I'd rather.

[oesteban]

Oh, yes, in theory we could use the main process without problems, indeed.

[oesteban]

Okay, I was removing this context to build the workflow in the main thread, and it could be interesting to keep it this way, as the workflow is created while OMP_NUM_THREADS is set to 1. This saves great numpy buildup.

We could still move it to the main process, but then it would make sense to make sure numpy is imported with OMP_NUM_THREADS = 1 (and that is then overridden in subprocesses).

[effigies]

Go ahead and merge this when you're ready. It would be nice if we could get away from the Manager() indirection for building workflows eventually, but I don't want to hold this up on that.