Adrian
Forum Replies Created
-
Posts
-
1. You can access this via CuboidGeometry::getPhysR
2. This information is provided in the geometry statistics printed at the start of all examples
3. CuboidGeometry::getLatticeR can be used to convert physical locations to lattice locations. These lattice locations can the be passed to SuperGeometry for accessing material numbers.
4. For post-processing, the unscaled lattice velocity moment is available as SuperLatticeVelocity2D
w.r.t. geometry renames:
All material numbers being set to zero is simply the default. This makes sense as zero cells are considered as inactive cells for which no processing is done.
More complex geometry setups are commonly created using indicator functors. OpenLB provides both a library of indicators for various geometric primitives as well as a STLReader indicator for importing STL data. All of these can be used in rename calls to set material numbers. You can check out e.g. the cylinder(2,3)d examples for basic examples of this. The User guide also contains further explanations.
A straight forward way to finding class definitions is via Doxygen. e.g. for AnalyticalFfromSuperF2D.
AnalyticalFfromSuperF2D interpolates using the node locations as sampling points while BlockReduction2D2D performs a reduction of the resolution (there is e.g. also a BlockReduction3D2D for extracting a hyperplane, BlockReduction functors generally use interpolation functors internally).
The snippet performs filesystem write operations using std::ofstream. As far as I can tell without seeing the full code, this is not restricted to the rank 0 process (where the reduced data is communicated to by BlockReduction2D2D). Thus all processes execute this the std::ofstream code and write to the same file. When using e.g. OpenLB’s default VTK writer this is resolved transparently in the background.
The
SuperGeometry(2,3)Dstores a vector ofBlockGeometry(2,3)Dinstances (this pattern is present all throughout OpenLB), one for each cuboid assigned to the process. At the lowest level, all material numbers of a block are stored in a plain array.It should be possible to write raw XML VTK files by setting
compress=falsein theSuperVTMwriter3Dconstructor.This is the compressed VTK data (storing everything in raw XML would significantly increase the file size). Why do you want to parse the VTK file manually?
If you want to access the material numbers for further processing in your program, the straight forward way is to access the SuperGeometry directly.
If you want to do further post-processing of VTK output outside of OpenLB, I would suggest to check whether there is a VTK library / binding available for your language of choice.
You have to ensure that the IO only happens in the main process (where
BlockDataSyncMode::ReduceOnlysyncs to). Otherwise each process will write to the same file in parallel and in addition not even have the correct data.The y+ criterion can be computed using the
SuperLatticeYplus3Dfunctor. Functors can be combined into expressions using functor arithmetic.When is the code snippet called? What are you simulating? Are the functor results correct? (Check using e.g. a debugger).
No, unfortunately the merge in 2018 did not work out due to unforeseen problems. However I am currently working on large changes in OpenLB to support both vectorization on CPUs and utilization of GPUs that will be published in release 1.5.
The increment operation in the nested loop contains a typo, it should be
++latticeR[1].No, currently there is no GPU support in OpenLB – however this is at the moment the main focus of my work. The next release will also include support for vectorization on CPUs which also delivers significant speedups.
Which parallel mode did you use? OpenMPI or OpenMP? For OpenMPI our efficiency is around ~80% so you should be able to get your desired timesteps per second by parallel execution on CPUs. Of course if you want to do this on a single host then there is no real way around GPUs – which is one of the reasons why I am focusing on it. E.g. a GPU LBM code of my own in some cases easily outperforms simulations on ~12 nodes of a small cluster using just a single GPU. This is also driven by the desire to fully utilize our new supercomputer at KIT.
This is indeed related to grid refinement.
SuperLatticeRefinementMetricKnudsen3Dimplements a refinement criterion [1] to help determine where to refine to which degree. This is one part of a prototype implementation [2] that I pulled into the release as it is also useful in other contexts. e.g. to check whether a simulation gets close to diverging or to identify problematic regions.[1]: Automatic grid refinement criterion for lattice Boltzmann method [Lagrava et al.]
[2]: Prototype of grid refinement in OpenLB 1.3 written for my Bachelor thesisIts certainly possible to read in external data to set the material numbers. E.g. one possibility that I have encountered in (non-OpenLB) example codes is to read in a bitmap image file to set geometry information. All you would need is some loop to iterate over the input data and set the material numbers using e.g.
SuperGeometry2D::get.However the most straight forward way is to use the OpenLB-provided interfaces, specifically indicators in combination with the rename functions. See e.g.
examples/laminar/cylinder2dfor a basic example. What specifically do you want to model?(In 3D we support CAD import via STL data)
util::intersectcomputes the intersection between cuboids (x0,x1)x(y0,y1) and (x0_,x1_)x(y0_,y1_).