TireState

[OpenTireMaster]

Currently the TireState object is used to pass information through the interface. This benefit of such an object is that it can be re-used easily between different types of tire models. The downside is that it may not be flexible enough for different objects, for example a thermal tire model may need additional information.

One option would be to have the TireState be of a dictionary/key:pair type object so the content would vary between different models. Another option would be to define a few different type of TireState objects, one for steady-state, one for transient and one for thermal for example?

Any thoughts on this?

[kktse]

The current implementation of the TireState object is confusing to use because it updates the state and returns the state. This is frustrating because it means the responsibility of making a copy of the TireState is on the user.

The use case is when you want to save all tire states by appending the state into a list. The key values can be extracted with a list comprehension. The list will contain the same value since it will add the same TireState instance multiple times. It would be nice if the inputs/outputs were decoupled for ease of use.

Otherwise if this is the desired behaviour, it might be more clear to make the state internal to the tire model, or to have no return type for solve() to make the intent clear that it will modify the argument variable.