Marc
Forum Replies Created

AuthorPosts

May 20, 2021 at 9:10 am in reply to: Output of the rootmeansquare(rms) velocity in the example of channel3D #5681MarcParticipant
Dear Xu Yang,
just check the last three entries of the SuperLatticeTimeAveragedF3D in Paraview, should be your RMS Velocity:
for (int iDim = _sData.getDataSize(); iDim < _sData.getDataSize()*2; iDim++)
if (_sDataP2.get(iCloc,input[1],input[2],input[3],(int) iDim_sDataP2.getDataSize())/_ensembles – _sData.get(iCloc,input[1],input[2],input[3],(int) iDim_sDataP2.getDataSize())*_sData.get(iCloc,input[1],input[2],input[3],(int) iDim_sDataP2.getDataSize())/_ensembles/_ensembles<0) {
output[iDim]=0;
}
else {
output[iDim] = sqrt(_sDataP2.get(iCloc,input[1],input[2],input[3],(int) iDim_sDataP2.getDataSize())/_ensembles – _sData.get(iCloc,input[1],input[2],input[3],(int) iDim_sDataP2.getDataSize())*_sData.get(iCloc,input[1],input[2],input[3],(int) iDim_sDataP2.getDataSize())/_ensembles/_ensembles);
}Best,
Marc This reply was modified 1 year, 6 months ago by Marc.
MarcParticipantDear Xu Yang,
have a look at the functor SuperLatticeTimeAveragedCrossCorrelationF3D. You can find the corresponding source code and documentation in src/functors/lattice/timeAveraged/superLatticeTimeAveraged3D.h(h)
Best Marc
MarcParticipantHey Vinh,
please look carefully at the error message again:
You get the error for the following code line:
fneq_bc[normalInwardsIndices[fIndex]] = fneq_bc[util::opposite(normalInwardsIndices[fIndex])];I told you to replace it by
fneq_bc[normalInwardsIndices[fIndex]] = fneq_bc[util::opposite<DESCRIPTOR>(normalInwardsIndices[fIndex])];Could it be that you leave the template argument <DESCRIPTOR>, which causes the error? In some weeks we will have a new release with a working example of the turbulent channel flow.
Best Marc
MarcParticipantHey Vinh,
it seems that there is an old function call in the src/boundary/wallFunctionBoundaryPostProcessors3D.hh file. Please replace the erroneus line 710 with
fneq_bc[normalInwardsIndices[fIndex]] = fneq_bc[util::opposite<DESCRIPTOR>(normalInwardsIndices[fIndex])];
This should compile.Best Marc
MarcParticipantDear Vinh,
at the moment we don’t have a suitable example to show the working principle of the wall function. We will include a helpful example in the next release. Here is a step by step summary how to use the wall function:
1. you need a suitable Descriptor e.g.#define DESCRIPTOR WallFunctionForcedD3Q19Descriptor
2. Then you should define your wallfunction parameter:
/* Used method for density reconstruction
* 0: ZouHe
* 1: extrapolation
* 2: constant
*/
int rhoMethod = 0;/* Used method for nonequilibrium particle distribution reconstruction
* 0: regularized NEBB (Latt)
* 1: extrapolation NEQ (Guo Zhaoli)
* 2: regularized second order finite Differnce
* 3: equilibrium scheme
*/
int fneqMethod = 3;/* Used wall profile
* 0: Musker profile
* 1: power law profile
*/
int wallProfile = 0;/// special formulation for straight boundaries
bool curved = false;/// use van Driest damping function in boundary cell
bool useVanDriest = true;/// von Karman constant for van Driest model
T vonKarman = 0.375;wallFunctionParam<T> wallFunctionParam;
wallFunctionParam.curved = curved;
wallFunctionParam.bodyForce = true;
wallFunctionParam.wallProfile = wallProfile;
wallFunctionParam.rhoMethod = rhoMethod;
wallFunctionParam.fneqMethod = fneqMethod;
wallFunctionParam.latticeWalldistance = latticeWalldistance;
wallFunctionParam.vonKarman = vonKarman;3. define a suitable Dynamics on your wall function boundary
ExternalTauEffLESForcedBGKdynamics<T, DESCRIPTOR> boundaryDynamics (converter.getLatticeRelaxationFrequency(), instances::getBulkMomenta<T,DESCRIPTOR>());
In Prepare Lattice
sLattice.defineDynamics(superGeometry, 2, &boundaryDynamics);
sBC.addWallFunctionBoundary(superGeometry, 2, converter, wallFunctionParam);I hope this helps you!
Best,
MarcMarcParticipantDear Lucas,
I would recommend you to use slip boundaries for the upper and lower wall, because you want to set a symmetry boundary condition. Furthermore you must ensure that your domain is large enough to diminish the boundary influence on the results.
Best Marc
MarcParticipantHey Frank,
you will find the code for the AnalyticalLinear2D functor in src/functors/analytical/analyticalF.hh. There you can check the implementation:
template <typename T, typename S>
AnalyticalLinear2D<T,S>::AnalyticalLinear2D(S x0, S y0, T v0, S x1, S y1,
T v1, S x2, S y2, T v2)
: AnalyticalF2D<T,S>(1)
{
this>getName() = “linear”;
T n2= (x1x0)*(y2y0) – (y1y0)*(x2x0);
if ( util::nearZero(n2) ) {
std::cout << “Error function” << std::endl;
} else {
T n0 = (y1y0)*(v2v0) – (v1v0)*(y2y0);
T n1 = (v1v0)*(x2x0) – (x1x0)*(v2v0);
_a = n0 / n2;
_b = n1 / n2;
_c = (x0*n0 + y0*n1 + v0*n2) / n2;
}
}if you want to print the _a, _b, _c variables, you can use e.g. a std::cout statement. The error in your second case is that your are using lattice coordinates (converter.getLatticeLength(1.)) instead of physical coordinates (1.0). This seems to be the reason for your decreased velocity.
Best Marc
MarcParticipantDear Sabet,
unfortunately we don’t have a released example. I hope that we will have an useful example in the next release. If you want more information, please send me an Email.
Best,
MarcMarcParticipantDear Mehdi,
the current implementation is not able to simulate moving walls, but we have an tested implementation that is able to do this. I wrote therefore a new infrastructure. Unfortunately, I can not promise that it will be included in the next release. Please send me an Email (marc.haussmann@kit.edu) and I can give you further information.
Best,
MarcMarcParticipantDear Sthavishtha,
the differnence is that MRTdynamics use descriptors::s<T,DESCRIPTOR> and MRTdynamics2 use descriptors::s_2<T,DESCRIPTOR>. This means the collision matrix in Mrtdynamics2 is changed. You can find the collision matrix s and s_2 in src/dynamics/mrtLatticeDescriptors.h.
Best Marc
MarcParticipantDear Ryan,
thank you for your feedback. The written value is not correct and the functor will hopefully replaced in the next release. We are not able to resolve the flowfield entirely. You can have a look at the laminar/poiseuille3d example, there you find a working calculation of the wall shear stress. The criteria to decide if a boundary layer is resolved, are the same for LBM and FVM. Unfortunately, OpenLB does not feature grid refinement at the moment. So it is hardly feasible to address wallresolved LES at high Reynolds numbers.
Best,
MarcOctober 28, 2019 at 12:13 pm in reply to: Exporting STL file to the simulation engine: UNKNOWN MATERIAL NUMBER #4653MarcParticipantDear Mehrdad,
firstly you can check the console output of the voxelizer:
[STLmesh] nTriangles=2654; maxDist2=0.000610779
[STLmesh] minPhysR(StlMesh)=(0.199901,0.0900099,0.0117236); maxPhysR(StlMesh)=(0.243584,0.249987,0.0398131)
[Octree] radius=0.143744; center=(0.221602,0.169858,0.025628)
[STLreader] voxelSize=0.0005615; stlSize=0.001
[STLreader] minPhysR(VoxelMesh)=(0.199984,0.0904058,0.0118712); maxPhysR(VoxelMesh)=(0.24322,0.249872,0.0393847)
[STLreader] Voxelizing … OKPlease check for your case, if the min and max dimensions of the stl mesh and the voxel mesh are correct.
In a further step you can check the Octree of the stlindicator with the call:
stlreader.writeOctree(); // (output is saved in the tmp floder)If the octree is not correct you can try to use other indicate functions (e.g. 1 or 3)
The prepare geometry step is sequential, so you can check after each renaming procedure the output to test, where the renaming problem occurs.
Best Marc
MarcParticipantDear YangLiu,
we don’t have a implemented import functionality for your purpose. You have two options either you transfer your voxelized geometry into stl and read it in by our default stl interface or you write a new interface by your own.
Best Marc
MarcParticipantDear Aurelio,
I just can guess, because I don’t know your simulation setup. If you want to simulate such a high Reynolds number, you should respect your grid spacing.
How do you estimate your grid spacing?
Do you have a wallbounded flow, if this is the fact what is your y+?
If you grid is to coarse you have to deal with a small tau, which could lead to instabilities.
Do you know where the instabilities occur? (at the boundaries, at the gas liquid Interface…)
You lattice velocitiy is too high, you should avoid lattice velocities higher than 0.1.My suggestions:
increase your grid size to get a stable simulation
estimate your smallest scales and adapt your grid spacing again to get physical meaningful resultsBest Marc
April 17, 2019 at 2:30 pm in reply to: Smagorinsky Turbulence Model and TRT collision operator #4244MarcParticipantHey tobit,
it is nice to hear that you achieve stable boundaries for high Reynolds numbers. The term interpolated I mentioned before was related to the boundary naming that we have in OpenLB. Our implementation of the interpolated boundary is described in Latt et al. “Straight velocity boundaries in the lattice Boltzmann method” (BC4). Guo’s neq Extrapolation is also a good choice!
Best Marc

AuthorPosts