Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create two phase solver for saturated soil with explicit method #633

Open
tianchiTJ opened this issue May 13, 2020 · 23 comments · May be fixed by #680
Open

Create two phase solver for saturated soil with explicit method #633

tianchiTJ opened this issue May 13, 2020 · 23 comments · May be fixed by #680

Comments

@tianchiTJ
Copy link
Contributor

tianchiTJ commented May 13, 2020

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

  1. 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.

  2. 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.

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

  4. 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
Copy link
Contributor

kks32 commented May 14, 2020

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
Copy link
Contributor Author

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

@kks32
Copy link
Contributor

kks32 commented May 14, 2020

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
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor

kks32 commented May 14, 2020

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
Copy link
Contributor

kks32 commented May 14, 2020

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

@tianchiTJ
Copy link
Contributor Author

@kks32 Is that the scheme what you mean?

@ezrayst
Copy link
Contributor

ezrayst commented May 14, 2020

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
Copy link
Contributor

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
Copy link
Contributor

kks32 commented May 14, 2020

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
Copy link
Contributor Author

@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
Copy link
Contributor

bodhinandach commented May 14, 2020

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
Copy link
Contributor

kks32 commented May 14, 2020

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
Copy link
Contributor

kks32 commented May 14, 2020

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

@kks32
Copy link
Contributor

kks32 commented May 17, 2020

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
Copy link
Contributor

kks32 commented May 25, 2020

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

@bodhinandach
Copy link
Contributor

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

@kks32 At the moment they are not derived. The TwoPhaseParticle is 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
Copy link
Contributor

kks32 commented May 26, 2020

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

@stale
Copy link

stale bot commented Aug 10, 2020

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 stale bot added the wontfix label Aug 10, 2020
@bodhinandach
Copy link
Contributor

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

@stale stale bot removed the wontfix label Aug 11, 2020
@stale
Copy link

stale bot commented Oct 10, 2020

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
Copy link

stale bot commented Dec 16, 2020

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 stale bot added the wontfix label Dec 16, 2020
@stale stale bot closed this as completed Dec 23, 2020
@bodhinandach bodhinandach reopened this Dec 24, 2020
@stale stale bot removed the wontfix label Dec 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment