Create two phase solver for saturated soil with explicit method

[tianchiTJ]

Create two phase solver for saturated soil with explicit method

Summary

Create ExplicitTwoPhase solver with fully saturated condition to carry out the hydraulic coupled computation. A one-point two phase method based on volume fractions is used to represent the solid phase and water phase on the same particle representively.

Motivation

Use it to compute the hydraulic coupled problem. It's the foundation of following implementation of SemiImplicitTwophase solver and even ThreePhase solvers.

Design Detail

1. Node base design The computation is mainly based on solving the momentum balance equations of mixture and water phase on nodes. (There are three different sections to represent the domain, solid phase, water phase and mixture). As solving two of them is enough to obtain the results, we solve the mixture first and then the water phase. Therefore, in the node class, all variables, like velocity, are designed and stored as 0 for mixture and 1 for water phase.

2. Particle class design Different with the node class, all variables in the particle class are designed and stored as 0 for solid and 1 for water phase, which is convenient to represent the effective stress and other variables. A "TwoPhaseParticle" namespace is created to include the functions and variables used.

   2.1. New variables for two phase particle Scalar type porosity, liquid_material_id, liquid_mass, liquid_mass_density, pore_pressure, pore_pressure_constraint Vector type liquid_velocity, liquid_strain, permeability Map type liquid_velocity_constraints Other type liquid_material 2.2. Current function need to be modified initialise_particle, hdf5, compute_mass 2.3. New functions for two phase compute_pore_pressure, update_permeability

3. Solver class design A mpm-explicit-twophase is created in the solver class. The main loop is quite similar with the mpm-explicit solver, but the mapping functions are used for each phase separately. compute_pore_pressure is an important additional function in the TwoPhase solver based on the Darcy law. The position update is based on the solid phase velocity.

4. Based on porous medium theory: The volume_fractions_ is defined in the particle class based on the porous medium theory and is used to compute the variables in each phase.

5. Fully saturated condition: The sum of volume_fractions_ should be equal to 1 and updated in each step.

6. An option is considered for the choice of formulation type (u-p,u-v-p,u-w-p)

Drawbacks

1. The critical size of time interval is influenced by the water phase,
2. The permeability can not be too small to form large fluctuation.

Rationale and Alternatives

Create semi-implicit solver based on incompressible flow hypothesis in the future.

Prior Art

One can refer to the following papers: [1] Kafaji, Issam KJ al. Formulation of a dynamic material point method (MPM) for geomechanical problems. 2013. [2] Jassim, Issam, Dieter Stolle, and Pieter Vermeer. "Two‐phase dynamic analysis by material point method." International journal for numerical and analytical methods in geomechanics 37.15 (2013): 2502-2522. [3] Zabala F, Alonso E E. Progressive failure of Aznalcóllar dam using the material point method[J]. Géotechnique, 2011, 61(9): 795-808.

[kks32]

Thanks, Tianchi! Would we be deriving the two Phase particles from Particle or ParticleBase class? So, there will be a lot of virtual functions which won't be active in Particle, is this right?

[tianchiTJ]

Yes, that's true. But It won't be a lot for explicit.

[kks32]

When we add more phases, this might get more complicated. Could we look at some Design Patterns, and see if we can adapt any of them. I'm tinking of Decorator / Adapter / Proxy

https://refactoring.guru/design-patterns/cpp.

https://isocpp.org/wiki/faq/multiple-inheritance#mi-example

Please let me know your thoughts.

[bodhinandach]

I would say, for the TwoPhaseParticle, going as what we discussed before was good enough. Not many functions to be derived and we can include some specialized functions as private functions and append it in the more general functions available in ParticleBase.

I am feeling we need to work more on refactoring the solver as some more specialized solvers are starting to get derived from the current MPMExplicit. I will draft a proposal in the upcoming weeks and open an RFC.

[tianchiTJ]

I agree with Nanda. I think the TwoPhaseParticle deriving for Particle is good for now. For the solver part, I think many functions are generally used for all solvers like the mapping process, applying traction and smoothing pressures. Do you think it's better to package them? Otherwise it's very likely to forget to add them into new solver.

[kks32]

I'm planning to use the decorator pattern to refactor the Solver, we can have an RFC to discuss that separately.

Could we potentially create a new class for Fluid phase functions and then use multiple inheritances to define the TwoPhase Particle with the base being ParticleBase still? The advantage is we don't have to define these functions in the base class, so not every Particle should have these functions. It would be worthwhile considering the advantages/disadvantages of both approaches.

[kks32]

@tianchiTJ could you please add ClassNames and their inheritance scheme to your RFC, thank you!

[tianchiTJ]

@kks32 Is that the scheme what you mean?

[ezrayst]

One thought I have (as hinted by Krishna) is that maybe we can think a roadmap for two-phase two-points (two layers) and potentially three-phase one-point and so on. Hopefully we don't have to refactor again when we get there.

We still can have TwoPhaseParticle which are derived from ParticleBase, I think. But when we have two-phase two points, what would be the structure?

[bodhinandach]

I'm planning to use the decorator pattern to refactor the Solver, we can have an RFC to discuss that separately.

I guess that's better to discuss the refactoring of the solver. I am seeing this as necessary too for the purpose of two-phase two points coupling that I will start soon entering June. I have some ideas in mind.

Could we potentially create a new class for Fluid phase functions and then use multiple inheritances to define the TwoPhase Particle with the base being ParticleBase still? The advantage is we don't have to define these functions in the base class, so not every Particle should have these functions. It would be worthwhile considering the advantages/disadvantages of both approaches.

I am okay with that. But if you are putting a separate class for the fluid part, there are few points that I can raise:

1. What about functions involving a mixture of fluid and soil at the same time? Actually, we encounter that many times too. In this case, the FluidFunction class should have the capability to access variables defined in Particle as well, or we should pass everything through function arguments.
2. How to access those functions from the solver level? Eventually, the solver should access it through the derived Particle, let say TwoPhaseParticle, class that hosts both the Solid and Fluid functionalities. Eventually, you need to define it in the ParticleBase as well. That's the same, right?

[kks32]

When we do TwoPhaseParticle, would all particles be TwoPhaseParticles?

If you have a derived class pointer, then you don't need to define it in ParticleBase.

[tianchiTJ]

@kks32 Is that the particle scheme you mean? One thing should be noticed is that there is some variables used in both phase, like volume, strain. How to connect the ParticleBase and FluidParticleBase?

[bodhinandach]

I think it's simpler to make it in ParticleBase as we have now. We can try to minimize that as much as possible, but for some function that we cant, let's put it as virtual function in ParticleBase and throw an error if it is accessed by any particles.

When we do TwoPhaseParticle, would all particles be TwoPhaseParticles?

No. a particle can just be normal Particle or TwoPhaseParticle. The usage is also can be done simultaneously, depends on "particle_type": "P2D", "P2DTWOPHASE", etc. specified in the .json and src file. Though the implemented solver may need to be changed if mixed usage is encountered.

[kks32]

The issue with doing all functions in ParticleBase is we need to add all these unnecessary throws for solid particle and it will keep increasing when we add ThreePhase.

If we are storing all different types of particles in the mesh class under a single container, that will be a lot of filtering to operate on functions for certain types of particles.

How would Initialise HDF5 data would work, would we be storing a lot more data for all the particles?

[kks32]

@tianchiTJ I just meant adding class names and inheritance to the documentation in RFC.

[kks32]

An additional argument against deriving classes to handle TwoPhase which are not consistent with the base class contract. This argument also applies to #634

C++ coding standards: 101 rules - Herb Sutter and Andrei

Rule 38: Practice Safe Overriding Override responsibly: When overriding a virtual function, preserve substitutability; in particular, observe the function's pre- and post-conditions in the base class. Don't change the default arguments of virtual functions. Prefer explicitly redeclaring overrides as virtual. Beware of hiding overloads in the base class. After the base class guarantees the preconditions and postconditions of operation, any derived class must respect those guarantees. An override can ask for less and provide more, but it must never require more or promise less because that would break the contract that was promised to calling code.

Effective C++ - Scott Meyers

Rule 32 Make sure public inheritance models "is-a" relationship

Hence, deriving TwoPhase paricle or FluidParticle will violate these two rules

[kks32]

@tianchiTJ could you please revise your RFC with the new direction in #637

[bodhinandach]

Hence, deriving TwoPhase paricle or FluidParticle will violate these two rules

@kks32 At the moment they are not derived. The TwoPhaseParticleis derived only from Particle. For the two-phase two-layer simulation, I am not going to couple them inside the particle, but at the solver.

[kks32]

@bodhinandach Deriving from particle and having functions specific to the derived types and not on other derived types will violate this rule.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[bodhinandach]

The development to address this RFC is ongoing as can be followed in PR #680

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.