[nipinl]

Hi,
I’ve commented out all calculations related to yPlus and then simulation is working fine.

Best,
Nipin

[nipinl]

Hi Adrian,
Thank you for your reply. I’m copying the backtrace here. I think I was vague in communicating the point at which simulation crashes. It is after stl file loading. Simulation works perfectly for coarser resolution;I tried N = 40 and 100 and it works. But it crashes for N>200.

Thank you for your time,
Best,
Nipin

Thread 1 “cylinder3d” received signal SIGABRT, Aborted.
0x0000155554d7e7ac in ?? () from /cvmfs/soft.computecanada.ca/gentoo/2023/x86-64-v3/usr/lib64/libc.so.6
#0 0x0000155554d7e7ac in ?? () from /cvmfs/soft.computecanada.ca/gentoo/2023/x86-64-v3/usr/lib64/libc.so.6
#1 0x0000155554d306f2 in raise () from /cvmfs/soft.computecanada.ca/gentoo/2023/x86-64-v3/usr/lib64/libc.so.6
#2 0x0000155554d1a4b2 in abort () from /cvmfs/soft.computecanada.ca/gentoo/2023/x86-64-v3/usr/lib64/libc.so.6
#3 0x0000155554d1a3d5 in ?? () from /cvmfs/soft.computecanada.ca/gentoo/2023/x86-64-v3/usr/lib64/libc.so.6
#4 0x0000155554d29662 in __assert_fail () from /cvmfs/soft.computecanada.ca/gentoo/2023/x86-64-v3/usr/lib64/libc.so.6
#5 0x000000000048ebc9 in olb::util::normalize<double> (a=std::vector of length 3, capacity 3 = {…}) at ../../../src/utilities/vectorHelpers.h:204
#6 0x00000000004a6d8b in olb::SuperLatticeYplus3D<double, olb::descriptors::D3Q19<olb::descriptors::FORCE> >::operator() (this=0x7fffffff4120, output=0x7fffffff3a30, input=0x7fffffff3a20) at ../../../src/functors/lattice/turbulentF3D.hh:77
#7 0x0000000000532b88 in olb::FunctorPtr<olb::SuperF3D<double, double> >::operator()<double*, int*> (this=0x7fffffff4360) at ../../../src/utilities/functorPtr.h:100
#8 olb::SuperMax3D<double, double>::operator() (this=this@entry=0x7fffffff4300, output=output@entry=0x7fffffff3e30, input=input@entry=0x7fffffff3d60) at ../../../src/functors/lattice/superMax3D.hh:88
#9 0x0000000000414fcb in getResults (stlReader=…, timer=…, superGeometry=warning: RTTI symbol not found for class ‘olb::SuperGeometry<double, 3u>’
…, iT=0, converter=…, sLattice=…) at cylinder3d.cpp:325
#10 main (argc=<optimized out>, argv=<optimized out>) at cylinder3d.cpp:466
#0 0x0000155554d7e7ac in ?? () from /cvmfs/soft.computecanada.ca/gentoo/2023/x86-64-v3/usr/lib64/libc.so.6
#1 0x0000155554d306f2 in raise () from /cvmfs/soft.computecanada.ca/gentoo/2023/x86-64-v3/usr/lib64/libc.so.6
#2 0x0000155554d1a4b2 in abort () from /cvmfs/soft.computecanada.ca/gentoo/2023/x86-64-v3/usr/lib64/libc.so.6
#3 0x0000155554d1a3d5 in ?? () from /cvmfs/soft.computecanada.ca/gentoo/2023/x86-64-v3/usr/lib64/libc.so.6
#4 0x0000155554d29662 in __assert_fail () from /cvmfs/soft.computecanada.ca/gentoo/2023/x86-64-v3/usr/lib64/libc.so.6
#5 0x000000000048ebc9 in olb::util::normalize<double> (a=std::vector of length 3, capacity 3 = {…}) at ../../../src/utilities/vectorHelpers.h:204
#6 0x00000000004a6d8b in olb::SuperLatticeYplus3D<double, olb::descriptors::D3Q19<olb::descriptors::FORCE> >::operator() (this=0x7fffffff4120, output=0x7fffffff3a30, input=0x7fffffff3a20) at ../../../src/functors/lattice/turbulentF3D.hh:77
#7 0x0000000000532b88 in olb::FunctorPtr<olb::SuperF3D<double, double> >::operator()<double*, int*> (this=0x7fffffff4360) at ../../../src/utilities/functorPtr.h:100
#8 olb::SuperMax3D<double, double>::operator() (this=this@entry=0x7fffffff4300, output=output@entry=0x7fffffff3e30, input=input@entry=0x7fffffff3d60) at ../../../src/functors/lattice/superMax3D.hh:88
#9 0x0000000000414fcb in getResults (stlReader=…, timer=…, superGeometry=warning: RTTI symbol not found for class ‘olb::SuperGeometry<double, 3u>’
…, iT=0, converter=…, sLattice=…) at cylinder3d.cpp:325
#10 main (argc=<optimized out>, argv=<optimized out>) at cylinder3d.cpp:466

[nipinl]

Hello Jan,
Thank you for the detailed response and for your insightful suggestions. I’ll follow those and keep you posetd.

Best,
Nipin

[nipinl]

Hi Martin,
I think you can start with resolvedRock3d example and do very little modification to get your task done. I am a beginner in olb and I’m trying to learn from the relevant examples, user guide and code base.

Start with the resolvedRock3d example. There, the pressure difference is applied in the x direction and both y and z are periodic(line#367). If you don’t want to to edit the code, you can rotate your geometry (in paraview or other) in such a manner that your old z is new x.

I am not sure if you need to specify a different material number for all the lateral surfaces and assign bounce back boundary condition to have no flow in those faces.

In olb, BC is assigned for each material number. Assigning material number is done in the prepareGeometry function(#97). Initially the material number everywhere will be 0. Zero is replaced everywhere by 2 in #105 by “superGeometry.rename(0, 2);”

For the left x face, material number 2 is replaced by 3 and is termed inflow (# 111-115). Similarly, right x face, outflow is defined replacing 2 by 4(#118-122). As I mentioned earlier, you might want to define lateral faces in this way and assign material number 2. Material number 2 is given bounce back BC later in the code. Someone more knowledgeable will be able to comment if this is required or not.
Start experimenting and do update in the thread.

Best,
Nipin

[nipinl]

Hi Sylvain,

I use simple bounce back, same as in resolvedRock3d. I run 100s physical time. Did you face stability issues with bounce back? I tried to increase the Re for resolvedRock3d, but it it also showing similar behavior. I guess something I’m missing. The table of parameters I used and the case set-up is here:
https://www.dropbox.com/scl/fi/tjh2til3vug2isxg4kgue/highReA5.zip?rlkey=o0b2y03z3j079j9dqc79bun38&st=5x80bsa6&dl=0

Best Regards,
Nipin

[nipinl]

Did you try reducing your pressure drop? the last argument?

[nipinl]

Hi Sylvain,
I found a related response here:
https://www.openlb.net/forum/topic/does-openlb-support-local-grid-refinement/#post-7816

Best,
Nipin

[nipinl]

Hi Bobbie,
I forgot to update here that my issue is resolved. I was writing vti in different format than ascii, which caused the issue. With right format, the simulation is working. I’m new to openLB, and now getting familiar with it going through the examples that are relevant to my case. Happy to communicate.

Best Regards,
Nipin

[nipinl]

Hi Jan and whoever viewing this thread,

I was missing one little piece: ParaView writes VTI files in ‘Append’ format. I overlooked the instruction to save in ASCII format, which caused the trouble. With the ASCII-formatted VTI file, the simulation works perfectly. I apologize for the confusion and for wasting some of your valuable time.

Best regards,
Nipin

[nipinl]

Dear Jan,
First of al, thank you so much for your time and interest. I really appreciate that.

I tried to run the example resolvedRock3d with the same set of arguments (./resolvedRock3d rock.vti “Tiff Scalars” 2.5e-6 1.0 200 1.0). Since it is working fine for you, I guess the only possibility would be that I am messing up with the creation of vti file. How are you generating the vti file?

I downloaded the image database using the link provided in the example. It has 512 tif images. When I load those images into paraview, ‘cell To Point data’ filter is greyed so I proceeded to save data as vti; but that resulted in a vti file with only one image data (784 kb).

Hence I loaded all 512 images in imageJ and saved as a single tif file followed by opening the tif file in paraview and ‘Save Data’ in vti to make rock.vti. In the dialogue box, I select ‘Choose arrays to write’ which confirms the array name “Tiff Scalars”.

For the simple cases like pipe, I have a series of bmp files (128 slices), which I use to make single tif file using ImajeJ and convert to vti using paraview.

Once again, thanks Jan for your help.

Best regards,
Nipin

[nipinl]

Hi Bobbie,
Have you tried the resolvedRock3d case? or have you tried any geometric model with vtk? Because, I faces some problems in running resolvedRock3d with vti file. Just curious!!
Regards,
Nipin

[Author]

Posts