system: "Epic" for tracking "mutation requests" related to Systems and its derivatives

[EricCousineau-TRI]

I'm having trouble keeping the different requests for mutation straight in my head. I just want this to serve as a means to view them together in one place. Because MBP+SG is so tightly with the Systems framework, I believe both topics should be tracked here.

Related:

• [ ] #12703 Modify MBP and SG (is this just param stuff, or also topology change?)
  • [ ] #13074 MBP Composition
  • [ ] #13177 MBP Decomposition
• [x] ~#9666 MBP + SG Modified after Clone~ Effectively duplicate of #12703?
• Issue for mutation of systems diagrams?
• Issue for tracking hierarchy in MBP itself?
• [ ] #12575 Unfix port?
• [ ] #12203 MBP and Making Controllers

Marginally related (e.g. via composition):

• [ ] #6927 ~MBP~ Systems Model Hierarchies ??? (edit: I dunno TBH)
  • [ ] #12980 MBP Compute with subset
• [ ] #12270 MBP Model Instance info
• [ ] #12980 Calculations on subsets of MBP model

Feel free to edit this and add / remove issues. And to clarify, I don't intend to be the owner of completing these sub-issues ;) FYI @sherm1 @amcastro-tri @edrumwri

[amcastro-tri]

I'll transcribe here some of the notes I took during the Drake Developer's meeting on Monday 04/13/2020.

The "mutation" can be split on levels of difficulty, starting with parameter changes (leaving the internal topology unchanged), followed by simpler topology changes caused the common case of adding/removing 6dof free bodies, welding and/or freezing joints, all the way to general model changes allowing general addition/removal of any kind of multibody element.

• Parameters (no topology changes):
  • Rework systems:: parameters API as needed.
  • Bodies: mass, inertias.
  • Joints: damping, pose.
  • Proper cache invalidation.
• Adding/Removing frees bodies (partial topology change):
  • Ability to add/remove 6dofs without changing the topology of previously added models in the world.
  • Ability to re-declare state at the systems:: level.
• Weld objects (usually manipuland to gripper, for planning)
  • Tree topology changes. Graph topology partially changes.
  • State changes.
• Ability to "freeze" a joint/replace by a weld joint. Related to "weld objects" item above.
• Final goal, automatic "Finalize()" whenever a new context is created.
  • All state dependent queries throw when topology changes are detected (cache topology?)

[jwnimmer-tri]

FWIW For my part, I don't see MBP mutation (bodies, masses, links, etc.) vs framework mutations (diagram wiring, port fixing) as coupled in any real way, and no reason to lump them into the same Epic.

[sherm1]

Changing anything in MBP that alters its use of state variables does imply some ability at the System level to deal with post-creation changes in the Context dimensions. But I agree that changes to Diagrams and ports are completely disjoint from MBP changes and don't belong in the same issue.

[EricCousineau-TRI]

If an MBP were changed such that a new model instance were added (which seems reasonable, if you're adding other stuff?), then wouldn't that possibly change the number of ports?

[sherm1]

Good point. You would definitely get more MBP input and output ports. They wouldn't be connected to anything though. If they need to be connected in order for the modified MBP to function, that's a Diagram-building task that would be beyond what could be expected from model editing. (That is, a user would have to build a new diagram themselves.)

To allow such modifications without user intervention, a Diagram would need to be built using only MBP's per-body and aggregate ports but not the instance-specific ones. Aggregate ports could conceivably be allowed to change size.