[sfraniatte]

I think I have solved my problem. The mistake was that I left the line “FEATURES :=” uncommented. Now, to be exhaustive, here the exact commands that I used :
_ ./nozzle3d –resolution 5 –max-phys-t 10 : the calculation duration (measured time cpu) was 29.278s and an average MLUPS of 376.907
_ ./nozzle3d –resolution 10 –max-phys-t 10 : the calculation duration (measured time cpu) was 501.328s and an average MLUPS of 686.931

I ran these calculations today and the evolution seems good this time. Thanks a lot for your time and I hope this will be useful for someone.

Best regards,
Sylvain

[sfraniatte]

Hello,

I attempted to apply these boundary conditions, but it turned out not to be a good idea in my case, as the simulation became less stable. I believe this might explain why there is so little information available on how to implement them. You have likely done everything correctly; it’s just that this approach doesn’t seem to work as intended in this particular situation.

For instance, when I applied these boundary conditions in the aorta example, the flow reversed for certain pressure inlet values.

[sfraniatte]

I am sorry because I understood my error… The number of cores used was to high which slow down the calculation. Stupid mistake !

Thanks a lot for your time !

Sylvain

[sfraniatte]

Ok, I have two computers :
_ an Ubuntu 22.04 VM on windows 11 with 6 CPU cores (Intel(R) Core(TM) i5-10400T CPU @ 2.00GHz)
_ an Ubuntu 24.04 with 32 CPU cores (AMD Ryzen Threadripper PRO 5975WX 32-Cores) and with a GPU card

My goal, today, is to launch a calculation on the computer which run on Ubuntu 24.04 on the CPU cores to run a biger simulation. However, when I test with the same case (my own case), the calculation is slower than when it is done whith the VM on windows.

I am wondering if the problem comes from CPUs which does not have the same brand.

Sylvain

[sfraniatte]

I mean that the calculation is not faster than in sequential mode. The calculation is faster on my other computer with 6 Threads…

Yes, indeed, I would like to use the CPUs only for now and one GPU in the future when my code will be ready for that.

Thank you for the details.

Sylvain

[sfraniatte]

Ok, the first lines after this call are :
[MpiManager] Sucessfully initialized, numThreads=32
[ThreadPool] Sucessfully initialized, numThreads=1

Yes, it returned true. However, I uninstalled CUDA then to have Openmpi which works properly. Because, it was not working. And it still does not work…

My main goal is to have Openmpi to use CPU. But I have the feeling that it is not possible due to the presence of the GPU card.

So, to sum up, I uninstalled CUDA and I install again Openmpi as explained in the user manual (sudo apt-get install openmpi-bin openmpi-doc libopenmpi-dev) but it still does not work properly.

Sylavin

[sfraniatte]

Where can I find the terminal log ? Is it when I compile Openlb at he installation ?

Yes, I did follow this section…

Thank you for your answer !
Sylvain

[sfraniatte]

Do you use a debugger like gdb ? I think it can help you

[sfraniatte]

Which error/bug did you get ? Take care to locate the inlet and outlet at the correct places…

[sfraniatte]

You are right ! It was the problem. I works with materials 3,31,32,33,34. I just really do not understand why it uses the material 3 to compute Yplus. I wonder how it computes the Yplus value and if it is correct in my case. Thank you !

[sfraniatte]

I compute y+ as in the aorta example :
if ( bouzidiOn ) {
SuperLatticeYplus3D<T, DESCRIPTOR> yPlus( sLattice, converter, superGeometry, stlReader, 3 );
SuperMax3D<T> yPlusMaxF( yPlus, superGeometry, 1 );
int input[4]= {};
T yPlusMax[1];
yPlusMaxF( yPlusMax,input );
clout << “\n yPlusMax=” << yPlusMax[0] << std::endl;
}

It is definetely the number of digits because I did the test with the same case, the same quantity of materials but with different materials number (by swithcing materials from 30, 31, 32, 33, 34 to 3, 6, 7, 8, 9 for the inlets it does work).

[sfraniatte]

Finnally, I think it works. It is just that the results are not what I excepted. I was looking at the pressure near the inlet and the outlet (which are not exactly at the inlet and the outlet) and it is not at all the values that I set at the inlet and outlet. However, when I see the whole flow with Paraview, I see that the stream become very complexe and I think it is ok. Then, by switching between Bouzidi and Bounce Back, because of the complexity of the aorta stl file, the result is different. It schows that Bouzidi is better I think.

Thanks a lot for your help and I can share it if you explain me how to do. I am still a beginner.

Best regard
Sylvain

[sfraniatte]

I spoke to fast, it still does not work. So, to be clear, I use the aorta example and I want replace the velocity inlet condition by a pressure inlet condition. So I use the aorta stl file and I did touch the indicators for the inlet and the outlets. The inlet/outlet materials are placed correctly. When I use Bouzidi condition, this line is used : “setBouzidiBoundary<T,DESCRIPTOR>(lattice, superGeometry, 2, stlReader);”. When I use Bounce Back Boundary, this line is used : “setBounceBackBoundary(lattice, superGeometry, 2);”. It works only in the second case. So, I think that I have to add something in the first case but I do not know what.

Sorry for the previous message…

Best regard
Sylvain

[sfraniatte]

I mean it is exactly the same behavior and the orientation of the inlets and the outlets are along the same axis. Sorry for the unuseful details.

However, it seems that I solved my problem. It was a line which did not have to be there.

Thanks a lot for your help !

Best regard
Sylvain

[sfraniatte]

I use my own stl file and the aorta stl file. The result is exactly the same in the two cases. So, you can consider that I use the aorta stl file and that there is no problem with the stl file. The pressure boundary axis is aligned. I would like to set a pressure inlet and outlet condition by imposing 10 Pa at the inlet and 0 Pa at the outlet. It works only with BouzidiOn=False but My walls are not straight…

[Author]

Posts