[Adrian]

How did you set up the in- / outflow boundaries? These are required in this case to handle the missing inbound populations (previously resolved using periodic boundaries).

The wall function boundary setup fails due to unexpected material numbers in these areas.

[Adrian]

Plain Bounce Back dynamics do not support non-zero velocity walls.

Depending on your geometry I would suggest to use either Interpolated Bounce Back (Bouzidi) boundaries (you can see their setup in e.g. the turbulence/aorta3d example) or local / interpolated velocity boundaries (see e.g. the poiseuille examples for basic examples of the various options). Alternatively OpenLB also offers Bounce Back with the velocity correction by Nguyen and Ladd.

[Adrian]

There is no additional limit on the relaxation time from the implementation side of things and any theoretical considerations translate to the simulation results.

You can of course try out different collision operators as well as change e.g. the spatial discretization to see what best fits your application.

[Adrian]

Warnings of this kind are printed when the boundary setter (the addVelocityBoundary method in this case) fails to instantiate the necessary dynamics / post processors for a particular cell. This means that the boundary for this cell is not well defined. However in practice this is frequently overlooked as single erroneous populations don’t necessarily impact the overall simulation in a noticeable fashion. This seems to also be the case here?

Of course it is good practice to keep an eye on such messages and to fix the underlying geometry problem. In this case I suspect that the discrete wall normal could not be recovered correctly / the wall normal can not be handled by the specific velocity condition.

Did you already verify the material number setup in ParaView?

w.r.t. your second question: Depending on what you mean, this is either an artifact of the specific geometry setup (rounding or otherwise) or the overlap area around each block that is used for communication.

[Adrian]

Temperature boundaries may be created using e.g. setAdvectionDiffusionTemperatureBoundary. Usage examples for this and alternatives are provided in e.g. thermal/porousPlate(2,3)d or thermal/squareCavity(2,3)d.

If this doesn’t help we would need to more closely check your application code to exclude any other problems in the setup.

[Adrian]

Good to hear!

I mean the indicator you use to set the material number of the obstacle:

olb:: IndicatorCuboid2D<SimType> obstacle( extend, origin);
superGeometry.rename( materialFluid, materialObstacle, obstacle);

You could pass this indicator directly to defineDynamics. But it makes sense to maintain a 1:1 relation between material and dynamics here, so no need to change it if it works.

[Adrian]

I received your mail and was able to compile and run the cuboid case.

Contrary to what you want to achieve (as I understand it) the advectionDiffusionObstacleDynamics are not actually applied to the entire obstacle cuboid on the AD lattice. The reason for this is that a material indicator for number 6 is used but this is only set on the outer boundary of the obstacle due to the default geometry cleaning. You can see this in the geometry VTK output.

I removed the clean calls and the obstacle now takes part in the AD dynamics. Alternatively one could use the original analytical obstacle indicator instead of a material indicator.

• This reply was modified 2 years, 8 months ago by Adrian.

[Adrian]

If you post your full code I’d be happy to take a closer look.
Did you already try running the code in unoptimized debug mode and checking the backtrace there?

For a starting point the actual types of NSDESCRIPTOR and TDESCRIPTOR would be of interest.

[Adrian]

w.r.t. the question on inflow / outflow indicators:

The reason why this is set up in this way is to ensure that the first resp. last x-axis orthogonal cell layer is setup as in- resp. outflow. For this we need to in some sense match up physical parameters with discretized (cell) locations (if we want to use indicators as is done in this example).

w.r.t. the extended domain:

This is needed to ensure that the discretized domain fits the whole pipe.

[Adrian]

The reason for this is likely an issue in the boundary setup, i.e. not all links between undefined no-dynamics nodes and fluid nodes are reconstructed correctly. This is a relatively common problem that can occur when using Bouzidi boundaries. One trick that helps surprisingly often is to change the discretization resolution by e.g. a single cell. Do you get any warnings printed during simulation setup?

If you can post your full code I’d be happy to take a closer look.

[Adrian]

Specifying the origin and direction is one possibility of parametrizing the hyperplane used by the plane integral functors. You can see other possibilities that are overloaded by constructors of SuperLatticeIntegralFluxMass2D in e.g. Doxygen. So yes, the flux is computed through the plane that is orthogonal to the direction vector and intersects the origin.

As for the output vector: SuperPlaneIntegralFluxMass2D scales the integral obtained by SuperPlaneIntegral2D by the given factors. The other documented components are returned unchanged.

You do not need to wrap the mass flux functor in an interpolation functor as the integral functors return their result independent of the input coordinates (they are only accepted to satisfy the overall functor interface).

• This reply was modified 2 years, 8 months ago by Adrian.

[Adrian]

Additional field data declared by the descriptor is saved / restored by the super lattice serialization.

Did you call SuperLattice2D::postLoad as in e.g. examples/particles/magneticParticles3d/magneticParticles3d.cpp:591? This is called automatically in our current development version but unfortunately not in the current release.

Depending on the exact code, there may be further obstacles in this particular example – e.g. the initial setup is random and non-reproducible by default. Also average rho in general is computed during collideAndStream and not up-to-date directly after reload.

If you post your adapted code I am happy to assist you further.

[Adrian]

latticeNew is still only of size 2…

[Adrian]

Global lattice locations in 2D are 3-component vectors – the first one is the cuboid number, not the x component.

[Adrian]

Reducing only the channel size without also changing the physical discretization resp. N accordingly results in a very small lattice. This simulation converges after only a small number of steps – before any VTK output were written.

[Author]

Posts