没事,找到错误就好。这个方法其实比较笨,因为每次你修改网格,就要重新处理一遍数据。
有的时候会麻烦一些。
祝收敛
没事,找到错误就好。这个方法其实比较笨,因为每次你修改网格,就要重新处理一遍数据。
有的时候会麻烦一些。
祝收敛
@wsy11 在 【分享+搬运】自定义非均匀inlet U 中说:
@星星星星晴 这个视频我已经看过了,也参考了视频中的步骤。
我把目录改成英文以后还是同样的报错,
我在其他的地方没有什么改动,都是用的tutorials\incompressible\simpleFoam\windaroundbuildings算例自带的条件。
,
肯定不是目录的问题,只是建议你不要使用中英文混合目录。
我查了一下我之前的CASE,是不是少了一个分号?
/*--------------------------------*- C++ -*----------------------------------*\
========= |
\\ / F ield | OpenFOAM: The Open Source CFD Toolbox
\\ / O peration | Website: https://openfoam.org
\\ / A nd | Version: 10
\\/ M anipulation |
\*---------------------------------------------------------------------------*/
FoamFile
{
format ascii;
class volVectorField;
object U;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Uinlet (10 0 0);
dimensions [0 1 -1 0 0 0 0];
internalField uniform (0 0 0);
boundaryField
{
inlet
{
type fixedValue;
value nonuniform List<vector>
494
(
( -1.2961 0.0000 0.0000)
( -0.7059 0.0000 0.0000)
( -0.2917 0.0000 0.0000)
( -0.0393 0.0000 0.0000)
( 0.0672 0.0000 0.0000)
( 0.1305 0.0000 0.0000)
( 0.1642 0.0000 0.0000)
( 0.1796 0.0000 0.0000)
( 0.1850 0.0000 0.0000)
.......
........
( 0.3551 0.0000 0.0000)
( 0.3592 0.0000 0.0000)
( -0.2114 0.0000 0.0000)
( 0.1055 0.0000 0.0000)
( 0.1069 0.0000 0.0000)
( 0.1057 0.0000 0.0000)
( -0.2113 0.0000 0.0000)
( -0.2135 0.0000 0.0000)
);
}
outlet
{
type pressureInletOutletVelocity;
value uniform (0 0 0);
}
wall
{
type noSlip;
}
#includeEtc "caseDicts/setConstraintTypes"
}
@wsy11 首先我建议你不要用中文目录。。
另外你的Error 写的是
Cannot find patchField entry for outlet。
是不是你其他的地方设置错了呢?
额,我已经很长时间没碰过这个东西了,建议你有条件看看那个youtube的视频!
@lyc 哦哦 所以正常情况下 positions里面应该是barycentric坐标,但是为什么你的case里面就只有这么几个数字就不知道了。
/*--------------------------------*- C++ -*----------------------------------*\
========= |
\\ / F ield | OpenFOAM: The Open Source CFD Toolbox
\\ / O peration | Website: https://openfoam.org
\\ / A nd | Version: 8
\\/ M anipulation |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class Cloud<passiveParticle>;
location "0.64/lagrangian/sprayCloud";
object positions;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
1656396
(
(0.04422067751 0.5540185624 0.3809619217 0.02079883845) 760548 2268048 2
(0.1546921353 0.1803744222 0.05967081669 0.6052626258) 759449 2265159 2
(0.09719880177 0.1125485611 0.3328846329 0.4573680042) 813065 2424670 2
(0.3671454797 0.1819634579 0.07532737629 0.3755636861) 812635 2423788 2
(0.04635296206 0.6766449271 0.1730520394 0.1039500714) 866648 2584882 1
(0.1204208922 0.2634564704 0.3806695666 0.2354530708) 824671 2459267 2
(0.2457338888 0.2946520318 0.2575474936 0.2020665858) 920105 2704057 2
(0.07306399804 0.145526467 0.294643519 0.486766016) 851535 2539390 1
@lyc 另外你可以通过paraveiw里面的spreadsheet 看到每个场具体的数,比如说nparticle
Barycentric coordinate system?
但是我的这边的case的输出结果是 ( a b c d) aa bb cc 7个数。在posisitons文件中,我还有一个文件叫position0,就是正常的三位坐标
我用的是OF8
而且你最上面那个2 代表说就只有两个parcel吧 怎么能生成这样的图呢?
建议你用paraview看一下,如果确定了可以在论坛里说一下~
另外如果这个不是的话,你看看这两个数是什么?
我也不记得是不是我调了code,lagrangian文件夹里面有个nParticle文件,那个是代表parcel中的particle的数量
你给的链接的第二个方法能用啊
@dxl 我印象中拉格朗日这边OF5以后发生了一些变化,不知道你用的什么版本。
但是归根到底就是在拉格朗日那边有一个判断。后续版本好像转为p.fraction了
如果dt太小,这拉格朗日的计算就跳过了
https://github.com/OpenFOAM/OpenFOAM-8/blob/master/src/lagrangian/intermediate/parcels/Templates/KinematicParcel/KinematicParcel.C
line 334-348
// Avoid problems with extremely small timesteps
if (dt > rootVSmall)
{
// Update cell based properties
p.setCellValues(cloud, ttd);
p.calcDispersion(cloud, ttd, dt);
if (cloud.solution().cellValueSourceCorrection())
{
p.cellValueSourceCorrection(cloud, ttd, dt);
}
p.calc(cloud, ttd, dt);
}
好久没碰了,特别细节忘记了。
@lyc 不好意思,我不知道答案
@李东岳
2body 不就是这样嘛
说的牛逼点就是考虑3-body了
@李东岳
就是空间里有n个颗粒,计算每3个颗粒之间的距离,用于后续的计算,电动势什么的。
手上有个code,三重循环,当前的算法是用了一个cutoff distance,于是导致循环里面有几个if。
这个能算,就是效率低。
问问看有没有什么已知的更高效的算法,求思路。
第一个问题问的太general了
各位大佬,请问有没有人知道有没有什么可以计算任意三个粒子之间的距离的算法?
除了说三重循环直接干的那种?
感谢
@lrl3512 这你就遇到了难点,比如parcel穿过processor怎么办?你想想有没有其他的方法能单独对每个parcel赋值?
@lrl3512 nParticle? 这只是代表一个parcel友多少个particle,和你说的东西无关的,你看filter一下 这几个id有关的东西 在po出来看看,我印象中好像是你走的是并行,所以不同的processor都是从0开始给parcel id的,你得把他们连起来
@lrl3512 你可以先在paraview看一下 用spreadsheet,是不是每个parcel都有对应的id。
@lrl3512 好像是originID,忘了,快一年没搞这些东西了,基础的还记得。最简单的,你在你的case 里面,lagrangian文件夹,一查就知道了,每个文件都是一定顺序的,不然of怎么知道哪个对应哪个,找到对应的编号 然后一直输出就行。
但这部分正好是lagrangian贵的地方,
@lrl3512 因为你在paraview中处理的都是储存的特定时间点的颗粒性质,除非你的timestep足够小,不然这根本算不上跟踪。
如果你想追踪特定的parcel,只能单独在某个地方单独让of写出来。譬如couldfunction,或者你去动你用的parcel.C。
不是很复杂的
@田畔的风 之前用of的时候,从来没考虑过这种优化 -O2 -O3, -xHost等等
现在知道c++编译的时候有这么个东西,所以就是给个想法。。谁知道是不是在某个版本,of添加了相关的东西呢?反正这种编程的手法基本上是不会错的。
无论是GCC还是Intel compiler 无论C/C++还是Fortran,在涉及到高性能计算的时候难免会遇到性能表现低于预期的情况。在刨除硬件原因,程序的编写也是个值得注意的地方。
矢量化是将算法从一次对单个值进行操作转换为一次对一组值进行操作的过程。现代 CPU 直接支持向量运算,其中单个指令应用于多个数据 (SIMD)。
https://www.intel.com/content/www/us/en/developer/articles/technical/vectorization-a-key-tool-to-improve-performance-on-modern-cpus.html
矢量化这里指的并不是说将变量转换为array 或者向量,矩阵。这里指的是编译的时候,基于AVX512/SSE等CPU指令集的优化。
下面是Intel 官方提供的 A Guide to Vectorization with Intel C++ Compilers.
https://www.intel.com/content/dam/develop/external/us/en/documents/31848-compilerautovectorizationguide.pdf
在我使用OpenFOAM的经历中,OF的编译都是直接使用wmake然后系统会自动编译,从来没有考虑过什么Compiler flag,有没有矢量化等等。
因此,有的时候user-define的model往往成为高性能计算的bottleneck。希望有空的时候,有些同学可以研究一下,提高计算效率~同时在b占看到用人用inteladvisor记性程序性能分析测试,推荐一波,没仔细看,但是感觉挺有用。
https://www.bilibili.com/video/BV1bg411S7kY/?vd_source=9b9f509ff457caa06206ec8f5560c371
不知道现在还能不能邀请注册了,我的名额早就用出去了。
如果有小伙伴热心,帮忙邀请一下这位同学。
10.1615/AtomizSpr.2017019354
可能说的是这个东西
刚才看了一下gay hub,发现真的是完全不一样了啊。。
还臭不要脸的添加了legacy
就这更新速度,生产队的驴也没有这么能干啊。。
@李东岳 当时看到 9 把lagrangian改成那个样子,就已经停留在8了,现在这么快都到11了。看起来也是有好多修修补补
所以以后查资料得看年份了,年份越久,可能越没啥鸟用
@vbcwl 6
@vbcwl 你竟然在移动硬盘里跑。。本身usb的速度限制是一方面,另外你就不怕硬盘坏了么。。牛
@vbcwl 额 你说的什么文件?我不用DPMFoam的,当年这也就是提供个思路。
你要查什么field? 有些field是不会写出来的,你得具体找你要查的什么,给他命令让他写出来,再编译,你就能查看到了。
@疏影横斜水清浅 hi,并没有。后来也不需要了
如果单纯为了喷射粒子,你完全可以不需要用内部平面,你可以直接设置一些喷射点,mannulinjection。
@vbcwl 在 添加粒子后计算速度变慢 中说:
前辈您好。颗粒体积远远小于网格体积,流体体积分数都接近于1,我最上面第三个图就是。我这个流向和展向尺寸比直径小很多,但是法向因为近壁面要加密并且法向尺寸也比较小,壁面处网格已经比颗粒直径小了,论文里普遍要求颗粒直径要小于法向网格尺寸,dp/Ymin一般小于0.5就可,我这里dp/Ymin大概是4了,也有一些人颗粒直径大于网格法向尺寸的。
这部分我没有发言权,我没做过这样密集的颗粒的研究,所以既然你的 $dp/Ymin \approx 4$ 那说明你这样做肯定是有问题的,到底怎么解决,我就不知道了
@vbcwl 在 添加粒子后计算速度变慢 中说:
然后最大库朗数是controlDict里的,我的算例参考自带的GoldSchmidt改的。
那这个是流体相的时间步设置。你如果用动态的timestep 这一项是有用的。会根据你的流场的Co来决定你的欧拉时间步。
但是你用的是PIMPLE求解的话,流场maxCo设置小于1是没有意义的啊。。那就直接用PISO好了啊。。 何必用PIMPLE去耦合浪费时间呢?
我个人理解的PIMPLE的意义就是在Co>1下耦合速度场和压力场保证计算收敛。
在kinematicCloudProperties里没有见到拉格朗日时间步的设置,我看别的求解器的算例下的cloudProperties有maxCo。
你看你的终端的输出,可能会有你拉格朗日的maxCo的设置。不然你就是default,这个要看你的code里面的设置是多少了。
您的意思是,如果设置了拉格朗日时间步长,假如这个时间步长是1,controlDict里的时间步长是2,那么每一步求解流场的同时,会求解两步颗粒场,同时最后一步的颗粒作用力被耦合到流体相中去,是这个意思么?
差不多是的,默认的OF是根据你的颗粒的MaxCo来决定每一个拉格朗日步的stepfraction,然后一点一点计算的。准确来说是每个拉格朗日步都会生成一个UTrans的source term,然后叠加起来,最后在solver中通过source term将颗粒对流场的影响添加进来。这也就是所谓的2-way coupling。
在kinematicParcel.C里面,这些都有写。
然后如果没有设置拉格朗日的时间步长那么,颗粒相与流体相采用同样的时间步长,这么理解对么?
不是,如果你没有对默认的拉格朗日库做调整的话,这个是由cloudProperties有maxCo决定的。
@vbcwl 你说的是MaxCo? 在cloudproperties的?
那是当然。。这里面的MaxCo决定的是你的lagrangian time step。是颗粒的时间步。你设置的越小,则代表对颗粒的子循环次数更多。从而导致你的UTrans 可能是不一样的。
你现在的情况,从我个人的认知是,说明你的粒子速度快,网格细,从而需要更小的lagrangian time step去resolve你的颗粒运动。也有可能是你的np过大,导致颗粒质量过大,从而导致你的momentum exchange过大。
你加颗粒是为什么?你的重点是颗粒还是流场?
@vbcwl 在 添加粒子后计算速度变慢 中说:
@李东岳 请问下,粒子直径和和网格尺寸有什么关联么?这个粒子直径之前是验证过在当前雷诺数下是没有问题的,现在跟之前比就是网格更细了,雷诺数基本没怎么变化的
欧拉拉格朗日对网格是有依赖的。颗粒直径和网格尺寸是有关联的,你的theta field 也就是alpha是多少,即cell中的颗粒体积/cell体积是多少,理论欧拉拉格朗日建议小于0.6,但是dpmfoam这块好像总会忽略这个问题。
具体要根据你的东西来,你也要看别人的论文怎么说。
如果按你说的2-way coupling的话,那颗粒自然会对速度流场有影响,速度场有影响的话自然pimple就要多算的吧
你现在的Co是多少,尝试减少一下你的Euler Time step。
或者你先跑 1-way coupling,你就能判断出到底是不是因为颗粒对流场的作用导致你计算变慢。
@cccrrryyy 暴露年龄之
楼主好人,一生平安
课程材料原地址是:
https://www.tfd.chalmers.se/~hani/kurser/OS_CFD/
个人认为这里面提供的一些材料很有帮助。
前两天有一次不知道怎么回事,这个网站登不进去了,于是整个爬了下来,可以解压缩后,打开index.html即可。
链接: https://pan.baidu.com/s/1qvtJRMlIj-V4cAcAX6rlaA 提取码: j9gf
@jasper-0 这就得你自己翻code了,得看你用在算什么,dense的话需要考虑体积比什么的了,看起来这玩意就是和dense的有关
你指的SU应该是动量方程里面的源项,就是2-way coupling中的颗粒对流场的影响,那边是包涵了所有的颗粒对流场的影响的,具体你得去code里面查到底是怎么算的。
如果你考虑的是颗粒受力的话,你就得去submodel里面看了。
植入颗粒的话,下面这个教程可能说的更清晰
https://www.foamacademy.com/wp-content/uploads/2018/03/particles_slides.pdf
至于你说的phicForces 因为没做DPMFoam 所以不知道具体是什么,不过看起来这个好像用在很dense的颗粒模拟里面吧
@dxl 就是foamtovtk以后,在paraview中读取lagrangefield,然后加一个glyphy
会不会是质量有问题?sum变成了0.5就不对了吧
const polyMesh& pmesh = this->owner().mesh();
List<DynamicList<typename CloudType::parcelType*>>& cellOccupancy =
this->owner().cellOccupancy();
// check all cells containing particles
forAll(pmesh.cells(), celli)
{
if ( cellOccupancy[celli].size() == 0 )
{
// do something
}
else
{
// do something else
}
}
@小狗狗 DPM中半径不可以为0
@小狗狗 你这么说的话 就是质点, 不考虑半径
@小狗狗 我没处理过这样的问题,无法给你准确答案。但是我认为是不可以的,就类似你计算drag的时候同样也要考虑半径,当你考虑空间关系的话,应该也需要将其考虑为真正的小球。比如用拉格朗日模拟气泡壁面的话,肯定也要考虑气泡与避免的距离一样。
@小狗狗 怎么说呢,parcel是point mass,有质量,有体积的particle的集合。
请问你说的假设半径为0指的是什么?
DPMFoam的parcel是有半径的,但是不会像DEM那样真正的占据一定体积。就是一个数,所以euler-Lagrange才对parcel占网格体积比有要求
@zhe 雷猴啊,同事要做三相的模拟,请问你做的咋样啦~
【【吴恩达-2022-中英字幕】令人醍醐灌顶的机器学习(我愿称之为人工智能AI教程天花板)】 https://www.bilibili.com/video/BV1pZ4y1v7Cf/?share_source=copy_web&vd_source=fba9ec24547e03fdba24485fc0a744a5
@李东岳 光猫要是有端口转发功能的话,你可以转发端口到你的内部ip
比如ssh 是22 于是你就转22号端口到你的本地机器192.168.1.111的22端口
你在外网 ssh 就行,关键是转发
@林飞2020
Bouncing?VOF?我不是做fluent的 但是做液滴碰撞实验。
看论文讲到液滴碰撞用VOF模拟,VOF法天然融合,没办法的,有一些比较tricky的方法,但是都非物理性的。
也有人用AMR,不知道Fluent有没有AMR,去产生极小的cell去离散两个液滴之间的气体膜,等等。还有说范德华力等等
论文:
10.1017/jfm.2021.797
10.1103/PhysRevFluids.5.113601
10.1007/s10494-012-9415-y
http://www.ilass.org/2/conferencepapers/64.pdf
简单的VOF是无法直接做出来的
cellI = p.cell();
scalar& PPC = summass_->primitiveFieldRef() [cellI];
PPC += p.nParticle()*p.mass();
我的技能也是有限,所以没有办法给你解决所有问题,你可以自己试试,找找资料,如果发现更好的办法,也希望你分享出来。
对于方法2,我个人有个想法,你获得你所要区域的cell number, 然后仅仅对这些cell进行输出也可以的。我自己没做过,大家都是摸着石头过河,可能每个人的解决方法并不通用,很case- sensitive,这也是开源的一个弊端。。
祝你好运~