[Adrian]

Thanks for letting us know!

Unfortunately we also frequently encounter version-related issues with the gnuplot interface. In general for any serious post processing I would recommend to use ParaView.

[Adrian]

The _external_ velocity field is used to realize the coupling og the lattices. As you observed this was originally stored / referred to using offsets into an array and has since been replaced by a significantly more flexible and maintainable descriptor field concept.

ForcedBGKdynamics use the forcing scheme by Guo (10.1103/PhysRevE.65.046308).

The fully model of the system results of these dynamics and the coupling instantiated by ShanChenForcedGenerator2D. There the value of the VELOCITY field is set to the local momentum (using computeJ i.e. computed from the populations).

[Adrian]

By memory isses you mean that you run out of memory on the system? One possibility is that the domain decomposition doesn’t do what it should and you end up with large empty areas that nevertheless need to be allocated on the system (as OpenLB only offers blocks of directly addressed grids at this time). Whether this is the case here is hard to tell from the provided information.

In general, small characteristic lengths do not necessitate large resolutions as the characteristic length is only a parameter of the physical parametrization of which the actual lattice quantities are derived.

[Adrian]

The resolution parameter N in examples is commonly w.r.t. some kind of characteristic length used during construction of the UnitConverter that yields the delta X value. You can see this if you check the usage of N in any of the examples.

[Adrian]

Does IndicatorTriangle2D fullfill your requirements?

This will be available in the next release. Ordinarily I’d quickly backport it to 1.4 for you but the new indicator is tied to more comprehensive changes of the library and unfortunately not easy to extract.

In general, smooth indicators are used by the resolved particle code to model particles with a porous boundary layer (in HLBM). See e.g.

R. Trunk et al. “Towards the Simulation of arbitrarily shaped 3D particles using a homogenised lattice Boltzmann method”. In: Computers & Fluids 172 (2018). doi: https://doi.org/10.1016/j.compfluid.2018.02.027.

[Adrian]

Unfortunately these links got lost when we changed the forum software a couple of years ago, sorry.

We can discuss the triange issue further in your separate thread.

[Adrian]

What exactly do you mean by “not symmetric at all”?

[Adrian]

This is most likely the same root cause (some mistake in application / compilation setup) as your other issue with setting up bouzidi boundaries. What happens if your write olb::setBounceBackVelocityBoundary?

[Adrian]

I mean that in to use the Bouzidi boundary setters you do not need to add any header includes beyond the olb(2,3).h(h) ones. There must be some other problem in your application code.

As for the other questions we can discuss them in the joint session where we can also look at your actual code.

[Adrian]

Good to hear! To clarify: The problem still occurs when executing in sequential mode? Or did you adapt the code somehow?

IndicatorTriangle2D is what you want for a plain triangle shape in 2D. (The smooth versions project on [0,1] instead of {0,1} for use in the HLBM particle code)

However I suspect that you want to construct a triangle geometry in 3D? If so the recommended way is to load a STL file (which describes just such a triangle geometry) using the STL reader class. This is used in the aorta3d example you are already familiar with.

[Adrian]

What happens if you open the Solidworks STL in Freecad, save it there and try to open this STL file in OpenLB?

[Adrian]

Some questions in order to pin this down: Does it work without the cylinder size change? Did you call vtmWriter.createMasterFile as in the default poiseuille3d case? Do the target folders exist and have the correct permissions?

[Adrian]

While a segfault should of course not occur and points to some problem in the library, it is hard to pin down without seeing your exact code. Did you already compile in unoptimized debug mode and extract a backtrace of the issue?

[Adrian]

I am not sure what you want to accomplish.

Is it simply using the existing Bounce Back Velocity boundary in a simulation?
If so you do not need to implement a getBounceBackVelocity function (?) by yourself, instead call e.g.:

setBounceBackVelocityBoundary(superGeometry, 3, omega, sLattice);
sLattice.defineU(superGeometry, 3, uTop);

in your boundary setup (replace 3 by the material number of your desired bounce back velocity boundary).

[Adrian]

Does the output of the default VTK files as implemented in the poiseuille3d example work on your system?

[Author]

Posts