Material IDs given in Preprocessing

[FloWsnr]

Thank you for the amazing work!

I am currently trying to set up a complex simulation with multiple solid materials. I understand that your simulations currently supports up to 4 solid materials (IDs 1,4,6,7). Material 2 is reserved for internal solid, material 0 is the wetting fluid and material 3 the non-wetting fluid. Two questions:

1. What is material 5?

2. Why do you change the material numbers to 2608 etc in the pore utils? Is that a random number, is that some density?

   erock[erock == 0] = 2608  # pore space / w fluid
   erock[erock == 1] = 2609  # boundary
   erock[erock == 2] = 2610  # grains
   erock[nw_fluid_mask == 3] = 2611  # add nw fluid back in if needed

Thank you for your help!

[je-santos]

Hi @FloWsnr,

That is a great question and, unfortunately, I don;t have a good answer. There is some sort of data type conversion whenever the c++ code reads in the python written geometry. I took me a little while to find those values, but you can see that if you run a simulation and open the geometry.vti file with paraview the numbers are right (0,1,2,etc).

It seems that I only have 1 of the boundaries there (=1). Feel free to add the rest of them and send me a PR. Here is where the dynamics are defined: https://github.com/je-santos/MPLBM-UT/blob/3e45adc6a776494246fae7505d3ba627006c8b9d/src/2-phase_LBM/ShanChen.cpp#L291

Best, Javier

[abhayjc]

Hii.... This is great work... I want to work with code but am facing issues with it. I learned installation process on youtube and followed same process but facing error. File "2_phase_sim.py", line 215, in image_pc, image_satn, pc, snwp = mplbm.run_porespy_drainage(inputs, wetting_angle, voxel_size) File "/home/ssahoo/mambaforge/envs/lbm/lib/python3.7/site-packages/mplbm_utils/pore_utils.py", line 152, in run_porespy_drainage drn = ps.simulations.drainage(pc=pc, im=image, inlets=inlets, voxel_size=voxel_size, g=0) AttributeError: module 'porespy' has no attribute 'simulations'

[FloWsnr]

Hi Javier,

I came back to the project (sorry for the one year delay :D) and finally found the error, i.e. the reason you had to use these weird numbers (2608 etc).

It has nothing to do with the cpp code. Instead, the function np_array.to_file("file.dat") here works not as intented.

Only for your specific numbers (and only because you convert the array into np.int16), the .dat file then has the correct numbers (1,2,3). If you change the numbers or the dtype (int32), the .dat file become broken.

The fix is to use explicit "C" ordering and the np.savetxt function.

flat_array = array.flatten(order="C")
np.savetxt("array.dat", flat_array, fmt="%d")