大家有遇到过并行计算和单核计算结果不同的情况吗？

CFDngu

最近编译了自己的求解器，在调试时发现这样的问题，就是单核计算和并行计算的结果不一样。

一个简单的二维算例，单核计算没问题，结果正确，用并行计算的结果明显错误，而且错误的很明显。一开始我以为是scotch分块的问题，后来换成simple分块还是不对。

请问是不是我编译的时候有什么地方疏忽了？我是仿照interfoam做的求解器。

之前同样的自己开发的边界，用interFoam算没问题。所以我觉得还是求解器的问题，但是编译过程中没有报错，计算没有报错，就是结果不对。

CFD中文网

有的。如果是自己写的求解器，要确保是并行的算法。即使不是自己的求解器，官方的求解器也经常出现并行发散的情况。这个问题很复杂。

random_ran

很好奇并行处理的结果与单核计算结果的差异。或者说并行量的大小对计算结果的影响。

对与小的问题，还可以进行互相的考证。但是对于实际的问题，我觉得很少会有人再去比对单核计算的结果。

CFDngu

@cfd-china 不知道为什么前两天论坛总是断开连接，给我急坏了！

我现在发现是并行的时候processor之间不交互，问题出现在这里：

       if (pimple.firstIter() || moveMeshOuterCorrectors)
         {
         scalar timeBeforeMeshUpdate = runTime.elapsedCpuTime();

        mesh.update();

        if (mesh.changing())                      **//Here comes the problem!**
        {
            Info<< "Execution time for mesh.update() = "
                << runTime.elapsedCpuTime() - timeBeforeMeshUpdate
                << " s" << endl;

            gh = (g & mesh.C()) - ghRef;
            ghf = (g & mesh.Cf()) - ghRef;
        }

        if (mesh.changing() && correctPhi)
        {
            // Calculate absolute flux from the mapped surface velocity
            phi = mesh.Sf() & Uf;

            #include "correctPhi.H"

            // Make the flux relative to the mesh motion
            fvc::makeRelative(phi, U);

            mixture.correct();
        }

        if (mesh.changing() && checkMeshCourantNo)
        {
            #include "meshCourantNo.H"
        }

其中第一个mesh.changing的if条件根本没有进去，我也不知道是咋回事，单核计算的时候就完全没问题，并行的时候不更新网格。

CFDngu

@random_ran 是有影响的，我看过类似的论文，和分块方式，分块数量都用影响，但是影响应该不大，不大懂并行，不好下结论，但是实际工程或者三维的算例，是根本没法对比的，用单核算不得慢死，和试验值能对上就行了。。。。

CFD中文网

@CFDngu
嗯，你把你那个Info改成Pout试试？Info在并行的时候不一定会输出信息。

CFDngu

@cfd-china 不是这个原因，这个mesh.changing确实没有执行

CFD中文网

@CFDngu 我测试了一下，是执行了的。

CFDngu

@cfd-china 正常是执行的，可是我编译了一个solver，没执行。。。。。
我的solver基本就是interDyMfoam没怎么改

五好青年

@cfdngu
蹲一个回复，关注2个问题
(1) 单核可以计算，并行报错
(2) 单核和并行计算，结果存在差距，差距是细微的可以忽略，还是跟核数有关？

机智的涛先生

@五好青年老哥，我也会有这个问题，单核正常，并行发散，这是不是与分配核数有关呀？

CFD中文网

大家有遇到过并行计算和单核计算结果不同的情况吗？