[Adrian]

w.r.t. setBounceBackVelocityBoundary: You should not need to include any files beyond the olb(2,3).h(h) headers. I can’t tell you more without seeing the code.

w.r.t. Bouzidi: Exactly, try increasing or decreasing the resolution by single cells. If this doesn’t help we’ll have to look more closely at your indicator / geometry setup. As per your second comment this is a cuboid and explains the problem, especially if the cuboid boundaries align exactly with cell locations.

w.r.t. particles: You can check out e.g. the particles/dkt2d example. There circles are used but HLBM supports arbitrary shaped particles (and depending on what you want to model using a moving wall you could consider the moving wall as a particle).

[Adrian]

The Nguyen Ladd velocity correction is what is implemented by BounceBackVelocity.

The error you get for the Bouzidi boundary configuration is verly likely a geometry / indicator issue. Without knowing what exactly your code does I can only suggest to perturb the resolution one way or the other – this frequently fixes at least some discretization issues.

In the current release your best bet for moving walls in the general case is to use the resolved particle system.

[Adrian]

Thanks for letting us know! This is indeed a communication issue w.r.t. the VTK output (the inter-block communication for the actual simulation is correct, luckily).

You can fix the Rayleigh Bernard example by adding a call to sLattice.communicate() in getResults for the VTK-writing timesteps.

[Adrian]

It is difficult to say what the problem is without knowing what exactly the setup is / seeing the code.

What boundary conditions and bulk dynamics are used?

[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 4 years, 5 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 4 years, 6 months ago by Adrian.

[Author]

Posts