ImperialCollegeLondon / pnextract

Pore network extraction from micro-CT images of porous media

Home Page:http://www.imperial.ac.uk/earth-science/research/research-groups/perm/research/pore-scale-modelling

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Questions about Medial Surface Settings parameters

EdgarL0 opened this issue · comments

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.

  • For ClipRoutx and ClipRoutyz parameters, my understanding is that they limit the size of maximal-spheres outside the boundaries, but I don't understand why the default value is different for x axis and y,z axis. Should I leave it this way ? In addition, if i want to delete myself all throats and pores generated close to the boundaries, can I totally disregard the parameter or it will still have influence on the rest of the computations ?

  • For midRFrac, I'm not sure if it is used before or for the labeling/creation of the hierarchy of the maximal spheres.

  • For RMedSurfNoise and nRSmoothing, I understand that they're herein to control the noise amplitude, but is this only for micro-CT images or should I also use it for DEM generated images ? Can I just simply put both to 0 if I want to skip this step or will it cause any problem ?

  • For lenNf and vmvRadRelNf, I have trouble in understanding the "relative" distance or size. For LenNf I understand that two pores A and B can be merged if dist(center(A),center(B))< LenNf(max(radius(A),radius(B)) but according my understanding this condition is the preliminary one that must be used to create the hierarchy and not at the time when we start to merge pre-identified pores. Then, in my mind, I would expect a LenNf value greater than 1 at this stage. Similarly with vmvRadRelNf, I understand that the pores will be merged if the throat size is very close to the pore size (while centers of pores must be close), but then I don't understand how to adjust vmvRadRelNf adequately, since it reduces the merging when reducing the parameter.

  • For Rcorsf and Rcors, I'm not sure about their role in the maximal ball algorithm, and how they influence the results.

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.

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 "RCorsnf*r_v+RCorsn".

commented

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.

@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.