[stephan]

Dear Amir,

thanks for your reply.
Please continue posting in case you need further help with the implementation, and use the “CODE” macro in the text field to highlight the snippets you include.

Your questions are absolutely not redundant, this is the right place to ask them.
We are always glad to help you with realizing your project.

BR
Stephan

[stephan]

Dear at8i,

in case you are not yet familiar with the C++ syntax standardly used in OpenLB, please have a look at introductory books/tutorials for C++ programming and our User Guide.
Then start with compiling, and running the most simplified examples (e.g. laminar, single-phase flows in simple geometries) offered in the latest OpenLB release.

The Example section in the current User Guide should help you with understanding the purpose of each sample code (e.g.: geometry primitives, which are necessary for your code snippet above).
You could then identify the example which is most suitable as a basis for extension towards your own application and have a detailed look on that.

Please note, that we unfortunately cannot debug your code within this forum, but we can however assist you in doing that by yourself.

In that sense, I’ll provide hints and try to answer your questions below.

– The .rename function is simply “renaming” the material numbers assigned to the voxels in your geometry, under (if any are specified) certain indicator constraints. These material numbers are then used as specifiers to be assigned with e.g. different boundary or initial conditions.
– Please use the doxygen documentation to double-check the arguments for renaming and indicator functions.
– First part (origin): Let me explain that via perceiving the 2D cuboid as a planar rectangle. The origin vector comprises the location of the lower left corner of the cuboid. The extend in turn is then the vector which is added to the origin to obtain the upper right corner of the cuboid. The center of the rectangle is then subsequently defined as “origin + 1/2 * extend”, and the angle theta is the rotation (counter-clockwise) which can addtionally be specified.
– Circular boundary: (1) Yes, please have a look at an example with a circular geometry. An incremental search in the olb folder for indicatorCircle2D / 3D should lead you to the specific sections. Copy or code along the syntax of your geometry and boundary conditions from that application after you made sure that it does what you want. (2) That should work, yes, however make sure to hit the nodes correctly with your indicator function (i.e. maybe you should consider a larger distance between the circles than one lattice unit or add a buffer distance e.g. half a lattice unit). (3) You can add multiphysics models in OpenLB in the same manner as the dynamics which are currently implemented. This of course requires knowledge in: C++, LBM for the actual model, and OpenLB in terms of code structure. From my point of view (I am not an expert in Fortran) realizing the same LB algorithm from scratch in Fortran should take you way longer than implementing it in OpenLB.

Hopefully, I could help you a bit.
In case you have further questions, please let me know.

BR
Stephan

[stephan]

Dear jdm,

I am glad to hear that you made progress with your showcase.

To assess the velocity field, you can use SuperLatticeVelocity3D, transform that via AnalyticalFfromSuperF3D and then use the resulting function with the typical (output, input) structure.
With the input value you can specify the location of the probe.
Please note that this procedure can be found in various examples.

Considering the parallel mode, we can recommend MPI.
Since I have not encountered the OMP issue before, I can not help you with that right away.

BR
Stephan

[stephan]

Dear Julius,

thank you for your bug report.
You are right with your observations.

First, please note that the MRT Basis compiled in M for D3Q7 is designed for anisotropic diffusion, though used in OpenLB strictly for isotropic cases via setting off diagonal relaxation values in S to 0 [see Ref. Li, Yang, Zhang 2016 International Journal of Heat and Mass Transfer 94].

Second, the matrix M for D3Q7 in the code has incorrectly arranged columns, as you claimed in your post.
This becomes clear when considering its rows nr. 1,2,3 (counted from 0).
The ordering should be fitted to the velocity set for D3Q7 in /src/dynamics/latticeDescriptors.h, i.e. the correct MRT Matrix should read:
{1, 1, 1, 1, 1, 1, 1},
{0, -1, 0, 0, 1, 0, 0},
{0, 0, -1, 0, 0, 1, 0},
{0, 0, 0, -1, 0, 0, 1},
{6, -1, -1, -1, -1, -1, -1},
{0, 2, -1, -1, 2, -1, -1},
{0, 0, 1, -1, 0, 1, -1}

Correspondingly, the corrected inverse of M can be calculated with a basic linear algebra package.
I’ll, leave that up to you.
Anything else belonging to the D3Q7 MRT configuration in the file mrtLatticeDescriptors.h should still uphold correctness.
Please contact me directly via email in case you need further information (stephan.simonis “at” kit.edu).

Thank you again for pointing out the bug.
We will include the correction in the next version of OpenLB.

BR
Stephan

• This reply was modified 3 years, 5 months ago by stephan.

[stephan]

Dear S,

thanks for posting.
Please note that we will release an updated version of OpenLB soon.
Additionally, an update for the tech report on Cygwin will be provided.

In case this problem is not resolved in the new version, we’d appreciate if you could provide further information on the issues you encountered.

BR
Stephan

[stephan]

Hi Raffaele,

have you managed to fix the problem?

Please excuse my late response.
You might want to try step by step enabling the comments.
Start with solely ADM dynamics used in the .cpp and the turbulentF3D as is (outcommented ADM lines).

A good example for testing could be the tgv3d case, since the automated gnuplot output includes reference solutions for the dissipation rate.

Then work your way up in the turbulentF3D. file and use the lines you need for your own application.

BR
Stephan

[stephan]

Hi jdm,

thanks for posting further information.
In paraview you can also open the geometry file located in the vtk folder, then visualize as points with colors corresponding to the material numbers.
Subsequently, slice the domain along the inlet section you want to observe closely.

If I understand correctly, in the second case you plotted, the program works as you want it to.
You could try to run the first case with different resolutions to isolate the issue further.

The indicator should be programmed with a buffer which depends on the meshsize, such that the nodes which you’d like to be declared as inlet or boundary are hit correctly.

BR
Stephan

[stephan]

Dear jdm,

thanks for posting.
I am not quite sure if I understand your setup correctly.
Could you please attach a paraview screenshot which visualizes the geometry, or alternatively provide a little more explanation/code?

Anyway, a possible issue could be that the indicator doesn’t match the grid correctly.
Maybe have a look at the standard examples, where inflows and geometry primitives are used.

Please also note that we have a spring school coming up next year, where we could help you more efficiently with realizing your own simulation in OpenLB.

BR
Stephan

[stephan]

Dear Junwei,

I am glad that it works.
Thanks for letting me know how you did it!

BR
Stephan

[stephan]

PPS: GSL typically requires an additional algebra subroutine library. Hence the final compiler command (if the library is linked to the default path) in your Makefile should end with
... -lgsl - lgslcblas -lm -lz -o $@.

[stephan]

PS: Further below in the GSL user guide (Section 2.2.1 Linking programs with the library), a basic gcc compiliation command is listed with additional compiler flags. You might want to include these flags in the specific Makefile in your OpenLB application. The section in the Makefile typically reads

###########################################################################
## link

link: $(OUTPUT)

$(OUTPUT): $(OBJECTS) $(ROOT)/$(LIBDIR)/lib$(LIB).a
	@echo Link $@
	$(CXX) $(foreach file, $(SRC), $(file:.cpp=.o)) $(LDFLAGS) -L$(ROOT)/$(LIBDIR) -l$(LIB) -lz -o $@

###########################################################################

The compiler flags you’d like to use should be added in the last line before $@ (e.g. ... -lgsl -lz -o $@)

• This reply was modified 3 years, 6 months ago by stephan.
• This reply was modified 3 years, 6 months ago by stephan.
• This reply was modified 3 years, 6 months ago by stephan.

[stephan]

Dear Junwei,

thanks for your message.
In case you installed GSL as suggested on the webpage in its own /gsl directory which is located under the standard search path of your compiler, a simple #include <gsl/… .h> should be enough.

For more information, please have a look at the GSL user guide (Section 2.2 Compiling and Linking).

If you have any further questions, please let me know.

BR
Stephan

• This reply was modified 3 years, 6 months ago by stephan.

[stephan]

… I forgot to mention the dynamics location.
There are several descriptors (see ADMlatticeDescriptors.h) and the corresponding (Forced)ADMBGKdynamics are located in the smagorinskyBGKdynamics.h.

Best
Stephan

[stephan]

Dear Raffaele,

the general application is similar, yes.
For example, you may have a look at ./examples/turbulence/nozzle3d/nozzle3d.cpp, define a flag similar to the other models (#define ADM) which in turn triggers the if-condition further below.
To make that work however, you have to uncomment and probably modify the corresponding functors in ./src/functors/lattice/turbulentF3D.h, .hh, .cpp.

BR
Stephan

[stephan]

Dear Raffaele,

thank you for your post.
Unfortunately, the current release does not offer examples which showcase ADM.
In case you have further questions, just let me know.

Best
Stephan

[Author]

Posts