porous medium simulation issue

[nipinl]

Hi,
I am new to OpenLB, but used palabos in the past. I have a series of images of a simple porous medium and wanted to estimate the permeability. The resolvedRock3d is a perfect example for me. I ran resolvedRock3d for a few hours serially in my desktop with no results. I tried in an hpc machine with 80 cores, but the simulation got killed in minutes for unknown reason. But I believe it is related to memory.

I download the digital rock sample, generate tif stack using Fiji and convert to vti using paraview. I repeated with image stack of simple shapes like pipe, which palabos run in few minutes; but observed same behavior. Other cases like city3d are running pretty fast in the hpc.

I am sure that I’m messing up something but unable to pinpoint. I have used the same arguments like “”Tiff Scalars” 2.5e-6 1.0 200 1.0″ for resolvedRock3d as I’m not sure of these values. For simple porous medium, I replace 200 with number of slices and 2.5e-6 with physical dx.

Any help in this regard is greatly appreciated.

Thanks,
Nipin

[jan]

Dear nipinl,

did you run the case from the example or another one? For me, it works as described there, even without a cluster. You should try to run that first and get accustomed to the parameters of the setup using that example.

The example case also comes with an explanation of the command line arguments:
<filename> <arrayname> <scaling-factor> <time-scaling-factor> <resolution> <pressure_drop>
So in the example you mentioned, rock.vti would be the file with the geometry, "Tiff Scalars" is the name of the array with the wanted data in that file.
Since the files are usually in different units, a scaling factor is provided. In this case the scaling factor is 2.5e-6, but you can use anything else. A pretty side effect is that you can actually artificially increase and decrease your pore size. A similar scaling factor is given for time. In the example 1 is suggested, but this can be changed if you want to have a longer or shorter simulation. 200 refers to the resolution (it resolves the y-length (extent[1]) with 200 cells -> physDeltaX is calculated from it). Finally, you have to option to define a pressure drop, which is set to 1.

What do you mean by “I replace 200 with number of slices”, how many slices do you have? It sounds like the resolution you’re using is much too high. Just start with a resolution of 200 or perhaps even 100 first and then perform grid independence studies to find the necessary resolution.

Best regards,
Jan

[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 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

[mdiazv64]

Hello. I would appreciate support regarding the application of the Lattice Boltzmann method in porous media flow. I am using the resolvedRock3d example applied to an image following the procedure explained in the manual but it does not converge. It runs around 3% (step=4185), but from then on it gives NAN and I don’t understand why that is.

In my case I have the following parameters:

Timeframe to be simulated: 29.7014 s
MaxIT: 139908
—————– UnitConverter information —————–
–Parameters:
Resolution: N= 100
Lattice velocity: latticeU= 0.000714753
Lattice relaxation frequency: omega= 1.33333
Lattice relaxation time: tau= 0.75
Characteristic length(m): charL= 0.0509
Characteristical speed(m/s): charU= 0.00171372
Phys. kinematic viscosity(m^2/s): charNu= 0.0001017
Phys. density(kg/m^d): charRho= 963.8
Characteristical pressure(N/m^2): charPressure= 0
Mach number: machNumber= 0.00123799
Reynolds number: reynoldsNumber= 0.857704
Knudsen number: knudsenNumber= 0.00144338
— Conversion factors:
Voxel length(m): physDeltaX= 0.000509
Time step(s): physDeltaT= 0.000212292
Velocity factor(m/s): physVelocity= 2.39764
Density factor(kg/m^3): physDensity= 963.8
Mass factor(kg): physMass= 1.27098e-07
Viscosity factor(m^2/s): physViscosity= 0.0012204
Force factor(N): physForce= 0.00143546
Pressure factor(N/m^2): physPressure= 5540.59
————————————————– ———–

Please, I would appreciate any suggestions on how to proceed.

[nipinl]

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

[jan]

Dear mdiazv64,

You should check that the material numbers are correct (that the inlet, outlet, and walls are where you want them to be). Also, as nipinl pointed out, you should try to reduce the pressure drop. Maybe it’s too high.

@nipinl: Thanks for the valuable suggestion.

Best regards,
Jan

[mdiazv64]

Dear nipinl and jan,

Thank you very much for your quick reply. In my case I want to estimate the permeability of a synthetic porous medium with cube shape in the z direction. The boundary conditions would be the pressure differential at z and non-flow on the other faces. But I wouldn’t know how to modify the boundary conditions in the code.
I would appreciate if you could guide me on this matter.

Best regards,

Martin

[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

[jan]

Hi all,

@nipinl thanks again for the valuable input.

Just a few additional thoughts on this (or maybe just reiterating what nipinl said in other words):

If you don’t want the periodic boundary, then you should turn it off, as nipinl mentioned, by setting everything to false cuboidGeometry.setPeriodicity(false, false, false); or just remove the line (it’s off by default).

I haven’t tested it, maybe you’re lucky and the current implementation already sets the walls correctly. However, you should make sure it does by checking the material numbers (the wall should be 2). If it doesn’t, then you should add a single layer of material number 2 to all 4 faces in prepareGeometry, similar to the inflow and outflow. Note that the superGeometry.clean(); has the potential to mess up the material numbers, so if you need to change something, you might want to turn it off first. Otherwise the changes are sometimes harder to evaluate with clean enabled.

Best regards,
Jan

[Author]

Posts