ENH: Simple Initial Solution
Pull request type
Please check the type of change your PR introduces:
- [x] Code base additions (bugfix, features)
- [ ] Code maintenance (refactoring, formatting, renaming, tests)
- [ ] ReadMe, Docs and GitHub maintenance
- [ ] Other (please describe):
Pull request checklist
Please check if your PR fulfills the following requirements, depending on the type of PR:
-
Code base additions (for bug fixes / features):
- [ ] Tests for the changes have been added
- [x] Docs have been reviewed and added / updated if needed
- [x] Lint (
black rocketpy) has passed locally and any fixes were made - [x] All tests (
pytest --runslow) have passed locally
What is the current behavior?
Using the initialSolution argument of the Flight class is quite inconvenient, specially when you retrieve from a previous Flight instance. The argument only supports an array as input.
What is the new behavior?
Flight instances can now be used as input to the initialSolution argument of the Flight class.
Does this introduce a breaking change?
- [ ] Yes
- [x] No
Other information
One option that we have is: should we initialize the solution monitors by copying the data from the Flight instance submited in the initialSolution argument? If we do this, the resulting Flight will have trajectory data from both Flights. Is this a convinience or an inconvience?
One option that we have is: should we initialize the solution monitors by copying the data from the Flight instance submited in the initialSolution argument? If we do this, the resulting Flight will have trajectory data from both Flights. Is this a convinience or an inconvience?
Both options of anwser can be right. I mean, there will be moments where the user wants to copy data from previous flight, but also there will be moments qhere you want to start a totally new flight. Should we be flexible? that old mergeFlights idea doesn't sound weird here.
Another question: Would be good idea allowing the user to set the time where to get the initial solution state? I mean, is that for sure that the last state vector is always the best vector to be used in the initialization of a second flight?
All in all, just have to say thank you for this PR, @giovaniceotto , this will definitely improve our development!
I like what @Gui-FernandesBR said! I also think having at least one test would be really important for this one since some changes in flight could make for some extreme initial conditions act weirdly. For now though seems to be a really good implementation
Thanks for the reviews. I will make some quick updats to the implementation considering the feedback.
I agree that tests are needed. I will add a couple of them.
Thanks for the reviews. I will make some quick updats to the implementation considering the feedback.
I agree that tests are needed. I will add a couple of them.
@giovaniceotto please just write down what tasks you have in mind and we can separate ourselves to tackle everything together if this is faster
Thanks for the reviews. I will make some quick updats to the implementation considering the feedback.
I agree that tests are needed. I will add a couple of them.
Hey @giovaniceotto really sorry for that, but I need to move forward today with the "complex simulations" development. We might be using the codes from this PR with current state. You can add your ideas as TODOs and this is going to be already good, better than coding.