This issue is low-priority. It is more important to come up with new examples (see #3) and make the existing ones more on point. In addition, the .py file is preferred for example code.

However, Jupyter notebooks are more practical to describe examples. Using mybinder.org is a possibility.

EDIT: the new strategy is to convert .py scripts to Jupyter notebooks and have notebooks as main scripts. .py will still be provided for users by converting Jupyter notebooks with pandoc.org.

Tasks

• Set up repo on mybinder (can be accessed here)

Notebook conversion

• Basic orbit estimation (a0cbeca)
• Keplerian satellite orbit (8868847)
• Linear sensitivity analysis (1f454f4)
• Perturbed satellite orbit (98aed13)
• Two satellites phasing (c1d5430)
• Reentry trajectory (0356de4)
• Thrust between Earth and Moon (5b4c206)
• Solar system propagation (941d2d4)
• Asteroid orbit optimisation (831c24d)
• Himmelblau minimisation (f1b1370)

While there are ways to convert the .ipynb to .py and vice versa, both directions bring certain unwanted issues that should be addressed.

From .ipynb to .py
The go-to way is to use jupyter nbconvert --to script 'example.ipynb'. This results in a working example. This can be followed up with using the clean_py_notebooks.py to make them more usable, however there are still empty quotes left over. Furthermore, it converts all the files in hard coded directories.

Solution:

1. Improve clean_py_notebook.py to get rid of empty """ strings.
2. Create a script that combines the command above with the clean_py_notebooks.py file so that the conversion from .ipynb to .py is seamless. The script should allow you to both choose specific files to be converted, and in addition also convert whole example libraries.

From .py to .ipynb
This direction is of lesser importance because the .ipynb will remain the actively developed examples. There are two options:

• The convert_py_to_ipynb.py file just creates one big code cell in a .ipynb file.
• The p2j (installed with pip) package does allocate code and markdown cells properly, but introduces countless <br> instances and does not allocate headers in markdown cells consistently.

The two options are both sub-optimal, which could use more work in the future also by means of a script.

An example should be added that demonstrated how to propagate rotational dynamics. Ideally, the followings should be included:

• Torque from the environment (Spherical Harmonics for instance).
• Torque from some kind of RCS thruster/momentum wheel (from the vehicle itself).
• Rotation from aerodynamics moment coefficient.
• Initial angular velocity.
• Incorporate thrust (and even TVC?) based on the vehicle orientation.

Steps needed

1. Move example applications from here to this repository;
2. Rename examples with more descriptive names;
3. Update examples with new tudatpy module names/structure;
4. Go through examples, add a better initial description and improve inline comments.
5. Add this repository as a git submodule of tudatpy repo.

Note
@DominicDirkx has already updated examples 1, 2 and 10 (.py files) in tudatpy to the new setup, where examples 2 and 10 correspond to the two example applications on the website. Example 2 was renamed to "perturbed_satellite_orbit" (here on the website), example 10 was renamed to "linear_sensitivity_analysis" (here on the website).

Hi at all,

I just wanted to suggest if the galileo constellation simulator could be converted as well, as it is a brilliant example to make pupils curious about the STEAM field. Thank you.

Best,
Stephan

The example applications "Keplerian satellite orbit" and "Solar System Propagation" (and possibly more) return errors.

The errors I met in the "Keplerian satellite orbit" are the following:

• In the script block [8] of the .ipynb file (or line 174 of the .py file):
  

I bypassed this by modifying the input of the runge_kutta_4 function as follows:
integrator_settings = propagation_setup.integrator.runge_kutta_4(fixed_step_size, fixed_step_size)

• In the script block [8] of the .ipynb file (or lines 177-185 of the .py file):
  

I bypassed this by modifying the input of the translational function by omitting the simulation_start_epoch and integrator_settings input as follows:
propagator_settings = propagation_setup.propagator.translational(
central_bodies,
acceleration_models,
bodies_to_propagate,
initial_state,
termination_settings
)

• In the script block [9] of the .ipynb file (or line 205 of the .py file):
  

At this point I attempted to run the "Solar System Propagation" example application but it returned similar errors.

The "Keplerian satellite orbit" example application seems to work fine before the last commit (The commit with SHA fff7b20 is functional).

The common introductory paragraph needs some beauty treatment. In particular the current year should be updated from 2022 to 2023, this sentence "This file is part of the Tudat." grammatically seems to be the reminiscent of two (?) once combined sentences, and the clickable link at the end does not work...

This issue tracks tudat-team/tudat-space#87. The issue relates to importing jupyter notebooks to reduce the overall size of certain examples. This is currently necessary for the asteroid orbit optimization example only. Both the .py and .ipynb files now import the necessary functions from the ipynb notebook.

It is not really clear from the current PyGMO examples when an aerodynamic coefficient interface or a thrust interface is set if it is included in the fitness function or in the general propagation file or in both. It gets a bit complicated to identify this from the current examples. Perhaps, it could be nice to provide few additions to current examples that shows where these attributes of the vehicle is included.

As a follow-up task from the developer meeting, @gaffarelj, could you please take care of the following tasks?

• delete the old .py examples
• provide new .py examples created via automatic conversion of Jupyter notebooks
• add this information (i.e., .py examples are provided, but they are converted automatically, so we don't maintain them / assure that everything is fine) to the README

When i run coupled_translational_rotational_dynamics.ipynb in JupyterLab, everything works fine until Cell In[5]:

---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
Cell In[11], line 12
     10 body_settings.get('Phobos').rotation_model_settings = environment_setup.rotation_model.synchronous('Mars', 'J2000', 'Phobos_body_fixed')
     11 body_settings.get('Phobos').gravity_field_settings = get_gravitational_field('Phobos_body_fixed')
---> 12 body_settings.get('Phobos').gravity_field_settings.scaled_mean_moment_of_inertia = 0.43
     14 # AND NOW WE CREATE THE BODIES OBJECT
     15 bodies = environment_setup.create_system_of_bodies(body_settings)

AttributeError: 'tudatpy.kernel.numerical_simulation.environment_setup.gravity_field.SphericalHarmonicsGravityFieldSe' object has no attribute 'scaled_mean_moment_of_inertia'

When I commented out the code that reported the error, Cell In[10] reported another error:

---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
Cell In[10], line 2
      1 # DYNAMICS SIMULATION
----> 2 simulator = numerical_simulation.create_dynamics_simulator(bodies, combined_propagator_settings)
      3 state_history = simulator.state_history
      4 dependent_variable_history = simulator.dependent_variable_history

RuntimeError: Error when creating rotational state derivative model, inverse inertia tensor of body Phoboscontains NaN. 

Why tudatpy.kernel.numerical_simulation.environment_setup.gravity_field.SphericalHarmonicsGravityFieldSe object has no attribute scaled_mean_moment_of_inertia here? Please help!

>>> dir(body_settings.get('Phobos').gravity_field_settings)

['__class__',
 '__delattr__',
 '__dir__',
 '__doc__',
 '__eq__',
 '__format__',
 '__ge__',
 '__getattribute__',
 '__gt__',
 '__hash__',
 '__init__',
 '__init_subclass__',
 '__le__',
 '__lt__',
 '__module__',
 '__ne__',
 '__new__',
 '__reduce__',
 '__reduce_ex__',
 '__repr__',
 '__setattr__',
 '__sizeof__',
 '__str__',
 '__subclasshook__',
 'associated_reference_frame',
 'create_time_dependent_field',
 'gravitational_parameter',
 'gravity_field_type',
 'normalized_cosine_coefficients',
 'normalized_sine_coefficients',
 'reference_radius']

We can use this thread to come up with ideas.

From my side: e.g., simulation of two objects in LEO with high collision risks (conjunction messages). We can reproduce situations that actually happened (real collisions or avoided ones).

A new example should be added that shows a plot of the error in position vs the number of function evaluations for different integrators, for a pure Keplerian orbit (perturbed orbit could be added later).

The error in position from the different integrators can be computed by taking the difference w.r.t. the analytical solution of a Kepler orbit.

This example would then showcase all the different integrators available.

With the number of mission design examples growing, the existing example should be moved to the new directory

In general, the PyGMO examples are very well detailed especially the asteroid orbit optimization. However, the examples lacks the information that provides why the input arguments of the UDP class is defined as a lambda function arguments. Perhaps this is something required for PyGMO to be compatible but it could be nice if it is clarified why this is done and whether or not if it is mandatory, meaning if the code can still work if these attributes are not set as functions but set as variables instead. (I am assuming it won't work).

A new example can be added that:

• propagates multiple satellites (at least 3)
• in an almost not perturbed orbit (only PM gravity or SH up to D/O2)
  • almost circular orbit (e<0.1)
  • almost polar orbit (i~88deg)
• Use one of the latest integrators for maximum positional accuracy (<1 m)

In this example, two of the satellites should be at the same position at the same time (also called collision). This would showcase the accuracy of the integrator. This example can be linked to #9 when discussing accuracy).

The fact that 3 satellites would be propagated could also be used to showcase the dependent variable that saves the body that is the closest to another one (see this issue).

The two-stage rocket ascent example returns an error now.

Problems:

• There is a difference in behaviour between the .py and .ipynb file.
• Compared to before the thrust refactoring, there is now an error for an exceeded minimum step size.

The question of what exactly needs to be shown with this example needs answering. Depending on that answer, the problem with the example is more or less problematic.

The problem occurs since the thrust refactoring in two_stage_rocket_ascent.py of commit 730e6ac.

I tested a few commits:

• With commit 730e6ac (random old commit without thrust refactoring or integrator/propagator refactor), the stage separation occurs after 8.33 minutes with no errors. This is run with tudatpy=0.6.4 and tudat=2.10.6.
• With commit 0ebc2e8 (commit where Miguel merged among others the updated two stage rocket ascent example for the .py file), the stage separation occurs after 7.75 minutes with a propagation error due to the minimum step size being exceeded. This commit has the updated thrust refactor, without the integrator/propagator refactor. This was run with tudatpy=0.7.1 and tudat=2.11.1.
• With commit f8989ee (master), which includes the thrust refactor and the integrator/propagator refactor, the stage separation also occurs after 7.75 minutes with a propagation error due to the minimum step size being exceeded. This is also with tudatpy=0.7.1 and tudat=2.11.1.

This is all for the .py files. The .ipynb files were not updated in sync with these commits. Running the .ipynb file of commit f8989ee that I refactored results in an index error because there are too few time steps to create results (because of the premature termination). Here the stage separation already occurs after 3.91 minutes.

Picking up from #1.

Existing examples to be updated following a more "standard" template:

• keplerian_satellite_orbit.py
• perturbed_satellite_orbit.py
• linear_sensitivity_analysis.py
• solar_system_propagation.py
• satellite_separation_via_differential_drag.py
• an estimation script , which is ready to be formatted in the same style as the example scripts listed above and even incorporated as a guided estimation example on tudat-space
• a thrust (orbit raising) script, which is ready to be formatted in the same style as the example scripts listed above (thrust_between_Earth_Moon.py, previously named earth_moon_transfer.py,)
• reentry_trajectory.py: a reentry script, which has an issue with the guidance scheme and is therefore not ready for publishing (but could still be styled)

Checks required for each example are:

• it should run on the latest tudatpy
• it should have an "intro" ("abstract")
• it should be properly commented and follow PEP 8 (more or less)
• (optional) it should be written in a Jupyter notebook, then turned into a .py script (automatically)

Right now, new examples have to be manually copied from the tudat-space repo to tudatpy-examples (or vice-versa), as well as manually converted from jupyter notebooks to py files (or the other way around).

Ideally, the examples should only be modified as jupyter files in tudat-space and automatically copied as jupyter and py files to tudatpy-examples.

If that automatic workflow is not possible (or at least while it isn't implemented), people working on examples should only modify them in the tudat-space repo. Only afterwards should they be copied to the tudatpy-examples repo. The goal is to have all the more recent versions of the examples in a single repo and in a single file type (to avoid having the two repos with a mix of new and old files), as the likelihood of someone forgetting to copy the examples to the repo they are not using relatively large.

To better make the estimation functionality visible, and identify shortcomings/improvements in the interfaces, additional example applications are to be created. Ideas for example applications will be provided and prioritized in this issue

A new example should be made about the ascent of a solid rocket on Mars.

This can showcase a basic model for thrust (off when no more propellant), of translational + mass propagation, and of the use of selected dependent variables, including a custom one.