April 16, 2021 at 5:06 am #5605
I’m looking at the content of the unit conversion, but the internal mechanism of the conversion is not clear. Do you have any relevant learning materials?
GloriousfaceApril 16, 2021 at 3:00 pm #5607
please have a look at the book “The Lattice Boltzmann Method” by Krüger et al. [https://www.springer.com/gp/book/9783319446479] which dedicates an entire Chapter to this task.
More information about the unitConverter in OpenLB can be found in the User Guide (https://www.openlb.net/wp-content/uploads/2020/12/olb_ug-1.4r0.pdf, see Section 2.4 “Lesson 4: UnitConverter – Lattice and Physical Units”).
Please note that akin introductory topics are taught at our yearly Spring school (https://www.openlb.net/spring-school-2022/), which offers many benefits for learning LBM and OpenLB.
StephanApril 17, 2021 at 12:25 pm #5608
Thanks for your reply and I have another question.
I’m looking at bstep2d. I find that the thickness of the import boundary is 0, but the thickness of the export boundary is certain. What’s the difference between the two methods? The code is attached below.
Vector<T,2> extendBC_out( 0 + 1.*converter.getPhysDeltaX(),heightChannel );
Vector<T,2> extendBC_in( 0, heightInlet );
Vector<T,2> originBC_out( lengthChannel – 1.*converter.getPhysDeltaX(),0 );
Vector<T,2> originBC_in( 0, heightStep);
IndicatorCuboid2D<T> inflow( extendBC_in, originBC_in );
// Set material number for inflow
superGeometry.rename( 2,3,1,inflow );
IndicatorCuboid2D<T> outflow( extendBC_out, originBC_out );
// Set material number for outflow
superGeometry.rename( 2,4,1,outflow );April 17, 2021 at 8:13 pm #5609
You are welcome.
Each origin and extend are part of the input arguments for the respective indicatorCuboid2D functor and should be well-defined as is.
For more information of the usage of indicator functors to build a geometry by stacking primitives together, please have a look at the User Guide (https://www.openlb.net/wp-content/uploads/2020/12/olb_ug-1.4r0.pdf, Section 5.1 “Creating a Geometry”).
StephanApril 18, 2021 at 10:11 am #5610
PS: To be precise… The function for the inlet boundary might be set to zero thickness since it is located at the domain’s origin. The thickness of the indicator for the outlet boundary has to be adapted to hit the target grid nodes. Of course you could make the former also of mesh-dependent thickness, which should be the favorable way of introducing functors for boundary conditions.
StephanApril 21, 2021 at 3:22 pm #5617
Thank you very much!
GloriousfaceJune 4, 2021 at 4:33 pm #5706
I have read 《The Lattice Boltzmann method》by Krüger et al, and have a thorough understanding of the principle of unit conversion, but I don’t understand the application of unit conversion in the program. For example, there are two things I don’t understand in the following code:
void prepareGeometry( UnitConverter<T, DESCRIPTOR> const& converter,
SuperGeometry2D<T>& superGeometry )
Vector<T,2> extend( lengthX,lengthY );
Vector<T,2> center( centerCylinderX,centerCylinderY );
IndicatorCircle2D<T> circle( center, radiusCylinder );
superGeometry.rename( 0,2 );
superGeometry.rename( 2,1,1,1 );
extend = 2.*L;
origin = -L;
IndicatorCuboid2D<T> inflow( extend, origin );
superGeometry.rename( 2,3,1,inflow );
origin = lengthX-L;
IndicatorCuboid2D<T> outflow( extend, origin );
superGeometry.rename( 2,4,1,outflow )；
superGeometry.rename( 1,5,circle );
1. Why there is unit conversion in function parameters but not in function body;
2. When constructing geometry, SI units are used instead of lattice units. Under what circumstances should lattice units be used?
I hope you can help me solve this problem. I would appreciate it.June 4, 2021 at 4:46 pm #5707
1: This is a holdover of creating this particular example. Unit conversion is indeed not used there.
2: Lattice units should be used during geometry setup when one needs detailed per-cell control of the geometry. This could of course also be done via physical locations but would require more attention to e.g. rounding issuesJune 5, 2021 at 2:04 pm #5708
Thank you very much for your replyJune 5, 2021 at 4:32 pm #5710
When I read the help document, I found that the analyticF function is applicable to the SI unit. Can I ask the following lines of code to set the speed and pressure in the SI system of units?
AnalyticalConst2D<T,T> ux( 0. );
AnalyticalConst2D<T,T> uy( 0. );
AnalyticalConst2D<T,T> rho( 1. );
AnalyticalComposed2D<T,T> u( ux,uy );
The calculation of LBM uses lattice units. These lines of code for setting the initial equilibrium distribution function directly use international units. Is there a conversion mechanism？
sLattice.defineRhoU( bulkIndicator, rho, u );
sLattice.iniEquilibrium( bulkIndicator, rho, u );June 6, 2021 at 10:33 pm #5711
SuperLattice(2,3)D::defineRhoUsets the rho and u moments of the indicated cells in lattice unit values given by the passed analytical functor. How these moments relate to the actual population values depends on the selected dynamics and momenta of each individual cell. No unit conversion is performed so if you pass a SI-relative analytical functor to either
iniEquilibriumyou will get wrong results.
If you want to set e.g. the velocity moment of some set of cells to a value in SI units you will need to scale the value using
June 7, 2021 at 12:34 pm #5714
- This reply was modified 2 years, 6 months ago by Adrian.
Thank you very much for your reply. I’m simulating two-component flow and trying to apply pressure boundary to the outlet, but there are two problems I don’t quite understand.
1.The initial density and initial velocity of each component are defined in prepareLattice function. How to define the initial density of inlet and outlet?
2.Is the initial density of the inlet of the two lattices consistent？
3.I set the following statement in the program to achieve the pressure boundary
setLocalPressureBoundary<T,DESCRIPTOR>(sLatticeOne, omega, superGeometry, 4);
setLocalPressureBoundary<T,DESCRIPTOR>(sLatticeTwo, omega, superGeometry, 4);
Do I need other statements, such as defineU？June 8, 2021 at 9:42 pm #5719
1: Moments of boundaries are set analogously to bulk cells using e.g.
defineRhoU(ignoring special cases such as interpolated bounce back where
defineUBouzidiis needed). These calls transparently update the parameters stored in the cell-specific momenta objects.
2: Consistency of multiple lattices requires coupling post processors (see e.g. our set of multi component examples)
3: Yes, these boundary setters only assign the dynamics and post-processors required for modeling the boundary. Further calls to define methods are needed to set up the data.
For a outline of how to set up a multi-component flow you can check out e.g. the
- You must be logged in to reply to this topic.