[Adrian]

Please do not post the same question two times. See my answer in the other thread.

[Adrian]

The error you are encountering is that your nvcc uses an older standard than C++11 (where nullptr was added) by default. Does a manual execution of nvcc -std=c++11 -c tinystr.cpp -o build/tinystr.o work? Is the environment where you build OpenLB using CUDA 11’s nvcc for sure? (It is quite easy to mix this up depending on where and how you installed CUDA, there may also be multiple versions in parallel)

In any case, as per the release notes OpenLB 1.6 requires at least CUDA 11.4.

[Adrian]

The issue here is likely that the CUDA release is too old (the diagnostic control option should be independent of any architecture setting). To confirm you can remove the option in line 78 of rules.mk.

The CUDA_ARCH value for a K80 should be 30 as it belongs to the Kepler generation.

[Adrian]

It is very unlikely that this is related to your computer configuration and the functor setup you listed. The duplicated files on the other hand are almost certainly caused by your specific changes / the way you (wrongly) call the non-MPI OpenLB application. This is not a bug in OpenLB.

You are also using the deprecated legacy particle code (see the user guide for the current approach).

In any case, the core OpenLB developer team can not offer this detailed level of support in this forum (we are answering questions here alongside our actual research and development work), especially considering that you do not share your work.

If you want this kind of personal support you should consider attending our spring school or finding some other way for both of us to get something out of this process (I know we suggested this to you before but your level of questions is again getting out of hand, sorry).

[Adrian]

So you are doing again what I told you many times before won’t work?… You can not magically turn a non-parallel build into a parallel program by prefixing its execution with mpirun.

Periodic boundaries for resolved/subgrid-scale particles definitely work using MPI. Or are you talking about some legacy particle mode?

Please explain in detail what you expect the screenshots to tell me, as far as I can tell they simply list the files in tmp. What is the difference in behavior between 1.5 and 1.6? What did you modify in channel3d (as it doesn’t contain particles in the release version).

[Adrian]

The screenshot also only shows files for a single cuboid – confirming that you run a non-MPI OpenLB case via mpirun. If you had set this up correctly you would see at least one cuboid file per process.

[Adrian]

Judging by your screenshot the “case you ran before in 1.5” is the same channel3d you are running now?

Please describe exactly what you are doing. As I mentioned the 8-fold duplication of VTK output points strongly towards you still using mpirun -np 8 for a non-MPI executable. You likely also have a contaminated tmp folder and build (which is why I suggested to fully clear the directory).

The line of code you posted will do exactly what its comment describes. Again, the duplicated lines you see are due to not compiling the application with MPI enabled but trying to run it using mpirun.

[Adrian]

…that is because you still used mpirun despite not activating MPI (as I explained in my post). Do you not see the connection between 8 processes and 8 outputs? This never worked in the way you described. Of course VTK output also works without MPI if you execute the program in the correct way.

In any case, happy to hear that it works.

For your second point: This sounds as if you did not fully clear the tmp directory between individual tries.

[Adrian]

This looks very much as if you did not actually activate MPI in the config. mpirun doesn’t warn you if you try to call it with a non-mpi executable – it will just start the same programm n times without any work distribution. You probably also noticed that all terminal output is duplicated eight times?

If you change the config to use MPI (see the user guide or the example configs) and recompile, everything should work.

[Adrian]

You mean you managed to fix it?

In any case, generating device code for a later generation than the one a GPU has would explain the Thrust exception.

[Adrian]

Happy to hear that the examples are working now.

What is the issue with your case? Does it work on the CPU?

[Adrian]

Yes, I am referring to possibility of using the resolved particle code with adapted particle dynamics to model “non-particulate” flows (this won’t get you general purpose FSI due to e.g. the lack of deformability but it should work for many kinds of rotating geometries)

Immersed boundary is the common approach for coupling a structural solver to LBM, however it is not the only one – e.g. the homogenized LBM approach utilized in OpenLB is just as capable for this (i.e. this is the underlying model of the resolved particle code).

I would suggest you start by modifying the settling cube case to only contain a single cube and then adapt the particle dynamics (there is documentation on this in the user guide) to restrict / drive its rotation. You are right that this would be a nice example to have in OpenLB.

In any case: Our annual Spring School will for the first time offer a separate track for advanced users to work together with members of the core developer team on such more complex topics beyond the scope of the normal LBM and OpenLB introduction. This could be a nice setting for collaborating on this.

[Adrian]

The error is for a different config – your listing states CUDA_ARCH as 62 whereas the error mentions 60. Is this the only change? If so, the issue is that you have a space after the cuda arch number that doesn’t get sanitized (will be fixed in 1.7).

[Adrian]

I agree that this would be very interesting and there are ongoing projects on FSI improvements in OpenLB. However, the public state is unchanged.

Did you investigate whether the resolved particle code is an option for your application? Despite being referred to as “particle code” the underlying model is capable of more general FSI. The new particle dynamics system is also amenable to modeling e.g. restricted rotation or movement of geometries (for example a rotating mixer).

[Adrian]

Yes, you are correct. This is an artifact of back when OpenLB did not have a unit converter (cylinder2d is one of the oldest example cases).

[Author]

Posts