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?

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

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.

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.

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.

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.

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

@kks32 Is that the scheme what you mean?

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?

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?

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.

@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?

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.

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?

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

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

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

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.

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

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.

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

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.

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.