Feature/proximal parallel

[Jax922]

Three parallel proximal scheme solvers for soft-body are supported:

• Parallel Jacobi
• Parallel Hybrid Jacobi
• Parallel Gauss-Seidel

[Jax922]

Hi Kenny，

Regarding the code redundancy, my idea is to create a new folder named "proximal" in the "rainbow." The visualization of the folder is shown as follows:

• rainbow
  • math
  • geometry
  • proximal
    • prox.py
    • base_proximal_solver.py
    • gauss_seidel_solver.py
    • jacobi_solver.py
  • simulators
    • ...

1. prox.py is the same as now, and supports some proximal friction models.
2. base_proximal_solver.py is a base class of the proximal solver. Some pseudo-code like :

class BaseSolver:
          def __init__(self, J, WJT, b, mu, friction_solver, engine):
                ...
          def check_convergence(self):
                ...
          def sweep(self):
                # Subclasses implement specific calculation logic
                pass
          def solver(self):
                 ...
                 for iteration in range(self.engine.params.max_iterations):
                       x = self.sweep(x) 
                       self.check_convergence(x, sol, iteration)
                       ...
                 return x, self.stats

3. gauss_seidel_solver.py and jacobi_solver.py are the subclasses.

class ParallelJacobiSolver(BaseSolver):
          def sweep(self, x):
                pass

class ParallelHybridSolver(BaseSolver):
          def sweep(self, x):
                pass

class ParallelGaussSeidelSolver(BaseSolver):
          def sweep(self, x):
                pass

class SerialGaussSeidelSolver(BaseSolver):
          def sweep(self, x):
                pass

...

But I am not sure if this idea is ok or not. Could you give some comments on it ?

[erleben]

Hi Dong,

I agree that separating out the common functionality in an independent module/sub-package makes sense. I agree that inheritance appears to be a good design strategy to make sure all the different kinds of solvers comply with the expected interface.

I perhaps feel that the new module should be placed in

rainbow/simulators/proximal_contact/

Because it is "simulation solver" code and as such should be inside the simulator module.

I would suggest the following renaming as well

prox.py -> proximal_opertors.py
base_solver.py -> solver_interface.py
gauss_seidel_solver.py -> no change
jacobi_solver.py -> no change
... add as many solvers as possible...

I would further suggest that the building of the contact graph and the coloring of the graph be given its own module. Perhaps,

blocking.py

This way it will be easier to add documentation and units to keep things more isolated. It helps to isolate these details of the code as well (improved information hiding)

Lastly, I would suggest making one convenience module for importing all solvers into a simulator. Like

prox_solvers.py

This is just so one can have a single import statement in any given simulator.

import rainbow.simulators.proximal_contact.prox_solvers as CONTACT_SOLVERS

I am fine with different wording as long as the meaning of the content is clear:-)

[Jax922]

Thanks for the feedback! I like your ideas, especially about renaming the files for clarity. I will go ahead with these changes.

[Jax922]

Hi Kenny,

The latest update to the code has been committed, and changelogs are as follows:

• Add the proximal_contact module, which is located in the simulators folder and contains prox_solver.py, blocking.py, solver_interface.py, gauss_seidel_solver.py, and jacobi_solver.py. The proximal solver supports 4 schemes: "gauss_seidel", "parallel_gauss_seidel", "parallel_jacobi", and "parallel_jacboi_hybrid".

  • The prox_solver.py file is the APIs of the proximal_contact module.
  • The blocking.py file supports building color groups from contact Jacobi matrix J.
  • The solver_interface.py file defines a base solver class that serves as a template for various iterative schemes(Gauss-Seidel, Jacobi, ...).
  • The gauss_seidel_solver.py file has two schemes: serial Gauss-Seidel scheme and parallel Gauss-Seidel scheme.
  • The jacobi_solver.py file has two schemes: parallel Jacobi and parallel Jacobi Hybrid.

• Save the gauss_seidel.py file in the prox_rigid_bodies folder, but the contact solver of the rigid body had changed to the proximal_contact module.

• More detailed docstring and comments for parallel Gauss-Seidel and Jacobi schemes.

• Using Conda to install the networkx package.

[Jax922]

Hi Kenny,

I pushed the new code to this branch based on our last discussion.

• To build the contact graph by using the contact_points array.
• Update the entire docstring to standard style.

[erleben]

Nice job, I have a minor naming issue on "body_type" which I do not thing is 100% clear enough.

[Jax922]

Hi Kenny,

I used the simulator_type instead of the previous name now, and using a body_type in an Engine class is unsuitable.
And I push the new code into this branch.