## poliastro

128 Members
General chat about poliastro, a fast, easy to use Python library for interactive Astrodynamics and Orbital Mechanics https://docs.poliastro.space31 Servers

SenderMessageTime
17 Jan 2021
astrojuanlu

FYI: after a lot of iterations, dhruvSondhi put a massive PR to migrate the documentation to reStructuredText to MyST (a Markdown dialect that adds some useful features from reST), you can have a look here https://github.com/poliastro/poliastro/pull/1073

we have a challenge now because apparently one can't have two `.md` processors at the same time (in our case, nbsphinx and myst-parser) but we are working on addressing it.

kudos to dhruvSondhi for the achievements so far and looking forward to seeing this merged ðŸ’ª

12:04:44
18 Jan 2021
eddie-in-orbit joined the room.15:56:52
eddie-in-orbitHi, my name is Eddie and I'm a highschool student from Sweden. I am currently doing a school project which includes poliastro code from the examples "atmospheric drag" and "orbital decay", which are part of the jupyter notebook "Natural and artificial perturbations". I'm relatively new to programming so i bascially just copied those two examples and slightly ajusted the code to work for my project(my project is in short to make a utopian calculation of when LEO can be free from space debris only through atm. drag, if no more debris were created during that time). The way i intended to do this, is by calculating the orbital lifetime of the debris with the longest orbital lifetime. I have a bunch of questions on the code, but I wanted to ask about determening the physical parameters of this longest lifetime-debris. The object would have a drag coefficient of 2.2, beginning altitude of 2000km, and as big of an mass/area ratio as possible. Could you guys help me/give me tips on how to determine the mass and the area of the debris.(I would assume it to have the mass/area of a "satellite" since rockets(upper stages) usually dont get up to 2000 km, i think)15:58:03
xionbox eddie-in-orbit: Excellent project idea! When you say "biggest mass to area ratio possible", I understand that as you want something which has a lot of mass yet a very low (drag) area. This is a good idea to set a theoretical upper limit on the duration of the deorbiting. My hunch is that one possible example of this would be to look at a heavy metal slate whose thickness is a very low (a few centimeters) and whose length is quite long. The thin part would be the "front" of the modeled object and the long plane would be colinear to the velocity vector (in other words, it would be parallel to the ground, so from the ground looking up you would see a big rectangle flying). Then, I would encourage you to find the mass of a typical upper stage, and determine the size of that modeled slate (which is a rectangular parallelepiped) by assuming that it's entirely made of lead (or some other heavy and high abundance metal) 17:42:44
xionboxYou could also use your drag coefficient to compute the matching width and thickness based on the density of the material 17:44:32
xionboxDo you have a research plan setup yet? One technique I've successfully used, and recommended to many, is to go step by step, each adding a bit more complexity. For example, start with a simple model which you think would take only a day's worth of work. Expect it to take nine times longer (the famous "Pi rule:" whatever is your time estimate, multiply it by Pi. If it's the first time you're doing it, multiply it by Pi squared). After that, add another step, e.g. repeat the same model for five variations of the slate and plot their altitude during their orbital decay for a maximum propagation time of ten years17:47:46
xionboxLong story short: I'm happy to provide you some guidance if needed! I know astrodynamics quite well, but I don't know poliastro too well17:52:20
astrojuanlu welcome eddie-in-orbit ! xionbox advice is very good :) I don't think you need (or can use) poliastro for that specific calculation. you would have to find out what geometric shape does have the maximum mass/area ratio - it has to be either a sphere or some sort of shoe box 17:56:19
eddie-in-orbit Wow! That's a super generous amount of advice xionbox . Thanks! (disclaimer: I'm not very knowing on the subjects.) I understand what you mean with the metal slate. Do you mean that I would use the mass of the upper stage and the density of the material to determine the volume of the slate? Meaning the slate is a simplified modell of an upper stage. In terms of a research plan, the plan was to use poliastro code and do the calculation with the parameters. I'm not sure if by 'simple model' you mean coding a program myself?, if so sadly I'm not yet skilled enough for that. That's why I made the decision to use open-source code for my project(while only slightly tweaking things.) (By the way xionbox I might have another astro-dynamical question for you, should i dm it?) 20:49:37
eddie-in-orbit astrojuanlu thanks for answering, is it impossible to use poliastro for this sort of calculation or just not recommended? Also do you know of any other open source code i could use for this? 20:50:01
xionbox
Wow! That's a super generous amount of advice xionbox . Thanks! (disclaimer: I'm not very knowing on the subjects.) I understand what you mean with the metal slate. Do you mean that I would use the mass of the upper stage and the density of the material to determine the volume of the slate? Meaning the slate is a simplified modell of an upper stage. In terms of a research plan, the plan was to use poliastro code and do the calculation with the parameters. I'm not sure if by 'simple model' you mean coding a program myself?, if so sadly I'm not yet skilled enough for that. That's why I made the decision to use open-source code for my project(while only slightly tweaking things.) (By the way xionbox I might have another astro-dynamical question for you, should i dm it?)
You're most welcome. We need more astrodynamists! I was thinking that you would use poliastro for the simulations: if a tool already exists for the simulation, it's usually better to use it (especially if it's open source!). If poliastro can model drag, then you should be able to use it. The slate modeling would be done outside of poliastro. Effectively, you'll tell poliastro what coefficient of drag you're modeling, the mass, and the initial spacecraft orbit but nothing else. However, in the paper/report, you'll justify that choice with the slate model. Do you see what I mean?
21:50:40
xionboxFeel free to ask your astro question here or in dm. If it's here, someone else can answer if I don't get to it immediately ;-) 21:51:11
astrojuanlu
astrojuanlu thanks for answering, is it impossible to use poliastro for this sort of calculation or just not recommended? Also do you know of any other open source code i could use for this?
poliastro understands mass and drag coefficient, but won't help you finding specifically which object will have a largets mass-to-area ratio - for that you might need some pen and paper :)
22:06:36
19 Jan 2021
eddie-in-orbit astrojuanlu: Yes, I only intend to use the program for calculating the lifetime of an objects who's area and mass I would decide without the program. But does poliastro not understand area too? I thought it was a part of the example code "atmospheric drag" as the variable A_over_m? 18:06:49
eddie-in-orbit xionbox: Yes, i think i understand. But i just got advice that "There are multiple calibration spheres in space right now, mere metallic spheres used to calibrate radar or laser stations. They probably fit the bill." And I was also given examples on these: https://earth.esa.int/web/eoportal/satellite-missions/s/starlette , any thoughts on the use of something like this for the calculation? The reason for not using a rocket-body would be it's large area. 18:12:18
xionbox eddie-in-orbit: The benefit of using a spherical model is that drag models often expect the vehicle to be a sphere, as it's a good first approximation. At the same time, it I don't think that it would meet your initial objective of assessing how long it would take the debris with the "highest mass/area ratio" to deorbit. For a high mass to area ratio, you need the mass to be high and the area to be very small, hence the idea of a slate. Returning to the research guidelines I mentioned though, it is an excellent idea to start with a sphere. Set up the simulation with that, run a few cases, and then determine your next step 18:17:39
astrojuanlu
astrojuanlu: Yes, I only intend to use the program for calculating the lifetime of an objects who's area and mass I would decide without the program. But does poliastro not understand area too? I thought it was a part of the example code "atmospheric drag" as the variable A_over_m?
poliastro only understands `A_over_m` - therefore it only receives the ratio between the two, not the mass and the area separately
18:23:16
eddie-in-orbit astrojuanlu: I understand. Thanks! 20:19:39
eddie-in-orbit xionbox: But would the metal slate actually be a representation of a possible space debris? Is there any space debris with that kind of mass/area ratio? That's why I was thinking about the sphere satellite since it's measurements are real and it might become(if it isn't already a debris.) It's got a lot of mass, and is quite small which fits the criteria. 20:41:05
xionbox A metal slate is not a good representation of space debris. A small sphere, however, is a good representation of small space debris. For an upper stage, a cylinder would be a better model I think 20:45:22
eddie-in-orbitI apologize for all the follow up questions, but an upper stage would probably have a large surface area right(or "effective area" meaning the area colliding with air particles)? I think maybe I'll simplify the project to a sphere just as you sugested, but maybe I'll stop it there and not model it after a slate afterwords. 20:57:48
xionboxDoes anyone have experience with interpolated trajectories when applied to position and velocity in astrodynamics? I've always heard of Hermite interpolation being used in SPICE for spacecraft trajectories. However, I am just testing the Lagrange interpolation, and it's truly excellent. For a simulated ISS trajectory, a Hermite interpolation requires me to fix the interpolation window to 5 minutes (which is consistent with some literature I've read maybe two years ago now). But with Lagrange, I'm getting errors consistently below 1e-7 meters even for an interpolation window of 20 minutes23:53:44
xionbox

Here is an example. Each line has the epoch in TAI, the position X, then a `<=>` symbol, and then the error between the position and the interpolated positions. The first number is the Hermite interpolation, and the second is the Lagrange interpolation:

``````[src/main.rs:87] window_states.len() = 32
2013-03-18T12:01:11.738469600 TAI  (1129.122705085018 km) <=> 1.84e14 1.09e-10 => lagrange order 31
2013-03-18T12:01:47.527183532 TAI  (1390.3232125905033 km) <=> 1.75e13 4.77e-11 => lagrange order 31
2013-03-18T12:02:23.381568908 TAI  (1649.721651353352 km) <=> 6.28e11 1.89e-11 => lagrange order 31
2013-03-18T12:02:58.858862876 TAI  (1903.727098868139 km) <=> 3.66e10 9.55e-12 => lagrange order 31
2013-03-18T12:03:33.666565895 TAI  (2149.9668648521983 km) <=> 2.17e9 2.27e-12 => lagrange order 31
2013-03-18T12:04:08.55150508 TAI  (2389.976560043338 km) <=> 5.36e7 3.18e-12 => lagrange order 31
2013-03-18T12:04:42.528567314 TAI  (2626.9557369988643 km) <=> 1.11e6 2.27e-12 => lagrange order 31
2013-03-18T12:05:17.904379367 TAI  (2865.991118818273 km) <=> 1.93e4 4.55e-12 => lagrange order 31
2013-03-18T12:05:55.324396133 TAI  (3113.8479170830524 km) <=> 2.21e2 3.64e-12 => lagrange order 31
2013-03-18T12:06:37.315587997 TAI  (3385.3341762207065 km) <=> 1.00e0 1.36e-12 => lagrange order 31
2013-03-18T12:07:20.317536830 TAI  (3655.454266953266 km) <=> 2.03e-3 9.09e-13 => lagrange order 31
2013-03-18T12:07:59.625464439 TAI  (3894.8388478265465 km) <=> -2.21e-4 1.36e-12 => lagrange order 31
2013-03-18T12:08:37.134294509 TAI  (4116.112983878798 km) <=> -2.01e-3 9.09e-13 => lagrange order 31
2013-03-18T12:09:13.594626903 TAI  (4324.122555306356 km) <=> -8.64e-3 0.00e0 => lagrange order 31
2013-03-18T12:09:49.137471675 TAI  (4519.840430864657 km) <=> -7.96e-3 0.00e0 => lagrange order 31
2013-03-18T12:10:23.983618736 TAI  (4704.651502741697 km) <=> 1.74e-1 -9.09e-13 => lagrange order 31
2013-03-18T12:10:58.345342159 TAI  (4879.757729686493 km) <=> 1.62e0 -9.09e-13 => lagrange order 31
2013-03-18T12:11:32.370984554 TAI  (5045.909409128179 km) <=> 9.58e0 -9.09e-13 => lagrange order 31
2013-03-18T12:12:06.114973068 TAI  (5203.326691655302 km) <=> 4.44e1 -9.09e-13 => lagrange order 31
2013-03-18T12:12:39.727280139 TAI  (5352.616933552424 km) <=> 1.13e2 9.09e-13 => lagrange order 31
2013-03-18T12:13:13.432216167 TAI  (5494.573553467754 km) <=> -1.57e3 1.82e-12 => lagrange order 31
2013-03-18T12:13:47.732339382 TAI  (5630.863047828626 km) <=> -2.46e5 1.82e-12 => lagrange order 31
2013-03-18T12:14:23.79819679 TAI  (5762.473125509185 km) <=> -3.96e7 3.64e-12 => lagrange order 31
2013-03-18T12:14:59.404225826 TAI  (5888.153763606213 km) <=> -4.71e9 1.82e-12 => lagrange order 31
2013-03-18T12:15:36.594088554 TAI  (6006.564458389619 km) <=> -4.35e11 -9.09e-13 => lagrange order 31
2013-03-18T12:16:14.438827037 TAI  (6116.186331517106 km) <=> -3.20e13 -2.73e-12 => lagrange order 31
2013-03-18T12:16:52.612147331 TAI  (6215.446946497398 km) <=> -1.85e15 -4.55e-12 => lagrange order 31
2013-03-18T12:17:30.65849304 TAI  (6301.617192628151 km) <=> -7.74e16 1.82e-12 => lagrange order 31
2013-03-18T12:18:06.715019226 TAI  (6375.03134716231 km) <=> -2.38e18 -9.09e-13 => lagrange order 31
2013-03-18T12:18:43.51027297 TAI  (6437.04567431023 km) <=> -5.83e19 -1.00e-11 => lagrange order 31
2013-03-18T12:19:19.441528320 TAI  (6488.298792620205 km) <=> -1.19e21 -1.80e-10 => lagrange order 31
2013-03-18T12:19:56.742275238 TAI  (6529.471619482752 km) <=> -2.22e22 -8.11e-10 => lagrange order 31
``````
23:55:08
xionbox

Note that if change the window size to 5 minutes (instead of 20), Hermite is much better (as expected):

``````[src/main.rs:87] window_states.len() = 8
2013-03-18T12:01:11.738469600 TAI  (1129.122705085018 km) <=> -2.70e-10 -2.27e-13 => lagrange order 7
2013-03-18T12:01:47.527183532 TAI  (1390.3232125905033 km) <=> 1.57e-11 0.00e0 => lagrange order 7
2013-03-18T12:02:23.381568908 TAI  (1649.721651353352 km) <=> -4.55e-13 6.82e-13 => lagrange order 7
2013-03-18T12:02:58.858862876 TAI  (1903.727098868139 km) <=> -9.09e-13 6.82e-13 => lagrange order 7
2013-03-18T12:03:33.666565895 TAI  (2149.9668648521983 km) <=> 6.37e-12 9.09e-13 => lagrange order 7
2013-03-18T12:04:08.55150508 TAI  (2389.976560043338 km) <=> -5.18e-11 9.09e-13 => lagrange order 7
2013-03-18T12:04:42.528567314 TAI  (2626.9557369988643 km) <=> -8.28e-9 9.09e-13 => lagrange order 7
2013-03-18T12:05:17.904379367 TAI  (2865.991118818273 km) <=> -1.99e-7 0.00e0 => lagrange order 7

``````
23:55:50
xionboxHmm, actually, SPICE does support Lagrange interpolation: types 8/9/10 ( https://naif.jpl.nasa.gov/pub/naif/toolkit_docs/C/req/spk.html )23:57:37
20 Jan 2021
xionboxHa! I found that source from two years ago! https://ilrs.gsfc.nasa.gov/data_and_products/dfpwg/pfsg/eph_interpolation.pdf00:06:56