ImperialCollegeLondon / pnextract

Pore network extraction from micro-CT images of porous media
http://www.imperial.ac.uk/earth-science/research/research-groups/perm/research/pore-scale-modelling
55 stars 28 forks source link

Questions about Medial Surface Settings parameters #8

Open EdgarL0 opened 3 years ago

EdgarL0 commented 3 years ago

Hello,

I'm working on a sample consisting of a packing of spheres generated from a DEM software, which is voxelized and so far everything is working well with the pnextract software. However, I have some specific and general questions regarding the medial surface parameters for pnextract.

Additionally, I saw in the code the presence of the MinRPore parameters, and I'm not sure how it works and if I need to adjust it myself or not, since it gets updated automatically at the end of the distance map computation.

Finally, in the pnextract paper in July 2017 (https://journals.aps.org/pre/abstract/10.1103/PhysRevE.96.013312), I see that you used a threshold for the radius of 1.75 voxel length for generating spheres, and another threshold named "d_treshold" to control the details of the medial-surface. Are those thresholds adjustable in pnextract ?

Thanks in advance for your answer,

Edgar.

aliraeini commented 3 years ago

The short answer is that medialSurfaceSetting should not be modified by the end-user. These settings were made run-time modifiable for code developers. For this reason, I sometimes regret that I exposed the keyword medialSurfaceSetting in the first place! BTW, here medial-surface is a term used to describe the maximal-ball hierarchy (which lie on medial surface), not an explicit triangulated mesh.

The keyword MinRPore is meant to be the only keyword to be modified by code users, to control the level of filtration to be applied to the medial surface etc. I shall update the documentation to clarify this.

That said, the default values are mostly chosen for typical micro-CT images (of sandstones, sandpacks, and carbonate rocks, and to some extent bead/sphere-packs). If the image is really high resolution or has a very different pore structure (long throats etc) than a sandstone or carbonate rock, then one need to just run sensitivity studies and inspect the generated medial-surface hierarchies (.vtu files) and pore labels and most importantly the computed flow properties.

On your specific comments:

ClipRoutx and ClipRoutyz are different because the X is considered flow direction and Y&Z are no flow and different assumptions are possible on how those should be treated, but ClipRoutx should be close to 0 which implies something like mirroring the pore-space on either side in X direction. This version of the code does not generate throats for Y and Z boundaries, mainly because of backward compatibility and because current pnflow code does not support that.

midRFrac is used for as a pre-screening check to check whether two maximal-spheres are potentially on the same branch of maximal-ball hierarchy,

RMedSurfNoise and nRSmoothing should not be changed for typical use cases. But if you do, smaller values sound more reasonable for sphere-packs.

On lenNf and vmvRadRelNf, there is no such thing as "to merge pre-identified pores", the merging is done during the generation of maximal-ball hierarchy. Once maximal-ball hierarchy is generated, the centres and number of pores are fixed as they are tied to the maximal-ball hierarchy. Anyway, for sphere-packs it makes sense to choose smaller values for lenNf (to reduce merging), if you willing to spend time on running sensitivity studies though. Decreasing vmvRadRelNf will reduce the merging of the nearby pores/spheres too. It;s value shall be higher than one and increasing it increases the degree of filtering (relaxation) applied to the radius and having a too large value will put other constraints (lenNf etc) in charge.

Rcorsf and Rcors are mainly for speeding up computations, to remove nearby spheres before starting to merge and group maximal-spheres based on the parameters mentioned above. By default RCorsn is same as MinRPore, but will be overwritten if medialSurfaceSetting keyword is provided. If you have a high-resolution but noisy image then it makes sense to increase Rcors or MinRPore, otherwise, in typical cases, Rcorsf which is the dimensionless version of Rcors should do an OK job.

MinRPore is the only parameter that the user supposed to adjust, although if not provided it will be automatically reset after distance map calculation.

If I recall correctly 1.75 is the MinRPore, and d_treshold is related to Rcorsf and Rcors. The formulation has been slightly updated to make the code a bit more robust for different image types and resolutions. Rcorsf default value is 0.15 though. and "d_treshold(r_v+r_mv)/2" is replaced with "RCorsnfr_v+RCorsn".

xu-kai-xu commented 3 years ago

Hi, I am doing some pore network extraction work from CT images with the pnextract code. As for my understand, the real pore space is continuous, which means the segmentation of pore and throat is some kind of arbitrary. So I wanna know if the pore space segmentation influences the permeability or other properties. I read from Dong, H., & Blunt, M. J. (2009). Pore-network extraction from micro-computerized-tomography images. Physical Review E, 80, 036307. that they use a parameter $\alpha$ to segment pore space (eq. 3). I guess the params lenNf and vmvRadRelNf play similar role as that $\alpha$, but I am not sure about it. How should I set the params to change the pore space segmentation process and get PNM with different relative pore and throat length. Thanks a lot.

aliraeini commented 3 years ago

@xu-kai-xu, the only keyword which is meant to be modified by the code user is MinRPore (or Rnoise, they are synonymous!). This can make the network coarser or more detailed if you decrease it.

$\alpha$ in Dong and Blunt (2009) is something else and is also present in the pnextract code, with some simplifications (see lines 78-79 of https://github.com/ImperialCollegeLondon/pnextract/blob/master/src/pnm/pnextract/blockNet_write_cnm.cpp). The number chosen here is "arbitrary" from a mathematical perspective, but its value can be fixed in a data driven fashion. The Rnoise is more arbitrary and in an ideal world! any number should give good results for the flow properties.