Architecture

[Mat-Pelle]

Thinking about how we could take the next step and have the simulation run based onfunctions the following question arose: What functions will we use? By this I mean the following: We could only use a function to simulate flight under propulsion and one simulation to do the same once the engine is off. But at the same time For what I understand, this issue is the arcitecture of the simulation.

My idea:

• An initializing function that defines key flight variables/measurements

• Have an overall function that is in charge of taking each time step and recognizes the different stages of the simulation (launch wile still in contact with launchpad rails, propelled flight, unpropelled flight/coasting, staging, free descent/ descent under parachutes, etc)

• Specific functions for each flight stage

• Have a function that registers all variables/measurements throughout the flight

• A function that, when called, provides all grapihcs and tables needed for evaluation

I am aware that many of this points you have already suggested (such as the graphics function), I just wanted to leave this issue registered here. As always, i would lie to hear your thoughts, ideas and suggestions.

[Mat-Pelle]

Continuation

Adding new thoughts as I keep thinking about the problem.

• We know that the 6DoF simulation basically models all that happens to the vehicle as a matrix of forces and moments applied to to it and how the vehicle reacts to them according to its aerodynamic/mass properties. As such, an argument could be made that we don't need to separate the different stages of flight, but instead the conditions that apply to them.

• At the same time, an argument could be made that in certain situations the simplification of the model from 6DoF would reduce the processing needs and simulation times.

[lobopablo]

Great analysis. I'll answer to the different points that you've brought up separetely.

• An initializing function that defines key flight variables/measurements.

I think this is (somewhat) similar to the already existing c.py file. I think it is better thought of as a module that is called (instead of a function) in order to receive all the required constants and values that will be used by the main simulation.

• Have an overall function that is in charge of taking each time step and recognizes the different stages of the simulation.

I believe this should be the body of the simulation.py file itself. Considering our simulation will be theoretical and act based on the "orders" or commands we input, we will be the ones "controlling" what happens when (when main engines are turned on, when MECO happens, when second stage engines are turned on, etc.). Therefore, the simulation file will consist in a while (or for) loop that defines which set of physical functions apply to each stage of the flight.

• Specific functions for each flight stage

I think each flight stage will indeed follow a different group of physical equations and functions. I'm not 100% sure whether it'd be convenient having this in different files or include them all as a part of the while/for loop previously mentioned. Initially this would sound like a huge amount of code to have together, but I don't think it should be. This is because most of the work is done by the small functions that calculate each of the required parameters (pressure, thrust, drag coefficient, etc.) to perform the actual calculation of the outputs (x, v, a, mainly).

• Have a function that registers all variables/measurements throughout the flight

Following the structure I've been mentioning, this would happen within simulation.py (similar to what is already being done by it).

• A function that, when called, provides all grapihcs and tables needed for evaluation

Surely can be done separately. Once we have the analytical outputs of the simulation, we can create different functions that create different sets of plots and tables according to the interest of each team (for example).

• We know that the 6DoF simulation basically models all that happens to the vehicle as [...]. As such, an argument could be made that we don't need to separate the different stages of flight, but instead the conditions that apply to them.

This is what I was trying to get to in the second comment mentioned previously. The flight (i think) is to be thought of as one thing, the conditions (and probably the equations that apply) are the ones that change.

• At the same time, an argument could be made that in certain situations the simplification of the model from 6DoF would reduce the processing needs and simulation times.

Hadn't thought of it before. This is another reason to work towards a as-modular-as-we-can simulation, that can be simplified for quicker (although less precise) result-gathering.

[Mat-Pelle]

There is something else we must take into account and just remembered: Classes

They would be the flight variables that change troughout the sim as they are processed by the functions, and for each specific case will become an object (the results of each sim)

Classes can also be made for each configuration of the rocket we want, where we define its aerodynamic and mass properties.

This is just a very early analysis, that requires more work and thought.

[lobopablo]

From what I understand and have read until now, classes definitely should play a role. I can't add too much about the topic yet since I haven't read and understood them well enough.