[Adrian]

The compiler can not decide which constructor of BlockReduction3D2D to use.

Making it clear that {0,0,1} should construct a normal vector [1] will solve this:

BlockReduction3D2D<T> planeReduction( density, Vector<T,3>{0, 0, 1} );

[1]: https://www.openlb.net/DoxyGen/html/db/ded/classolb_1_1BlockReduction3D2D.html#a158fe582f00266150512a0ef416d1984

[Adrian]

You can change the gnuplot command in src/io/gnuplotHeadMapWriter.hh:247 respectively src/io/gnuplotWriter.hh:337. For your example the latter should be the relevant one.

[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.

[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 2 years, 11 months ago by Adrian.

[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

[Adrian]

This is a functor arithmetic expression for substracting 1 from the result of calling densityF. functor_dsl::lift is a helper for wrapping a reference in a std::shared_ptr for which functor arithmetic is implemented. This is just used here for brevity, one could also construct the density functor inside a shared pointer directly.

[Adrian]

The functor for extracting pressure information SuperLatticePhysPressure2D returns the physical pressure w.r.t. the given unit converter. Currently no SuperLatticePressure2D exists but this would be trivial to implement either by adapting the physical pressure functor or by using functor arithmetic. E.g. (untested):

SuperLatticeDensity2D<T,DESCRIPTOR> densityF(sLattice);
auto latticePressureF = (functor_dsl::lift(densityF) - 1.0) / descriptors::invCs2<T,DESCRIPTOR>();

[Adrian]

Yes, the periodicity in OpenLB is configured via CuboidGeometry::setPeriodicity. In 2D setPeriodicity(true, true) does what you want.

[Adrian]

Ok, just to make sure: Did you also provide a matching implementation for this method signature declaration? It would help if you could share your code changes.

You can also try doing your population value changes by directly accessing the lattive cells from your application code using e.g. SuperLattice2D::get(iC,iX,iY).

[Adrian]

Did you define the new iniEquilibrium method in the SuperLattice2D? (File: src/core/superLattice2D.h)

By default there is only a iniEquilibrium function requiring both density and velocity fields.

Defining just the density in an existing lattice is possible using e.g. SuperLattice2D::defineRho.

[Adrian]

No, we currently do not include local mesh refinement in the release. There are prototypes but unfortunately nothing yet that is consistently usable across all features.

[Adrian]

Thanks for the bug report! We will fix it for the next release.

[Adrian]

No, OpenLB currently doesn’t support local grid refinement. Various approaches exist as prototypes but it is not clear when this will be at a stage where we include it in a release as most efforts are currently focused on improving general performance and supporting GPUs.

Thus the bstep2d case only uses a fixed resolution for the whole lattice. The other M resolution is an remainder from development, thanks for pointing out this possible source of confusion!

[Adrian]

defineUBouzidi is not a method of the super lattice but a free function that accepts the super lattice (sLatticeOne resp. sLatticeTwo in your case) as its first argument.

So this should look something like (I can not ensure that this works in this way exactly as I do not know your whole code):

defineUBouzidi(sLatticeOne, superGeometry, 5, poiseuilleU);
defineUBouzidi(sLatticeTwo, superGeometry, 5, poiseuilleU);

[Adrian]

Any external force has to be added manually in OpenLB using forced dynamics. So if you currently use e.g. a normal BGK collision you already model a “weightless” system.

[Author]

Posts