Confusion on GamePhysics's outputs

[samm82]

You mentioned here that "the desired outputs [of GamePhysics] are in your table*, along with a few things that we wouldn't typically care about. The goal of the game physics engine is to find the position (p(t)) and orientation (phi(t)) over time. We are also sometimes interested in the linear velocity and angular velocity. The two delta symbols in your table wouldn't be something that we are typically interested in.

*the table mentioned (built from the currently defined outputs of GamePhysics):

However, GamePhysics currently has no place where these values are explicitly calculated as outputs. The IMs calculate linear and angular acceleration, as well as the time at collision. There are DDs for linear and angular velocity, which could be used as outputs following #3575. The position seems to be implicit in the DD for linear displacement, and likewise for orientation in the DD for angular displacement. There is also a DD for the centre of mass which uses the symbol $\mathbf{p}(t)_\text{CM}$, but this seems to be used to specify that "the motion is translational, so the position, velocity, orientation, and angular acceleration functions are for the centre of mass", although it could also potentially be used to specify the position of a given rigid body.

Is there anything I'm missing in my analysis here? Where do you think we should get the outputs position (p(t)) and orientation (phi(t)) over time from? Do we need to add IMs for them?

[samm82]

Not sure if this issue will morph into an action item, but I wanted to note the following so I didn't forget about them since they are related:

1. There seems to be a mistake in the DDs for linear displacement and linear acceleration from a duplicate addition of a dependence on time (possibly from #3210/#3432):
2. While orientation and angular velocity should be dependent on time (which may end up being part of the investigation of #3608), they don't appear as such unless manually created to be so (other quantities have this issue as well, but I'm focusing on the outputs for now):

[smiths]

@samm82, p(t) comes from IM:transMot. We solve the ODE given in the Equation for position. The position is there because acceleration is defined in terms of position. The equation can be thought of as the second derivative of position with respect to time, instead of acceleration.

This is a theme in our examples with ODEs. The output is shown as acceleration, but the purpose is to solve for position. (The same thing applies for the angular acceleration and the actual orientation (rotation)). Drasil knows more about ODEs than it did in the past, but it still doesn't entirely get them. :smile:

[samm82]

And then I'm guessing that phi(t) comes from alpha(t) by the same token

I'm thinking I'll use the DDs for linear and angular velocity as the only outputs right now, remove the relevant parts from the existing FRs but leave the rest as is, similar to what we did for #3607 - is that a suitable fix for now until Drasil understands ODEs better?

[smiths]

Right phi(t) comes from alpha(t). Yes, what you describe is a suitable fix for right now. It is a step in the right direction for Game Physics.

[balacij]

Is GamePhysics supposed to have any outputs at all? I thought it was meant to be a library of theories, and that the existing FR was automatically formed (and in error).

[samm82]

@balacij Currently none of GamePhysics's requirements are automatically generated. However, I was wondering if it made sense for there to be a program with no outputs, but if it did, that GamePhysics seemed like a good candidate (its requirements all say "determine", not "output"). It being a library tips it a little more towards that direction, at least to me, but I'm also not sure what the usefulness of determining values is if those values aren't outputted so the user can actually use them. 🤔

[smiths]

Good discussion @balacij and @samm82. However, I don't think being a library means that there are no outputs. The library provides services that do calculations and output results. The output may be in memory, not to the screen or to a file, but it is still output. At least in my general view of what output means. The library could also provide services that output values to files, or to the screen. If the word output is too suggestive of a program, not a library, we could say the outputs are the unknowns. We give the library known values so that it can calculate the unknowns. The values of the unknowns still have to be available somehow.

As far as how we treat things in most of Drasil, the distinction between a library and a program isn't too dramatic. Maybe I'm oversimplifying, but I think to make the requirements apply to a library, rather than a program, we could add wording to the SRS like "the library shall provide the following services" and then list the requirements.

[JacquesCarette]

See my recent comments on the multiple meanings of output. We should use a more refine vocabulary as output is too overloaded. Each of the above uses of 'output' is legitimate, but quite different, and should entail being processed differently.

[smiths]

For traceability purposes the comments from @JacquesCarette on outputs can be found here.

[samm82]

Currently, most of the discussion in this issue has been migrated to #3608. The only thing left to do is to make an issue for adding position and orientation to the outputs of this example (along with sources), but this doesn't really make sense until #3259 is completed, so I may wait on creating that issue/closing this one.

[JacquesCarette]

See my recent comments on the multiple meanings of output. We should use a more refine vocabulary as output is too overloaded. Each of the above uses of 'output' is legitimate, but quite different, and should entail being processed differently.