Allow flexible dependsOn stage: allow an Output's dependsOn stage be the dependsOn stage of its dependencies

[chrisdembia]

This came up with #398. Right now, an Input's requiredAt and an Output's dependsOn stage are hard-coded into a component. However, some components like Operators are generic and don't know what its requiredAt and dependsOn stages are; they should simply be "inherited" from whatever output's are hooked up to the component. Solutions:

1. a "pass-through" requiredAt/dependsOn stage that says "just use my dependency's dependsOn stage".
2. remove stages from inputs and outputs. Is there something that makes it necessary for inputs and outputs to have associated stages? You'll get an exception either way if the stages don't match up. @aseth1 said that by specifying these stages, the exception occurs earlier (during "construct" time instead of during simulation).
3. @mitkof6 suggested another option: for these generic components, create a property that allows one to specify the stages for a component. This would be easier to do (though we don't currently have support for Stage properties), but would introduce redundant information, and thus another place for user error.

[sherm1]

Right now, an Input's requiredAt and an Output's dependsOn stage are hard-coded into a component.

It makes sense to me for an Input to have a requiredAt stage, since that is an attribute of the Component. An "addition" operator, for example, would set its requiredAt stage to Infinity since it doesn't impose any restriction. But the dependsOn stage in general is an attribute of a Component and its inputs, so shouldn't be available until after the Inputs have been connected, and needs to be a method so it can calculate the stage. Measures have the same issue, and the depends-on stage is a virtual method. Here is the code that returns the depends-on stage for Measure::Plus that adds two input measures.

[mitkof6]

This is a part of a discussion that I had with @chrisdembia. I was thinking of a dependency graph that will resolve the dependency stage dynamically.

The purpose of input/output stage, as I understand it in the current implementation, is to check whether the state is properly realized, which is a desirable thing. On the other hand, the property of the stage is not the input/output responsibility, but depends on the quantity that is to be accessed in the case of the input. For the output the stage may depend on the state or variable that we want to provide as an interface. I believe the stage property should be optional or hidden. This may be ok as it is in the current implementation, but as I mentioned this can cause problems if you plan to extend the notion of the Component in the future.

Imagine that you design a component, let say a dynamic filter. You add the state variables, you construct the input and output infrastructure. Then you decide to connect this component to a coordinate of a joint which is realized on position stage. You go to the filter component and change the stage of the input, output and states, so the component will evaluate after the joint coordinate is realized. Then, sometime later, you decide to use the same filter component on the muscle forces, again you are forced to change the filter’s evaluation stage, because the muscle forces are realized in a later stage (I think velocity, but correct me if I am wrong). Of course you can add the stage as an input to the filter class (as in the Delay implementation), but still it will make things complex in the future, where more complex connections could be presented.

So the root of the problem seems to be the staging. My first though was that the filter’s output should be evaluated if its dependencies are realized, and I thought of a dependency graph, where you can access a component’s output only if only its dependencies are realized. I don’t know how you can implement this in the current framework or if there is a shortcut. My suggestion is that you add an extra stage S which can be a real number minStage <= S <= maxStage, so you can have an arbitrary number of stages in between the preexisting ones. Then you have to extend the notion of connecting so it can construct the dependencies based on the connections. You can have a different kind of a state or a measure that you can assign the realization stage S after the dependency graph is realized (dynamically). Then, during realization of the components, there will be an internal representation, which will point out the correct order of realization.

The node of the dependency graph can denote the realization stage, while the edges will be the dependencies or the physical connections. This graph can be parsed and an arbitrary real number can be assigned to each node. In addition, new nodes can be inserted to ensure proper realization, or of internal loops are presented, you can further partition them as I mentioned in the pdf. The dependency graph can be a separate mechanism, which can ensure proper use, type checking, correct evaluation, identify infinity loops and resolve them. So I find it very useful as a structure.

[sherm1]

This makes sense to me. In fact it is conventional in simulation codes for there to be a sorting phase after the model is built to make sure everything gets computed in the right order. In OpenSIm this would happen in initSystem() when the specified model is used to build a computational System for Simbody. It is already partially happening because Simbody requires the multibody tree (mobilized bodies) to be created prior to, say, putting in a constraint that references one of those bodies or joints. Even with the same stage requirements, an expression composed of operator Components has to be built so that the inner expressions get evaluated before outer expressions that depend on them.