Let Flight.initialSolution start at the rail about rocketpy

[giovaniceotto]

Alright, I assigned this issue to myself. @Gui-FernandesBR, can you give me more context about this issue? An example of how and why this would can help me a lot.

The main problem I currently face is guaranteeing consistency. When the user enters an initialSolution, currently she/he must specify the valeu of the entire state vector: x, y, z, vx, vy, vz, e0, e1, e2, e3, w1, w2, w3.

To check if the rocket is still on the rail, whose start point is currently set by default to (0, 0, 0), we use the Pythagorean thereom and check if x**2 + y**2 + z**2 <= self.env.rL, where self.env.rL is the rail length.

That being said, if the user specifies a value of x or y different from 0, the value of z must be so that it is consistent with the rail inclination and heading. Otherwise, values for x, y and z can be consistent the the check mentioned above but inconsistent with the rail inclination and heading. The same goes for velocity, attitude and angular velocity. If they are not consistent with the rail, we can get result which do not respect reality.

I currently do not see an example for when this feature could be useful, so I would recommend we make it clear in the documentation that when the initialSolution argument is used, the rail phase is skipped.

[giovaniceotto]

Regarding initial launch position, this is not defined in the flight class, but rather in the Environment class, by setting latitude, longitude and elevation.

[giovaniceotto]

I believe comments from @Projeto-Jupiter/back-end regarding this issue can be specially important!

[Gui-FernandesBR]

Ok now I understand what happened here, in the end we don't need to modify initialSolution argument.

In the future we will be able to modify lat/lon coordinates of the launch pad so this problem will be solved.
See #163 to more information