CFD中文网

@zhangxc0223 老铁实现了吗？如何不通过createFields添加新变量来输出变量？或者怎么添加不需要read的变量来输出？我试了no_read还是提示没有对应文件

@ldymig openfoam+CFD-DEM+Lighhhts 我没有用过，不过听说是计算速度还可以，就是内存需求比较大？后面准备做CFD-DEM，也在找合适的方案

openfoam的颗粒计算居然不是并行的？！那工程计算，甚至很多科学计算都无法使用啊……那看来现在CFD-DEM还是用openfoam+CFDDEM+Liggghts更靠谱？

@D-Benjamin 具体一共都有哪些函数我也不是很清楚，具体函数和怎么用通常都是看看openfoam自带的边界或者求解器或者其它的应用有类似你想获得功能，就去翻源代码。gsum应该也可以对边界上的网格体积或者面进行求和，应该就能实现你说的功能。

个人理解，如果不改transport property的话，引用的nu应该要加上phase1的关键字，比如可能要输出的应该是nu.air。关键是看nu在你用的solver里注册成了什么名字，这个名字可能和输入的名字完全不一样（注：是注册的名字不是变量名）

这个问题应该可以通过对已有的边界条件进行简单的修改，形成新的边界条件，可以参考cyclic边界让入口获取出口的patchID，然后gsum求和再付给入口。并行的问题可能是在循环出口边界的时候，每个processor多计算了分界处的网格（这只是我的猜测，我没用试过代码）。推荐用g开头的openfoam自带的函数，这些函数都是支持并行的并会自动广播的，不需要你自己再考虑并行的问题，除非你要实现的功能没有。

是欧拉-欧拉，确实如果引入边界条件的话不知道压力场怎么处理。谢谢分析，我再想想。加多孔介质主要就是物理上好解释，我现在觉得可以在wall的区域再附加一个指向wall外面的源项（根据具体问题可以指定方向），类似重力，以此抵消重力以及其它数值问题造成的穿透问题，相当于在这个源项下，wall区域的固体会被很缓慢地排出wall。我估计一开始如果就加上的话，可能就可以阻止固相进入wall，而且有多孔介质巨大的阻力系数在，排出的固相应该速度非常小，对wall外面的计算应该影响有限。

希望实现如题的功能，请各位不吝指教。

希望在两相流中设置一个区域或者一个面（比如一面墙），只有某一相能感受到，比如固相会感受到这面墙且无法穿透，但是对于气相则完全没有作用。有没有什么简单的思路可以实现？

我尝试在墙的位置添加了多孔介质源项，这个源项只作用于固体，且系数非常大，刚开始基本可以达到要求，但是由于多孔介质的阻力和速度有关，所以还是随会计算进行（物理计算时间非常长），会有固相以非常缓慢的速度在重力的作用下穿透这面墙……

@Calf-Z-DNS 圆管不会泄压吗？我计算二维的box，左右壁面，也是会出现泄压的问题。如果cyclic确实是周期边界的话，我觉得即使是3维无限大平板间流动，或者三维全周期流动，也都不应该出现泄压或者质量不守恒的问题，因为从任何边界流出去的都会从对应的neighbour流进来，所以我怀疑openFOAM里面的cyclic并不是准确的periodic，当然具体还是要看代码，我最近正在看。

@马乔 在 OF文件读写 中说：

#include "fvCFD.H"

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
//

class proxyWriter
:
    public regIOobject
{
private:
    scalar value_;

    proxyWriter(const proxyWriter&) = delete;
    void operator=(const proxyWriter&) = delete;

public:
    proxyWriter(const IOobject& io, const scalar& value)
    :
	regIOobject(io),
	value_(value)
    {
    }

    virtual bool writeData(Ostream& os) const
    {
	os<<value_;
	return os.good();
    }

    proxyWriter& operator++()
    {
	++value_;
	return *this;
    }
};


int main(int argc, char *argv[])
{
    #include "setRootCaseLists.H"
    #include "createTime.H"

    // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

    proxyWriter writer
    (
	IOobject
	(
	    "value",
	    runTime.timeName(),
	    runTime,
	    IOobject::NO_READ,
	    IOobject::AUTO_WRITE
	),
	0.
    );

    Info<< "\nStarting time loop\n" << endl;

    while (runTime.loop())
    {
        Info<< "Time = " << runTime.timeName() << nl << endl;

	++writer;

        runTime.write();

        runTime.printExecutionTime(Info);
    }

    Info<< "End\n" << endl;

    return 0;
}
:chigua:

@马乔 @Samuel-Tu 请问这个怎么用？这是重新编译一个lib然后link到controlDict吗？那怎么知道是在这一步的什么时候输出？是计算前还是计算后？

最近在研究边界条件的问题，想复制一个边界条件出来修改编译测试。参考了网上的教程，但是还是有些问题，想请教大家。

OpenFOAM里面的边界条件有些只包括一个C文件，一个H文件，这种边界条件按照网上的教程都可以直接编译。比如fixedFluxPressure，我拷贝到新的文件夹test下，创建一个Make文件夹，在其内部创建files和options文件：
files:

fixedFluxPressure/fixedFluxPressureFvPatchScalarField.C

LIB = $(FOAM_USER_LIBBIN)/libUsr

options:

 EXE_INC = \
	-I$(LIB_SRC)/finiteVolume/lnInclude\

LIB_LIBS = \
	-lfiniteVolume

编译正常。
但是还有一部分的边界条件包含多个C文件和H文件，这种就编译不成功了。以cyclic为例，拷贝$FOAM_SRC/finiteVolume/fields/fvPatchFields/constraint/cyclic 到testcyclic文件夹，test下面生成Make文件夹，Make里面建立files和options:

files:

cyclic/cyclicFvPatchField.C

LIB = $(FOAM_USER_LIBBIN)/libcyclicFvPatchField

options:

 EXE_INC = \
	-I$(LIB_SRC)/finiteVolume/lnInclude\

LIB_LIBS = \
	-lfiniteVolume

执行wmake libso

wmake libso .
wmakeLnInclude: linking include files to ./lnInclude
Making dependency list for source file cyclicFvPatchField.C
g++ -std=c++11 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -O3  -DNoRepository -ftemplate-depth-100 -I/home/xc15/OpenFOAM/OpenFOAM-7/src/finiteVolume/lnInclude -IlnInclude -I. -I/home/xc15/OpenFOAM/OpenFOAM-7/src/OpenFOAM/lnInclude -I/home/xc15/OpenFOAM/OpenFOAM-7/src/OSspecific/POSIX/lnInclude   -fPIC -c cyclic/cyclicFvPatchField.C -o Make/linux64GccDPInt32Opt/cyclic/cyclicFvPatchField.o
cyclic/cyclicFvPatchField.C:32:1: error: redefinition of ‘Foam::cyclicFvPatchField<Type>::cyclicFvPatchField(const Foam::fvPatch&, const Foam::DimensionedField<Type, Foam::volMesh>&)’
 Foam::cyclicFvPatchField<Type>::cyclicFvPatchField
 ^
In file included from cyclic/cyclicFvPatchField.H:225:0,
                 from cyclic/cyclicFvPatchField.C:26:
cyclic/cyclicFvPatchField.C:32:1: error: ‘Foam::cyclicFvPatchField<Type>::cyclicFvPatchField(const Foam::fvPatch&, const Foam::DimensionedField<Type, Foam::volMesh>&)’ previously declared here
 Foam::cyclicFvPatchField<Type>::cyclicFvPatchField
 ^
cyclic/cyclicFvPatchField.C:44:1: error: redefinition of ‘Foam::cyclicFvPatchField<Type>::cyclicFvPatchField(const Foam::fvPatch&, const Foam::DimensionedField<Type, Foam::volMesh>&, const Foam::dictionary&)’
 Foam::cyclicFvPatchField<Type>::cyclicFvPatchField
 ........
make: *** [Make/linux64GccDPInt32Opt/cyclic/cyclicFvPatchField.o] Error 1

error太长，只贴了一部分，但是基本上都是说重复定义和声明

正确的编译方式应该是什么？

@Samuel-Tu 求解器里面用info输出吗？有办法能输出到单独的文件里面吗？

@random_ran 谢谢您的关注。我在controlDict里面输出了全场的固含率、速度、压力，不需要计算完就可以看到质量明显的不守恒。

如果您把fvOption加的源项去掉，仅在重力作用下计算还会出现颗粒相沿重力反方向运动的非物理现象……

但是如果我不使用周期边界，上下边界也设成壁面，是会出现比较正常的固相堆积在底部，气相被挤压到上部运动趋势和结果，且质量是守恒的。

所以我考虑问题应该还是出在cyclic边界上，具体需要看一下cyclic怎么实现，对于单向流和多相流的差别在什么地方，我最近也好好研究一下。如果您有什么想法和发现，欢迎讨论和指导。

another same issue https://www.cfd-online.com/Forums/openfoam-solving/199582-twophaseeulerfoam-dispersed-phase-not-conservative.html

@random_ran @Calf-Z-DNS @东岳 各位大神，我在CFD-online上找到了一个类似的问题%(#006fff)[https://www.cfd-online.com/Forums/openfoam-solving/146839-cyclic-boundary-violates-mass-conservation.html]，似乎cyclic BC在处理两相流的时候会导致质量不守恒。苦于刚接触C++和openFAM，我确实看不明白cyclic边界具体是如何实现的。请问各位有什么理解，有什么文章可以推荐一下吗？

@random_ran 谢谢您的回复，这是我的测试算例cyc_test.zip

我的算例是两相流的2D算例，求解器用的twoPhaseEulerFoam，重力沿-z，然后fvOption的meanvelocityForce给了气体一个+z方向的源项保证气速，计算开始后我输出的全场平均压力在不断降低，固含率也无法保持恒定。虽然不可压缩流动的绝对压力没有意义，但是总压和固含率的变动无法解释。并且这种情况在撤掉气体上的源项，也即只施加重力的情况下仍然存在。

关于channel395的算例，如果把初始的压力场不设为0，也会出现迅速泄压的情况，不过看起来流场还是比较正常。对于C++和openFOAM都是刚接触，基本照着算例改的，很多设置还没有搞清楚，不知道是不是我的设置有问题？

@浪迹天大 ControlDict里面的writeControl和writeInterval似乎会覆盖前面的？

application     twoPhaseEulerFoam;

startFrom       latestTime;

startTime       0;

stopAt          endTime;

endTime         2;

deltaT          1e-4;

writeControl    timeStep;

writeInterval   100;

purgeWrite      0;

writeFormat     ascii;

writePrecision  6;

writeCompression off;

timeFormat      general;

timePrecision   6;

runTimeModifiable on;

adjustTimeStep  no;

maxCo           0.9;

maxDeltaT       1e-04;

functions
{
    
   volFieldValue1
   {
       type            volFieldValue;
       libs            ("libfieldFunctionObjects.so");

       log             true;
       //writeControl    writeTime;
        writeControl    timeStep;  
        writeInterval   1;   //"这里的writeInterval 1 似乎会覆盖前面的100导致所有的输出都是每个时间步都输出？"
       
       writeFields     true;

       regionType      all;
       operation       volAverage;

       //weightField     alpha1;

       fields
       (
           alpha.particles   
           U.air
           U.particles  
           p
           p_rgh
       );
   }
}

@Calf-Z-DNS 我最近计算周期边界也发现了这个问题。我测试的系统是个2维系统，左右（x方向）壁面，上下（z方向）周期，,y方向一层网格empty，算气固两相流，用twoPhaseEulerFoam求解器，重力方向沿-z，然后用fvOption的meanvelocityForce保证气体全场平均速度为定值，初场给定固含率0.1。计算开始全场平均压力不断降低，不过监测的全场平均气体速度确实是我给定的值，最奇怪的是整体固含率会不断降低，最后会降到非常低，局部最低固含率都负数了，然后固含率又开始升高，压力也开始升高……总感觉openFOAM里面的cyclic边界有问题……把fvOption去掉，仅在重力下计算，也有同样的现象。不知道你对这个问题有什么新的认识吗？