Unit conversion

[Gloriousface]

Hello everyone，

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?

Thanks
Gloriousface

[stephan]

Dear Participant,

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.

BR
Stephan

[Gloriousface]

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 );

[stephan]

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”).

BR
Stephan

[stephan]

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.

BR
Stephan

[Gloriousface]

Thank you very much!

Gloriousface

[Gloriousface]

Hello everyone

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 );
Vector<T,2> origin;
IndicatorCircle2D<T> circle( center, radiusCylinder );

superGeometry.rename( 0,2 );
superGeometry.rename( 2,1,1,1 );

extend[0] = 2.*L;
origin[0] = -L;
IndicatorCuboid2D<T> inflow( extend, origin );
superGeometry.rename( 2,3,1,inflow );
origin[0] = 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.

[Adrian]

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 issues

[Gloriousface]

Thank you very much for your reply

[Gloriousface]

Hello，everuone

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 );

[Adrian]

SuperLattice(2,3)D::defineRhoU sets 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 defineRhoU or iniEquilibrium you 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 UnitConverter::getLatticeVelocity.

• This reply was modified 3 years, 9 months ago by Adrian.

[Gloriousface]

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？

[Adrian]

1: Moments of boundaries are set analogously to bulk cells using e.g. defineRhoU (ignoring special cases such as interpolated bounce back where defineUBouzidi is 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 multiComponent/microFluidics2d example.

[Author]

Posts