Consider making Solvers into Components

[aymanhab]

Original discussion started along PR #2733 Copied here for future reference by @aseth1

The Component abstraction is not only for ModelComponents but for Solvers and Operators and other calculators that use System resources. It would be straightforward to make Solver derive from Component. InverseKinematicsSolver would have ListOutput with a Channel for every error. These would include Coordrinate, Marker (distance) and Orientation (angle) errors. Then, we would not be restricted to accessing errors in files only, but using Solvers in the context of broader pipeline. That was always the intent.
I mean actual reporting of Marker errors as quantities, not just the text of the worst marker in the Messages window (current behavior). Many users (including myself) have scripts that diff the marker data in a trc file against marker locations reported by IK in .sto so they can compute distances and use them to refine scaling and IK. With Outputs, it would be easier for users could to select just the Markers/Sensors/Coordinates they care about.

[aymanhab]

I sure like the idea of using outputs in Solvers as you clearly laid out, however I don't think deriving from Component as it stands now is the best way to go about it, just read the comments at the top of Component.h, look at the list of methods and you'll undoubtedly see that it's not a great fit even though that was the original intention. I can go into specifics but if we agree on the need to use Outputs with Solvers (as the one and only requirement) we can find solutions without placing Solvers in a place where they don't belong in class hierarchy. Changing inheritance in code is trivial the downstream effects are massive IMHO.

[aseth1]

@aymanhab Component was originally written with this purpose in mind.

just read the comments at the top of Component.h, look at the list of methods and you'll undoubtedly see that it's not a great fit even though that was the original intention

https://github.com/opensim-org/opensim-core/blob/master/OpenSim/Common/Component.h#L26-L42

Please let me know which statement you believe contradicts this intent for Component. Solvers and other computation components often need direct access to and modify the underlying MultibodySystem including additional System resources. For example, the InducedAccelerationSolver adds contact constraints for the purpose of solving and they aren't part of the conceptual Model.

It is possible that Component has become too specialized, but I don't believe that is the case and that certainly was not the intent. Many of the Solvers would benefit and it would enable us to link Solvers together via Inputs and Outputs which would bring us closer to the realization of users putting together Custom Studies without having to write code.

Please consider it especially as we are thinking about how to reunify the InverseKinematicsTool/Study.

[aymanhab]

Thanks @aseth1

Here are the comment at the top of Component.h
"

• The abstract Component class defines the interface used to add computational
• elements to the underlying SimTK::System (MultibodySystem). It specifies
• the interface that components must satisfy in order to be part of the system"

Obviously Solvers in general are not a part of the SimTK:System, though they interact with it.

The high level issue is that the Component class implements multiple interfaces, the dominant one
judging by the number and names of methods is the "Composite design pattern" which is to represent hierarchical structures: https://en.wikipedia.org/wiki/Composite_pattern. Component as it is, implements other interfaces as well that we found useful: Serialization/Properties (by inheritance from Object) Connectivity (Using inputs/outputs/sockets) and Visualization among others.
While some existing components may not be exactly exchangeable, exchanging a muscle with a solver would be a significant stretch.

Traditionally we discussed solvers being computations, as such they are not fundamentally hierarchical. You'll see this fit issue standing out when methods that are hierarchy-related, system-related or serialization/properties-related end up being empty or unused, or we need to stretch the meaning to do something with them most of the time for Solvers.

I totally agree that providing Solvers with inputs/outputs to connect "blocks" together and create workflows without programming is a great goal and that will be extremely useful, and we should explore mechanisms to facilitate this reuse without adding all the luggage of Component to Solvers IMHO.