关于计算时间的deltaT问题



  • 仿真网格1687568,一共不到2百万的网格;
    controlDict中的deltaT设置为0.1

    application     interFoam;
    startFrom       startTime;
    startTime       0;
    stopAt          endTime;
    endTime         100;
    deltaT          0.1;
    writeControl    adjustableRunTime;
    writeInterval   5;
    purgeWrite      0;
    writeFormat     ascii;
    writePrecision  6;
    writeCompression uncompressed;s
    timeFormat      general;
    timePrecision   6;
    runTimeModifiable yes;
    adjustTimeStep  yes;
    maxCo           0.9;
    maxAlphaCo      0.9;
    maxDeltaT       1;
    

    采用40核并行,一晚上一共运行了3s多的时间,按道理应该是每0.1s一输出,请教下这个是什么情况呢
    2020-06-21 07-58-22屏幕截图.png


  • 管理员

    200万网格不应该一个时间步算3秒,你内存所有通道都用上了么?



  • @东岳 老师,我是一晚上的时间在log中显示的计算结果一共计算了3s,这也太慢了,我查看了tutorials中的例子和您之前讲血管的案例,都是根据deltaT的值输出的;我这里deltaT 0.1正常应该是Time =0.1s一输出;
    上面那个图中Time=3.11332下一次输出的是Time=3.11357,在之后是Time=3.11383,这里的deltaT也变成了log文件中显示的deltaT=0.0002578949log中显示的和我在controlDict设置的deltaT这相差的也太大了,我用单核计算了一下,还是这样,我已经彻底不知道哪里出问题了~


  • 管理员

    因为你是自动调整时间步长,为了保证库朗数,这个很必要,你内存所有通道都用上了么?
    要不就降网格数,处理成100万,先跑出结果,再细化网格优化数据



  • @东岳 好的老师,我查查这个内存通道怎么全部用上,我以为能跑起来就可以,还有这么多说法


  • 管理员

    不清楚你那个CPU几个通道,要全部通道都用上,比如4个4G内存,而不是2个16G,前者比后者快得多。



  • @东岳 谢谢老师指导
    下面也给以后看帖子的人一些提示,不要犯我一样的错误:
    DTCHull中得controlDict

    application     interFoam;
    startFrom       startTime;
    startTime       0;
    stopAt          endTime; 
    endTime         4000;
    deltaT          1;
    writeControl    timeStep;
    writeInterval   100;
    purgeWrite      0;
    writeFormat     binary;
    writePrecision  6;
    writeCompression off;
    timeFormat      general;
    timePrecision   6;
    runTimeModifiable yes;
    

    在这里时间步长是固定的,也就是每1s一输出;
    而我采用了adjustTimeStep yes;这样的话,这样的话为保证库朗数,自动调整时间步长,所以就会出现我图中时间步特别小的情况。这些老师在OKSS1中详细讲过,我给忘记了;
    真对上面老师说的CPU几个通道,怎么设置,我再研究研究之后跟帖~



  • 关于DTCHull中的controlDict,我也有疑问,这个算例没有maxCo ;maxAlphaCo ;maxDeltaT 的设置,而且我跑了之后看log.interFoam,在一般显示Courant Number mean: max: 和Interface Courant Number mean: max: 的地方,却是如图的Flow time scale min/max ,Smoothed flow time scale min/max (这两个值我不是很明白)。
    Screenshot from 2021-04-22 14-48-55.png
    我把这个算例的DTC换了另一个船后(改变了模型和水面值,controlDict没变)发现log里的这个地方显示的是Co Num,而且因为时间步长的设置保持原DTC算例的1,库朗数很大,很快就发散了:
    Screenshot from 2021-04-22 14-58-12.png
    疑问:1.第一个图中的Flow time scale min/max ,Smoothed flow time scale min/max 是什么意义,和什么设置有关;
    2.第一个图的log为何没有显示库朗数Courant Number mean: max: 和Interface Courant Number mean: max;
    3.原DTC算例的时间步长为1应该有很大的库朗数为何顺利收敛了?
    问题也许不太成熟,希望能得到解答,先行谢过。:xiexie:



  • @Joann 我先抛个砖,你的第一个问题应该是因为在fvSchemes里定义ddt的时候使用了localEular,而不是平常用的Eular。我理解的localEular就是在不同的区域根据网格尺寸使用不同的时间步长,所以不会有全局的库朗数输出,但会有最大最小时间步长输出。



  • @tidedrinker 非常谢谢你的回复,长知识了
    我试着两个算例就ddt的选择不一样算了一下,
    选择LocalEular的时候controlDict没有设置MaxCo,maxAlphaCo ,maxDeltaT 可以顺利收敛算到最后,
    选择Eular的时候,显示库朗数,需要有maxAlphaCo,增加了这个设置(值取了15)之后,算到41秒库朗数太大了崩了(exited on signal 8 (Floating point exception).)这个时候应该就需要时间步长较小。
    然后看到了这个帖子
    https://www.cfd-china.com/topic/412/关于时间离散euler与localeuler离散
    才知道用了LocalEular的算是LTSinterFoam的意思,求解稳态问题,所以表明DTCHull这个算例因为属于稳态所以就用了LocalEular时间离散,而另一个DTCHullMoving就不是稳态问题了所以就用了Eular。
    早期的OpenFOAM版本还有LTSInterFoam,https://github.com/OpenFOAM/OpenFOAM-2.0.x/tree/master/tutorials/multiphase/LTSInterFoam


Log in to reply
 


CFD中文网 | 东岳流体学术 | 东岳流体商业 | 吉ICP备20003622号-1