[fem] Allow additional quadrature points for external force integration

[xuchen-han]

Closes #21496

---

This change is 

[chen-tianjian]

Reviewable status: 1 unresolved discussion, needs platform reviewer assigned, needs at least two assigned reviewers, commits need curation (https://drake.mit.edu/reviewable.html#curated-commits), missing label for release notes (waiting on @xuchenhan-tri)

---

examples/multibody/deformable/deformable_torus.cc line 212 at r1 (raw file):

  if (use_suction) {
    auto suction_force = std::make_unique<PointSourceForceField>(
        plant, plant.GetBodyByName("cup_body"), Vector3d(0, 0, -0.065), 0.01);

Can we make this falloff_distance even smaller in this example, e.g. 3mm is a realistic value, without changing the mesh resolution?

[chen-tianjian]

Reviewable status: 2 unresolved discussions, needs platform reviewer assigned, needs at least two assigned reviewers, commits need curation (https://drake.mit.edu/reviewable.html#curated-commits), missing label for release notes (waiting on @xuchenhan-tri)

---

examples/multibody/deformable/deformable_torus.cc line 193 at r1 (raw file):

  /* Subdivide the element for suction force integration; otherwise, the mesh is
   too coarse for the support of the suction force field (1cm radius). */
  deformable_config.set_element_subdivision(2);

Can we achieve the same thing by adding more quadrature points, without changing the mesh resolution? Just as a demo to show the capability of the new feature.

[chen-tianjian]

Reviewable status: 1 unresolved discussion, needs platform reviewer assigned, needs at least two assigned reviewers, commits need curation (https://drake.mit.edu/reviewable.html#curated-commits), missing label for release notes (waiting on @xuchenhan-tri)

---

examples/multibody/deformable/deformable_torus.cc line 193 at r1 (raw file):

Previously, chen-tianjian (Tianjian Chen) wrote…

Can we achieve the same thing by adding more quadrature points, without changing the mesh resolution? Just as a demo to show the capability of the new feature.

Sorry maybe I misunderstood. I thought the subdivision is equivalent to having a finer mesh which slows down everything, but that is not true, right?

[xuchen-han]

Reviewable status: 1 unresolved discussion, needs platform reviewer assigned, needs at least two assigned reviewers, commits need curation (https://drake.mit.edu/reviewable.html#curated-commits), missing label for release notes (waiting on @xuchenhan-tri)

---

examples/multibody/deformable/deformable_torus.cc line 193 at r1 (raw file):

Previously, chen-tianjian (Tianjian Chen) wrote…

Sorry maybe I misunderstood. I thought the subdivision is equivalent to having a finer mesh which slows down everything, but that is not true, right?

Yes, we are only sampling more quadrature points to integrate the external forces. It definitely adds computation overhead, but it should slow the sim down nearly as much as actually subdividing the mesh. Perhaps this needs a better name?

---

examples/multibody/deformable/deformable_torus.cc line 212 at r1 (raw file):

Previously, chen-tianjian (Tianjian Chen) wrote…

Can we make this falloff_distance even smaller in this example, e.g. 3mm is a realistic value, without changing the mesh resolution?

You could definitely play with the parameters in this demo. However, keep a few things in mind.

1. The PointSourceForceField is likely not a good model for suction force; it's only a toy model for testing the external force field. In particular, when the manipuland goes "into" the suction cup (due to the suction force and compliant contact), the point source force will push the manipuland out, which is probably not what you want.
2. The external forces are integrate explicitly, as the force field becomes closer to a singularity, it may becomes a source of instability.
3. Keep in mind that we are taking rather large timesteps here. If the gripper moves 10mm in a timestep, would it still make sense to have such a small fall-off distance? I don't know the answer but something worth thinking about.

[kylc]

@xuchenhan-tri and I have identified a few items which are needed to wrap up the development of this PR, which I will be able to tackle:

• Clean up some of the leftover TODOs in the PR, mostly just refactoring out duplicated code
• Internalize or publicly expose the compile-time sample count in the LinearSimplexElement template
• Improve test coverage

It would also be good to hear from @chen-tianjian and @jbinagia that the proposed design meets our needs.

My understanding of the current state of things is:

• We have identified that additional sampling points for the external force integration will improve our simulation accuracy. We want to implement this in such a way that doesn't drag down simulation performance too much.
• The proposed change exposes an API for this, and allows us to specify a subdivision factor up to 4. This only affects external force integration, not other more expensive computations. Presumably this maximum factor is large enough as the sample count grows quickly (n^4) with the subdivision factor.
• To prove this out, the deformable torus example has been updated with a much more concentrated force field which does not behave properly on a coarse mesh, but does work after increasing the external force quadrature point subdivision factor (using the new feature).

We may want to investigate these questions (I'm looking for feedback here):

• How much is the realtime rate impact of applying different subdivision factors in e.g. the deformable torus example. Is it relatively small, as we expect?
• Does the set_element_subdivision method need a better name to emphasize it only affects external force integration? Perhaps set_element_subdivision_for_external_force_integration.

[xuchen-han]

Thanks for the nice summary. In addition to these, the first thing you probably want to do is to rebase this very old PR on master. Some of the files touched have changed significantly since, so expect to spend some time on resolving the conflicts.

[jbinagia]

Reviewable status: 1 unresolved discussion, needs platform reviewer assigned, needs at least two assigned reviewers, commits need curation (https://drake.mit.edu/reviewable.html#curated-commits), missing label for release notes (waiting on @xuchenhan-tri)

---

multibody/fem/deformable_body_config.h line 98 at r1 (raw file):

  }

  /** @pre 0 <= element_subdivision <= 4. */

FWIW I initially thought based on the name that element_subdivision is the factor by which you divide (e.g. a value of 1 means there is no change). I think the documentation below clarifies that it's actually "number of times each element is subdivided" (meaning 0 is no change, rather than 1). But maybe this points to another potential confusion with the name. Perhaps something like set_element_subdivision_count?

[jbinagia]

• How much is the realtime rate impact of applying different subdivision factors in e.g. the deformable torus example. Is it relatively small, as we expect?

Agreed this would be a good experiment to do