# 29-04-22 Tudat Developer Meeting

## Agenda
- NA + PO recap and lessons learned ([@Dominic Dirkx](https://tudat.slack.com/team/UU5T8GRU2))
- Integrators refactoring update ([@Jérémie Gaffarel](https://tudat.slack.com/team/U02EFR3H524))
- Standardization of formatting via .clang-format ([@Geoffrey](https://tudat.slack.com/team/U012SQEFWSZ))
- IAC paper tasks + responsabilities
- How to deal with depreciation (discussion)
- Development priorities (discussion)
- Exception/Error handling & conversion ([@Geoffrey](https://tudat.slack.com/team/U012SQEFWSZ))
- Further developing tudat CLI/GUI or not ([@Geoffrey](https://tudat.slack.com/team/U012SQEFWSZ) / [@Jérémie Gaffarel](https://tudat.slack.com/team/U02EFR3H524))

## Minutes

### Legend where ambiguous
**JG**: @Jérémie Gaffarel
**J**: @Joao Encarnacao
**DD**: ...

### NA + PO recap and lessons learned ([@Dominic Dirkx](https://tudat.slack.com/team/UU5T8GRU2))
- **DD**
- PO finished 2 weeks ago.
- This year was the first time in person with Python, DD was very happy compared to last years with P&O. Students and educators were able to focus on the content and not the code.
- Some complaints and compliments about the API documentated, but overall better than last years.
- One thing that will need some work:
- Students spend a lot of time on the post processing.
- Plots, automated plots: *how much do we want to provide to them*?
- If we have 100 sets of data: *how do we visulize it in a fixed way?*
- We might need to make it part of the course (NA/PO?)
- DD will send a brightspace page to call for useful snippets of code to use for plotting.

- **J**: Has a plotting utility (missed the details?) which contains a bash script + python version. It could be more complicated than doing it in Python if you already know what you're doing. Users can even give a script with columns (?) and plots will be generated themselves.

- **Marie**: Students should really be faced with a course which teaches them how to plot for themseves.
- **J**: Joao has the scripts available as a docker image available on GitHub.
- **K**: Crucial basic skill for the work we do, wherever it happens, i.e. which course, we should coordinate it. Because it's so fundamental, being able to use (i.e. matplotlib), we shouldn't mandate a preference, but rather teach through generalized examples in the true raw nature of (i.e. matplotlib)'s API.
- **J**: Can provide the wrapper, or for the more savvy, utilize the code examples.
- **DD**: Should convert to a format that matplotlib can understand.
- **J**: Define the format which tudat spits out data. When you want to (print?) something, you need to provide the description, dimension and value. **Define it and stick to it**.
- **DD**: Thank you to everyone that helped get tudat to where it is now.

### Integrators refactoring update ([@Jérémie Gaffarel](https://tudat.slack.com/team/U02EFR3H524))

- **JG**: Added a general fixed step integration method.
- Can use this method for i.e. RK, Euler.
- Replaced RK, Euler with this general one.
- Expanded the possible integration schemes with additiona butcher tables.
- This method can be also be used with coefficients sets with embedded methods, by specifying wether the higher or lower order should be used (previously, variable step integration had to be used with an inifinite tolerance and min dt = init dt = max dt).
- Butcher table can be printed.
- (For later one, DD mentions we should allow students to provide their own butcher table as a matrix).
- Changes to the API done. Changes to guide, and additional testing to be done (however some challenges for the latest).
- - **Conclusion**: First iteration is done, next step is for time step control.
- Variable step class wil l be refactored
- All the input parameters of variable stpe integrator (for timestep control) will be moved to separate class. Output would be optimal step size. Responsibility is delegated to a lower level for time step control.
- Same kind of class can be user-specified to allow for custom time step control (as a function of time and/or error estimate).
- **DD**:
- Timestep for multistep was wonky, after going through a **very old** paper, some modifications were made, and it seems to be behaving better.
- Additional changes are being made t
- *(...) missed some details here*
- After changes are made, DD wants example applications to demonstrate how error changes as a function of the integrator, step size, tolerance etc...
- **JG**:
- We went from 8 integrators to about 20, so we should motivate and explain which integrators are best for which cases.
- **DD**:
- Present cases which students can discuss and investigate the stability of different integrators.

### Standardization of formatting via .clang-format ([@Geoffrey](https://tudat.slack.com/team/U012SQEFWSZ))
- **G**: Described briefly on clang-format, that the team should come to some agreement on a simple clang format file that can be used it automated formatting.

### IAC paper tasks + responsibilities
- **K**: Is doing the overseeing of the writing of the paper.
- **Miguel**: Strongly suggests everyone to go to Italy.
- **G**: Idea was an incremental case study on the asteroid mission.
- Analytical, propagation, estimation and optimization.
- **Marie**: Concerning their thesis, Gallilean moons, wants to develop functionality/examples for this case study for a 5 minute presentation preparation.
- Dominic D.,
- Geoffrey G.,
- Mattia T.
- **DD**: Deadline?
- **K**:
- 1 sep - presentation deadline
- 2 sep - paper deadline

### How to deal with depreciation (discussion)
- **DD**: We are soon deprecating interfaces relating to the integrator.
- We need a consistent way of dealing with this deprecation.
- **G**: There are three deprecation mechanics:
- C++ deprecation: `[[deprecated]]` above `fn` or `cls`
- Python deprecation: Decorators
- Sphinx API deprecation
- **DD**: C++ deprecation is not required. Python warnings could be annoying.
- **G**: Warning can be suppressed with an import of `warnings` and a short one line piece of code.

*A quick google reveals:

import warnings
warnings.filterwarnings("ignore", category=DeprecationWarning) 

**Dominic: General important note**
> Deprecation warning should include which version deprecation **will** occur or **has (?)** occured in, so that users may refer to the relevant version of the documentation.

- **J**: We should enforce a policy that inforces:
1. Something gets deprecated,
2. That deprecation gets removed.
- **G**: Convention is 1-2 deprecations for an increment of a minor version.
- **DD**: Every now and then, someone should in a cleaning

### Development priorities (discussion)
- **DD**: Will be concerned mostly with the estimation code going forward, in conjunction with his research.
- **Marie**: Working on multi-body, multi-observation estimation work.
- **Miguel**: Working on the framework for mtuli-gravity assists and deep space maneuvres. The idea would be tointegrate the low thrust legs into this framework. Finishing off some obstacles, and then will be focusing on changing the API accordinging and finishing off in 2-3 weeks.
- **DD**: This will finish off the weakest link of tudat, the link between analytical and numerical.
- **DD**: Suggestions for features that users would want implemented in tudat:
- **G**: **\[Feature 1\]** Exposure of event loop of the simulator.
- **K**: **\[Feature 2\]** Tudat learn module. A separate tudat module that will provide interfaces to machine learning frameworks. Mattia will be working on a surrogate model which learn throughout the process of the simulator.
- **K**: Focus should be on a framework for machine learning for the broader community. Requirements should be determined.
- **DD**: This should be oriented around the interfaces that would be best to have for *tudat*.
- **JG**: **\[Feature 3\]** Propagating energy model for your power subsystem.
- **DD**: This would be defining system models.
- Pointable solar panels, body-fixed or otherwise.
- **K**: Instrumentation in general is lacking, which plays a part in this idea.
- **G**: Perhaps a distinct spacecraft object for spacecraft subsystem interfaces should be considered.
- **DD**: Is sad to admit it, but it might be the best option. This will tie in closely with the refactoring that has been going on concerning the orientation, which concerns state information about the spacecraft.
- *General disucssion on multi-threading.*
- *GPU computing would be amazing, but it's a huge undertaking.*

## Action
- **All**: Standardize output format of results, and stick to it. What framework? Candidate: pandas.
- **GG**: is there an issue open for clang-format, if not create it, and discussion will occur there.
- **G**: Open GitHub repository for IAC paper.
- **G**: Open issue on deprecations, and add links.
- **DD**: Separate meeting and discussion on spacecraft subsystems design etc.
- **JG**: Open an issue on the timeout of the API documentation.