Is the longitudinal pipeline primarily running on GPU or CPU?

[RDoerfel]

Dear FastSurfer team,

I saw that FastSurfer supports longitudinal processing now. Pretty cool!

I was wondering is it primarily running on GPU or CPU? I would like to parallise it to run multiple subjects in parallel and I'm wondering whether I should run on our CPU cluster (no GPU), or GPU cluster (rather little CPU).

Best, Ruben

[dkuegler]

It uses both in concert. We already have a specialized script that schedules the CPU and GPU-heavy parts of cross-sectional FastSurfer on a SLURM cluster.

For the longitudinal pipeline, this is different and it is a mix of GPU and CPU workloads across multiple steps.

Thus far, there has not been any demand/requests to extend the cluster scheduling script to longitudinal processing, but you should be able to orchestrate the calls yourself as well.

The longitudinal processing is laid out in long_fastsurfer.sh.

long_fastsurfer.sh already has a --parallel flag (and --parallel_seg and --parallel_surf subflags, see the documentation).

If you take a look at the longitudinal processing, it has 5 components:

1. Template Init
2. Template Seg
3. Template Surf
4. Long Seg
5. Long Surf

Steps 1, 2, 3 are GPU-heavy and Step 3 and 5 are CPU-heavy.

So the simplest way to approach to achieve the distribution of the jobs would be to

I. Copy long_fastsurfer.sh (long_fastsurfer_CPU-heavy.sh) and comment out steps 3 and 5, then run the script on your GPU cluster (using all other parameters as you would use).

II. Copy long_fastsurfer.sh (long_fastsurfer_GPU-heavy.sh) and comment out steps 1, 2, 4, the run the script on your CPU cluster (using the same parameters as in I.)

I have not tried this myself, but from a quick inspection of long_fastsurfer.sh this should work with no further edits.

[RDoerfel]

cool, thanks!

[RDoerfel]

Maybe a follow-up question, would it make sense to add support for the flags "--seg_only" / "--surf_only", similar to the cross-sectional pipeline?

[dkuegler]

I guess it might make sense to introduce such flags for this use-case. At that time, it would probably make sense to extend this to a --steps flag that lets the user select which steps to run. As the CPU requirements of for example steps 3 and 5 are also somewhat different and for optimal scheduling you might want to select different options, for example for the --threads flag.