我们在将GROMACS 2023移植到鲲鹏920服务器上时遇到了数值稳定性方面的问题。硬件平台是双路鲲鹏920,每路64核,操作系统是openEuler 22.03,编译器用的是毕昇编译器,数学库使用ARM PL。移植过程很顺利,编译没有报错,短时间的测试算例也能正常跑完。但在运行一个标准的水盒子模拟(SPC/E模型,10纳秒时长)时,发现总能量的漂移速度明显比同一算例在Intel Xeon平台上的结果快得多。具体来说,在Intel平台上10纳秒模拟的能量漂移在可接受的千分之几以内,而在鲲鹏上同样时间内能量漂移超过了百分之二,并且体系的温度也出现了缓慢的爬升。我们尝试了单核运行来排除MPI通信的影响,结果能量漂移依然存在。用GCC替换毕昇编译器后重新编译,漂移的程度略有变化但没有本质改善。想请教这种长时间模拟的能量漂移加剧问题,应该从哪个方向去排查,是数学库精度还是编译器优化对浮点运算顺序的影响?
我们在将GROMACS 2023移植到鲲鹏920服务器上时遇到了数值稳定性方面的问题。硬件平台是双路鲲鹏920,每路64核,操作系统是openEuler 22.03,编译器用的是毕昇编译器,数学库使用ARM PL。移植过程很顺利,编译没有报错,短时间的测试算例也能正常跑完。但在运行一个标准的水盒子模拟(SPC/E模型,10纳秒时长)时,发现总能量的漂移速度明显比同一算例在Intel Xeon平台上的结果快得多。具体来说,在Intel平台上10纳秒模拟的能量漂移在可接受的千分之几以内,而在鲲鹏上同样时间内能量漂移超过了百分之二,并且体系的温度也出现了缓慢的爬升。我们尝试了单核运行来排除MPI通信的影响,结果能量漂移依然存在。用GCC替换毕昇编译器后重新编译,漂移的程度略有变化但没有本质改善。想请教这种长时间模拟的能量漂移加剧问题,应该从哪个方向去排查,是数学库精度还是编译器优化对浮点运算顺序的影响?