CFD中文网

@OFan

@大喵 请问问题解决了吗？

@JqBu 报错如下，贴出来给大家看看，有没有大佬指教一下呢```
Courant Number mean: 0.0440313 max: 0.39994
Interface Courant Number mean: 0.00208161 max: 0.39994
deltaT = 1.54321e-06
Selected 1971 cells for refinement out of 125250.
Refined from 125250 to 139047 cells.
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigSegv::sigHandler(int) at ??:?
#2 ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3 Foam::fvMeshTopoChangers::refiner::refineUfs(Foam::HashSet<int, Foam::Hash<int> > const&, Foam::polyTopoChangeMap const&) at ??:?
#4 Foam::fvMeshTopoChangers::refiner::refine(Foam::List<int> const&) at ??:?
#5 Foam::fvMeshTopoChangers::refiner::update() at ??:?
#6 Foam::fvMesh::update() at ??:?
#7 ? in "/opt/openfoam10/platforms/linux64GccDPInt32Opt/bin/interFoam"
#8 ? in "/lib/x86_64-linux-gnu/libc.so.6"
#9 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#10 ? in "/opt/openfoam10/platforms/linux64GccDPInt32Opt/bin/interFoam"

@JqBu 找到个of官方算例动态加密网格的，是下面这样，不过在我的算例里还是跑不了，贴出来记录一下把

topoChanger
{
    type            refiner;

    libs            ("libfvMeshTopoChangers.so");

    // How often to refine
    refineInterval  1;

    // Field to be refinement on
    field           alpha.water;

    // Refine field in between lower..upper
    lowerRefineLevel 0.001;
    upperRefineLevel 0.999;

    // Have slower than 2:1 refinement
    nBufferLayers   1;

    // Refine cells only up to maxRefinement levels
    maxRefinement   2;

    // Stop refinement if maxCells reached
    maxCells        200000;

    // Flux field and corresponding velocity field. Fluxes on changed
    // faces get recalculated by interpolating the velocity. Use 'none'
    // on surfaceScalarFields that do not need to be reinterpolated.
    correctFluxes
    (
        (phi none)
        (nHatf none)
        (rhoPhi none)
        (alphaPhi.water none)
        (ghf none)
    );

    // Write the refinement level as a volScalarField
    dumpLevel       true;
}

想在of10里做些工作，但是发现of10的动态网格加密和以前版本有很大不同，求助大家一下：
比如我想按alpha.water的大小加密网格，以前可以写：

dynamicFvMesh      dynamicRefineFvMesh;

但是现在of规则变了，不能这样写了，src里没有dynamicfvMesh了，只有这些是和动网格相关的，但是要不是网格是移动的要不就是要topo的，

请问大家of10里怎么给alpha加密网格呀？

@jqbu 请问大家 看看我是哪里少考虑了？还是计算错了？ 能否帮我分析下原因？感谢！

@jqbu 比如
， ， ， ， ， ， ，

1atm下大概是这样

7MPa下就变成了这样

但是经过计算统计，常压下、1MPa时候这个式子大概是成立的，为什么在7MPa时等式后边三项计算结果比初始动能小很多？

@李东岳 是的李老师

重启大法好 比卸载重装 新版本覆盖啥的有用多了

今天win下的paraview打开突然出问题，但是也不报具体的错就闪退，安装新的版本并行版本报错说没有msmpi.dll，普通的版本也还是不行，也不说少啥就直接闪退，这样大家遇到过吗？不会要重装系统把？

@队长别开枪 好的 谢谢前辈！

@队长别开枪 戴前辈，还想请教您一下，Allrun-parallel中的# Reconstruct distributed data
runParallel redistributePar -reconstruct中那个redistributePar是什么操作？有时候我用动网格计算时，一个核合并reconstructParMesh再reconstructPar这样运行速度比较慢，看您的算例才知道合并也可以并行，那请问如何并行合并动网格计算的结果呢

@jqbu 或者请问其他熟悉Plic-VOF的大佬有什么建议嘛？才了解有这种方法捕捉界面，还不熟悉，请各位多指教呀

戴前辈您好，看到您的方法就想用of里的dambreak算例试一下，尝试了在of1912和of1812中加载您的求解interPlicFoam，但是算$FOAM_TUTORIALS/multiphase/interFoam/RAS/damBreak算例的时候，虽然按照您github上的要求修改了fvScheme和fvSolution，但是计算第一步就会出现问题，浮点数溢出，减小算例时间步长到1e-5也不行，细化一倍网格也不行，请问这是为什么呢？（我注意到您给出的tutorials都是多面体网格的，并非六面体网格，不知道是不是您的求解器不适用于六面体网格？）

又检查了一下p1, p2这对碰撞对粒子所在的网格，发现p1,p2并没有在一个网格内，这和程序设计的逻辑不一致，我的compositeCollisionModel是在ORourke基础上改的，两个粒子本应该在是在同一个网格内才可能发生碰撞
结果显示p1在ID为154862的网格内，p2在ID为159677的网格内，那么问题来了，为什么程序会跑出这种结果？p2到底是哪来的？

@星星星星晴 在 拉格朗日模型里是如何加入或删除粒子的？||为什么遍历粒子时粒子的属性会出现随机的情况？ 中说：

响

是的 我现在是加了限制极大值极小值，但是后来就会出现ID=1，或者=2的情况，粒径和位置信息啥的也都不对，有点疑惑

以下问题基于OF7，OF9以上版本不确定具体模型是怎么回事，但是OF8以下的大概差不多，希望各位大佬们给点拨以下！

核心问题：拉格朗日模型在添加或删除粒子的时候是基于什么list或者是什么序列存储的粒子的信息？
我发现不同子模型在添加粒子时候都是通过addParticle函数实现的

template<class ParticleType>
void Foam::Cloud<ParticleType>::addParticle(ParticleType* pPtr)
{
    this->append(pPtr);
}

// 用injectionModel举例，先new一个指针作为粒子，再通过指针赋予粒子各种属性
parcelType* pPtr = new parcelType(mesh, pos, celli);

// 然后调用addParticle函数将有属性的粒子加入场内
cloud.addParticle(pPtr);

删除粒子的时候调用deleteParticle函数

template<class ParticleType>
void Foam::Cloud<ParticleType>::deleteParticle(ParticleType& p)
{
    delete(this->remove(&p));
}

// 用StochasticCollisionModel里的程序举例
if (mass < this->owner().constProps().minParcelMass())
{
     this->owner().deleteParticle(p);
}

那么在对指针（也就是粒子）进行append和remove的时候，OF是创建了一个指针的list吗还是什么，因为每个粒子指针都是new出来的，单纯new出来的指针是用二叉树的形式存储在堆里，应该不会出现指针的信息是随机生成的情况（为什么这么说见后面，我想象到的能让系统赋值随机数的可能性就是有一个list，本来list的各个位置都是有值的，然后人为把某个信息删掉，这样那个位置的信息就会是随机的？）。

核心问题的来源（希望有耐心的大佬帮忙解答一下下面的问题！！！感激不尽！！！）：
最近测试喷雾算例时候会遇到一个问题，就是在计算的时候算着算着就会发散，大概像下面这样，CompostieCollision是我自己建的类，在这个模型里会有粒子的删除和添加功能（单就粒子的删除和添加功能来说，是仿照OF里自己的程序写的，不会有什么问题），但是问题应该是出现在这个类里了

仔细检查，多次测试输出了寻找到的粒子碰撞对p1,p2的各种属性时发现：p1的ID和各种属性是不会出现问题的，p2的ID会出现0、极大数或极小数，p2的粒径也不对，有时粒径很大，有时粒径为0（这里的ID是通过origID函数返回的，返回值是const类型，所以不会变）。如图

感觉这里的问题可能是系统遍历到粒子的时候随机生成了一些信息，导致粒子的ID是随机数，出问题的粒子的属性也不对（见下面报的错）。

为了更好的计算，找到更多错误的规律，随后限制了遍历碰撞对的条件，限制了粒子的ID应该在计算域内的粒子数范围内，随后发现：p2的ID会是一个比较小的整数，粒径信息不正确，位置信息压根就没有，报错也报的是位置信息的错

但是上述问题只是在有几十万粒子的喷雾算例里才会出现，在只有两个粒子的binary collision里计算时不会出现这些问题，ID一切正常，各种属性信息也一切正常。

请问各种大佬能不能麻烦给点建议？

@星星星星晴 感谢回复😊 回头我研究研究这个mpirundebug