PDA

View Full Version : Where to get data for outer Jovian moons?



IsaacKuo
2009-Jan-10, 04:14 PM
I'm developing a wargame set around 2150, where the outer moons of Jupiter are important sources of water/hydrogen (delivered to LEO, it costs less delta-v than from Earth, Mars, Moon, or Ceres--only Phobos/Deimos require less delta-v, and not by much).

I'm most interested in the Pasiphae group, including Pasiphae, Sinope, Callirrhoe, Megaclite, Autonoe, Eurydome, and Sponde. Some or all of these moons will have a lot of ice, which is easy to mine.

My question is where to get orbital elements for these moons. I'd like to accurately simulate the positions of these moons for around the year 2150.

Also, how accurate would this data be for 100-200 years into the future? Would some orbital parameters be more likely to stay roughly constant? Are some parameters so uncertain that I can get away with simply assigning them randomly?

Note--I'm assuming non-nuclear development of space using mostly chemical rockets. If you have the opportunity to refuel, chemical rockets are actually better than solar/nuclear thermal rockets (because they use less hydrogen), as well as near-mid future electric rockets. The outer Jovian moons are arguably the easiest best place to industrialize first--even before our Moon.

grant hutchison
2009-Jan-10, 04:31 PM
JPL provides a mean elements (http://ssd.jpl.nasa.gov/?sat_elem) table that will get you to roughly the right place.
Unfortunately, some orbital elements will have evolved quite markedly between now and your game setting: the lines of nodes and apsides precess with periods on the order of a century, so the orbit orientations will be completely different at your future time, although the sizes, shapes and inclination to the ecliptic will be approximately the same.
JPL also provides a very accurate ephemeris system (http://ssd.jpl.nasa.gov/?horizons), but it won't address your particular problem, since it covers dates only a few decades into the future for the bodies you're interested in.

Grant Hutchison

mugaliens
2009-Jan-10, 07:30 PM
Some or all of these moons will have a lot of ice, which is easy to mine.

How much delta-v would you save by combining hydrogen from solar wind with oxygen liberated from asteroids? Oxygen is 16 times more massive than hydrogen, but there's 2 hydrogens, so you're lifting 8 times more mass of O2 than H2. So, if you have to lift O2, you might as well toss in the H2 in the form of nice, stable water. But if you can mine O2 from asteroids, skip the delta-v and just get the whole thing from space.

On the other hand, an ice colony would make for a great setting for a game. :)


My question is where to get orbital elements for these moons. I'd like to accurately simulate the positions of these moons for around the year 2150.

Wikipedia's entry for Moons of Jupiter (http://en.wikipedia.org/wiki/Moons_of_Jupiter)contains some terrific background into into the moons, and nearly all have links to their own Wikipedia pages in this table, here (http://en.wikipedia.org/wiki/Moons_of_Jupiter#Table).

As for the motions, Grant provided the JPL link.

Buttercup
2009-Jan-10, 07:53 PM
The Galileo orbiter of the 1990s...

IsaacKuo
2009-Jan-10, 08:31 PM
JPL provides a mean elements (http://ssd.jpl.nasa.gov/?sat_elem) table that will get you to roughly the right place.
Unfortunately, some orbital elements will have evolved quite markedly between now and your game setting: the lines of nodes and apsides precess with periods on the order of a century, so the orbit orientations will be completely different at your future time, although the sizes, shapes and inclination to the ecliptic will be approximately the same.

Thanks! That's exactly the data I was looking for. How does precession work? I'm visualizing it as taking the existing orbit and rotating it along the ecliptic axis...is that right?

So I keep the following:

semi-major axis
eccentricity
inclination
argument of periapsis (?)

While assigning the following randomly:

longitude of ascending node
mean anomaly

Does that sound good?

IsaacKuo
2009-Jan-10, 08:46 PM
How much delta-v would you save by combining hydrogen from solar wind with oxygen liberated from asteroids?

None. It costs MUCH more delta-v to get to/from asteroids than it does to get to/from Jupiter's outer moons. The critical factor is Jupiter's gravity, which gives a powerful Oberth effect boost. The delta-v to get from an outer Jovian moon is about 2km/s to transfer into a highly elliptical Jupiter orbit and then only about 650m/s to boost into a Jupiter->Earth transfer orbit. It only takes a 525m/s Oberth effect boost to get to Mars; or 750m/s to get to Venus. This makes the outer Jovian moons an excellent place to supply orbital stations/refueling depots around Mars and Venus, as well as Earth.

The cost to get to Jupiter's outer moons is much greater, but you're doing it with an empty tanker. The tankers would cycle between Earth elliptical orbit and Jupiter--going into a highly elliptical orbit lets you retain most of the required orbital energy for escape velocity, while simultaneously maximizing your Oberth effect boost. From Earth elliptical orbit to Jupiter is 3200m/s, with an additional ~2km/s to match orbits with an outer Jovian moon.

For a typical interplanetary mission launched from Earth, the biggest cost is getting to LEO--that's 8+km/s before your first opportunity to refuel. This plausibly requires a two stage launcher. From LEO, you can refuel worth 2-3km/s to boost up to a moderately elliptical orbit. Refuel again worth another 2-3km/s to boost up to a highly elliptical orbit (doing this in two steps saves fuel, but it's not necessary). From there, you can refuel if you want for a journey just about anywhere you want. It only costs 375m/s to get to Venus or 450m/s to get to Mars.

grant hutchison
2009-Jan-10, 09:25 PM
Thanks! That's exactly the data I was looking for. How does precession work? I'm visualizing it as taking the existing orbit and rotating it along the ecliptic axis...is that right?The orbit twists in its Laplacian plane ("regression of the nodes"), which is more or less equivalent to the ecliptic for these moons; it also rotates in its own orbital plane ("rotation of the apsides"), so that the periapsis migrates around the orbit. The JPL elements list gives the periods for these movements, as Pnode and Pw, respectively.

If you're happy to have a sort of "artist's impression" of the real situation in 2150, you could assign random values to the longitude of the ascending node, the argument of the periapsis and the mean anomaly, and keep the other values from the table.

Grant Hutchison

IsaacKuo
2009-Jan-10, 11:06 PM
I'd like to not make up any numbers at random, if it's appropriate. I don't mind learning more about orbital mechanics to calculate things out properly. But right now, I know very little about how to make the proper calculations for precession.

The game map for the Jovian system is likely going to look like a cylindrical projection map, so the moon orbit curves look like sinusoidal tracks. There will be two basic types of orbit--"circular" and "elliptical". The latter mean highly elliptical orbits with low altitude periapsis. The former means comparatively low eccentricity orbits (including all moon orbits).

With highly elliptical orbits, a fleet's counter remains in one spot--that spot being the point of apoapsis. With this type of orbit, it's cheap to change the altitude of apoapsis with trivial burns at periapsis, and it's cheap to change whether the orbit is prograde/retrograde/polar with small burns at apoapsis. But it's expensive to try and change the projected direction of apoapsis.

The "circular" orbits are probably simplified to somewhat abstract away altitude. This works if you only transfer between orbits by first entering a highly elliptical orbit. But you can also use direct transfer orbits, and I'm not yet sure how to handle that in a player-friendly way.

tony873004
2009-Jan-11, 12:16 AM
You can use my program, Gravity Simulator to compute it for you. The hard part is already done for you, as there is a 2006 simulation of all of Jupiter's known moons. You could slowly propogate it into the future. It'll take a few hours to do 150 years, as you must keep a slow time step to retain accuracy. The orbits will naturally precess for you. After a desired amount of time, you can have Gravity Simulator create an Excel-readable file of all the moons and their orbital elements. Visit this page: http://www.orbitsimulator.com/gravity/articles/joviansystem.html

The results will be pretty good, but not perfect, for a few reasons:

There's probably lots of uncertainty in their current positions, especially ones discovered by spacecraft, as follow-up observations may be non-existant.

In Gravity Simulator, Jupiter is modeled as a sphere, while in real life, it is an oblate spheroid. At the distance of the Pasiphae group, this won't make a huge difference.

For a rough idea of accuracy, see http://www.orbitsimulator.com/gravity/articles/sl9.html , which describes Gravity Simulator recreating the breakup and subsequent impact 2 years later of Comet Shoemaker-Levy 9.

IsaacKuo
2009-Jan-11, 04:49 PM
That looks great! What's a good timestep to use to minimize the error? If I have some idea of the algorithm being used, I can perform my own error analysis.

(Too big a timestep and you have integration errors; too small a timestep and you have roundoff errors.)

Silly question of mine--are the outer moon orbits supposed to not even vaguely line up from cycle to cycle? If so, I had no idea the "orbits" were so chaotic.

grant hutchison
2009-Jan-11, 04:55 PM
Silly question of mine--are the outer moon orbits supposed to not even vaguely line up from cycle to cycle? If so, I had no idea the "orbits" were so chaotic.They're not chaotic. The lack of closure of the orbits is because the nodes precess significantly during one orbit: the orbital plane is shifting constantly, and the moon never comes back to where it started from.

Grant Hutchison

frankuitaalst
2009-Jan-11, 05:05 PM
They're not chaotic. The lack of closure of the orbits is because the nodes precess significantly during one orbit: the orbital plane is shifting constantly, and the moon never comes back to where it started from.
Grant Hutchison
The orbits of the Jovian moons indeed show a lot of variation of their orbital parameters as function of time , especially the outer ones which seem to orbit close to the limit of stabilty . To give an idea of the variation of eccentricity and inclination :
http://www.orbitsimulator.com/cgi-bin/yabb/YaBB.pl?num=1222549877

IsaacKuo
2009-Jan-11, 06:30 PM
Thanks for the plots! This really opens my eyes up to what I'm up against.

My game map is going to be a cylindrical projection, with altitude somewhat abstracted away. On this map, the sinusoidal paths will shift leftward (or rightward) with each cycle instead of closing. Does that sound about right?

frankuitaalst
2009-Jan-11, 06:42 PM
Thanks for the plots! This really opens my eyes up to what I'm up against.

My game map is going to be a cylindrical projection, with altitude somewhat abstracted away. On this map, the sinusoidal paths will shift leftward (or rightward) with each cycle instead of closing. Does that sound about right?
I think this can be done , but mind the gaps ! (ie : going from one to another cycle ) . Depends also how long you want to run your game and the accurancy .
Another mehod is running the program Tony provided in the desired time-frame , outputting the orbital values , and reading them in your program ...

IsaacKuo
2009-Jan-11, 06:57 PM
There won't be any gaps--the sinusoidal path simply has a wavelength slightly less than 360 degrees of longitude.

I'm still wondering what the errors will be like for Tony's program. Besides simulation error, which is plainly significant (step size choice seems far more significant than it should be), there's also the unavoidable observation errors.

BTW, the ultimate product will be a board game, not a computer game. I've been writing a lot of small utility programs to help me calculate things, but it's ultimately for a board game.

IsaacKuo
2009-Jan-11, 08:05 PM
I've just thought of a weird alternative projection that might make things...well it's an interesting idea.

Instead of a point projection from the center of Jupiter, the projection is from a circular standard orbit ring with a 20,000,000km radius. The map is a torus around this circular ring. All of the relevant moons spiral around this ring in a helix path.

If you unwrap the torus map into a square, then the orbit paths are all near 45 degree ballistic paths which almost (but not quite) close on themselves. In fact, all transfer orbits with ~2km/s appear as ballistic 45degree paths.

If you look at a polar plot of inclination vs radius, then an orbit doesn't actually form a neat circle around the 20,000,000km "standard orbit" point. Instead, it will be distorted into a bean shape, where eccentricity affects its thickness and/or distortion while inclination affects its height.

I feel like this torroidal projection may be the compromise I'm looking for between precision physics and playability.

mugaliens
2009-Jan-11, 08:52 PM
None. It costs MUCH more delta-v to get to/from asteroids than it does to get to/from Jupiter's outer moons.

Of course this makes sense! Like many, I lazily fell into the "distance" trap when I should have been thinking about the differential gravimetric potentials throughout the set of Riemann manifolds adjoining them.

The only penalty, of course, is the additional mass required to support astronauts for the extended trip. If you're automating the trip (why not?), then you'll have to delve into business economics and consider the holding expense, that is, the after-tax alternative investment rate of the funds sunk into your freighters over the time differential between an asteroid run and a jovial run, to see if they're really competitive, as well as increased life-cycle cost associated with the fact that you're making less runs per year against those holding costs.

(sigh)

As usually, things aren't always as simple as calculating delta-v and being done with it...

IsaacKuo
2009-Jan-12, 03:04 AM
I'm assuming the Jovian Mineral Corps mining ships are unmanned. Besides the fact that the missions take many years, the Oberth effect maneuvers that save so much delta-v require traversing the powerful radiation zones around Jupiter.

In my original timeline, I assumed the use of Lunar rocket propellant refineries (aluminum powder/lox slurry). However, the delta-v costs for shipments from the Moon are actually even worse than the delta-v costs for shipments from outer Jovian moons.

But the kicker for me is the cost and complexity of aluminum mining on the Moon, and the general energy costs of the various refining operations. You've got all sorts of mechanics to crush/manipulate ores, and then all sorts of chemical processes involved in sifting out the desired alumina, and so on. And solar power is only available on the Moon half of the time.

Contrast this with ice mining. The JMC mining ships just need to use a solar concentrator to sublimate ice into water vapor and condense it in a cold collector. There are no chemical reactions and no significant electrical power requirements.

After the water/ice is shipped back to Earth orbit, very simple refining stations with 24/7 solar power can electrolyze it into oxygen/hydrogen propellant.

My gut feeling is that the multi-year wait for the first water/ice shipments will look good compared to the amount of time it takes to develop lunar propellant refineries. And the payoff is high performance LOX/LH2 propellant rather than mediocre Al/LOX propellant.

tony873004
2009-Jan-12, 04:24 AM
What's a good timestep to use to minimize the error? ... (Too big a timestep and you have integration errors; too small a timestep and you have roundoff errors.)
The slower the better. I doubt roundoff error will have a significant effect. The integration error from large time steps is your biggest problem. I'd try a time step of 16 seconds. Set it up before you go to bed, and set the Autopilot to automatically pause at your desired date.

16 seconds should be pleanty slow enough, but if you want to determine the maximum acceptable time step, start with a large time step, say 4096 seconds. That should only take a couple of minutes to get you 150 years into the future. Record your data on your desired date. Then begin the simulation again, cut your time step in half, go forward to the same time and date (you can use Autopilot to automatically pause the simulation for you on your desired date). Record your data. Compare to your first trial run. Keep doing this, and you should notice that your results converge upon a value when the time step is low enough.

Another way to test it is to query JPL Horizons for the orbital elements on a date far in the future. They should have data up to the year 2050, so just choose January 1, 2050. Then propogate the simulation to January 1, 2050, and compare the results. Do this for different time steps.



If I have some idea of the algorithm being used, I can perform my own error analysis.
It's an Euler-Cromer algorithm. You can see the code here: http://www.orbitsimulator.com/cgi-bin/yabb/YaBB.pl?num=1160874415/6#6

IsaacKuo
2009-Jan-12, 06:40 AM
Hmm...the code in your link is described as Euler's method, and it sure looks like plain old Euler's method. No wonder the errors are so sensitive to time step!

Using doubles, the roundoff error for each numerical calculation is at least on the order of 2E-16. Figure maybe 100 calculations per time step, for a total of 2.9E10 calculations. If errors did not grow, you'd be looking at an average error of 3.4E-12, which is plenty low enough.

However, if there's any growth to errors, then it quickly blows up. With a stable orbit, I wouldn't worry about it too much. But with chaotic orbits, small deviations exponentially blow up.

Still, I suppose the truncation errors will be essentially swamped by observation errors. If small truncation errors will chaotically blow up, surely the observation errors will chaotically blow up by far more than that anyway!

I'm surprised you don't use a Runge-Kutta algorithm. They're easy to implement in a plug-and-play "cookbook" fashion, even if you don't comprehend the theory behind them. Other fancy integration methods require some numerical analysis knowledge to properly implement, but Runge-Kutta is practically as easy and straightforward as forward Euler's method.

The big payoff is accuracy and performance. Since error is proportional to the time step to the fourth power, halving the time step improves accuracy by a factor of 16. You never have to choose excessively small time steps, and the essentially good accuracy means you can choose much larger time steps and still maintain accuracy.

The bottom line is that while each time step might take four times longer, the accuracy is so good that you can chose a time step several orders of magnitude bigger--meaning you massively improve the performance to simulate a particular duration of time.

Runge-Kutta is only worse than Euler's method if your time step calculation time is already about as sluggish as your display frame rate. For example, if you want to smoothly display 60 frames per second, then you really want each time step to only take 1/60th of a second to calculate. This can be an issue if you're modeling a massive particle system.

tony873004
2009-Jan-12, 09:07 AM
The link should have called it Euler-Cromer

...Since error is proportional to the time step to the fourth power, halving the time step improves accuracy by a factor of 16...

But the inverse is also true. Doubling the time step degrades accuracy by a factor of 16. I've also got a leapfrog method that's 2nd order, so halving the time step improves accuracy by a factor of 4, but doubling time step degrades it by a factor of 4. It was useless for all sims with a timestep higher than about 16 seconds, as the planets spiraled outward.

Plain Euler's method will also cause the planets to spiral outward. The difference between plain Euler and Euler-Cromer is the order things are done. Velocity is computed prior to position in E-C, so position is computed using the updated velocity. In regular Euler, position is computed using the old velocity, then velocity is updated. I've never formally studied this. I think the term is symplectic? If I understand it correctly, Symplectic integrators such as E-C don't add energy with each step, while non-symplectic ones such as regular Euler do. I understand that RK-4 is non-symplectic, so at high time steps things fall apart.

I wrote an RK-4 for Gravity Simulator, but never debugged it to the point of being able to release it. From my limited tests, I could take time steps twice as large as E-C before things blew up, but the code executed more than 2x slower, negating this benefit. But I was doing what you describe as "plug and play cookbook" and modifying someone else's code without understanding it, so fine-tuning it wasn't really an option.


I've played with other programs that use RK-4, and Gravity Simulator with its E-C engine, seems to run rings around them. Again, I've never studied this formally, so I'm not sure why.


Frankuitaalst, a member of this forum, wrote a Picard integrator for Gravity Simulator, which was very promising under certain circumstances. Even though it executed very slowly, you could take huge time steps. To compare it to E-C, I made a simulation of asteroid Apophis, starting in 2007, and propogating it forward until its April 2029 encounter with Earth. If I remember correctly, Picard could take 17-minute time steps, and after 22 years of simulating, the asteroid was only 200 km away from where JPL said it would be. It only took about 10 minutes to simulate the 22 years. E-C, with a time step high enough to do it in a few minutes, missed by over 100,000 km. But as I made more trial runs, lowering the timestep with each trial, the miss distance asympotically approached 200 km, same as Picard, when the time step was approaching 1 second. The problem is it took about 4 hours of computer time. But this is why I don't think the roundoff error of many iterations will amount to much. 22 years, both Earth and Apophis traveled billions of km to get to their encounter positions, and Apophis only missed by 200 km JPL's predicted close approach distance. It missed by the same distance as the Picard integrator, even though it took thousands fewer iterations to complete the journey.

But Picard needed to take large time steps to overcome the execution time. This actually presented a disadvantage in the graphics output, as entire orbits could be done in something like 10 steps, not giving me many points to plot. The other disadvantage is that a simulation with more than 20-30 objects slowed the program to the point it was unusable.

One day, I'd like to add a menu option to Gravity Simulator where the user can choose between different integrators. Picard definately has its niche, and RK-4 probably does too.

Feel free to write an RK-4 if you like. Gravity Simulator's GUIs are written in Visual Basic, but the E-C integrator is a plug-in dll written in C++. Therefore, if you want, you can write your own (I imagine the RK-4 routine would be about 100 lines of code) and plug it in.

StupendousMan
2009-Jan-12, 02:48 PM
Talk about coincidence. I've just finished writing a very simple N-body code for one of the courses I teach. It's not friendly, and has no graphical interface, but it will compute positions and velocities and place the results into a text file for later use. I include a little Perl script to compute running totals of energy and angular momentum.

The code allows the user to choose the method of integration by editing a text file -- the same input file that contains the initial masses, positions and velocities of the bodies. The current choices for methods are (quoting from the input file):



# method "E1" is Euler's method, first order,
# for both velocity and acceleration
# method "E1a" is Euler's method, first order,
# but use the new velocity to advance old position
# method "E2" is Euler's method, second order
# also known as Heun's method
# method "RK4" is fourth-order Runge-Kutta


Free free to use this code as you wish. Those who were disparaging the Euler methods can peruse the RK routine -- maybe it will help you write your own.

You can find a tar file with source code (plain ASCII C) at

http://spiff.rit.edu/richmond/temp/nbody.tar

I do not promise to provide any help with the code. Read the README file, look at the source code, and use it if it does what you want. If not, write your own (or use Tony's excellent program instead).

mugaliens
2009-Jan-12, 07:05 PM
After the water/ice is shipped back to Earth orbit, very simple refining stations with 24/7 solar power can electrolyze it into oxygen/hydrogen propellant.

Why wait? Why not use aluminized mylar solar reflectors to concentrate solar energy for both electrical and thermal requirements, separate the O2 and H2, store each, and burn a small amount on the way back, shortening your trip, and lightening your load for resulting braking maneuver?

Besides - if done right, you might wind up with useable H2 and O2 once you arrive, no processing required. And if you really think ahead, you might have just the right amount, in the right tranks, to boost your originally intended load where you need it.

- Mugs

tony873004
2009-Jan-12, 07:11 PM
...I do not promise to provide any help with the code...
I bet I can get you to bend on that :)

Thanks for the code. It looks well-documented, but I'm sure it'll take me some time to comprehend.

IsaacKuo
2009-Jan-13, 12:22 AM
Why wait? Why not use aluminized mylar solar reflectors to concentrate solar energy for both electrical and thermal requirements, separate the O2 and H2, store each, and burn a small amount on the way back, shortening your trip, and lightening your load for resulting braking maneuver?
You're right about electrolyzing water en route, but burning any amount on the way back won't shorten the trip significantly.

Instead, the basic issue is getting going in the first place. You need about 2km/s to transfer into a highly elliptical orbit, and then thrust a few hundred m/s in a deep Oberth effect maneuver to transition into Jupiter->Earth transfer orbit. With a hydrogen/lox rocket, this 2.5km/s requires a mass ratio around 1.8...so roughly half of your water needs to be electrolyzed anyway just to get started on the return journey.

So, you have two small tanks for LOX and water, and a big tank for LH2. The capacity of the water tank is about equal to the capacity of the LOX/LH2 tanks. You first fill up all three, and then burn the LOX/LH2 to go home. During the journey home, you may as well electrolyze the water tank into the LOX/LH2 tanks.

Thus, when you arrive in elliptical Earth orbit, you can deliver refined LOX/LH2. You don't deliver all of it, you keep some to make another journey back to Jupiter.

IsaacKuo
2009-Jan-24, 02:30 AM
After developing my game background further, it occurs to me that there are surely many outer moons which haven't even been discovered yet, and that these could plausibly be much smaller than the ones we've already discovered.

The moons we know about tend to be at least 2km in diameter, which makes them really big. This rules out some potentially efficient mining operations, like "swallowing" the entire moon inside steam heating chamber, or nudging the moon into a highly elliptical orbit, or hauling the entire moon back to Earth orbit.

Surely there are plenty of smaller outer moons with diameters less than 1km. What about diameters on the order of 10m?

cjameshuff
2009-Jan-24, 03:22 AM
Looks like I missed a discussion on orbital sims...



Why wait? Why not use aluminized mylar solar reflectors to concentrate solar energy for both electrical and thermal requirements, separate the O2 and H2, store each, and burn a small amount on the way back, shortening your trip, and lightening your load for resulting braking maneuver?

Water ice is easier to store...it could literally be as easy as wrapping it in foil. Hydrogen would require large, probably actively cooled cryogenic tanks, and being hydrogen, there would be leaks and diffusion losses. Also, a pinhole puncture in that big hydrogen tank would have major consequences. So it really makes sense to ship it as ice, at least on the way to the inner system.

Also, electrolyzing water into LOX/LH2 takes a lot of power and equipment. If you do it en-route, you have to apply the delta-v needed to make the trip to the photovoltaic panels and concentrator mirrors, pumps, electrolysis cells, compressors, radiators, liquefaction equipment, etc. It makes more sense to leave that stuff in a fixed orbit and just deliver larger loads of ice to it. The refining station would have the benefit of more solar power, as well, and wouldn't be dormant half the time as it returns home without a load of ice.

IsaacKuo
2009-Jan-24, 03:44 AM
The basic question then becomes--how do you ship it back at all? You may have to refine a large fraction of it anyway just to make the return journey.

I eventually figured out a way around the problem, by using a solar powered steam rocket. Because it has a much lower specific impulse than a LOX/LH2 rocket, the mass ratio is much worse--but it avoids the PV panels and cryogenic hydrogen tank and such.

To take advantage of the Oberth effect, though, you need a high power drive and a solar powered steam rocket would be very low powered out around Jupiter. I solve this problem using a novel drive system I call an "aeroramjet". The basic idea is to efficiently use ramscooped upper atmosphere to heat propellant. It's essentially a plasma stream powered rocket. It's a very novel and counterintuitive concept which I'm still developing. The bottom line, though, is that it gives us a high power steam rocket that works under some particular restricted circumstances (essentially, what an aerobrake can do, an aeroramjet can do the opposite way).

cjameshuff
2009-Jan-24, 09:31 PM
The basic question then becomes--how do you ship it back at all? You may have to refine a large fraction of it anyway just to make the return journey.

You could use another stationary refinery out near Jupiter. It would be churning away while your ship makes its trip to Earth and back, and have both a load of clean ices (water's not the only useful one) and fuel ready when it returns.

For the flyby, you could also use a tether. Spool out a bag of ice on the end of a tether while you swing by Jupiter, drop the ice in as you swing past, and accomplish essentially the same maneuver as your orbital ramjet idea, except without the need for a ramjet that operates at 40-60 km/s. A few hundred m/s would be fairly easy to achieve, either through spinning up a short tether or exploiting tidal forces across a long one. With Spectra fiber, a tether massing 5.2 tonnes could tie two 100 tonne masses together with a relative velocity of 500 m/s. (I haven't tried working out the material requirements of a lopsided sling yet)

Another variation, perhaps more similar to the aeroramjet in feasibility...use differential drag to spin the tether up as it goes through the upper atmosphere. Have it "tumble", with each end alternately dipping further into the atmosphere than the other and converting forward motion into angular momentum. Forward velocity subtracted from one adds twice as much to their relative velocity as it removes from their total velocity, effectively transferring momentum from one to the other. Maybe use something like paracones to increase drag (and improve the differential between the ship and the mass being dumped) at higher altitudes so you don't just vaporize your tether.

IsaacKuo
2009-Jan-24, 10:13 PM
The main delta-v costs aren't during the Jupiter-Earth transfer--that's only 650m/s thanks to the Oberth effect. The main delta-v costs are in getting to/from the moon. Even with a favorably elliptical orbit, the delta-v costs may be 1.3km/s. It's pretty unfavorable to refine fuel in Jupiter grazing orbit when it costs 1.3km/s to get it to the moon and another 1.3km/s to get it (along with the ice/ore) back.

It makes far more sense to place this refinery in orbit near the moon. The same amount of solar energy is available either way. These moons are several kilometers in diameter, so there's plenty of work for the refinery to do before being transfered to another moon.

As for the tether idea--the basic problem is low exhaust velocity. A few hundred m/s should be easy to achieve, but it means sacrificing a large amount of mass. For example, if we assume a tip speed of 650m/s, you need to throw away as much mass as your loaded ship--a mass fraction of 2:1. In contrast, an inefficient aeroramjet may offer an effective exhaust velocity of 10km/s, so the mass fraction is only 1.07.

A tether might be an interesting method of launching from the moon. The performance is poor compared to a solar steam rocket, but it's fully reusable. I like the idea of using a tether as "exhaust" for a rocket. The tether starts off coiled up inside a high pressure tank. One end of the tether sticks out from the tank and is tied to the moon. Upon launch, the tether shoots out the end of the tank due to gas pressure. This works just like a toy water rocket, except the exhaust is a solid "string" instead of a stream of water. Ultimately, the tether leaves the tank altogether. This gives a lot of initial impulse for a low amount of energy, thanks to the high reaction mass and low exhaust velocity. Normally, this type of rocket is not a good idea because it consumes a large mass of propellant. But not here! The propellant is a "string" tied to the moon, so it can be reused.

The differential drag idea doesn't work, btw. Drag on one end of the tether only adds to the forward velocity of the other end if the tether's mass dominates over the payload. Think of the tether as a (stiff) lever. When you apply a force to the tip, it will rotate around a point near the center of mass. If this center of mass is near the center of the tether, than the other side of the lever will go in the opposite direction. If this center of mass is near the other end of the tether, it will not.

cjameshuff
2009-Jan-24, 11:44 PM
It makes far more sense to place this refinery in orbit near the moon. The same amount of solar energy is available either way. These moons are several kilometers in diameter, so there's plenty of work for the refinery to do before being transfered to another moon.

I think you misunderstood something. By "near Jupiter", I meant just this, on the moon of interest or in an orbit easily accessible from it. Not in a Jupiter-grazing orbit. "Near" in solar system terms, not Jupiter system terms.



As for the tether idea--the basic problem is low exhaust velocity. A few hundred m/s should be easy to achieve, but it means sacrificing a large amount of mass. For example, if we assume a tip speed of 650m/s, you need to throw away as much mass as your loaded ship--a mass fraction of 2:1. In contrast, an inefficient aeroramjet may offer an effective exhaust velocity of 10km/s, so the mass fraction is only 1.07.

The tether would be far, far easier to construct than a 60 km/s ramjet. And I don't think your mass fraction will be anywhere near that good...I suspect you'll be combining propulsion with cooling, and be ejecting very large quantities of steam at rather low temperatures and velocities.

Also, if the counterweight retains enough velocity from the Jupiter pass, a small amount of delta-v (from a standard rocket, perhaps combined with your aeroramjet idea) might move it away from a Jupiter-grazing orbit. An ion drive could boost it back up to a high-apoapsis elliptical orbit and adjust its orbital phase for rendezvous with the next vehicle, salvaging a large chunk of the delta-v you applied to that mass initially.



A tether might be an interesting method of launching from the moon. The performance is poor compared to a solar steam rocket, but it's fully reusable. I like the idea of using a tether as "exhaust" for a rocket. The tether starts off coiled up inside a high pressure tank. One end of the tether sticks out from the tank and is tied to the moon. Upon launch, the tether shoots out the end of the tank due to gas pressure. This works just like a toy water rocket, except the exhaust is a solid "string" instead of a stream of water. Ultimately, the tether leaves the tank altogether. This gives a lot of initial impulse for a low amount of energy, thanks to the high reaction mass and low exhaust velocity. Normally, this type of rocket is not a good idea because it consumes a large mass of propellant. But not here! The propellant is a "string" tied to the moon, so it can be reused.

This seems like it'd cause a lot of wear and tear on the "tether", have problems with unspooling the tether rapidly enough, take up a lot of vehicle mass, and have extremely poor performance. You're not using it as a tether at all, just as weird-shaped reaction mass, and on an icy moon, you've got no shortage of reaction mass. The sling really seems like a better way to go. Anchor a hub into your favorite moon or asteroid, use an induction motor to keep it spun up, pump ballast into a counterweight as payloads descend toward the end and jettison when the payload is released.



The differential drag idea doesn't work, btw. Drag on one end of the tether only adds to the forward velocity of the other end if the tether's mass dominates over the payload. Think of the tether as a (stiff) lever. When you apply a force to the tip, it will rotate around a point near the center of mass. If this center of mass is near the center of the tether, than the other side of the lever will go in the opposite direction. If this center of mass is near the other end of the tether, it will not.

The tether I was considering was symmetrical, equal masses on each end, and so the center of mass was indeed near the center. That is a low mass fraction for the delta-v if the counterweight is single-use, but it is relatively easy to do, the main cost is in accelerating that counterweight from the moon, and I don't expect anything but a conventional rocket to be much better.

IsaacKuo
2009-Jan-25, 12:06 AM
An aeroramjet would be extremely simple to construct. It's simply a 15 degree half angle intake cone based roughly on the Galileo probe, and a bell nozzle, along with a valve for the propellant supply (heating of the water tank will be enough to produce the required injection pressure).

An "aeroramjet" is fundamentally different from a traditional ramjet, in that there is no combustion. Combustion is problematic for many reasons--the main one being that you need molecular level mixing. Molecules which don't physically bump into each other can't react with each other. This is why combustion takes time. An aeroramjet doesn't require molecular level mixing, it just uses bulk kinetic energy aerodynamic interaction to accelerate/shock/heat the propellant.

Anyway, the tether idea won't work if you have equal masses on each end, unless the mass of the tether dominates over the mass of the end weights. The tether only rotates near the center if the mass is mostly in the center. If the mass is mostly on the ends, then "near" the center actually becomes close to the tip.

If the mass is mostly concentrated on the tips, then a rearward impulse on one of them will cause the average velocity to be shifted rearward by half of the impulse velocity, and it will also cause the tips to revolve around each other with an "orbital speed" of the other half of the impulse velocity. At no point will either of the masses have any "forward" velocity. Instead, each mass's velocity will cycle from zero velocity to 100% rearward velocity and back.

In order for your idea to work, you need the tether to have a mass that utterly dominates over the tip masses. Ideally, the mass is concentrated in the center of the tether, so it has near zero moment of inertia. This mass will reduce the amount by which the average velocity is shifted rearward.

For example, suppose the tips each have 1kg, and the center has a mass of 2kg. Then a rearward impulse of 4kgm/s on one of the tip masses will cause the average velocity to be shifted rearward by only 1m/s. However, the initial rearward velocity of the inner tip mass is 4m/s. This provides a rotational inertia of 3kgm^2/s (assuming a tether length of 2m). Assuming the mass and countermass even things out, then eventually the tip masses will each have an orbital speed of 1.5m/s. This is added or subtracted to the average velocity of 1m/s, so the tip speed varies from 5m/s in the forward direction to 2.5m/s in the rearward direction.

IsaacKuo
2009-Jan-25, 12:16 AM
Oh--about using an ion drive to boost the altitude of a space tether. Given Jupiter's powerful magnetic field and large amounts of magnetosphere plasma, I would hope that it may be possible to use electrodynamic force to directly accelerate the tether rather than spending ion rocket fuel (ion rocket fuel is expensive; trading expensive ion rocket fuel for cheap water would be a bad trade). However, I do not know how to calculate the effectiveness of electrodynamic tether propulsion around Jupiter.

Still, any sort of electric propulsion will suffer from the general cost of electrical power around Jupiter. A solar steam rocket, chemical rocket, or aeroramjet gets a lot of energy from the Oberth effect (sacrificing mass into Jupiter's deep gravity well). Any sort of electric propulsion will have a tough time competing with that.

EDG
2009-Jan-25, 04:00 AM
I usually use this for reference for planetary facts:
http://nssdc.gsfc.nasa.gov/planetary/planetfact.html

I note that it hasn't been updated for about 18 months though - is there anything more recent in this sort of format that anyone can point me to?

cjameshuff
2009-Jan-25, 10:30 PM
An aeroramjet would be extremely simple to construct. It's simply a 15 degree half angle intake cone based roughly on the Galileo probe, and a bell nozzle, along with a valve for the propellant supply (heating of the water tank will be enough to produce the required injection pressure).

It is simple in concept, I expect implementation to be quite a bit more complex than you describe. You're not going to be able to just let radiated heat from the shockwave warm the tank, water in the tank will slosh back under acceleration, leaving portions cooled only by contact with relatively slow-moving steam. With the need to heat the whole tank, you won't be able to start thrust as quickly or as tightly control the balance between thrust and surface cooling. Also, your version requires that the entire water tank be strong enough to withstand the pressure of the steam.

You'll need a water pump, heat exchanger surfaces filled with small high pressure steam channels, and plumbing to gather the steam and deliver it to thrusters and zero-thrust discharge ports...too much or too little thrust is a particularly bad thing when doing this sort of maneuver. Those heat exchangers will have to be carefully designed to avoid any fluid flow effects that could allow hotspots to form, and you'll probably need finer control of the flow to individual portions of the ramjet and skin to regulate temperature.

I would try for a cylindrical or linear Busemann biplane, eliminating most of the wave drag, with heat exchangers facing the internal shockwave and steam rocket ports in the back. You might get away with passive thermal protection on the exterior, if you can get sufficient cargo capacity and stay close enough to an ideal Busemann biplane shape.

IsaacKuo
2009-Jan-25, 10:55 PM
The outer shape of the hull would indeed be a cylinder (along with some wing-like fins for aeroassist and aerobraking maneuvers). The intake cone is inverted, so it funnels air into a "throat". I've done some calculations on the design so far, and the intake is roughly 98% efficient. There's no need for heat exchangers--the propellant is simply injected into the airstream just behind the throat. Even if there's no mixing, radiation/conduction is sufficient for heat transfer. No physical barrier between the propellant and the airstream is required.

Behind the throat is a cylindrical "mixing chamber", which is not really required but the volume around this "chamber" is useful for all of your vehicle's hardware and tanks. Behind that is a water-cooled nozzle.

My baseline design doesn't actively cool the intake cone, since it's roughly based on Galileo's heat shield (which was simply ablative). The rear nozzle is actively cooled, though, because rocket nozzles are commonly cooled this way.

The cross section is somewhat like a Busemann biplane, but with an extended "straight" section in the middle to improve internal volume.

IsaacKuo
2009-Jan-25, 11:13 PM
By the way, I came up with an interesting tether proposal I call "skyloop". I don't know if this idea has already been discussed, but it's so simple I imagine it must have been invented already.

It's similar to skyhook, but it doesn't require very strong tether materials and can provide Earth escape velocity. Instead of a rotating tether, skyloop is a simple steel loop. It only rotates fast enough to maintain a circular shape.

The payload is boosted straight vertically up, and it uses a hook to latch onto the skyloop. The hook features sacrificial bearing fluid to survive hypersonic sliding of the loop past the hook.

In the reference frame of the skyloop, the payload enters the "bottom" at 8km/s and leaves the "top" at maybe 7km/s (some speed is lost due to friction).

In the reference frame of Earth, the payload enters the "bottom" at 0km/s and leaves the "top" at 15km/s. This is actually well above Earth escape velocity, so you'll want to unlatch earlier and/or apply braking force to reduce velocity (assuming your final destination is Earth orbit).

Interestingly, the rotation of the skyloop is not directly related to the functioning of the launch system. It's only needed to maintain the loop's circular shape.

Like Skyhook, skyloop needs to be "recharged" periodically. One method would be to latch a solar electric satellite onto the skyloop.