Simulation of tracer+fluid propagation within a 3D fracture network

[nialov]

Hey,

firstly, thanks for the software and considerable work you have done to document and structure the code well! It definitely helps in getting started with such a complex scientific topic.

I am (trying) setting up a (simple?) model where water flows along discrete (2D) fractures in a 3D domain. I have managed to get a working 3D model, mostly based on your TracerFlowModel example with setting up the fractures, domain and fracture network as 3D. However, the propagation does not seem to happen between fractures i.e. through the 1D intersections between fracture planes. Questions:

• Your examples do not seem to touch this subject so I am interested if this phenomenon is supposed to be possible?
• Secondly, if this propagation should occur, how to speed it up so that I can see it?

Let me know if you want me to share my current code 😬

Cheers,
Nikolas Ovaskainen

[IvarStefansson]

Hi Nikolas,
I suspect the culprit to be the vanishingly small value of normal_permeability. My suggestion is you set this to 1e-2, say. Please let me know if this helps. You might also be interested in using the classes DimensionDependentPermeability and CubicLawPermeability.
Cheers,
Ivar

[nialov]

If I understood correctly, you can only see the initial state and the first time step already shows a state where the tracer swept through the domain? I.e. the simulation reaches steady-state?
One culprit is your usage of FractureSolidConstants where you do not provide an explicit value for permeability, which is the matrix permeability (surrounding rock). By default, that value will then be set to 1, leading to rapid flow through your 3D domain. which can lead to the observed results, and is in any case not recommended for Darcy flow.

Yes, this was the case and the default matrix permeability was part of the problem, thank you for the info! I changed it to a lower value.

You do not need to include the DataSavingMixin explicitly, as that class is already included in the SinglePhaseFlow you are using. Remove it if you intend to expand the model as you might run into inheritance issues.

I had not noticed this was the case, I removed it as suggested.

Is there a reason you include the cell final_results_export ? According to how you configured your time manager and your model parameters, you should get all the time steps between 0 and endtime exported by default. From the files you get exported I can see that your simulation finishes after 29 time steps. Calling final_results_export and redundantly writing files, while ignoring time-related arguments of write_vtu, can lead to your top-level pvd file loosing references to individual time steps saved before that call.

This was probably the case, I was partly overwriting the results at the end. This fix along with changing the matrix permeability made the simulation sensible, now flow happens in time steps rather than immediately reaching steady state 🥳 .

Thanks a lot for the help! I might still come up with questions if I have time to delve deeper.

[vlipovac]

No worries, great we could help!

[IvarStefansson]

Out of curiosity, might I ask what you are working on, Nikolas?

[nialov]

Out of curiosity, might I ask what you are working on, Nikolas?

Short answer is that I am using porepy results as a comparison to laboratory contrast flow agent tests we have conducted in crystalline rock samples. Basically I just want to see, if the fluid behaviour we see in the ct-scanned sample, at multiple time steps, is similar to results provided by porepy. Time is quite limited and my next main focus is somehow trying to create fracture networks that can be used as inputs in porepy and that resemble the ct-scan results where fractures have been segmented.

Broader answer is that I am working on trying to close the gap between geological data collection, usually by geologists, and the numerical modelling that could be made better accessible for the same geologists. We organized a workshop related to this area in June (See https://github.com/nialov/dfn-modelling-workshop-for-nuclear-waste-repositories-2025 for info). If you are interested, we are probably organizing another iteration of the workshop in June 2026.

[IvarStefansson]

Sounds interesting! Please feel free to keep me posted on your progress!