Fracture flow in porous media

[Philipp Schädle]

Hey all,

I am interested in reactive transport processes in fractured porous media on reservoir scale. In the manual of the porous flow module it is written that chemical reactions are going to be implemented in the near future.

Is there any plan to implement flow (and transport) in fractures in the porous flow module? 

Best,

Philipp

[Andrew....@csiro.au]

Hi Philipp,

Yes, we are planning to implement chemical reactions in 2017. What do you mean exactly by "flow in fractures" ? Currently you can: (1) define a part of your mesh to be a fracture and allow fluid to flow (Darcy eqn) in it; or (2) define certain sides of your 3D elements to be fracture planes and allow fluid to flow in them (using a higher conductivity, for instance).

a

Hey all,

Best,
Philipp
--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/moose-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/7636a860-9377-45ff-bb73-9fe2a8281afc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Philipp Schädle]

Hi Andrew,

I would like to investigate reactive transport through fractured porous media like in enhanced geothermal systems. Ultimately, I want to model fracture networks with potentially many intersecting fractures. For that I am interested in a discrete representation of the fractures. 

Option 1 seems to be a continuum fracture representation, right? 

Best,

Philipp

[Andrew....@csiro.au]

​That sounds very similar to what quite a few other moose users are interested in, so i imagine there will be lots of overlap between your work and other people's. Great!

In (1) we create a mesh that has fractures inside it. That is not an easy task. Then we prescribe high permeability to those fractures.

Is this what you mean by a "discrete representation" of fractures, or something different? I feel i'm about to learn something here!

a

From: moose...@googlegroups.com <moose...@googlegroups.com> on behalf of Philipp Schädle <philipp....@gmail.com>
Sent: Tuesday, 21 February 2017 8:04 AM
To: moose-users
Subject: Re: Fracture flow in porous media
 

Hi Andrew,

I would like to investigate reactive transport through fractured porous media like in enhanced geothermal systems. Ultimately, I want to model fracture networks with potentially many intersecting fractures. For that I am interested in a discrete representation of the fractures. 

Option 1 seems to be a continuum fracture representation, right? 

Best,
Philipp
Am Montag, 20. Februar 2017 21:16:57 UTC+1 schrieb andrew.wilkins: Hi Philipp,Yes, we are planning to implement chemical reactions in 2017.  What do you mean exactly by "flow in fractures" ?  Currently you can: (1) define a part of your mesh to be a fracture and allow fluid to flow (Darcy eqn) in it; or (2) define certain sides of your 3D elements to be fracture planes and allow fluid to flow in them (using a higher conductivity, for instance).
a

From: moose...@googlegroups.com <moose...@googlegroups.com> on behalf of Philipp Schädle <philipp....@gmail.com>
Sent: Tuesday, 21 February 2017 3:49 AM
To: moose-users
Subject: Fracture flow in porous media
 
Hey all,

I am interested in reactive transport processes in fractured porous media on reservoir scale. In the manual of the porous flow module it is written that chemical reactions are going to be implemented in the near future.

Is there any plan to implement flow (and transport) in fractures in the porous flow module? 

Best,
Philipp
 --
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/moose-users.
To view this discussion on the web visit  https://groups.google.com/d/msgid/moose-users/7636a860-9377-45ff-bb73-9fe2a8281afc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
   

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/moose-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/dccdd822-6e2c-442c-9d35-8e75cd2cb66e%40googlegroups.com.

[Antoine Jacquey]

Hi Philipp,

Like Andrew said, we are a few moose users dealing with flow within fractured porous media.
If you are interested in generating meshes with discrete fractures or faults as lower dimensional elements, you can take a look at this publication from colleagues of mine http://link.springer.com/article/10.1007%2Fs12665-015-4537-x. They created a meshing software based on triangle and tetgen with can generate such meshes. If you want to try it, we can send an executable on request.

We also developed a moose-based application for modeling coupled thermo-hydro-mechanical in faulted and fractured geothermal reservoirs. We only included non-reactive transport for now and I am not sure we will go in the direction of reactive transport.
In case you want to know more, don't hesitate to contact me.

Cheers,

Antoine

[Philipp Schädle]

Hi Andrew,

It's good to here that there are also other people working on that.

From your description it seems that you use a discrete fracture-matrix approach to model flow in fractures. As you already said the meshing is a challenging task. Maybe Antoines' tool can help there. 

For reactive transport modelling in such fracture networks it would be necessary to implement specific physics and chemistry to the fractures. For example, in fractures I would like to consider different models for reactive surface area than in the porous matrix. 

Cheers,

Philipp

[Philipp Schädle]

Hi Antoine,

Thanks for the link. It sounds very interesting and I will have a closer look, soon. 

Is your moose-based application related to the porous flow module or to some other modules? I read in one of the other google group chats that you tried to combine the XFEM module with porous flow. How did that go? This is actually something I though of as well. Although there are still some things missing for the implementation of flow in fractured porous media using XFEM. 

Regarding your THM app, is there any publication about this, or something else where I could find some more info?

Cheers,

Philipp

[Andrew....@csiro.au]

​Hi  Antoine,

This question about meshing keeps coming up. Do you think you could put the meshing source code on github somewhere, and provide a link to it from mooseframework.org (or similar)? Then we can just point people to it and let them play rather just talking about it! We have some basic cubit/trelis functionality, but your stuff looks much more developed.

a

From: moose...@googlegroups.com <moose...@googlegroups.com> on behalf of Antoine Jacquey <antoine...@gmail.com>
Sent: Tuesday, 21 February 2017 6:12 PM
To: moose-users
Subject: Re: Fracture flow in porous media
 

Hi Philipp,

Like Andrew said, we are a few moose users dealing with flow within fractured porous media.
If you are interested in generating meshes with discrete fractures or faults as lower dimensional elements, you can take a look at this publication from colleagues of mine http://link.springer.com/article/10.1007%2Fs12665-015-4537-x. They created a meshing software based on triangle and tetgen with can generate such meshes. If you want to try it, we can send an executable on request.

We also developed a moose-based application for modeling coupled thermo-hydro-mechanical in faulted and fractured geothermal reservoirs. We only included non-reactive transport for now and I am not sure we will go in the direction of reactive transport.
In case you want to know more, don't hesitate to contact me.

Cheers,

Antoine

Le lundi 20 février 2017 23:04:54 UTC+1, Philipp Schädle a écrit :

Hi Andrew,

I would like to investigate reactive transport through fractured porous media like in enhanced geothermal systems. Ultimately, I want to model fracture networks with potentially many intersecting fractures. For that I am interested in a discrete representation of the fractures. 

Option 1 seems to be a continuum fracture representation, right? 

Best,
Philipp
Am Montag, 20. Februar 2017 21:16:57 UTC+1 schrieb andrew.wilkins: Hi Philipp,Yes, we are planning to implement chemical reactions in 2017.  What do you mean exactly by "flow in fractures" ?  Currently you can: (1) define a part of your mesh to be a fracture and allow fluid to flow (Darcy eqn) in it; or (2) define certain sides of your 3D elements to be fracture planes and allow fluid to flow in them (using a higher conductivity, for instance).
a

From: moose...@googlegroups.com <moose...@googlegroups.com> on behalf of Philipp Schädle <philipp....@gmail.com>
Sent: Tuesday, 21 February 2017 3:49 AM
To: moose-users
Subject: Fracture flow in porous media
 
Hey all,

I am interested in reactive transport processes in fractured porous media on reservoir scale. In the manual of the porous flow module it is written that chemical reactions are going to be implemented in the near future.

Is there any plan to implement flow (and transport) in fractures in the porous flow module? 

Best,
Philipp
 --
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/moose-users.
To view this discussion on the web visit  https://groups.google.com/d/msgid/moose-users/7636a860-9377-45ff-bb73-9fe2a8281afc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
   

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/moose-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/4abb8003-e65f-4fa0-a17d-eb50f0dcd612%40googlegroups.com.

[Antoine Jacquey]

@ Philipp

Our moose-based application (Golem) is not directly based on Andrew's module Porous Flow, though they have some parts which are similar.
The mechanics model we use has a similar formulation as the Tensor Mechanics module of Moose (similar codes for stress divergence and finite strain for example). For the hydrothermal part, we do not consider multi-phase flow as the Porous Flow module can do. We consider only fully-saturated single-component flow. So that's the main difference I would say.

I used the XFEM module for some tests yes. I implemented some constrains classes for darcy flow and heat transfer to match the physics of our application. But this is still preliminary work and I still need to test the formulation again. I got actually too busy to continue this work. I have not yet tried to implement some kind of effective stress concept on the interface of the fracture (I think that's the next main step). Here is an example of what I could do in 2D for TH coupling with XFEM:


We do not have any publication yet for the moose-based application. I am actually preparing a manuscript with a colleague on that topic. I can keep you updated when the status is more advanced.


@ Andrew
I am not a developer for this Meshing software so I am not the best suited person to answer your question, but I will try. I just know that my colleagues who developed that cannot release the source code for now due to the regulations of our institution. They need to find an agreement with the legal department of our institution to have an open-source license and this process is still ongoing from what I understood. For now the source code is stored on a internal Gitlab platform.
Mauro (one of the developer) can give you more details about that if you want.
Meanwhile, they can provide you with the executable and basic examples if you want to play around. Contact person: Mauro (cac...@gfz-potsdam.de)

Cheers,

[Philipp Schädle]

Hey Antoine,

Your figures look really good. Did you ever try to consider two intersecting fractures, particularly in 3D? This would be something very interesting to consider for flow and transport. 

How did you consider flow and heat transport along the fracture? Looking at the temperature plot it seems that there is not much heat transport along the fracture. But I might be wrong.

This is definitely an interesting approach. I am happy if you keep me up to date regarding any publications about your app or the XFEM coupling. 

Cheers,

Philipp

[Antoine Jacquey]

Hi Philipp,

For the XFEM model for pore pressure and temperature, I was considering that heat is transported only by conduction within the fluid across the fracture, this is why, a clear jump in temperature can be observed between the two faces of the fracture. The heat transport along the fracture is mostly controlled by advection (the fracture has a higher permeability than the surrounding rock).

At the time when I was experimenting with the XFEM module, intersecting fractures was not supported by the module. I don't know if it's still the case, may be a developer of the module can answer you.

However, we consider intersecting fractures in 3D using the lower dimensional elements (2D) within the 3D matrix (without XFEM then). We have kind of a "benchmark" for advection of temperature in fractures and faults. Here is a short movie with a really low resolution (for easiness of sharing).

Cheers,
Antoine

[Benjamin Spencer]

In MOOSE's XFEM implementation, we can currently handle intersecting fractures in 2D, but not in 3D.  An element can currently only be split once in a time step, so you have to first impose one cut, and then at a latter time impose the second cut.  It's probably not terribly hard to extend that to 3D -- we just haven't gotten to it yet.

-Ben

--
You received this message because you are subscribed to the Google Groups "moose-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to moose-users+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/moose-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/f53b86c5-8ec1-4fdb-be84-1f46f1ce6347%40googlegroups.com.

[Philipp Schädle]

Hi Antoine,

Thanks a lot for the video, this looks really nice. I guess you used your moose-based application Golem and the MeshIt tool to generate this simulation. What kind of method do you use in order to consider the physics at the lower dimensional fracture element? Is there any pressure discontinuity? 

As I am also interested in reactive transport I am thinking about working with the porous flow module and implement something similar there. 

Cheers,

Philipp

[Andrew....@csiro.au]

​I do a lot of development in PorousFlow, and would be delighted if you could contribute your ideas and code, Philipp. I'm certain everyone else thinks the same way. Our goal is to make it as useful as possible, and since the architecture and short-term goals of PorousFlow are currently quite flexible, now is a great time to start contributing. If I, or others can help, please just ask. Or perhaps you'd like to set some goals, or something else?

Excited,

a

From: moose...@googlegroups.com <moose...@googlegroups.com> on behalf of Philipp Schädle <philipp....@gmail.com>

Sent: Wednesday, 8 March 2017 7:57 PM
To: moose-users

Hi Antoine,

Cheers,
Antoine

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/moose-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/c08f2bcd-cd0a-4f0e-b4d1-b546c4a268f0%40googlegroups.com.

[Philipp Schädle]

Hi Ben,

Thanks for that information. 

I am looking forward to see where the XFEM module goes. 

Best,

Philipp

Am Donnerstag, 2. März 2017 20:48:05 UTC+1 schrieb benjamin.spencer:

In MOOSE's XFEM implementation, we can currently handle intersecting fractures in 2D, but not in 3D.  An element can currently only be split once in a time step, so you have to first impose one cut, and then at a latter time impose the second cut.  It's probably not terribly hard to extend that to 3D -- we just haven't gotten to it yet.

-Ben

On Thu, Mar 2, 2017 at 2:05 AM, Antoine Jacquey <antoine...@gmail.com> wrote:

Hi Philipp,

For the XFEM model for pore pressure and temperature, I was considering that heat is transported only by conduction within the fluid across the fracture, this is why, a clear jump in temperature can be observed between the two faces of the fracture. The heat transport along the fracture is mostly controlled by advection (the fracture has a higher permeability than the surrounding rock).

At the time when I was experimenting with the XFEM module, intersecting fractures was not supported by the module. I don't know if it's still the case, may be a developer of the module can answer you.

However, we consider intersecting fractures in 3D using the lower dimensional elements (2D) within the 3D matrix (without XFEM then). We have kind of a "benchmark" for advection of temperature in fractures and faults. Here is a short movie with a really low resolution (for easiness of sharing).

Cheers,
Antoine

--
You received this message because you are subscribed to the Google Groups "moose-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.

Visit this group at https://groups.google.com/group/moose-users.

[Philipp Schädle]

Hi Andrew,

That's great to hear. I would like to model reactive transport processes in fracture networks of EGS systems. For that I need an efficient and robust method to model highly fractured networks as well as computationally demanding reactive transport processes.

You said that you are working on the reactive transport part and that this might be released in fall. This is definitely something I am looking forward to see. Are you working on a fully implicit formulation or some sort of operator splitting? This might be important in order to implement transport along fractures and between fracture and porous matrix.

Best,

Philipp

[Andrew....@csiro.au]

Hey Philipp,

We have got the chemical advection and diffusion done, but haven't yet written a PR, so it's not in the code. What we haven't got is the important things - the actual chemical reactions and their effect on porosity and permeability! We plan on using an approach that's basically identical to ToughReact for that - using generalised concentrations and reading the reactions from a database.

I will endeavour to add the chemical advection + diffusion as soon as i can, unless someone else volunteers to do it.

Regarding the operator splitting - I benefited from a detailed brain-dump from Hai Huang while at INL recently, who has previously coded reactive transport physics. He strongly urged me to consider operator splitting. I think my position on this is recognise that operator splitting will probably be necessary, and if it is, then use MOOSE's MultiApp approach, with two instances of PorousFlow running: one with fluid flow/mechanics/etc and the other with chemistry. In this way we don't have to code anything much special before actual runtime. What do you think about this? I've BCCed Hai in case he wants to add something here.

I've also BCCed Jonathon and Chris who are the chief drivers of reactive transport in PorousFlow. They are concerned with modelling things like CO2 sequestration. They might like to add something too. We haven't worked on the chemistry since about November2016 - perhaps it's time to channel some energy into this part of PorousFlow.

What are your timeframes? Eg, would you like to complete this coding in a week, a month or a year?

a

From: moose...@googlegroups.com <moose...@googlegroups.com> on behalf of Philipp Schädle <philipp....@gmail.com>
Sent: Wednesday, 8 March 2017 11:29 PM
To: moose-users
Subject: Re: Fracture flow in porous media
 

Hi Andrew,

Hi Antoine,

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/eeaaa33f-0fc5-4447-a724-536acc9cfe31%40googlegroups.com.

[Philipp Schädle]

Hi Andrew,

What do you mean by chemical advection/diffusion? Did you implement anything specific or basically the regular tracer advection/diffusion? Do you plan to use an existing code to solve the reaction equations or do you want to code your own solvers?

Before actually considering Moose to work with, my attempt was to use an existing open source geochemistry solver and couple this one to a flow and transport solver. I am not sure if using existing codes is along the lines with the development polity of Moose or your module in particular. However that may save a lot of time. The geochemistry code I am talking about is very efficient in solving chemical reactions and its algorithms are particularly dedicated to be used for reactive transport applications. Things like porosity or any thermodynamic property could also be updated from the geochemistry solver.

Using an existing code and couple its algorithms to the porous flow module would suggest to use an sequential (operator splitting) approach. Your suggestion to use Moose's MultiApp approach would be consistent with this and it seems to save quite some time for implementation. Hence, I would also consider to use an (iterative) sequential approach.

I will have to finish my PhD within the next three years. So there is quite some time for me to work on certain things. However, I would want to get something running by the end of the year. This would ideally include reactive transport in highly fractured networks. So, it would be also important for me to know what the general timeline for development of the porous flow module is.  At the moment it is difficult for me to estimate any implementation time as I know Moose only very little.

Best,

Philipp

[Andrew....@csiro.au]

​
Shall we take this discussion off list? Hai also suggested we use an existing code and couple via multiapps.

a

From: moose...@googlegroups.com <moose...@googlegroups.com> on behalf of Philipp Schädle <philipp....@gmail.com>
Sent: Friday, 10 March 2017 7:03 PM
To: moose-users
Subject: Re: Fracture flow in porous media
 

Hi Andrew,

What do you mean by chemical advection/diffusion? Did you implement anything specific or basically the regular tracer advection/diffusion? Do you plan to use an existing code to solve the reaction equations or do you want to code your own solvers?

Before actually considering Moose to work with, my attempt was to use an existing open source geochemistry solver and couple this one to a flow and transport solver. I am not sure if using existing codes is along the lines with the development polity of Moose or your module in particular. However that may save a lot of time. The geochemistry code I am talking about is very efficient in solving chemical reactions and its algorithms are particularly dedicated to be used for reactive transport applications. Things like porosity or any thermodynamic property could also be updated from the geochemistry solver.

Using an existing code and couple its algorithms to the porous flow module would suggest to use an sequential (operator splitting) approach. Your suggestion to use Moose's MultiApp approach would be consistent with this and it seems to save quite some time for implementation. Hence, I would also consider to use an (iterative) sequential approach.

I will have to finish my PhD within the next three years. So there is quite some time for me to work on certain things. However, I would want to get something running by the end of the year. This would ideally include reactive transport in highly fractured networks. So, it would be also important for me to know what the general timeline for development of the porous flow module is.  At the moment it is difficult for me to estimate any implementation time as I know Moose only very little.

Best,
Philipp
Am Mittwoch, 8. März 2017 23:51:19 UTC+1 schrieb andrew.wilkins: Hey Philipp,We have got the chemical advection and diffusion done, but haven't yet written a PR, so it's not in the code.  What we haven't got is the important things - the actual chemical reactions and their effect on porosity and permeability!  We plan on using an approach that's basically identical to ToughReact for that - using generalised concentrations and reading the reactions from a database.

Hi Andrew,

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/52b9d77a-5b6b-424d-9924-f5ce5bc5c720%40googlegroups.com.

[Antoine Jacquey]

I'm actually interested to hear your ideas and pros/cons about this external coupling for chemistry or internal calculation in Moose.
I do not plan to go for reactive transport in the near future but I was asked by some colleagues if it would be possible to implement during the next years.
We ended up with two possibilities: external coupling with Phreeqc (open-source) with possible iterations within a time step to insure stability or completely implement the chemistry in Moose which may be a lot (I do not know a lot about reactive transport so I am not sure how much work that would be).
I am still not sure which option has the best ratio efficiency, time consumption. Would be glad to hear your thoughts on that.
Cheers,

Antoine

[Andrew....@csiro.au]

Hi Antoine,

I'm CCing Jonathon and Chris who are my MOOSE collaborators in CSIRO who are more expert on the chemistry than me.

Antoine is interested in PorousFlow and would like to study reactive transport. He is wondering whether it'd be better to use a MultiApp coupling with an open-source geochemistry solver rather than coding the chemistry into MOOSE.

My feeling is that coding into MOOSE would be an easier way to go. This is just based on a *few* experiences of coupling-2-codes-together experiences that I have had. Initially everything seems super easy, but there are always unforseen technical nightmares (in my experiences so far) that take a lot of energy to resolve. Also, you end up having to partially maintain two codes and the interfaces between them, and the codes never quite do what you want.

This is just my very limited experience, and is not related to chemistry. I'm quite keen to hear what Jonathon and Chris think. Is it possible to estimate the time required to implement chemistry in MOOSE, and the time required to couple MOOSE to XXXX ? I cannot even do the former, since I'm not an expert here.

a

From: moose...@googlegroups.com <moose...@googlegroups.com> on behalf of Antoine Jacquey <antoine...@gmail.com>
Sent: Wednesday, 15 March 2017 7:48 PM
To: moose-users
Subject: Re: Fracture flow in porous media
 

I'm actually interested to hear your ideas and pros/cons about this external coupling for chemistry or internal calculation in Moose.

Antoine

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/moose-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/310e79b9-ad64-4c3d-b732-58edc66f5c7c%40googlegroups.com.

[Philipp Schädle]

Hi all,

An advantage of coupling geochemical solvers with flow and transport solvers is, that the geochemical solver has no spatial dimension. In fact, the flow and transport simulation is performed for the given spatial domain and the geochemical calculation is than performed for every point in space. This also means that on large grids a lot of chemical simulations are necessary to perform. Consequently, it is important to use efficient methods to solve the chemical calculation. 

Due to aforementioned I think it could be more efficient to use an existing geochemical solver which is dedicated to solve such problems.

I am considering to use Reaktoro as the geochemistry solver (reaktoro.org/about/), which is developed by one of my colleagues. Reaktoro provides numerical methods which allow efficient simulation of demanding applications like reactive transport modelling. In Leal et al., 2016 (Computational methods for reactive transport modeling: A Gibbs energy minimization approach for multiphase equilibrium calculations.) it is shown that it can be faster, more robust and equally accurate than existing tools. Nevertheless, you can also call Phreeqc methods out of Reaktoro. 

I am curious to here what you guys think about this. 

Cheers,

Philipp

[mauro13]

Hi,

As for a previous post from Antoine, we had given some thoughts on external coupling a geochem simulator (PHREEQC in our case) to the MOOSE framework. Indeed, the advantage (As Philipp pointed out) stays in the non dimensional (node based calculation) which provides flexible in passing the information back and forth.
My main concern at this point is on how to best consider the retro-feedback from the chemistry into the THM FE framework. 
Take this situation as an example:
That is, if precipitation of a certain mineral occurs, and therefore a change in the porosity at a specific node, how can we pass this information to the FE simulator? If we change the porosity locally, we would need to constrain the related change in the in(out)flow on an elemental base in order to conserve the fluid mass locally (where the fluid will go, in other words). This will require calculating the intracell fluxes at each iteration and its changes over time( this is why, I think, usually FD or FV have been considered for this kind of simulations). Alternately, we can impose constraints on the time stepping, thus (hoping to) limiting these unbalances, though I do not see any physical criterion here (would be mere try and mostly fail) and could be heavy in terms of  computing times.
We have been discussing these (and other) issues with some colleagues here deeply involved in reactive transport modelling, without arriving at any satisfactory conclusions. I would be really interested to hear your opinions in this regard.
Cheers,
Mauro

[Andrew....@csiro.au]

​
The standard way of doing this is to perform a (Picard) iterative process like: while (unconverged) do: solve the flux; solve the chemistry; couple. The test for convergence would be whatever you'd write if you had a properly coupled single code. So, not hard to implement, but potentially computationally inefficient in practice. Obviously the type of simulation will have a great effect on whether this strategy works in practice. I guess one advantage of coding everything in MOOSE is that we'd have the option of solving everything at once, or using MultiApps (2 MOOSE instances) and using the Picard approach.

a

From: moose...@googlegroups.com <moose...@googlegroups.com> on behalf of mauro13 <mauroc...@gmail.com>
Sent: Friday, 17 March 2017 6:22 PM
To: moose-users

Cc: Ennis-King, Jonathan (Energy, Clayton North); Green, Chris (Energy, Clayton North)
Subject: Re: Fracture flow in porous media
 

Hi,

As for a previous post from Antoine, we had given some thoughts on external coupling a geochem simulator (PHREEQC in our case) to the MOOSE framework. Indeed, the advantage (As Philipp pointed out) stays in the non dimensional (node based calculation) which provides flexible in passing the information back and forth.
My main concern at this point is on how to best consider the retro-feedback from the chemistry into the THM FE framework. 
Take this situation as an example:
That is, if precipitation of a certain mineral occurs, and therefore a change in the porosity at a specific node, how can we pass this information to the FE simulator? If we change the porosity locally, we would need to constrain the related change in the in(out)flow on an elemental base in order to conserve the fluid mass locally (where the fluid will go, in other words). This will require calculating the intracell fluxes at each iteration and its changes over time( this is why, I think, usually FD or FV have been considered for this kind of simulations). Alternately, we can impose constraints on the time stepping, thus (hoping to) limiting these unbalances, though I do not see any physical criterion here (would be mere try and mostly fail) and could be heavy in terms of  computing times.
We have been discussing these (and other) issues with some colleagues here deeply involved in reactive transport modelling, without arriving at any satisfactory conclusions. I would be really interested to hear your opinions in this regard.
Cheers,
Mauro

On Thursday, March 16, 2017 at 11:02:17 AM UTC+1, Philipp Schädle wrote:

Hi all,

An advantage of coupling geochemical solvers with flow and transport solvers is, that the geochemical solver has no spatial dimension. In fact, the flow and transport simulation is performed for the given spatial domain and the geochemical calculation is than performed for every point in space. This also means that on large grids a lot of chemical simulations are necessary to perform. Consequently, it is important to use efficient methods to solve the chemical calculation. 

Due to aforementioned I think it could be more efficient to use an existing geochemical solver which is dedicated to solve such problems.

I am considering to use Reaktoro as the geochemistry solver (reaktoro.org/about/), which is developed by one of my colleagues. Reaktoro provides numerical methods which allow efficient simulation of demanding applications like reactive transport modelling. In Leal et al., 2016 (Computational methods for reactive transport modeling: A Gibbs energy minimization approach for multiphase equilibrium calculations.) it is shown that it can be faster, more robust and equally accurate than existing tools. Nevertheless, you can also call Phreeqc methods out of Reaktoro. 

I am curious to here what you guys think about this. 

Cheers,
Philipp

Am Mittwoch, 15. März 2017 23:47:55 UTC+1 schrieb andrew.wilkins: Hi Antoine,I'm CCing Jonathon and Chris who are my MOOSE collaborators in CSIRO who are more expert on the chemistry than me.

Antoine is interested in PorousFlow and would like to study reactive transport.  He is wondering whether it'd be better to use a MultiApp coupling with an open-source geochemistry solver rather than coding the chemistry into MOOSE.
My feeling is that coding into MOOSE would be an easier way to go.  This is just based on a *few* experiences of coupling-2-codes-together experiences that I have had.  Initially everything seems super easy, but there are always unforseen technical nightmares (in my experiences so far) that take a lot of energy to resolve.  Also, you end up having to partially maintain two codes and the interfaces between them, and the codes never quite do what you want.
This is just my very limited experience, and is not related to chemistry.  I'm quite keen to hear what Jonathon and Chris think.  Is it possible to estimate the time required to implement chemistry in MOOSE, and the time required to couple MOOSE to XXXX ?   I cannot even do the former, since I'm not an expert here.
a

From: moose...@googlegroups.com <moose...@googlegroups.com> on behalf of Antoine Jacquey <antoine...@gmail.com>
Sent: Wednesday, 15 March 2017 7:48 PM
To: moose-users
Subject: Re: Fracture flow in porous media
 
I'm actually interested to hear your ideas and pros/cons about this external coupling for chemistry or internal calculation in Moose.
I do not plan to go for reactive transport in the near future but I was asked by some colleagues if it would be possible to implement during the next years.
We ended up with two possibilities: external coupling with Phreeqc (open-source) with possible iterations within a time step to insure stability or completely implement the chemistry in Moose which may be a lot (I do not know a lot about reactive transport  so I am not sure how much work that would be).
I am still not sure which option has the best ratio efficiency, time consumption. Would be glad to hear your thoughts on that.
Cheers,
Antoine
 --
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/moose-users.
To view this discussion on the web visit  https://groups.google.com/d/msgid/moose-users/310e79b9-ad64-4c3d-b732-58edc66f5c7c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
   

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/moose-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/05d9c1f9-ab2d-4d8c-a69f-2625da110a2c%40googlegroups.com.