1. 这个问题先搞清楚eddy 在 Micapipe 里到底是什么角色先说个真实场景你在终端里跑 Micapipe 的-dwi模块前面 T1、功能像、B0 一切都好好的日志一条条刷过去到了某一步突然停在Running eddy ...然后过了十几分钟你回来一看任务挂了。报错也许只有一行eddy: command not found也许是更晦涩的EDDY died with SIGSEGV。不管哪种只要你是用 Micapipe 做脑科学影像处理大概率会在 eddy 这一步卡住。我自己第一次跑通之前在这上面耗了整整一个下午。Micapipe 是一套多模态影像处理流程它把自由Surfer、FSL、ANTs、MRtrix 这些工具串在一起自动完成从结构像预处理到扩散成像预处理的很多环节。但很多人都没意识到Micapipe 本身不是一个“自带所有算法”的软件它更像一个调度器很多重活都交给了外部工具。而扩散数据预处理里最关键的一步就是 FSL 的 eddy。eddy 负责对弥散加权图像做涡流畸变校正和头动校正这一步的质量直接决定后面张量拟合、纤维追踪是否可靠。所以配置问题的核心就是让 Micapipe 能在运行时准确找到 eddy并且让 eddy 能正常从你的数据里读出它需要的信息。这个问题的影响范围其实比想象中大。去 GitHub 上翻一翻 Micapipe 的 Issues会发现相当一部分提问都集中在 DWI 预处理阶段而 eddy 相关的话题又是其中重灾区。很多刚接触神经影像的同学在装完 Micapipe 之后第一反应是检查 Micapipe 本身结果折腾了半天发现真正的问题是 FSL 装得不对、环境变量没生效或者在 HPC 上提交作业时根本没把 FSL 的环境带进计算节点。我自己也见过不少组里的研究生卡在同一个报错上一周都没走出来最后只是把FSLDIR写对就好了。所以这篇就专门来拆解 eddy 配置问题。我会从环境搭建、路径配置、数据准备、GPU/CPU 选择和常见报错排查几个方面逐一展开尽量把那些文档里没写透、但实际跑起来一定会遇到的细节都捞出来讲清楚。1.1 Micapipe 并不是一个“自带所有工具”的软件Micapipe 的定位是流程编排和结果质量控制它把很多成熟的工具像搭积木一样组合起来。在处理扩散数据时它内部会调用 FSL 的 topup 和 eddy也会用到 MRtrix 的一些命令来生成掩模、做张量拟合。理解这一点非常重要因为一旦出现“eddy 找不到”“eddy 崩了”之类的报错问题往往不在 Micapipe 的代码本身而在于外部依赖没有就位。打个比方这就像你搭了一台自动装配流水线Micapipe 是那条流水线的主控电脑eddy 则是某一个工位上最核心的机械臂。主控电脑发出指令说“机械臂动了”但如果机械臂压根没接电、或者没有从正确的位置安装流水线自然就卡住。你很可能把主控电脑翻来覆去检查半天却忘了最基础的问题其实是机械臂那边的供电和环境。因此配置 eddy 的第一步不是去改 Micapipe 的参数而是先把 FSL 这个“机械臂供应商”伺候好。Micapipe 在运行时默认通过FSLDIR这个环境变量去定位 FSL 的安装位置然后在$FSLDIR/bin下面找eddy这个可执行文件。如果这个链路有任何一个环节断了后续所有努力都会变成徒劳。1.2 eddy 卡住时通常卡在三个层面根据我踩过的坑和帮别人定位过的问题eddy 配置问题基本可以归成三类。第一类是环境层问题FSL 没装对或者装了但环境变量没有导出到当前 Shell或者你在 HPC 上用了 Singularity 容器但容器内部没有继承宿主机的 PATH。这一类报错通常很直白最常见的提示就是eddy: command not found偶尔也会出现eddy: error while loading shared libraries说明文件在、但动态库找不到。第二类是资源层问题eddy 是一个极其吃内存和磁盘的程序尤其是在处理高分辨率、多方向的弥散数据时。默认情况下eddy 会在临时目录里写大量中间文件如果/tmp空间不够、权限不对或者内存不足它就会以 segmentation fault 或其他奇奇怪怪的方式直接崩溃。很多人以为是配置问题结果换了个大内存节点或者把TMPDIR指到自己的目录问题瞬间消失。第三类是数据参数层问题eddy 不是你把一张图像丢进去就能跑的它需要--index、--acqp、--bvecs、--bvals这些配套文件而且对相位编码方向、有效回波时间这些元数据的正确性要求很高。Micapipe 会自动生成这些文件但如果你输入的 BIDS 数据本身缺少必要字段或者 bvec/bval 和图像维度不一致eddy 就会在启动后立刻报错退出。1.3 什么时候你会遇到“eddy 配置问题”我接触过的几种典型情况都可以用同一套排查思路去解决。一是全新安装 Micapipe 之后第一次跑 DWI 数据这种最常见。你按照官方文档把 Micapipe 装好FreeSurfer 也跑通一遍了结果到-dwi这一步才发现 FSL 根本没被正确识别。原因是很多人先装了 Micapipe后来才装 FSL装完 FSL 之后没有重新打开终端环境变量自然没生效。二是从 Linux 本地机器迁移到 HPC 集群的时候。本地机器上一切正常上了 Slurm 或 PBS 集群之后提交的作业脚本里没有module load fsl或者没有 source 用户的.bashrc导致计算节点上的环境和你交互节点的环境不一致。这种情况特别具有迷惑性因为你在登录节点上明明敲which eddy能找到作业一提交进去就找不到了。三是升级了 FSL 版本或者系统编译器之后突然开始报libiomp5.so、libgomp.so这类动态库缺失的错误。这其实不是版本越新越好而是 FSL 编译时依赖的 OpenMP 库和系统当前环境不匹配。把这三类情况放在一起看你会发现所谓“eddy 配置问题”绝大多数时候并不是一个需要硬啃源码的难题而是一个环境管理问题。只要把依赖链和环境变量梳理清楚前面三分之二的问题就已经解决了。2. 环境配置把 FSL 和 eddy 彻底装明白2.1 FSL 安装并不是“解压完就能用”很多人在 FSL 安装上会犯同一个错误从官网下载了压缩包解压到/usr/local/fsl然后觉得安装已经结束直接开始跑 Micapipe结果被 eddy 教做人。其实 FSL 的安装流程里解压只是第一步后续还有环境变量配置、许可文件确认、动态库链接检查等几个步骤每一步都会影响后续运行。FSL 6.0 的官方安装包通常是一个.tar.gz压缩文件解压之后目录结构基本是/usr/local/fsl/bin、/usr/local/fsl/etc、/usr/local/fsl/data这样。我建议无论你装的是 6.0.5 还是 6.0.7都用绝对路径去设置环境变量不要用相对路径否则很容易出现在某些登录节点上正常、在某些工作目录下找不到命令的情况。另外不同 FSL 版本里 eddy 的具体二进制文件名也有变化。早期版本里会有eddy_cuda、eddy_openmp这样的独立可执行文件而eddy往往是一个符号链接或者脚本用于根据当前环境自动选择合适的后端。到了 FSL 6.0.5 之后bin/eddy通常是eddy_openmp的符号链接。如果哪个环节没有链接好你which eddy的时候也许能查到但真正执行时还是会报错。2.2 环境变量写入 bashrc 的三行关键配置正确配置 FSL 环境变量其实只需要让系统知道两件事FSL 装在哪里FSL 的可执行文件在哪个目录。按照我的习惯会在~/.bashrc的末尾追加下面这几行export FSLDIR/usr/local/fsl export PATH$FSLDIR/bin:$PATH source $FSLDIR/etc/fslconf/fsl.sh第一行定义 FSL 的根目录第二行把 bin 目录加入 PATH第三行是 FSL 官方提供的一个配置文件它会帮你设置好一部分 FSL 内部使用的环境变量以及FSLMACHTYPE之类的平台标识。如果某台机器上 FSL 不是装在/usr/local/fsl而是装在用户目录下比如~/software/fsl那就把第一行改成对应的路径后面两行会跟着自动适配。需要注意一个小坑source $FSLDIR/etc/fslconf/fsl.sh这一行必须在FSLDIR已经导出的情况下再写否则.bashrc里这个$FSLDIR可能是空的。如果你把四行写在一起顺序上一定不能颠倒。改完之后不要偷懒一定要重启终端或者至少执行一次source ~/.bashrc。我见过太多人改完.bashrc之后不重新加载然后在同一个旧终端里继续调试浪费大量时间。配置完之后可以用三个命令快速验证which fsl fslversion which eddy如果which eddy能返回一个实际路径比如/usr/local/fsl/bin/eddy说明这一步已经通了。如果which fsl有结果但which eddy是空的那很可能是你的 FSL 版本比较老或者安装不完整需要重新检查安装包。2.3 Micapipe 安装选哪一种方式Micapipe 的安装方式大致分两条路线容器化和本地环境安装。容器化方式我强烈推荐尤其是在 HPC 集群上。官方提供了 Docker 和 Singularity/Apptainer 镜像镜像里已经把所有依赖都打包好了包括 FSL、ANTs、FreeSurfer 等你在容器里跑 Micapipe基本不用操心 eddy 路径问题。你只需要保证宿主机能正常执行 Singularity并把数据目录挂载进容器里。本地环境安装也有自己的优势可定制性强CLI 调试方便不依赖容器权限。一般是通过源码或者 pip 安装 Micapipe 的 Python 包和命令行工具。这种方式下Micapipe 会直接调用你系统 PATH 和FSLDIR里能找到的可执行文件所以你的 FSL 环境变量配置就变得至关重要。我个人的建议是如果你只是想在单机上快速跑通一个数据集用容器最省心如果你要反复修改参数、二次开发或者在多台机器上复现流程那本地环境安装更适合。这里不存在绝对正确的方法只看哪个更匹配你的使用习惯。但不管是哪种方式真正决定 eddy 能不能跑起来的仍然是你对 FSL 环境的掌控力。因为即便容器里带了 FSL你如果把数据放在没有读权限的目录下或者在 Singularity 命令里忘了把临时目录挂载进去eddy 照样会崩溃。2.4 安装之后先别急着跑花两分钟做 eddy 自检每次配置完新的环境我都习惯先做一轮自检而不是立刻把整个 Micapipe 流程跑起来。这个习惯帮我节省了很多排错时间。自检过程很简单分成三步。第一步是检查基础可执行文件which eddy eddy --helpeddy --help如果能在终端打印出一大堆参数说明说明动态库依赖没有问题程序至少能正常启动。如果这一步就直接报cannot open shared object file那多半是系统缺少 OpenMP 相关的运行库后面我会专门讲。第二步是检查 FSList 内部工具是否能正常访问which topup which fslmaths which fslroi这几个命令是 Micapipe 在调用 eddy 之前几乎一定会用到的。它们能正常工作说明 FSL 的安装在整体上是完整的问题可能只出在 eddy 这一个单独的可执行文件上。第三步是检查临时目录。eddy 对/tmp的要求很高建议提前确认echo $TMPDIR df -h /tmp如果没有设置TMPDIR系统会默认使用/tmp。在某些集群上/tmp空间只有几个 GB而一个高分辨率的 DWI 数据在跑 eddy 时很容易生成几十 GB 的中间文件这几乎是必崩的。我通常会在.bashrc里增加一行export TMPDIR$HOME/tmp mkdir -p $HOME/tmp这样至少能保证临时目录的空间可控。3. 跑通一次 DWI 预处理的完整配置举例3.1 准备数据前的三个小约定在进入到具体命令之前我先说三个我在数据准备阶段坚持遵守的约定。这三个约定不直接写在代码里但能帮你提前规避大部分因为输入数据导致的 eddy 配置问题。第一个约定永远用 BIDS 格式组织 DWI 数据。Micapipe 对 BIDS 的支持已经相当成熟只要你的数据符合 BIDS 规则它就能自动识别_dwi.nii.gz、_dwi.bvec、_dwi.bval这些文件。如果你手动改过文件名或者目录结构Micapipe 虽然也能通过额外参数指定路径但 eddy 需要的数据一致性检查就会变得更容易出错。第二个约定确认 bval 文件中包含足够数量的 b0 图像。eddy 在做涡流校正时对 b0 的分布是很敏感的。如果 b0 数量太少或者全部集中在扫描开头topup 和 eddy 之间的配合就会出现问题。常规的做法是至少保留 5 个以上的 b0且分布在扫描序列的不同时间点。第三个约定确保.json文件里写清楚了相位编码方向和有效回波时间。例如PhaseEncodingDirection: j或者j-TotalReadoutTime: 0.066。Micapipe 会根据这些信息自动生成 eddy 所需的acqparams.txt如果 json 里缺字段它生成的参数文件就是错的eddy 会直接拒绝运行或者给出非常离谱的结果。我遇到过不少人数据本身没问题但因为转换原始 DICOM 的时候没有把 json 一起转出来导致 Micapipe 里 eddy 永远卡在topup或者eddy启动后的第一行。所以每次开始处理之前先花几分钟打开 json 看一眼这个时间花得非常值。3.2 最稳的命令行调用方式Micapipe 的官方命令行接口里-dwi是处理扩散数据的入口。举个例子一个最基础的调用大概长这样micapipe \ -bids /data/BIDS \ -out /data/derivatives \ -sub 01 \ -ses 01 \ -dwi \ -dwi_denoise \ -dwi_main dwi当然这不是唯一的写法Micapipe 的版本更新很快不同版本之间的参数名称可能略有差异。我更想强调的是在这种调用方式下eddy 的配置问题主要取决于 Micapipe 内部生成的临时命令。所以如果你遇到了问题不要只盯着 Micapipe 的输入参数而是要设法把 Micapipe 真正执行的 eddy 命令找出来看看。Micapipe 通常会把中间命令和执行日志写到输出目录下的logs文件夹里。我在排查时会先打开日志文件grep -i eddy micapipe_01_dwi.log这条命令会把日志里所有和 eddy 相关的行过滤出来。你会看到 Micapipe 调用了哪些参数、传入了哪些文件路径。这一步的信息密度比官方文档更高因为它就是你机器上真实发生的情况。如果你的环境配置导致 eddy 命令本身无法执行Micapipe 的报错往往非常简短可能只是说EDDY failed。这个时候最有效的操作是把日志里 eddy 那一行完整地拷贝出来自己在终端里手动执行一遍去掉-outs之类的输出路径参数只保留输入相关参数。这样能把问题从“Micapipe 配置”压缩到“eddy 本身”这个更小的问题域里。3.3 配置错误现场EDDY died with SIGSEGV既然标题是配置问题我就拿一个最让人崩溃的报错来拆解EDDY died with SIGSEGV。这个报错在 HPC 用户群里特别常见而且特别难查因为 eddy 并不会告诉你到底是哪一步越界了。我遇到的一个典型案例是这样的跑一套大约 180 个梯度方向、2.5mm 分辨率的 DWI 数据前面 topup 顺利结束日志显示Running eddy然后过了大概五分钟日志末尾出现EDDY died with SIGSEGV。第一次遇到的时候我怀疑是输入数据的问题于是反复检查 bvec/bval检查acqparams.txt都没发现问题。后来我把临时目录换到自己的家目录下再跑一次居然就成功了。再对比系统默认/tmp的使用情况发现/tmp已经被占得只剩 3GB而 eddy 在运行过程中需要在临时目录写一个比原数据还要大好几倍的中间矩阵文件。空间不够程序就会尝试写入失败然后引发段错误。所以如果你看到 SIGSEGV建议优先检查三样东西临时目录剩余空间、内存上限、以及输入图像的读取权限。很多“内存不足”并不是真的物理内存不够而是你在集群上提交任务时设置的内存上限太低。eddy 是一个特别贪心的程序它初始化的时候要为每个梯度方向分配矩阵空间如果线程数开得很大内存占用会呈线性甚至超线性增长。遇到了 SIGSEGV第一反应不应该是重装程序而是先查资源。3.4 一个很有用的检查顺序表格为了方便你之后照着操作我把 eddy 挂掉之后的检查顺序做成了一张表。这个顺序是我自己摸索出来的基本能覆盖绝大多数情况下的问题。顺序检查项方法典型结论1eddy 是否在 PATH 中which eddy如果无结果FSL 路径没配好2FSL 环境变量是否生效echo $FSLDIR空值说明.bashrc未加载3动态库能否加载eddy --help报 shared library 说明欠 OpenMP 库4输入文件是否齐全检查_dwi.bvec/_dwi.bval/ json缺文件或者字段不全会导致 eddy 启动失败5临时目录空间df -h /tmp或$TMPDIR空间不足会 SIGSEGV6内存限制看作业脚本的 mem 参数小内存跑大数据直接崩7GPU 是否可用nvidia-smiGPU 版 eddy 需要显存和驱动8Micapipe 日志里 eddy 完整命令grep -i eddy 日志把命令手动执行能区分程序问题和数据问题这个顺序不是我随便排的它的逻辑是先确认“程序能跑”再确认“程序能读数据”最后确认“资源足够”。遵循这个顺序能让你在排查时少走很多弯路。4. 深入 eddy 本体CPU/GPU、临时目录和资源限制4.1 你机器上到底有没有可用的 eddyFSL 的 eddy 可不是只有一种形态。在很多系统上你在bin目录下能看到eddy_cuda、eddy_openmp、eddy三个不同名字的可执行文件。eddy通常是一个脚本或者符号链接它会根据系统情况决定到底调用哪个后端。理解这一点对配置问题特别重要因为你可能确实有eddy_openmp但eddy这个链接本身没有建好。先来看看怎么确认eddy到底指向什么ls -l $(which eddy) file $(which eddy)如果输出显示eddy - eddy_openmp说明这是一个符号链接没有问题。如果显示的是一个脚本文件你可以用cat看看脚本内容通常里面会根据CUDA是否可用来决定调用eddy_cuda还是eddy_openmp。还有一种情况是 FSL 安装的时候只装了部分组件比如有些精简版 FSL 不包含 GPU 版本的 eddy此时你可能会看到eddy_cuda不存在但eddy_openmp存在。只要eddy_openmp在Micapipe 那边通常也能用只是速度会慢不少。这里给大家一个我在实测中的直观感受同样一套 100 多个梯度方向的数据CPU 版 eddy 可能要跑四五个小时GPU 版 eddy 用一张中端显卡大约只需要四十分钟。如果课题数据量大GPU 版不是可选项而是刚需。4.2 GPU 版本 eddy_cuda 的配置陷阱很多同学一听到 GPU 版 eddy 就兴奋觉得装上显卡驱动就能用。实际上 GPU 版 eddy 还依赖一套 CUDA 运行环境而且不同版本的 eddy_cuda 对 CUDA 版本的要求也不一样。FSL 6.0.4 附带的 eddy_cuda 可能只支持 CUDA 10.2而 FSL 6.0.7 可能要求的又是 CUDA 11.x。配置 GPU 版 eddy 之前先做两个检查。第一个是确认显卡驱动支持的语言版本nvidia-smi查看右上角的 CUDA Version它表示驱动程序支持的最高 CUDA 运行时版本。第二个是确认 eddy_cuda 文件本身需要的 CUDA 版本通常可以通过strings $(which eddy_cuda) | grep -i cuda_version | head不一定每个版本都有这种字符串所以更实在的办法是直接跑一下eddy_cuda --help如果它报找不到libcudart.so.X那就是 CUDA 运行时库路径没配置好。你可以在.bashrc里加上export LD_LIBRARY_PATH/usr/local/cuda/lib64:$LD_LIBRARY_PATH配置完成之后再跑一次eddy_cuda --help通常就能正常输出了。需要注意千万别把LD_LIBRARY_PATH乱改因为 FSL 其他组件对系统库的依赖也非常敏感改得太激进可能会导致其他程序崩掉。4.3 tmp 目录与磁盘空间最容易被忽略的配置项如果让我选一个“最隐蔽的 eddy 配置坑”临时目录一定排在第一位。eddy 运行时会在 tmp 目录下生成大量中间文件包括数据拷贝、索引矩阵、结果矩阵等。这些文件占用空间庞大而且在任务结束之后会自行清理。如果你的临时目录空间不够它并不会像一般程序那样给出优雅的“磁盘已满”提示而是会以 segment fault、写文件失败等形式直接退出。除了空间临时目录的文件系统类型也值得看一眼。某些 HPC 集群的/tmp本质上是内存文件系统速度确实很快但空间有限另一些集群的/tmp挂在共享存储上空间大但 IO 压力也大。eddy 对 IO 非常敏感如果临时文件写入太慢整个流程会被拖到无法接受的程度。我的建议是专为神经影像分析设置一个独立的临时目录放到本地的 SSD 上。比如export TMPDIR$HOME/scratch/tmp mkdir -p $TMPDIR然后在跑 Micapipe 之前用df -h $TMPDIR确认一下空间。一个粗略的经验值临时目录的空间至少要为 DWI 原始数据大小的 10 到 20 倍。如果你的原始 DWI 是 5GB临时目录至少要有 50GB 以上才比较稳妥。4.4 在 HPC 集群里提交任务时怎么带上配置在 HPC 上跑 Micapipeeddy 配置问题是重灾区中的重灾区。很多集群使用 Slurm 调度登录节点和计算节点的环境不完全一样。你在登录节点上.bashrc里配置好的 FSL 路径提交作业之后计算节点可能完全不知道。解决办法有几种。第一种是在作业脚本里显式加载环境#!/bin/bash #SBATCH --job-namemicapipe #SBATCH --cpus-per-task8 #SBATCH --mem60G #SBATCH -p gpu #SBATCH --gresgpu:1 module load fsl/6.0.7 export FSLDIR/opt/fsl/6.0.7 export PATH$FSLDIR/bin:$PATH source $FSLDIR/etc/fslconf/fsl.sh micapipe -bids ... -out ... -sub 01 -dwi第二种是不依赖 module 系统直接把你在.bashrc里配置的所有 FSL 相关行复制到作业脚本顶部确保计算节点进入 Micapipe 命令之前环境就已经准备就绪。还有第三种如果你用的 Singularity 容器一定要把宿主机的临时目录和镜像内部的临时目录映射好singularity exec \ --bind $HOME/scratch/tmp:/tmp \ --bind /data:/data \ docker://micapipe/micapipe:latest \ micapipe -sub 01 -dwi ...我见过太多人在 Singularity 里跑 Micapipe 时eddy died最后发现只是/tmp没有绑定镜像内部的/tmp只有几百 MB根本不支持 eddy 的中间文件写入。把--bind加对之后问题当场消失。5. 常见问题速查表与最后的排查技巧5.1 一张表把所有配置问题说清楚下面我把从环境搭建到实际运行中最常遇到的 eddy 配置问题整理成了速查表。你在实际排查时可以把它当作一个 checklist 使用。报错现象可能原因解决方案eddy: command not foundFSL 路径未配置或 Shell 未重启检查.bashrc中的FSLDIR和PATHeddy: error while loading shared libraries缺 OpenMP 库或 CUDA 库安装libgomp或配置LD_LIBRARY_PATHEDDY died with SIGSEGVtmp 空间不足、内存不足、输入文件损坏扩大TMPDIR提高作业内存检查输入Could not open file ...路径权限或文件格式不对用fslhd检查 nii 文件头确认权限topup failed相位编码方向字段缺失或 json 未配套补充 BIDS json 的PhaseEncodingDirection字段Index file is not same lengthbval/bvec 行数与图像体积数不匹配手动比对fslval dwi dim4与 bval 行数CUDA error: out of memory显存不足减少 eddy 并行 MPI 进程数或换更大显存 GPUNo module named pyfreesurferMicapipe 依赖环境不完整按文档安装所有 Python 依赖用 conda 环境管理eddy_openmp: No such fileFSL 安装组件不完整重新运行 FSL 安装器或检查bin目录符号链接结果出现大量 NaN输入张量或 bvec 方向不合法检查 bvec 是否单位化检查相位编码信息这张表谈不上面面俱到但覆盖了 80% 以上我实际遇到过的配置问题。遇到没列出来的情况核心排查思路也不会变先把报错完整记录下来然后沿着“文件是否存在 → 依赖是否能加载 → 输入参数是否合理”的顺序逐层排查。5.2 一条调试命令走天下最后再分享一个压箱底的调试技巧当你被一个 eddy 配置问题搞得焦头烂额时试着把 eddy 从 Micapipe 的流水线里单独拉出来手动跑一遍。Micapipe 的输出目录下通常会保留 eddy 的中间输入文件比如经过 topup 校正后的dwi_post_topup.nii.gz、index.txt、acqparams.txt、bvecs、bvals等。你可以在终端里先构建一个最小命令eddy \ --imaindwi_post_topup.nii.gz \ --mask... \ --indexindex.txt \ --acqpacqparams.txt \ --bvecsbvecs \ --bvalsbvals \ --topuptopup_results \ --outmanual_eddy \ --verbose手动执行的好处是你能一眼看到 eddy 是在加载动态库的阶段崩溃还是读取数据的时候崩溃或者是在计算过程中崩溃。这三个阶段对应的解决方案完全不同。如果你想更快还可以先用fslroi把 DWI 数据截取出前 20 个 volumes 来测试。一个小数据子集如果 eddy 能正常跑完说明配置没有问题剩下的就是资源或完整数据的问题。这个方法在定位 HPC 集群上的资源限制时简直不要太好用。我自己现在每次在新机器上配置 Micapipe都会遵循一套标准动作先把 eddy 手动跑通一个小子集然后再启动完整流程。这个过程看起来多花了十分钟实际上省掉了后面少则几小时、多则几天的排错时间。这个方法我推荐给所有要做扩散数据分析的人不管你是不是 Micapipe 的重度用户以后直接用 eddy 做单序列处理时一样受益。