Clarrifying output of tesselationWrapper for pore size

Hi

>If I understand correctly the following code generates a regular Delaunay triangulation, then computes the volume of each Voronoi cell.

Correct.

>Is there a way to estimate the pore diameter?

Sorry but... what is "a pore"? And why should it have a diameter? The pore space is not made of spherical voids...

Bruno

Hi Bruno,
thank you for the reply.
Yes in general pores are not spherical. Sometimes they are assumed to be spherical for simplicity. I retract that question.

Is it possible to calculate a pore size(pore body or pore throat).

Jesse

It all depends on what you call a pore, a pore size, etc.
B

Please see attached picture
http://pasteall.org/pic/890cbd9a2847d8f640088abf4eb42a2c
I would like to calculate the radius of such an inscribed sphere.
Jesse

Ok, then it is available. However it is not part of TesselationWrapper and still tricky to use. I would have to exploit TwoPhaseFlowEngine, and I don't dare trying to explain here.
If you are prepared you can check the code a find your way. Else you can implement your own inscribed sphere calculation in python, that's "just" based on well known equations.
Good luck!
Bruno

Thanks for the reply.
Ill take a look at TwoPhaseFlowEngine and computePoreBodyRadius to see what I can glean from there
best
Jesse

Hi Bruno,
I compibled yade with the additional flag: -DCMAKE_CXX_FLAGS=-DTWOPHASEFLOW
Then, using the code below I am able to export details about the pore network.
    TwoPhase=TwoPhaseFlowEngine()
    TwoPhase.initialization()
    TwoPhase.savePoreNetwork()

To test it out, I took a packing of many clumps, and exported the pore network, then compressed the packing and exported the pore network again.
I then compare the two PoreBodyRadius.txt files which are saved out by ->savePoreNetwork(), I see there is a minor change, however, most of the pore radii have a value of 3.58352e-09 in both files. (Both files are attached below)

Some hopefully useful info:
Screenshot of packing uncompressed:
http://pasteall.org/pic/c4ea0606ccf1f05d34fd2f4d3f137924
PoreBodyRadius.txt uncompressed:
http://pasteall.org/939654/text

Screenshot of packing compressed:
http://pasteall.org/pic/d0d01e9550c2c89c78872089682f72a8
PoreBodyRadius.txt compressed:
http://pasteall.org/939656/text

Do you know what I might be missing? Please let me know if I can provide other clarifying information

many thanks
Jesse

Could this be an issue with the scale of the spheres? Or does the method have issues when dealing with clumps or overlapping spheres?

The problem here is to define which quantities you are interested in.
If you can somehow define what you call a "pore body radius" then most likely it will not be equivalent to the output of savePoreNetwork().
Besides, as you suspect the spheres should not be overlapping too much.
Bruno

Hi Bruno,
thank you for the reply. Im looking to get the maximum inscribed sphere which fits in the pore.
I confirmed that the output from savePoreNetwork() to the file PoreBodyRadius.txt, is generated by the method
computePoreBodyRadius()
This method is described:
    // This routine finds the radius of the inscribed sphere within each pore-body
    // Following Mackay et al., 1972.
I looks like computePoreBodyRadius should calculate exactly what I am looking for.
Is there documentation or anyway to fine tune this method?
many thanks
Jesse

A little more info which I hope clarifies the issue:
This image is a vizualization of the packing in blue and the maximum inscribed sphere fitting inside the pore in red
for an uncompressed packing:
http://pasteall.org/pic/ff406868e6a245c170983d6ebcd8082e

and for the compressed packing:
http://pasteall.org/pic/9aed9bec9c9e607f426b5e64a7532940

There are several things to note. There are a whole bunch of very small inscribed spheres, these all have the same size (3.58352e-09). As well, in the uncompressed packing one very large pore sphere is generated which encompasses the entire packing. I am not sure where to start here. Am I using computePoreBodyRadius incorrectly? Is this a known issue with the method I can correct somehow?

your help always is appreciated
many thanks
Jesse

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

computePoreBodyRadius was implemented by Thomas Sweijen for two-phase flow and (I guess) it includes some pore merging as described in [1]. The minimum radius could be there to help numerical stability of the flow problem, hence not a feature of the actual geometry - that's just my guess.
HTH
Bruno

[1] https://link.springer.com/article/10.1007/s11242-016-0689-8