Skip to content
  • 最新
  • 版块
  • 东岳流体
  • 随机看[请狂点我]
皮肤
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • 默认(不使用皮肤)
  • 不使用皮肤
折叠
CFD中文网

CFD中文网

小

小火人

@小火人
关于
帖子
28
主题
2
群组
0
粉丝
0
关注
1

帖子

最新

  • 壁面加密导致其他区域网格被加密,如何改善?
    小 小火人

    https://www.bilibili.com/video/BV1or421x7Ut/?spm_id_from=333.999.0.0&vd_source=5dfca494f85875fa7f031a9f632b1a89
    第9分钟介绍这种High Aspect Ratio对于瞬态、稳态的具体影响。


  • VMware Ubuntu1804
    小 小火人

    @李东岳 2021-10-05 00 28 15.png 东岳老师,我在ubuntu-16.04.6-desktop-i386上面安装of-8,在编译paraview时提示这个异常,查了好久仍没弄明白,想请教下:140:

    2021-10-05 00 38 15.png
    另外有个疑问,就是我看paraview官网都是64位的,i386的ubuntu不能使用paraview吗?我下载解压后,双击bin\paraview没反应:haqi:


  • 四年没搞OF了,再次出发
    小 小火人

    此情此景,作为理工直男,应该说点稍显文学水平的话鼓励下,of好棒,of好厉害,我也好棒好厉害!:tishizi:


  • OpenFOAM后处理与Fluent结果比较
    小 小火人

    @random_ran 多谢多谢!:laughing:


  • chtMultiRegionSimpleFoam前处理未能生constant下finalAgglom文件
    小 小火人

    @cfd-china 对了,出现这个问题的原因,有没有可能是blockMesh单、双精度的原因,还有求解器单、双精度在哪里能看,能否指点下?:expressionless:


  • chtMultiRegionSimpleFoam前处理未能生constant下finalAgglom文件
    小 小火人

    @cfd-china 好哒:laughing:


  • chtMultiRegionSimpleFoam前处理未能生constant下finalAgglom文件
    小 小火人

    @cfd-china 有点意思,神,但如果是
    (-1 -1 -1)
    ( 0 0 0)
    正常走不通,放大操作应该改为
    (-1 -1.001 -1)
    ( 0 0 0)
    还是下面呢?
    (-1 -0.999 -1)
    (0 0 0)
    :confused:


  • chtMultiRegionSimpleFoam前处理未能生constant下finalAgglom文件
    小 小火人

    @cfd-china 经过微小改动热源坐标,总算算例走通了,不过这个问题确实有点意思,毕竟不能每次都这么费力地改动。即使单核计算走通了,并行计算却又报错:sad:


  • chtMultiRegionSimpleFoam前处理未能生constant下finalAgglom文件
    小 小火人

    我在计算一个电路板(表面有许多小元器件热源)表面温度场时,元器件热源通过topoSet设置,如下:
    0_1469973385884_kmodel.JPG

    算例运行出错,后来发现前处理划分网格,有如下问题:
    0_1469973132109_cell缺.png
    0_1469973170788_cell多.png

    log文件表示未能生成finalAgglom文件:
    0_1469973256388_finalAgglom.JPG

    finalAgglom的log文件显示原因在于某cell未能找到:
    0_1469973303509_cell_log.png

    令人匪夷所思的是,仅对topoSet下该元器件box坐标进行微小修改后,算例正常计算,
    改前(运行报错):
    0_1469973827241_2.JPG
    改后(运行顺利):
    0_1469973806836_1.JPG

    各位神,对此有什么好的解决办法吗?毕竟,元器件(小热源)很多,这样无规律的修改模型参数十分繁琐,且毫无方向感。:confused:


  • 有谁知道怎么在openfoam3.0.1上编译foamToTecplot360?求教。
    小 小火人

    0_1469972545332_foamToTecplot360编译.JPG 下载OF-2.3.0对应的tecplot360版本进行编译即可,我在OF-2.4.0版本安装没问题,你可以试试,我的理解是,OF-2.3.0后tecplot没有变


  • 壁面加密导致其他区域网格被加密,如何改善?
    小 小火人

    @Dream_Chaser 嗯,后来这么用了,多谢:tongue_out:


  • OpenFOAM后处理与Fluent结果比较
    小 小火人

    你好,我说下当时情况,记不全了(有点啰嗦,勿怪)。
    1、上面那个是初始算例,后来发现虽宏观上三者基本一致,但注意到OF与Fluent差异更小,以至于后来再也没用CFX比较。
    2、就计算时间差异,单核算即使100h(4天),也可以通过并行将花费时间大幅减小,后来时间差异也没有深究。不过后来过几个算例,双核大概五十多个小时,四核大概二十个小时左右(记不清了)
    3、不知是我设置有问题还是其他原因(上面有人提到原因可能是buoyantBoussinesqSimpleFoam时间步设置成了10-8s,后来我改为1s试了下,并未看到计算时间明显减小),后来有人怀疑残差定义三者有别(听说fluent残差是计算域通量残差积分),考虑到自身课题进度等原因,未花费精力对其深究。
    4、计算设置是固定步数,CFX由于迅速收敛而未达到计算步数,fluent与of到计算步数而未收敛,故计算过程中加大了步数。
    5、当时算例log后来估计删了(,找了没找到,那个算例太原始,没受重视)。
    6、我的浅薄之见:of比CFX、fluent计算慢在情理中,试想一个庞大的商业公司每年养N多人搞开发,如果计算速度不比一套of计算代码快的话就怪了。CFX可能采用了某些神秘的加速收敛方案(我只用过一次CFX),毕竟源代码未公开。:joking: :joking: :lol:


  • 壁面加密导致其他区域网格被加密,如何改善?
    小 小火人

    应该是壁面附近加密造成的,通过主流中间那条黑带也可以看出。:sad: 不过,这发现OpenFOAM的snappyHexMesh或许有可能解决这个问题


  • 壁面加密导致其他区域网格被加密,如何改善?
    小 小火人

    嗯,之前这么初步试过,虽然有所改善,但效果不大理想,再试试


  • 壁面加密导致其他区域网格被加密,如何改善?
    小 小火人

    我的算例是侧向出流的一个通道,由于进出口通道壁面加密导致中间区域网格被加密,从网格数量而言,中间那部分加密既没有加密需要,却会造成网格数量大幅增加。有什么改善的技巧吗?0_1464918756299_图片1.png


  • paraview彩虹条设置
    小 小火人

    改为彩虹色后,但是与tecplot后处理的Fluent彩虹色亮度不一样,如果要进行比较的话,建议在paraview里调一下亮度值


  • OpenFOAM后处理与Fluent结果比较
    小 小火人

    震动,先算了一阶的,然后以一阶结果为初始场改为二阶或高阶后计算的


  • OpenFOAM后处理与Fluent结果比较
    小 小火人

    @cfd-china 嗯,多谢指点,这次讨论获益匪浅:laughing:


  • OpenFOAM后处理与Fluent结果比较
    小 小火人

    @cfd-china 果然是lighting的原因,改后如下:
    0_1464232123700_捕获.JPG


  • OpenFOAM后处理与Fluent结果比较
    小 小火人

    以下三张图依次为buoyantBoussinesqSimepleFoam,Fluent6.3,CFX15.0计算残差曲线,边界条件及k-e模型参数相同,总均为ICEM导出六面体网格,约112w。
    (buoyantBoussinesqSimepleFoam设置delt=10-e8,我擦:big_mouth: ,刚才发现了个openfoam计算设置的错误:big_mouth: :big_mouth: ,不知道这个信息是不是对时间花费很关键,但至少上面of结果不可信了,buoyantBoussinesqSimpleFoam求解器该算例时,controlDict下求解器名字写成了simpleFoam,由于是从simpleFoam下拷贝过来加入换热计算的,这个名字漏掉改了,计算却没报错)。话说回来,我觉得of计算这么慢的主要原因在于我把时间步设置的过小造成的,当时是先算了瞬态,所以算稳态时时间步没有进行修改。
    0_1464231831904_openfoam.JPG 0_1464231853728_fluent.JPG 0_1464231875063_CFX.JPG

  • 登录

  • 登录或注册以进行搜索。
  • 第一个帖子
    最后一个帖子
0
  • 最新
  • 版块
  • 东岳流体
  • 随机看[请狂点我]