A couple questions regarding particles

Hey there! I’m not entirely sure how to ping as this question was intended for Rene Gassmoeller, but I’m curious how other people are thinking about modeling reactions with particles as well.
Daniel Douglas and I were talking about particles and we ran into a couple questions that I hope you don’t mind answering:
How are fluid reactions, solid->liquid and vice versa handled with particles? Are new particles created during operator splitting timesteps or are some of the reacting solid ones converted into fluid particles? Daniel said you mentioned separate “worlds” that can overlap each other so I suppose one might contain the solid and the other liquid, but how would these communicate with each other in terms of changing water content of the solid?

1 Like

Hi @flacombe1, thanks for reposting this to the forum!

I think you raise very valid and interesting questions. The tldr answer is that currently we do not support everything you raised as questions, and if you wanted to do these things with particles in ASPECT it would require some coding to implement a few new features. I can describe what can currently be done:

How are fluid reactions, solid->liquid and vice versa handled with particles? Are new particles created during operator splitting timesteps or are some of the reacting solid ones converted into fluid particles?

What reactions happen on particles is controlled by the particle properties you select. E.g. the grain_size particle property lets the material model compute the amount of grain size change and then applies that change to the particles. We currently have no particle property that tracks the amount of melt, the closest property is the one called melt_particle, which tracks if the value of the compositional field that stores porosity at the particle location is above a certain threshold. If the value exceeds the threshold the particle property is set to 1 (=particle is in melting region), otherwise it is set to 0. An additional feature of this particle property is that the particles that have the property 1 (inside the melt region) are advected with the fluid velocity, while the other particles are advected with the solid velocity.

Daniel said you mentioned separate “worlds” that can overlap each other so I suppose one might contain the solid and the other liquid, but how would these communicate with each other in terms of changing water content of the solid?

Currently there can be different worlds, but ordinarily they do not communicate at all. It is not impossible however to let them communicate. If you had a particle property A in world 0 that needs to know information of particle property B in world 1, then you could do something like the following:

                  particle_properties =
                    this->get_particle_manager(1).get_interpolator().properties_at_points(this->get_particle_manager(1)..get_particle_handler(),
                                                                                                quadrature_points,
                                                                                                property_mask,
                                                                                                cell);

here, cell is the current cell, property_mask is a deal.II ComponentMask that describes which particle property you want (property B), quadrature_points are the locations where you want to know the property (likely the locations of the particles in world 0), and the vector particle_properties will then be filled with the interpolated property values.

Concerning generation of fluid particles and advecting different particle worlds with different velocities: This is also not implemented at the moment, but especially advecting different worlds with different velocities shouldnt be hard to implement. Generating additional particles itself is also easy, but getting the numerical algorithm right (conserving mass etc.) is more tricky and would require a proper design of the algorithm.

Hope that helps, let me know in case you have a precise plan for what you want to do, I can point you in the right direction for what to implement.

Best,
Rene

A tiny addition to Rene’s excellent answer:

Are new particles created during operator splitting timesteps or are some of the reacting solid ones converted into fluid particles?

Perhaps I’m reading your question wrong, but it sounds like you are imagining that the particles each correspond to a physical thing (like an olivine grain or a melt droplet). This is a completely reasonable assumption, but it is better not to imagine particles as a part of the model. Instead, I imagine them as little pins stuck into particular parts of the model that move as the model moves. In ASPECT, we can tell the part of the domain near to each particle to act in a certain way by assigning particular values to that particle. Conversely, we can update the values stored on a particle by interrogating the domain near to each particle.

To answer your question, ASPECT does not automatically create new particles during operator splitting timesteps, nor does it convert reacting solid particles into fluid particles. Instead, particle properties (such as phase proportions) can be updated to reflect phase changes, and user-defined methods can modify particle behaviour to simulate mass transfer.

Thank you both for your responses!
I was motivated to ask this as I run what John would describe as coupled two phase flow models, which gives my hydrologist committee member a heart attack; so to appease neither I describe them as fugacity dislocation creep models. We’ve set them up in the 1D solubility benchmark and I was curious what using particles would do. From my understanding they track sharp boundaries well and I was hoping to see what would change at the phase boundaries when we got to the really low Fluid Reaction Time Scales. I was also hoping they would handle instantaneous hydration overestimation better- I’m not sure how to describe this better so I’ll refer to a couple of figures that were intended to be viewed as separate gifs, but are too big to post here.
(I apologize for the legend running away; these models all have different runtimes and varying timestep sizes, so correlating them all means that there are large TimeStepDifferences, that eventually become insignificant due to the large runtime of these tests.)

Essentially the problem is that in the beginning of the model we set 1% BoundFluid (0.01) as the amount of water within the solid everywhere- accommodated as either _Porosity or _BoundFluid fields with 0% BF allowed in the middle third and 0% P in the outer thirds. We can see that as the model progresses every model run approaches the “correct” amount of porosity in the middle, but that initial pulse to ~0.016 and ~0.013 respectively stems from an initial overestimation of how much porosity should come from the 0.01 we initially gave it. Based on your answers I’m not sure that particles would help reduce this, but I think it’s an interesting problem nonetheless.

These are two sets of model runs where the only differences, besides the number of models in the set, are: CFL-1 / 0.5, and Reference Fluid Density-2000 / 2500.
The RFD change accounts for dampening the extremes, but the CFL seems to change the groupings of models between sets. CFL-0.5 has the red and green models grouped, while CFL-1 has the green and yellow grouped.

@gassmoeller It would be really interesting to implement particles for future work as I’m working on adding compressibility to these coupled models right now, but I’m not sure if compressible particles are supported.
Assuming no compression, if I understand your answer correctly, could we have one particle world inform the solid fugacity calculations by setting a particle property to contain some water content number while advecting the solid in a field normally?

@bobmyhill You were correct in reading my question that way and I appreciate knowing that they are more tracers than simulation points, as it changes the nature of the question somewhat.

I’m a new user and limited to one image per post, this is the second image