Orbital Mechanics

tahanson43206 · 2019-09-28 14:37:43

For GW Johnson re #25 ...

Thanks for your perspective, and for the tip about NEMAR .... my first high level language was Fortran, after building a foundation in assembler, which was the path open at the time.

(th)

SpaceNut · 2019-09-28 15:58:46

1977 college level programing courses were still done on type key punch card or punched paper tape where the program was then fed into the computer for the languages of Fortran, Basic, colbalt, all of which they were still using the 1 wide magnetic tapes writing the data in NRZ mode as it whizzed by the head as it traveled from one reel to the other.
Back to navigation its still about using geometry to solve space time calculations of where you are based on the target by which the movement is then fed into the computer for how long a burn must be to change or to correct course direction.

GW Johnson · 2019-09-28 17:57:38

In college, as an undergraduate I learned Fortran II on some IBM machine that had only a 3-digit designation that I can no longer remember. That was 50 years ago. It prepared me well for the Fortan IV that I used in industry. Which is quite distinct from the Fortran 77 that seems to have replaced all the older Fortran compilers since then. I NEVER learned Fortran 77, but it appears at first glance similar to the advanced BASIC's.

I spent some 8 years in industry doing pencil-and-paper equivalents to the spreadsheets used today. This was initially slide rule stuff, then programmable pocket calculator stuff, augmented by card batch runs on the mainframe computer, if (and only if) there no way to do the analysis any other way. America went to the moon like that!

Then I spent 3 years in industry with a desktop terminal into a mainframe computer (NOT today's desktop or laptop computer!!!) using BASIC in one of its forms, to do the same sort of automated pencil-and-paper calculations of the finite-difference forms of the equations of motion. I got better answers in actual flight test than the young kids trying to solve differential equations on the computer. And by FAR!!!

Then I spent 8 years more in industry doing what I had done in the years before, just translated into one of the advanced BASIC languages, on desktop computers (essentially today's laptops, just bigger and heavier). It was during this interval that my card batch FORTRAN program for analyzing ramjet ground tests got translated into something that a desktop could do more effectively.

In the years since, after being laid off due to plant closure at age ~ 45 in 1994, I have translated these abilities into automated programs couched in QuickBASIC 4.5 for trajectories, propulsion, and flight dynamics. And more. After layoff from defense work, I have never done defense aerospace work professionally again. I did some civilian (civil) engineering, and a lot of teaching, anywhere from junior high to college graduate school levels. In topics ranging through math, physics, and engineering.

Until I was fired for blowing the whistle on a seriously-misbehaving administrator. From there it was part-time college teaching at a different college until I became Medicare-eligible. Then I retired. Period.

Most recently, I have been helping a good friend with his auto mechanic repair business, which is a thing that 1 person cannot successfully do. One of the teaching jobs I had required my ASE certification, which made me quite attractive for this final employment, besides the fact that the business owner has been my friend for over 3 decades. Otherwise, I am fully retired, and only building cactus eradication farm implements for sale to the public out here on my home farmstead.

GW

Last edited by GW Johnson (2019-09-28 18:08:48)

tahanson43206 · 2019-09-28 19:36:20

For GW Johnson re #28 and prior...

For SpaceNut re #27 blending with #28

Thanks for a trip down memory lane. Google came up with NEWAR Fortran after a couple of tries.

The result list featured a government site where a catalog of FORTRAN programs is cataloged for posterity.

One discovery (for me at least) is that good old FORTRAN 77 is now (apparently) replaced by FORTRAN 90, to attempt to bring the language into the object oriented age.

I had to work my way manually through the list until NEWAR showed up, which is why the experience was full of memories ... hardware, software, problems to be solved at the time .... it's all there.

https://www.science.gov/topicpages/f/fo … er+program

NEMAR plotting computer program
NASA Technical Reports Server (NTRS)
Myler, T. R.
1981-01-01
A FORTRAN coded computer program which generates CalComp plots of trajectory parameters is examined. The trajectory parameters are calculated and placed on a data file by the Near Earth Mission Analysis Routine computer program. The plot program accesses the data file and generates the plots as defined by inputs to the plot program. Program theory, user instructions, output definitions, subroutine descriptions and detailed FORTRAN coding information are included. Although this plot program utilizes a random access data file, a data file of the same type and formatted in 102 numbers per record could be generated by any computer program and used by this plot program.

(th)

SpaceNut · 2019-09-28 19:41:30

There were many computer languages in the 80's as computers advanced and some were based simular to the Unix, Linix was born, advance operating systems, pascal machining drawing language, autocad just to many to remember as I tripped through the computer age of manufacturing of them.....

GW Johnson · 2019-09-28 21:01:49

In college I learned on an old IBM computer with Fortran II. That was late 1960's. In industry, when I entered the workforce permanently in 1975, and for a very long time afterward, the standard was Fortran IV.

Fortran 77 bears little resemblance to Fortran IV or earlier. In point of fact, it more closely resembles the advanced BASIC's. I've seen it, though I never learned it. I know absolutely nothing of anything called Fortran 90. Never, ever heard of it while I was in the defense workforce, and that was through November of 1994.

What I have on my computer is an advanced BASIC called QuickBASIC 4.5. This is another obsolete language, although it supposedly resembles Fortran 77, as do most of the advanced BASIC's. It is easy to do something called "spaghetti code" in this version of BASIC (or the earlier ones) and in Fortran IV and earlier. The more modern "structured" languages supposedly do not permit this (which means from my point of view, they are over-organized and overly-restricted).

I am quite capable of programming from a pencil-and-paper block diagram, including the need to do "spaghetti code", which is inherent to properly model ramjet engine cycle analysis. You simply cannot do that analysis properly unless you are free to program-up "spaghetti code". Locking-out that capability too-severely limits you.

I'm sorry, but the modern programming language guys got that aspect wrong. Too lazy to do their own structures, I guess.

GW

Last edited by GW Johnson (2019-09-28 21:05:29)

SpaceNut · 2019-10-16 20:50:39

Some tools for mars and other places

https://www.nasa.gov/centers/ames/engin … ature.html

kbd512 · 2019-10-17 00:54:46

GW,

Sorry, but I don't follow. Why do you "need" to use spaghetti logic to do a ramjet design analysis?

I think an appropriate tool is fairly closely related to the problem you're trying to solve. I've never understood the fixation some people have with language constructs and the way in which some specific task can be accomplished, as if that's indicative of good design or that some specific tool is necessarily "better" than another because of how it can be used to solve some particular problem. "Good for what?" really should be the first question that gets asked. I think it revolves around your toolbox, at least in part. If you only have one tool in your toolbox... Well, you should know the rest. Expand your horizons a little. Some of the things you can do with more tools in your toolbox would blow your mind. There's typically an elegant solution to a problem when you have multiple tools to choose from.

RobertDyck · 2019-10-17 07:41:10

GW Johnson wrote:

In college I learned on an old IBM computer with Fortran II. That was late 1960's. In industry, when I entered the workforce permanently in 1975, and for a very long time afterward, the standard was Fortran IV.

I learned Fortran 4 in high school in the late 1970s.

GW Johnson wrote:

I am quite capable of programming from a pencil-and-paper block diagram, including the need to do "spaghetti code", which is inherent to properly model ramjet engine cycle analysis. You simply cannot do that analysis properly unless you are free to program-up "spaghetti code". Locking-out that capability too-severely limits you.

Then you never worked on a major project involving millions of lines of code. I remember that debate from the late '70s. Computer professionals worked hard to find rare examples where spaghetti code was simpler, short, easy to understand. I could give cases where breaking out of a loop prematurely greatly simplifies code, but not out-right spaghetti code.

In 1990 I worked for Westfair Foods maintaining software for the Superstore, a major grocery store here. Code was COBOL on a mainframe. Second in command for our department insisted on using goto statements, made it mandatory. Result was spaghetti code. Trying to figure out what the code was supposed to do was difficult. This caused a lot of errors. One day I worked on an enhancement, but one section of code didn't make sense. I told my boss I needed another day to figure it out. He asked what it's for. I said data from the handheld stock keeping device. He said that device is not supported, it's highly controversial, don't ever mention it again. We put it in production, that night it crashed on exactly the line I said it would, for exactly the reason I said it would. Pager went off, I had to go in to work. I couldn't figure it out, so called a senior analyst for help. He called the boss and the second in command. We got it fixed, data was uploaded from the store controller, cash registers were able to open just an hour before store open. You can imagine how much hysteria this caused with corporate executives. If I was permitted just one more day none of that would have happened.

Software had become spaghetti code. A forensic analysis of the code showed it was originally well written, but patches were done so badly that mistakes were common. When I carried the pager for Acklands-Granger and Bumper-to-Bumper in 1987 I could go 2 weeks without the pager going off. For the Superstore whoever carried the pager wasn't expected to be productive during the day because it was a question of how many times it would go off per night. Spaghetti code is that unreliable. And when I approached the boss about moving to goto-less code, which was mandatory in university, he told me to get members to do it. But his second in command pushed back hard, I got in trouble for doing what the boss told me to do. When the company consolidated computer departments, the Winnipeg office was closed, all software developers lost their jobs.

Does that help?

tahanson43206 · 2019-10-17 12:30:22

For GW Johnson and RobertDyck ....

Would the two of you be willing to look at the mission planning site that SpaceNut found?

It appears to be suitable (as nearly as I can tell from first impressions) for use by academics or students, but also by actual mission planners who are thinking about bidding on NASA opportunities, or even making proposals for possible funding.

The code appears to have already been written to perform fairly sophisticated calculations, and (as I understand it) the database is loaded up with a great number of objects already, and (apparently) more are being added.

(th)

GW Johnson · 2019-10-18 11:15:32

Well, I did not mean to provoke so much discussion.

I never worked on anything over about a tray of cards, which would be no more than around 2000-2500 lines of code. I never needed anything bigger than that, and no person working alone is going to be able to debug and verify much more than that, in a day or two. Which is exactly what I had to do. Alone.

The ramjet cycle analysis has nested loops modelling some rather complicated compressible flow physics, with a strong interaction between the combustion chamber c* and massflow quantities, and the fundamental operation of the inlet (subcritical vs supercritical operation, which determines how much air massflow gets scooped up, and what the max possible inlet stagnation pressure can be). It also interacts with the fuel control scheme, which may (or may not) alter fuel flow as the air flow changes.

The loop modelling the inlet-nozzle massflow balance therefore has multiple exit criteria, each leading to a different and distinct next step, reflecting the very complicated physics going on. It doesn't just run to a preset single, simple completion criterion.

I call that "spaghetti code", maybe y'all do not. But I didn't need millions of lines of code to do it.

It gets even worse with low-speed range ramjets that can run at subsonic flight speeds: the ramjet nozzle throat is usually unchoked below about Mach 1.1-ish speeds (in properly-sized designs). That means the combustor Mach number is no longer locked in by the nozzle contraction ratio, which in turn always results in a subcritical inlet. Fly fast enough, and the nozzle chokes, locking in the combustor Mach number at its maximum value. So there's another couple of levels of nested loops there.

It's also why low-speed range ramjets have convergent-only nozzle profiles, no expansion bell. If unchoked, such a bell is a diffuser, not a nozzle, thus reducing exit velocity (and thus thrust and Isp) for a given massflow.

Like I said, it's complicated. I wrote this up as four different codes, each around 2000 lines. There's a low-speed ramjet sizing code, and the related low speed ramjet performance code. These use pitot-normal shock inlets and convergent-only nozzle profiles.

And, there's the high speed ramjet sizing and performance codes. These allow a variety of empirical inlet models (none of which operate below about Mach 1.6-ish flight speeds), and a fully convergent-divergent nozzle profile that is always choked.

Like I said, ramjet gets really complicated.

I'm probably not the person to look at modern code. RobertDyck probably is. His training and experience is more modern than mine, by far.

GW

SpaceNut · 2019-10-18 17:37:31

Some would call it the assembly language for the processor instruction after complining the source code which is writen in the upper level language. The bit chasers in my day wrote in assembler to test product as well as to debug a failing pcb.

SpaceNut · 2019-11-11 17:53:21

louis wrote:

So do you have an estimate for the additional power required to turn an average 7 month Hohmann transfer into a 3 month journey?
SpaceNut wrote:
Those dammed math equations of distance, mass change, fuel allotment for burn period, to speed...(isp) or exit velocity thrust....which is momentum once the engines fire and all fuel is used over a period of time.....

Remember the ship that goes faster to mars is all that much harder to slow in the thin atmospher of mars and will produce a lot more heat for the shield to remove as the drag component of heating is related to the speed of the ship and the angle of attack. Going faster also means you will need more fuel on retro propulsion to slow the ship to a touch down once its in landing. Si the current 100 ton of fuel will need to cut into the payload mass to mars surface to allow for the ship size to stay the same while compensating for larger tanks for landing due to the increase speed.

louis wrote:

Yes, I meant including all factors including deceleration...I am just wondering what the proportion of propellant/fuel to payload/rocket mass would be to, say, achieve a 3 month journey time.

SpaceNut · 2019-11-11 17:55:06

Work the equation backups for the new on orbit to mars arrival speed to be able to solve for the new thrust needed to slow the ship for retro propulsion. First to solve is the guide path aerobraking speed at exit of mach even if the mass of the ship, fuel, and payload leave at the same consolidated value to give you a first pass number. This is the engine thrust that must be achieved at altitude to be able to slow the ship down.

https://www.reddit.com/r/spacex/comment … on_system/

Mars departure speed is more like 4.3 kms for a 6 month journey to mars and you are looking to get there is half the time which would mean a new arrival speed of 8.6 or higher depending on distance which could be as high as 9.50 kms. We can solve for the new value of fuel mass change later for the earth departure.

http://design.ae.utexas.edu/mission_pla … riteup.pdf
DV vs C3 from Low Earth Orbit

There is a simulator program link which has been posted by another member here by rgclark I think for the glide path.

Fast transits and aerocapture topic

If we were trying for high orbit breaking we would just pass and bounce off to hopefully slow in time for another pass as the orbitors do.
https://space.stackexchange.com/questio … ut-landing

Of course months or years looping to slow down is not what we would want for a manned mission.

https://ntrs.nasa.gov/archive/nasa/casi … 209887.pdf
ENABLING EXPLORATION MISSIONS NOW: APPLICATIONS OF ON-ORBIT STAGING

SpaceNut · 2019-11-11 17:57:21

I think that its articles like this one that twists the facts without the full picture.
https://www.space.com/24701-how-long-do … -mars.html

The fastest launched mission https://en.wikipedia.org/wiki/New_Horizons of which there was no refueling, no circular staging which is called a direct path launch. Atlas V rocket directly into an Earth-and-solar escape trajectory with a speed of about 16.26 km/s (10.10 mi/s; 58,500 km/h; 36,400 mph).

It launched on Atlas V (551) AV-010 with a payload of 30.4 kg (67 lb).

January 19, 2006: Successful launch at 19:00 UTC after a brief delay due to cloud cover
April 7, 2006: The probe passed Mars' orbit 1.5 AU from Earth

Thats a mer 75 days of flying....

https://upload.wikimedia.org/wikipedia/ … e_appr.png

SpaceNut · 2019-11-11 18:01:08

Working backwards from the on orbit arrival speed you will need to run a simulation of the mars EDL.
Simulation of Entry Descent and Landing (EDL)

https://sites.nationalacademies.org/cs/ … 083264.pdf
Entry, Descent and Landing for Future Human Space Flight

https://dartslab.jpl.nasa.gov/Reference … alaram.pdf
MARS SMART LANDER SIMULATIONS FOR ENTRY, DESCENT, AND LANDING

https://ntrs.nasa.gov/archive/nasa/casi … 033126.pdf
Mars Phoenix Entry, Descent, and Landing Simulation Design and Modelling Analysis

https://ntrs.nasa.gov/archive/nasa/casi … 010129.pdf
ASSESSMENT OF THE MARS SCIENCE LABORATORY ENTRY, DESCENT, AND LANDING SIMULATION

https://www.colorado.edu/event/ippw2018 … rkhart-jpl
Simulation of Mars 2020 Entry, Descent, and Landing

SpaceNut · 2019-11-11 18:02:01

GW Johnson wrote:

What I said about orbital mechanics and entry speed has nothing to do with any specifics about Spacex's vehicles or anybody else's vehicles. This is the same orbital mechanics and entry physics that govern all vehicles.
For a Hohmann min energy transfer orbit, twice the semi-major axis "a" of the transfer ellipse is the Earth distance from the sun plus the Mars distance from the sun. Velocity is easy to figure at any radial distance "r" from the sun from V = [GM(2/r - 1/a)]^0.5, where M is the central body mass, in this case the sun. Perihelion velocity will be less than solar escape for elliptical mechanics to apply. I don't have the period equation in my head, but it is proportional to a^1.5, that I remember. Half the period is the one-way transit time on that transfer ellipse.
On any other faster trajectory, up to the limit of perihelion velocity less than solar escape, twice the semi-major axis of the ellipse is the radial distance from the sun plus a radial distance far past Mars. Velocities are figured from the same velocity equation. The one-way transit time is less than half the period, because you get off before reaching the aphelion point.
There's no point using perihelion distances inwards of Earth, because it is the velocities nearer perihelion that are higher, and that is how you make the trip faster.
When you depart Earth (whether from the surface or from orbit), you want the final velocity "far from the Earth" to be parallel to the Earth's motion about the sun. You want its magnitude as measured with respect to the sun to be the perihelion velocity of your transfer ellipse. That's how you get on the transfer trajectory, whether it is Hohmann min energy or something faster. The delta vee required is larger the faster the perihelion velocity, which in turn corresponds to the faster trip.
At the orbit of Mars, you have a velocity magnitude figured on your trajectory (min energy or faster) per the equation I gave above, and that's with respect to the sun. Its direction is tangent to your trajectory. Mars has a velocity with respect to the sun. Your velocity with respect to Mars, essentially "far from Mars", is the vector difference: yours minus Mars's. Assuming you are going for direct entry and one-pass aerobraking, you just let Mars run over you "from behind".
Mars's gravity will accelerate you toward Mars, so your speed at entry interface will be higher than the magnitude of your velocity vector with respect to Mars when you are "far from Mars". You figure that from Vinterface = (Vinfinity^2 + Vesc^2)^0.5. Vesc is Mars's escape velocity.
You are quite free to run these numbers for yourself. They apply to any vehicle whatsoever. Computer programs do this slightly more accurately as 3-body interactions, but these simple calculations are actually very good estimates.
As for entry dynamics, you want your velocity vector at entry interface just grazing the planet at something in the 1-2 degrees below horizontal. If speed at entry is below 10 km/s, convection will dominate the aeroheating. If faster, radiation from the plasma dominates the picture. Empirically, convection varies as velocity squared, plasma radiation varies as speed to the 6th power.
You will want to tilt your spacecraft to generate lift in the needed direction, even if it is a capsule aeroshell shape. That would be downlift to counter bouncing off the atmosphere, until your speed has fallen below approximately circular orbit speed. Then you want uplift, in order to counter the sagging of your trajectory downwards from the influence of gravity, as you slow. It's all over at approximately local Mach 3 speeds. Then "ordinary" supersonic compressible flow analysis applies from there.
Those entry physics also apply to any vehicle whatsoever.
For Earth-Mars min-energy transfers, Mars entry interface is about 7.5 km/s. For faster transfers, it is much higher, leasing directly to higher heating and higher deceleration gees. For similar direct entries coming home to Earth (where you run into the planet from behind), min energy trajectories have entry interface velocities in the 12-13 km/s class. Faster trajectories (in the 6 month flight time class) have entry velocities in the 17 km/s class.
It's just physics. You just run the numbers. Then you have to design your vehicles and your propulsion to those conditions. It's that simple, and it is that hard.
GW

SpaceNut · 2019-11-11 18:02:59

https://en.wikipedia.org/wiki/List_of_Mars_orbiters

The difference for orbiters and landing is the time altering the dives through the mars air to slow for the circular orbit which is over months once the first dive occurs to slow to orbiting speed. This is not what we would want to do as that extends the life support to take care of the slow process to slow down.

https://upload.wikimedia.org/wikipedia/commons/thumb/c/c9/Odyssey_summary_br.jpg/250px-Odyssey_summary_br.jpg with
Mars Odyssey launched from Cape Canaveral on April 7, 2001, and arrived at Mars about 200 days later on October 24 a total 6 months, 17 days to begin aerobraking. Odyssey then spent about three months aerobraking ended in January 2002.

MRO was launched August 12, 2005, and attained Martian orbit on March 10, 2006. In November 2006, after five months of aerobraking,

Maven launched 18 November 2013 and arrived at mars 22 September 2014
MAVEN spacecraft entered orbit around Mars, completing an interplanetary journey of 10 months

MAVEN was launched aboard an Atlas V launch vehicle at the beginning of the first launch window on November 18, 2013. Following the first engine burn of the Centaur second stage, the vehicle coasted in low Earth orbit for 27 minutes before a second Centaur burn of 5 minutes to insert it into a heliocentric Mars transit orbit.
On September 22, 2014, MAVEN reached Mars and was inserted into an elliptic orbit 6,200 km (3,900 mi) by 150 km (93 mi) above the planet's surface.

SpaceNut · 2019-11-11 18:03:35

Hohmann transfers are typically the most efficient transfer a spacecraft can make to change the size of an orbit. In orbital mechanics, the Hohmann transfer orbit is an elliptical orbit used to transfer between two circular orbits of different radii around the same body in the same plane. The Hohmann transfer orbit uses the lowest possible amount of energy in traveling between these orbits.

Its the amount of energy needed to follow the arc from earth to mars. Earth is moving in its orbit at delta v of and mars is orbiting at its own delta v amd you are trying to catch mars from departure acceleration.

https://upload.wikimedia.org/wikipedia/ … it.svg.png

https://www.instructables.com/id/Calcul … -Transfer/
http://design.ae.utexas.edu/mission_pla … ansfer.pdf

tahanson43206 · 2019-11-11 19:12:36

For SpaceNut or GW Johnson (other contributors welcome) ...

Somewhere recently I picked up the idea that one of the probes that went to Mars was traveling at 7.5 km/s upon arrival at the planet.

I tried to find the post just now and could not. It is relatively recent.

My first question would be ... is that the velocity of the vehicle as it approaches Mars?

It could also be a velocity relative to another object in the Solar System.

I was curious to know what the Rocket Equation would say, so I found this site:

http://www.quantumg.net/rocketeq.html

The rocket equation

Enter values for 3 of the variables and press calculate on the remaining one. (Note that I use the more popular specific impulse with isp = ve / 9.8)
Alternatively, you can set delta-v, isp, and the stage parameters to do a fixed point calculation of a stage dry mass. (inert mass ratio = dry mass / propellant mass)
dv    m/s recalc 7500 meters per second (7.5 km/s)
isp    s recalc 385 (from memory - could be incorrect)
m0    kg recalc 100000 kg before the burn
m1    kg recalc 13699+ kg after the burn
Stage
inert mass ratio
payload mass recalc
dry mass recalc
Equation: m1 = 100000 / Math.exp(7500 / (9.8 * 385))

In running this experiment, I'd like to point out my uncertainties:

1) dv ... I think the velocity of the vehicle approaching Mars was 7.5 km/s relative to Mars, but am not sure
2) ISP ... 385 came to mind as a middle-of-the-road ISP, but that could be way off
3) m0 ... This is the mass (as I understand it) that would be of the vehicle, payload and fuel before the burn
4) m1 ... this would be the mass of the vehicle (and payload) without fuel after the burn

Assuming all the guesses are reasonable, then I would deduce that 100000 - 13700 or 86300 kg is the fuel burned to achieve orbit.

Where I'd like to go with this is to try to estimate what one of Elon's starships would be facing if the decision were made to dock at Phobos instead of trying to aerobrake in the atmosphere of Mars before attempting a retro-propulsion landing.

Edit after following one of SpaceNut's links:

https://space.stackexchange.com/questio … f-velocity

"...whose apogee just barely gets close enough to Mars that Martian gravity can capture it." At a near Mars aphelion a ship from earth would be moving about 2.7 km/s slower than Mars. Mars capture isn't possible without aerobraking or a burn. – HopDavid Dec 12 '18 at 2:24

The 2.7 km/s velocity is SO much better than the 7.5 km/s velocity I saw somewhere in recent posts.

Trying again:

The rocket equation
Enter values for 3 of the variables and press calculate on the remaining one. (Note that I use the more popular specific impulse with isp = ve / 9.8)
Alternatively, you can set delta-v, isp, and the stage parameters to do a fixed point calculation of a stage dry mass. (inert mass ratio = dry mass / propellant mass)
dv m/s 2700 m/s
isp s 385 again
m0 kg 204544 kg before burn
m1 kg 100000 kg (vehicle and payload after burn)

This scenario assumes retropropulsion with no aerobraking.

(th)

Last edited by tahanson43206 (2019-11-11 21:18:34)

SpaceNut · 2019-11-11 20:12:21

Getting into sync with mars is the first issue of which if you are not slowing by aerobreaking then you will need to be going slower than mars escape velocity so as to do a gravitational capture. https://en.wikipedia.org/wiki/Gravity_of_Mars Of course you need to be ahead of the planet as you are swept up by the planet as it approaches you. Once circling mars you raise or lower the orbit and speed over time to match the moons.

https://space.stackexchange.com/questio … f-velocity

SpaceNut · 2019-12-19 20:18:45

http://www.spacedaily.com/reports/Scien … m_999.html
Scientists closer to solving Newton's 'three-body problem'

Newton's laws of motion, nor any physical laws, explain the movements of three bodies in orbit.

GW Johnson · 2019-12-19 22:46:07

There are (as yet) no analytical solutions to the 3-body problem. There have been numerical solutions to the 3 body problem since about 1965. That is the source of the figure-eight orbit path used by Apollo to reach (and return from) the moon.

With better-than-1965 computers, astronomers now routinely work the n-body problem numerically, where n can be very large indeed. That is how galaxies are simulated on supercomputers.

The speed relative to Mars at Mars arrival of a vehicle, depends upon the trajectory by which it went there. For min-energy Hohmann transfer it is about 5.6 km/s at entry interface. It is higher for a faster trajectory, being near 7 km/s if the 2-year period abort orbit trajectory is used.

Mars has an atmosphere whose friction and drag effects are very significant at orbital speeds, like Earth's. You can delete most of the propulsive braking to land in favor of aerobraking hypersonics. But, you will come out of hypersonics very close to the surface, unlike Earth, because of how thin that atmosphere is.

Fractional-ton objects of "ordinary" design typically come out of hypersonics 25+ km above the surface (a handful of minutes from impact), while 10-ton+ objects will come out under 10 km, only several seconds from impact. 100-ton class objects come out about 5 km from the surface. That's why chutes are useless for big objects on Mars: no time to deploy, much less get any deceleration from them. On Earth, end of hypersonics occurs for really big things well above 45 km altitude. Always.

How much propulsion you need to touch down depends upon when you are forced to start the burn. Spacex thinks their "Starship" will be able to pull up while modest supersonic from below to above 5 km, landing on Mars. That local peak is about Mach 1 speed, which on Mars is about 0.23-0.24 km/s. That is where they "flip" tail-first, and light off the touchdown burn.

I think they will have to light the engine earlier to augment the lift to actually pull up like that. That would be ignition at a higher speed: at least Mach 1.5, maybe even 2. Murphy's Law says I am right, despite their simulations. Garbage-in, garbage-out is a real risk for anything never done before.

Almost nothing about any of that design analysis is rocket equation work. That's just the touchdown burn, and you'd better factor-up those speeds to cover hover/divert. Practical stuff. I'd recommend a factor of at least 1.5 on the velocity at touchdown ignition.

GW

Last edited by GW Johnson (2019-12-19 22:50:22)

SpaceNut · 2019-12-20 17:05:16

Centripical, centrifugal, gravity, momentum all to explain how fast we will be moving at a given distance or the forces that are exerted all seem odd when we treat parts of an equation as near zero or zero for value when comparing mass of an object to another incomparison to the tiny rocket...

so from the stand point of the rocket as its sees 4 forces relative to the others with the others to far away to count as it moves from its start towards it destination.

GW Johnson · 2019-12-21 11:25:38

You estimate the required kinematic delta-vee from all sorts of trajectory considerations. Then you factor it up to a mass ratio-effective delta-vee with a factor representing the effects of gravity and drag losses, or other practical considerations, such as hover and divert budgets for propulsive touchdowns. That mass ratio-effective delta-vee allows you to size your rocket propulsion stage or stages as an initial design concept. Concept only. Not even feasibility has been established.

From there you have to run a series of ever-increasing-fidelity simulations of the design's performance on the mission, revising the design after each step. It is a very iterative process, consuming much time and effort and resources. It's definitely NOT just one calculation! Although, that initial performance calculation (of the many) is the make-or-break demonstration of basic concept feasibility. Fail, and you need another concept. Pass, and it is worthwhile to continue to refine the design with those many iterative steps.

That's part of the reality of "rocket science". It ain't simple, it ain't easy, and it ain't quick.

But, the dominant part of the reality of "rocket science" is that it ain't just science. It's really only about 40% science, which is written knowledge. It's about 50% art, which is critical knowledge never written down, but passed on one-on-one on-the-job from mentor to youngster. And it's about 10% blind dumb luck.

And that's in production work. In development work, the art and luck portions are larger. A lot larger.

Been there and done that. All of it.

GW

Last edited by GW Johnson (2019-12-21 11:27:30)

New Mars Forums

Announcement

#26 2019-09-28 14:37:43

Re: Orbital Mechanics

#27 2019-09-28 15:58:46

Re: Orbital Mechanics

#28 2019-09-28 17:57:38

Re: Orbital Mechanics

#29 2019-09-28 19:36:20

Re: Orbital Mechanics

#30 2019-09-28 19:41:30

Re: Orbital Mechanics

#31 2019-09-28 21:01:49

Re: Orbital Mechanics

#32 2019-10-16 20:50:39

Re: Orbital Mechanics

#33 2019-10-17 00:54:46

Re: Orbital Mechanics

#34 2019-10-17 07:41:10

Re: Orbital Mechanics

#35 2019-10-17 12:30:22

Re: Orbital Mechanics

#36 2019-10-18 11:15:32

Re: Orbital Mechanics

#37 2019-10-18 17:37:31

Re: Orbital Mechanics

#38 2019-11-11 17:53:21

Re: Orbital Mechanics

#39 2019-11-11 17:55:06

Re: Orbital Mechanics

#40 2019-11-11 17:57:21

Re: Orbital Mechanics

#41 2019-11-11 18:01:08

Re: Orbital Mechanics

#42 2019-11-11 18:02:01

Re: Orbital Mechanics

#43 2019-11-11 18:02:59

Re: Orbital Mechanics

#44 2019-11-11 18:03:35

Re: Orbital Mechanics

#45 2019-11-11 19:12:36

Re: Orbital Mechanics

#46 2019-11-11 20:12:21

Re: Orbital Mechanics

#47 2019-12-19 20:18:45

Re: Orbital Mechanics

#48 2019-12-19 22:46:07

Re: Orbital Mechanics

#49 2019-12-20 17:05:16

Re: Orbital Mechanics

#50 2019-12-21 11:25:38

Re: Orbital Mechanics

Board footer