[Markus Mohrhard]

Hello Eduardo,

you need to download and build openmpi with these flags. This is not an OpenLB flag.

Go to https://www.open-mpi.org/ and download a recent version and build it with this flag ( a normal make && make install should work).

Kind regards,
Markus

[Markus Mohrhard]

Hello Eduardo,

most likely the easiest option is to build openmpi yourself. Openmpi has a build flag to build the c++ interfaces despite them being marked as deprecated.

Use the –enable-mpi-cxx while building openmpi to build the mpi interface.

I think there is currently no better solution if the cygwin project does not provide the c++ pieces of the openmpi build.

Regards,
Markus

[Markus Mohrhard]

Hey,

thanks for the report. We had already fixed this issue in our development branch.

Find below the fix that is necessary to fix the VTK export:

Code:

diff –git a/src/io/blockVtkWriter2D.hh b/src/io/blockVtkWriter2D.hh
index ea92f0d34..6c8634a3e 100644
— a/src/io/blockVtkWriter2D.hh
+++ b/src/io/blockVtkWriter2D.hh
@@ -189,8 +189,8 @@ void BlockVTKwriter2D<T>::writeRawData(const std::string& fullNameVti, BlockF2D<
for (int iDim = 0; iDim < f.getTargetDim(); ++iDim) {
evaluated[iDim] = T();
}
– for (i[0] = 0; i[0] < ny+1; ++i[0]) {
– for (i[1] = 0; i[1] < nx+1; ++i[1]) {
+ for (i[1] = 0; i[1] < ny+1; ++i[1]) {
+ for (i[0] = 0; i[0] < nx+1; ++i[0]) {
f(evaluated,i);
for (int iDim = 0; iDim < f.getTargetDim(); ++iDim) {
if (singleton::mpi().getRank()==0) {
@@ -251,8 +251,8 @@ void BlockVTKwriter2D<T>::writeRawDataBinary(const std::string& fullNameVti,
for (int iDim = 0; iDim < f.getTargetDim(); ++iDim) {
evaluated[iDim] = T();
}
– for (i[0] = 0; i[0] < ny+1; ++i[0]) {
– for (i[1] = 0; i[1] < nx+1; ++i[1]) {
+ for (i[1] = 0; i[1] < ny+1; ++i[1]) {
+ for (i[0] = 0; i[0] < nx+1; ++i[0]) {
f(evaluated,i);
for (int iDim = 0; iDim < f.getTargetDim(); ++iDim) {
if (singleton::mpi().getRank()==0) {

Kind regards,
Markus

[Markus Mohrhard]

Hello Laurent,

yes it will be possible as soon as it is in a reasonable shape. Please contact Mathias Krause to find out how and when we can provide you with a pre-release tarball. Note that the work is currently still ongoing and will hopefully be merged into our main development branch in the next weeks.

Regards,
Markus

[Markus Mohrhard]

Hey Laurent,

most likely you have 2 E5-2620v4 which are 8 core/16 thread CPUs. In total you will see 32 virtual cores but there are only 16 physical cores, so the best performance will be reached with 16 MPI jobs. With anything above 16 you have additional context switches that take time and limit the available cache per core.

For additional information about that I recommend to read about Simultaneous multithreading (SMT) or Hyper-threading (HT).

Regards,
Markus

[Markus Mohrhard]

Hello Laurent,

the currently released OpenLB versions don’t support GPUs yet. We have an unreleased prototype that is using CUDA for GPU support and hope to release initial GPU support as part of OpenLB 1.3.

Regards,
Markus

[Markus Mohrhard]

Hey Chris,

normally nothing should be required. I’d start by writing a small test for one single grid point and make sure that the results are correct. I’m sorry but as I have never looked into higher order solutions I can not provide you with more guidance.

Regards,
Markus

[Markus Mohrhard]

Hey Chris,

I’m sorry but I can honestly not help you as I have no idea what you are trying to implement. I assume that you have a paper that you are trying to reproduce but you need to carefully check the results of the paper.

The lattice descriptor part looks fine.

While implementing you need to be a bit careful as our f_i and therefore the f_i^eq is shifted by t_i. This is usually the only part that one needs to pay special attention to while implementing but our rho and u calculation should already deal correctly with the shift (see e.g. adding 1 back to rho).

Kind regards,
Markus

[Markus Mohrhard]

Hey Chris,

lbHelpers.h and lbHelpersD2Q9.h belong together. lbHelpersD2Q9.h contains the template specialization for the lbDynamicsHelpers class for the D2Q9DescriptorBase (and therefore for the D2Q9Descriptor). The call to lbHelpers<D2Q9Descriptor>::some_method() is forwarded to lbDynamicsHelper<D2Q9Descriptor::BaseDescriptor>::some_method. The compiler now has the generic version for that method in lbHelpers.h but an explicit template specialization in lbHelpersD2Q9.h that fits as well. As the C++ standard requires the compiler to select the explicit template specialization the code will use the lbHelpersD2Q9.h version in the end.

My suggestion for using a different equilibrium implementation would be to define a new descriptor (keep in mind that you also need to change the base descriptor) and then implement an explicit template specialization for this new descriptor (new descriptor in latticeDescriptors.h[h] and new template specialization in a new lbHelpersXY.h file (keep in mind that the new file needs to be included in lbHelpers.h)). That way you can keep your changes separate and can easily switch back to the classical equilibrium calculation.

Regards,
Markus

[Markus Mohrhard]

Hello Chris,

bstep2d uses a BGKDynamics with a D2Q9Descriptor which in the end calls into lbHelpersD2Q9.h.

prepareLattice in bstep2d.cpp tells you which boundaries are used in the example. The variable bulkDynamics corresponds to the BGK fluid dynamics, bounce back is obvious and only the velocity and the pressure boundary require some more work.

By default the example uses local boundaries (273 createLocalBoundaryCondition2D<T,DESCRIPTOR>( sBoundaryCondition ); ) which means that we get a RegularizedBoundaryManager2D and as a Result CombinedRLBdynamics (with MixinDynamics as BGKdynamics). The only difference between the pressure and the velocity boundary in that case is the used boundary momenta.

Which descriptor are you currently missing. Depending on the type of descriptor you might just need to add a new descriptor. There are only a few cases where putting work into the lbHelpers and the corresponding template specializations is ever required.

Regards,
Markus

[Markus Mohrhard]

Hello Luis,

Can you provide the output of pwd, cat Makefile and cat ~/olb-1.2r0/config.mk ?

Regards,
Markus

[Markus Mohrhard]

Hello Luis,

please just call make and if that still produces an error paste your command and the error message.

Regards,
Markus

[Markus Mohrhard]

Hello Mohamed,

it looks quite suspicious that your build tries to include “c:\program files\gfortran\include\unistd.h”. Do you by chance have an older MinGW installation on your build machine that is in the PATH?

Searching for your error message points to a MinGW bug that was fixed 3 years ago.

Regards,
Markus

[Markus Mohrhard]

Thanks for the report.

I have fixed this in our master branch through

Code:

std::unique_ptr<float[]> bufferFloat(new float[fullSize]);

which handles deleting the allocated memory as well. The same approach was already implemented in the 3D case.

[Markus Mohrhard]

Hello Ishan,

the easiest way is to copy the OpenLB code to a location that you have full write permissions. A simple example for this would be your home directory. The “Permission denied” message means that you are not allowed to create files in this location.

OpenLB does not store any absolute paths, so you should be fine to copy the existing directory, then call a make clean && make

Hope this helps.

Regards,
Markus

[Author]

Posts