Are the last two fields the min and max transit time in days?

It's not working for me. Is it Java?

It works for me the first time I hit "Plot C3". If I change some parameters and hit that button again it doesn't work right (doesn't update the image). I'm using Chrome on Windows 7.

I've made several attempts but haven't been able to get it to work.

I was trying this on iOS and it didn't work, which isn't a surprise. I'll try it with a real computer.

Quote from: Hop_David on 01/18/2014 05:17 pmI've made several attempts but haven't been able to get it to work.Which OS/Browser are you using? Which steps did you take and/or where/how did it fail? (to be sure; you had valid input data in all fields?)

Quote from: kfsorensen on 06/09/2011 02:13 pmI've just been playing around with the trajectories and see a few interesting things--when you look "down" on them as we're used to doing, they look wrong. Very non-Hohmann transfer. But when you look at them obliquely you can see why--they always "want" to arrive when Ceres is crossing its "line-of-nodes" which is where its orbital plane intersects with the Earth's orbital plane (the ecliptic).The earth at departure, Ceres at Arrival, and the sun form the corners of a Lambert space triangle. The transfer ellipse must be coplanar with this triangle.A Hohmann transfer traverses 180 degrees. Since Ceres' orbit isn't coplanar with the earth, this forces the transfer orbit to be at right angles to both earth's orbit and Ceres' orbit.This geometry that forces a polar orbit is what I believe accounts for the diagonal streak through pork chop plots.I tested this notion by clicking on the diagonal on one of your pork chop plots and looking at the trajectory:It does indeed look like the departure and destination are 180 degrees from one another which forces a polar orbit at 90 degrees to both departure and destination orbit.I believe it's much better to depart on a Hohmann coplanar with earth's orbit. Then at the line of nodes, do a plane change burn and continue onto the destination:I like to call this a folded Hohmann transfer. Depending on where the line of nodes folds the earth to Ceres Hohmann, plane change can range from 6.7 km/sec to 2.4 km/sec.The 6.7 km/sec plane change is at perihelion of the Hohmann. This is the 10.5 degree plane change between two 36 km/sec vectors. But the perihelion is at earth departure. So V infinity would be the difference between a 30 and 36 km/sec vectors at 10.5 degrees to each. You would also enjoy an Oberth help if you're launching from LEO. So there is a benefit if your launch is at the line of nodes.However, I believe your application exaggerates the benefits of launching at the line of nodes since it doesn't allow for midcourse plane changes.

I've just been playing around with the trajectories and see a few interesting things--when you look "down" on them as we're used to doing, they look wrong. Very non-Hohmann transfer. But when you look at them obliquely you can see why--they always "want" to arrive when Ceres is crossing its "line-of-nodes" which is where its orbital plane intersects with the Earth's orbital plane (the ecliptic).

I moved my mouse about until hovering over approximate Hohmann departure and arrival dates: March 12 2016 and November 27 2016. As expected, this was in the middle of a dark diagonal stripe. Arrival velocity was given as 20635m/s. As expected, the chart seems to say steer clear of Hohmann windows.

I've made several attempts but haven't been able to get it to work.I have a general complaint against apps based on Lambert iterations. For a Hohmann orbit the departure and arrival points of a Lambert space triangle differ by 180º. If inclination of destination planet isn't zero, this forces the heliocentric transfer orbit to be polar. This transfer orbit is at 90º to earth's orbit and usualy around 90º to the destination planet's orbit.A 90 degree plane change is huge. So usually pork chop apps like this discourage Hohmann transfers.The 90 degree plane change can be largely mitigated by a midcourse burn or a broken plane transfer. I wish online pork chop apps would have this caveat. I talk about this more at Deboning the Porkchop Plot.

If I understand you correctly, the lamberts method does not handle the Hohmann edge-case, however the areas outside the black stripes are still correct? Then I should have a notice of this limitation.

However, does it matter, at least in case of earth->mars? I have a question for you; would the total delta-v requirement for your proposed 'ideal' trajectory be less than the alternative trajectories around the stripe? 6.7 to 2.4 km/s plane change sounds a bit expensive?Looking at NASAs MAVEN, they seem to have followed a trajectory given by solving lamberts problem, rather than a Hohmann transfer.

What is the advantage of your proposal, to also consider Hohmann transfers?

I wish online pork chop apps would have this caveat. I talk about this more at Deboning the Porkchop Plot.

The app is correct. It's just that a two burn ballistic trajectory often is far from the least delta V path. If the line of nodes is distant from launch, 3 burns (Departure burn, mid course plane change, arrival burn) can give a path with a substantially lower delta V budget. See this broken plane transfer pdf.

The virtue of a Hohmann is that the transfer orbit is tangent to both departure and destination orbits. With parallel velocity vectors, no direction change is needed only speed change.Mars' orbit is noticeably elliptical. So a transfer orbit tangent to both earth and Mars orbit sometimes differs from an 180 degree Hohmann from one circular orbit to another.

From the Spaceflight 101 Maven Mission Profile here is a pic of the Maven path:Notice the transfer orbit is tangent to departure and destination orbits. Little or no delta V is needed for direction change, only speed change.Also the launch window for this tangent orbit was pretty close to Mars. ascending node: 50º. Earth crosses Mars' ascending node in early to mid November.

Quote from: malu5531 on 01/19/2014 01:05 amWhat is the advantage of your proposal, to also consider Hohmann transfers?An 8 month Hohmann transfer is only an approximation based on the simplifying assumption of a circular Mars orbit. Since Mars orbit is an ellipse, tangent transfer orbit can be shorter or longer than 8 months. The transfer orbit can be more or less than 180 degrees, but in that neighborhood. The advantage of tangent transfer orbits is less delta V.

I guess in general it's important to make sure arrival velocity is tangential to the destination orbit?

I'm about 5 years late to the party here, but I just made a Porkchopper tool on Flight Club. It includes most basic functionality. Does the maths in the client so should be pretty easy to use and responsive tooTry running some plots first with the granularity set to a high number (perhaps 7 or 14 days). Then when you get a feel for the dates and travel times you're interested in, refine those fields and lower the granularity down to whatever you want. That way, you don't spend ages waiting for your browser to solve a bunch of redundant Lambert iterationshttps://flightclub.io/porkchopper

the plotting program I used to use has gone awol

Quote from: waveney on 05/16/2024 08:09 pmthe plotting program I used to use has gone awolIf you're referring to EasyPorkchop written by Juan Luis Gonzalo at UPM, it's still available (for now) on Archive.org.https://web.archive.org/web/20240115183644/http://sdg.aero.upm.es/index.php/online-apps/porkchop-plotYou can also download a local copy, which doesn't rely on any website remaining available. I would highly recommend doing this. I have also attached a backup copy to this post, as it's licensed GPL v3.Locally runnable copy available here: https://web.archive.org/web/20240115183644/http://sdg.aero.upm.es/ONLINEAPPS/Lambert/SDG_EasyPorkchop_1.0.0.zip

I think I found out why the porkchop simulators limit the deltaV range.There's something oddly wrong when you go to large deltavs.Here's what I changed in the code to get higher deltaVs. I get an intermediate high deltaV departure window that at 20km/sec claims 10 days... doesn't seem right.here's the code for a deltaV range of 10km/sec: var levelsStep = [ 0, 1.0, 2.0 , 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0, 10.0 ] // Values for the contour levels , colors = [ "#4ba7fc", "#3d93ff", "#137bff", "#13ff9b", "#00e785", "#00e01f", "#42c700", "#c76300", "#c71700", "#a40000" ] // Colors for the contour levels , ndim = 300 // Grid size in departure time , mdim = 300 // Grid size in time of flight , DVrange = 10; // Maximum Delta-v range [km/s]

Quote from: InterestedEngineer on 05/18/2024 11:02 pmI think I found out why the porkchop simulators limit the deltaV range.There's something oddly wrong when you go to large deltavs.Here's what I changed in the code to get higher deltaVs. I get an intermediate high deltaV departure window that at 20km/sec claims 10 days... doesn't seem right.here's the code for a deltaV range of 10km/sec: var levelsStep = [ 0, 1.0, 2.0 , 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0, 10.0 ] // Values for the contour levels , colors = [ "#4ba7fc", "#3d93ff", "#137bff", "#13ff9b", "#00e785", "#00e01f", "#42c700", "#c76300", "#c71700", "#a40000" ] // Colors for the contour levels , ndim = 300 // Grid size in departure time , mdim = 300 // Grid size in time of flight , DVrange = 10; // Maximum Delta-v range [km/s]There's... a lot of limitations in Easy Porkchop. The main one is that the accuracy is terrible, thanks to a limited number of refinement iterations. But even just updating it to modern Javascript and doing some minor refactoring can lead to large speedups.And yes, for efficiency Easy Porkchop will "prune" any solutions that are >10 km/s (v_{infinity}) above the 'optimal' solution, as found by a sparse 50x50 grid search (see the Javascript function GlobalDVminEstimator in the file LambertSDG-1.0.0.js).

Yes, the Easy Porkchop errors get larger the further you get from the "peak" of the porkchop (which is normally not a big concern). This is discussed in the accompanying paper.

Quote from: Twark_Main on 05/18/2024 11:30 pmQuote from: InterestedEngineer on 05/18/2024 11:02 pmI think I found out why the porkchop simulators limit the deltaV range.There's something oddly wrong when you go to large deltavs.Here's what I changed in the code to get higher deltaVs. I get an intermediate high deltaV departure window that at 20km/sec claims 10 days... doesn't seem right.here's the code for a deltaV range of 10km/sec: var levelsStep = [ 0, 1.0, 2.0 , 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0, 10.0 ] // Values for the contour levels , colors = [ "#4ba7fc", "#3d93ff", "#137bff", "#13ff9b", "#00e785", "#00e01f", "#42c700", "#c76300", "#c71700", "#a40000" ] // Colors for the contour levels , ndim = 300 // Grid size in departure time , mdim = 300 // Grid size in time of flight , DVrange = 10; // Maximum Delta-v range [km/s]There's... a lot of limitations in Easy Porkchop. The main one is that the accuracy is terrible, thanks to a limited number of refinement iterations. But even just updating it to modern Javascript and doing some minor refactoring can lead to large speedups.And yes, for efficiency Easy Porkchop will "prune" any solutions that are >10 km/s (v_{infinity}) above the 'optimal' solution, as found by a sparse 50x50 grid search (see the Javascript function GlobalDVminEstimator in the file LambertSDG-1.0.0.js).I'm pretty good at Javascript. If I can get a "source of truth", I'd be happy to spend some time hacking this up and putting it on Github.It needs some unit tests.

Patched conics is when you switch between central bodies as you move between spheres of influence, but that's not how porkchop plots are typically generated. Do you mean "conic sections?"EasyPork does its (admittedly rough) convergence in three iterations, but other algorithms typically take 8-15 iterations to achieve machine level precision. Let me see if I can dig up some citations.Fun fact, but all Lambert Solvers are 2D! The 3D ones just flatten the three points (origin/Sun/destination) onto a 2D plane first.

The way I understand things, generally a porkchop plotter is used to generate a "Ten Thousand Foot" overview of transit windows, and then for the actual planning you'll use a more accurate numerical orbit propagation and optimization tool like GMAT. So essentially the plotter only need to get you within a couple days of the optimal window, at which point other software tools take over from there.I'm having a bit of trouble understanding fully, but if you care to PM your code I'd be happy to give up any hints or pointers I can muster (in strict confidence of course).Dug up some citations, as mentioned earlier.https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=27636d0fcdd957b13d2c566ef111aa34a5b3d81bhttps://indico.esa.int/event/111/contributions/321/attachments/579/624/Lambert_ICATT.pdfhttps://arxiv.org/abs/1403.2705

// radii[] are a list of radiuses, typically fixed delta but don't need to be const tangential = oldTangentialVelocity * oldRadius / radii[\i] const magnitudeSquared = oldC3 + 2 * mu / radii[\i] const radialSquared = magnitudeSquared - Math.pow(tangential,2) radial = Math.sqrt(radial) const elapsedTime = Math.abs((oldRadius - radii[\i]) / ((oldRadialVelocity + radial) / 2 ))

Quote from: Twark_Main on 05/22/2024 06:38 amThe way I understand things, generally a porkchop plotter is used to generate a "Ten Thousand Foot" overview of transit windows, and then for the actual planning you'll use a more accurate numerical orbit propagation and optimization tool like GMAT. So essentially the plotter only need to get you within a couple days of the optimal window, at which point other software tools take over from there.I'm having a bit of trouble understanding fully, but if you care to PM your code I'd be happy to give up any hints or pointers I can muster (in strict confidence of course).Dug up some citations, as mentioned earlier.https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=27636d0fcdd957b13d2c566ef111aa34a5b3d81bhttps://indico.esa.int/event/111/contributions/321/attachments/579/624/Lambert_ICATT.pdfhttps://arxiv.org/abs/1403.2705It is really hard to find a good description of Lambert's problem out there as actually used in orbital rendezvous.My impression is that most are trying to solve the Lambert Targeting Problem (LTP). i.e. given a fixed start time, a fixed end time, the angle between a start and end between two orbital bodies is known by their fixed orbits, the transfer time is fixed (because start/end are fixed) so calculate the deltaV required to make a rendezvous happen.

As I work through the problem I'm finding that if I completely stay in polar coordinates the targeting problem becomes trivial math.

I might be confused by the LTP math, but it appears that they didn't stay in polar coordinates which IMHO makes things far more complicated.

(That, and having the deltaV be the dependent variable instead of the independent variable).

@RadicalModerate helped me out with figuring out that all deltaV should be tangential is horribly incorrect for hyperbolic trajectories. Something else a simple Pork Chop plot can't do right.

The real answer for minimizing transit times while minimizing deltaV is...

Quote from: InterestedEngineer on 05/28/2024 03:38 am@RadicalModerate helped me out with figuring out that all deltaV should be tangential is horribly incorrect for hyperbolic trajectories. Something else a simple Pork Chop plot can't do right.I'm not aware of a Porkchop Plotter which makes that (surprising to me) assumption? Easy Porkchop certainly doesn't.Quote from: InterestedEngineer on 05/28/2024 03:38 amThe real answer for minimizing transit times while minimizing deltaV is......is to plot transit time vs delta-v (eg using a conventional plotter), and then feed that tradeoff curve forward into your mission architecture planning.There won't be just one universal solution that simultaneously minimizes both time and delta-v, because to reach a unique solution you effectively need some sort of "conversion ratio" between time and delta-v, and that tradeoff is going to be mission-specific.

The use cases I have are so bad for a pork chop plotter

1. I have 7km/sec of deltaV. Tell me how fast I can get to Mars. ...2. I want to get to Mars in 30 days. How much deltaV do I need?

3. I want to run a SEP craft with a certain mass flow rate and thrust to Mars. How long will it take? Pork chop plotters can't do continuous acceleration.

I don't want a pork chop plotter. I want a... mission planning tool that's almost a pork chop plotter?

Quote from: InterestedEngineer on 06/01/2024 12:27 am1. I have 7km/sec of deltaV. Tell me how fast I can get to Mars. ...2. I want to get to Mars in 30 days. How much deltaV do I need? Both of these seem solvable like I described earlier: a simple line graph with a single curve plotting delta-v vs transit time.However, for a dumb computer, you will still need to tell it the approximate start date and travel time of your journey, so it knows which conjunction (or even multi-revolution solution) you want to analyze. The easiest way to do that would be.... show the user a Porkchop Plot, and have them click on a point.Otherwise the computer will be "clever" and spit out the perfectly correct answer...... that's only valid for the 2177 Earth-Mars conjunction.

Quote from: InterestedEngineer on 06/01/2024 12:27 am3. I want to run a SEP craft with a certain mass flow rate and thrust to Mars. How long will it take? Pork chop plotters can't do continuous acceleration.Totally different bag of worms. Quote from: InterestedEngineer on 06/01/2024 12:27 amI don't want a pork chop plotter. I want a... mission planning tool that's almost a pork chop plotter?For the first two, would the graph like I described help?For the last one you'll need GMAT. More importantly, you need the custom non-public scripts that are used with GMAT for low-thrust optimization.

Quote from: Twark_Main on 06/01/2024 12:48 amQuote from: InterestedEngineer on 06/01/2024 12:27 am1. I have 7km/sec of deltaV. Tell me how fast I can get to Mars. ...2. I want to get to Mars in 30 days. How much deltaV do I need? Both of these seem solvable like I described earlier: a simple line graph with a single curve plotting delta-v vs transit time.However, for a dumb computer, you will still need to tell it the approximate start date and travel time of your journey, so it knows which conjunction (or even multi-revolution solution) you want to analyze. The easiest way to do that would be.... show the user a Porkchop Plot, and have them click on a point.Otherwise the computer will be "clever" and spit out the perfectly correct answer...... that's only valid for the 2177 Earth-Mars conjunction. Idealized is good enough. It is irrelevant whether it's +/- a couple of days or a 0.5 km/sec.

And Porkchops are terrible at hyperbolic trajectories. I've never seen one do one correctly.

They also don't spit out the vector for the deltaV. I can't even tell if they've optimized tangential and radial components.

Yes, but making the graph is the problem. At this point I'm far enough along I'll just make my own graphs.

Multi-variate optimization might be a bit of a hassle but it's doable, it's what neural net learning does all day long.

[...] I want a... mission planning tool [...]

[snip](My own interest is in trajectories with departure burns, arrival burns, and mid-course plane-change burns. Porkchop style tools don't seem to support that.)

Quote from: InterestedEngineer on 06/01/2024 12:27 am[...] I want a... mission planning tool [...]Still there are some open source alternatives. GMAT for example is available under the Apache License. https://opensource.gsfc.nasa.gov/projects/GMAT/

NSI standard C++ using an Object Oriented methodology,

Quote from: InterestedEngineer on 06/01/2024 01:24 amAnd Porkchops are terrible at hyperbolic trajectories. I've never seen one do one correctly.Which ones?

It's odd that this bug would exist, since the underlying Lambert solver algorithms I've seen are perfectly capable of handling hyperbolic trajectories.

Quote from: InterestedEngineer on 06/01/2024 01:24 amThey also don't spit out the vector for the deltaV. I can't even tell if they've optimized tangential and radial components.Do you want the vector for the delta-v (ie the heliocentric spacecraft velocity vector minus the heliocentric Earth velocity vector), or do you just want the heliocentric spacecraft velocity vector?It would be pretty trivial to make the Easy Porkchop algorithm spit out either one. Obviously it has to find them to solve the problem.

Quote from: InterestedEngineer on 06/01/2024 01:24 amYes, but making the graph is the problem. At this point I'm far enough along I'll just make my own graphs.I look forward to years and years of correcting people after they got fooled by recycled copies of your "idealized" (ie wrong) graphs.

I'm currently working on making Easy Porkchop less hilariously wrong for high delta-v trajectories. When I have something that won't be absurdly wrong, I might work on graphs.

Quote from: InterestedEngineer on 06/01/2024 01:24 amMulti-variate optimization might be a bit of a hassle but it's doable, it's what neural net learning does all day long.Very funny!

Quote from: sdsds on 06/01/2024 01:34 amQuote from: InterestedEngineer on 06/01/2024 12:27 am[...] I want a... mission planning tool [...]Still there are some open source alternatives. GMAT for example is available under the Apache License. https://opensource.gsfc.nasa.gov/projects/GMAT/ from README.txtQuoteNSI standard C++ using an Object Oriented methodology,Oh dear, mallocs in the middle of computation loops. Might as well just use a scripting language if one didn't care about performance.2 decades of C++. Still hate it. One of the languages where O(nlogn) can be easily turned into O(N^2) mallocs if you are not insanely careful. which most aren't.

Quote from: Twark_Main on 06/01/2024 01:34 amQuote from: InterestedEngineer on 06/01/2024 01:24 amAnd Porkchops are terrible at hyperbolic trajectories. I've never seen one do one correctly.Which ones?all the ones in this thread. The JPL will intentionally not let you input high enough deltaVs to go hyperbolic. Which is probably a way of covering up a bug.

Quote from: Twark_Main on 06/01/2024 01:34 amIt's odd that this bug would exist, since the underlying Lambert solver algorithms I've seen are perfectly capable of handling hyperbolic trajectories.I think you said they have accuracy problems.

There's also a bunch of corner cases I can see in the code for it. Which means probably not tested very well, esp. since stuff like the JPL Pork Chop plotter won't let you test it in the first place.

Quote from: Twark_Main on 06/01/2024 01:34 amQuote from: InterestedEngineer on 06/01/2024 01:24 amThey also don't spit out the vector for the deltaV. I can't even tell if they've optimized tangential and radial components.Do you want the vector for the delta-v (ie the heliocentric spacecraft velocity vector minus the heliocentric Earth velocity vector), or do you just want the heliocentric spacecraft velocity vector?It would be pretty trivial to make the Easy Porkchop algorithm spit out either one. Obviously it has to find them to solve the problem.Yes. I want the standard patched conics solutions.

[skip a bit, Brother...]Quote from: Twark_Main on 06/01/2024 01:34 amQuote from: InterestedEngineer on 06/01/2024 01:24 amMulti-variate optimization might be a bit of a hassle but it's doable, it's what neural net learning does all day long.Very funny!Seriously that is what neural net learning is fundamentally.

Is there a scenario where it uses less fuel to do a plane change separately instead of combining it with the departure & arrival burns? Of course we all know about the bi-elliptic transfer, but is there a less extreme case you're thinking of?

Heh. I can understand tense SLS threads, but not tense orbital mechanics threads!

QuoteYou're familiar with the Lambert space triangle?Yes. You mentioned "Orbital Mechanics" by Prussing and Conway a few pages ago. I am one of Professor Conway's graduate students. I've been reading this message board for years but I never found anything that I felt I could contribute to. I'm happy to see an orbital mechanics thread!You are right that it is (usually) better to have a mid course maneuver. I say usually because sometimes it turns out from an operational perspective that it's cheaper in dollars to spend the extra fuel than it is to bring in the staff for an additional burn.The way I would do this numerically:First, choose the launch date. That gives you the position and velocity of the Earth on the date of launch. Second, choose a total flight time T_{flight}. That gives you the position and velocity of Mars.Second, choose a magnitude and direction (two angles) of the launch v_{infty}. You do it this way because you can bound the magnitude without having to impose an explicit constraint. That's an additional three variables. Add this vector to Earth's velocity to get the initial velocity of the spacecraft.Third, choose a "burn index" eta. This is scaling factor that varies in [0,1]. For practical purposes let's let it vary in [0.1,0.9]. Propagate the spacecraft forward in time from the date of launch to time t=eta*T_{flight}. For this you could use the "Universal Kepler Solver" on page 36 of Prussing and Conway. It's not great as it doesn't handle orbits with eccentricity 1, so if you're interested there is a better one in Battin's "Mathematics and Methods of Astrodynamics." You have now arrived at the point where the mid course burn will occur.Fourth, solve Lambert's problem to go from the burn point to the location of Mars in time (1-eta)*T_{flight}. Then calculate your braking burn (rendezvous, orbit insertion, aerobraking, whatever) just as you did before.This becomes a six variable problem. You control the launch window by putting bounds on the decision variables, most importantly T_{launch} and T_{flight}. I would use differential evolution or particle swarm to solve this. You could try using Excel's solver too. I think it could handle this problem because it should be unimodal (only one local minimum). I have not verified that though.The solver will find that the burn index should appear at the node point, assuming you've allowed a long enough T_{flight}. But if you insist on a very short transfer, it will place the burn earlier, and if you insist on a long transfer, it might go out to a high aphelion and do the burn there, or figure out for itself that it needs to do a multi-rev orbit. Very flexible.All that said, I like what you are doing. You're an artist by trade, right? One of the difficult things about the way engineers do orbital mechanics is that it's very difficult to explain to the general public. But your work, from what I see from your website, is a lot easier to present as a teaching tool. Every year we have an engineering open house and I think about having a booth, but I can't figure out how to explain what I do to kids and so I never do it.I will confess that I haven't checked your math yet. Can you add true anomaly to your chart? Or better yet x,y,z coordinates of the spacecraft and the planets so that we can check the endpoints.Also, do you have access to AIAA journals? If not I could go hunting for you and see if anyone has tried to do this before.

You're familiar with the Lambert space triangle?

Quote from: Twark_Main on 06/01/2024 07:04 pmIs there a scenario where it uses less fuel to do a plane change separately instead of combining it with the departure & arrival burns? Of course we all know about the bi-elliptic transfer, but is there a less extreme case you're thinking of?Selecting two posts from a very old thread.Quote from: Chris Bergin on 03/27/2011 12:17 amHeh. I can understand tense SLS threads, but not tense orbital mechanics threads! Quote from: jenglan3 on 03/27/2011 02:18 pmQuoteYou're familiar with the Lambert space triangle?Yes. You mentioned "Orbital Mechanics" by Prussing and Conway a few pages ago. I am one of Professor Conway's graduate students. I've been reading this message board for years but I never found anything that I felt I could contribute to. I'm happy to see an orbital mechanics thread!You are right that it is (usually) better to have a mid course maneuver. I say usually because sometimes it turns out from an operational perspective that it's cheaper in dollars to spend the extra fuel than it is to bring in the staff for an additional burn.The way I would do this numerically:First, choose the launch date. That gives you the position and velocity of the Earth on the date of launch. Second, choose a total flight time T_{flight}. That gives you the position and velocity of Mars.Second, choose a magnitude and direction (two angles) of the launch v_{infty}. You do it this way because you can bound the magnitude without having to impose an explicit constraint. That's an additional three variables. Add this vector to Earth's velocity to get the initial velocity of the spacecraft.Third, choose a "burn index" eta. This is scaling factor that varies in [0,1]. For practical purposes let's let it vary in [0.1,0.9]. Propagate the spacecraft forward in time from the date of launch to time t=eta*T_{flight}. For this you could use the "Universal Kepler Solver" on page 36 of Prussing and Conway. It's not great as it doesn't handle orbits with eccentricity 1, so if you're interested there is a better one in Battin's "Mathematics and Methods of Astrodynamics." You have now arrived at the point where the mid course burn will occur.Fourth, solve Lambert's problem to go from the burn point to the location of Mars in time (1-eta)*T_{flight}. Then calculate your braking burn (rendezvous, orbit insertion, aerobraking, whatever) just as you did before.This becomes a six variable problem. You control the launch window by putting bounds on the decision variables, most importantly T_{launch} and T_{flight}. I would use differential evolution or particle swarm to solve this. You could try using Excel's solver too. I think it could handle this problem because it should be unimodal (only one local minimum). I have not verified that though.The solver will find that the burn index should appear at the node point, assuming you've allowed a long enough T_{flight}. But if you insist on a very short transfer, it will place the burn earlier, and if you insist on a long transfer, it might go out to a high aphelion and do the burn there, or figure out for itself that it needs to do a multi-rev orbit. Very flexible.All that said, I like what you are doing. You're an artist by trade, right? One of the difficult things about the way engineers do orbital mechanics is that it's very difficult to explain to the general public. But your work, from what I see from your website, is a lot easier to present as a teaching tool. Every year we have an engineering open house and I think about having a booth, but I can't figure out how to explain what I do to kids and so I never do it.I will confess that I haven't checked your math yet. Can you add true anomaly to your chart? Or better yet x,y,z coordinates of the spacecraft and the planets so that we can check the endpoints.Also, do you have access to AIAA journals? If not I could go hunting for you and see if anyone has tried to do this before.

I guess I was right to have my doubts. No evidence of a show-stopper with hyperbolic orbits and Porkchop Plotters (innuendo isn't evidence).

[snip]

2. There are a couple of "if this is hyperbolic do X" spots in the code that likely haven't been tested

5. The hyperbolic orbits don't appear to be graphing correctly. Which means they weren't tested or someone would have fixed that.

Quote from: InterestedEngineer on 06/02/2024 05:09 am[snip]Yes, we know. "Code smell."Quote from: InterestedEngineer on 06/02/2024 05:09 am2. There are a couple of "if this is hyperbolic do X" spots in the code that likely haven't been tested"Likely" Sprinkling in unsupported, question-begging probability words to prop up your argument has a bad "rhetoric smell" FYI.Quote from: InterestedEngineer on 06/02/2024 05:09 am5. The hyperbolic orbits don't appear to be graphing correctly. Which means they weren't tested or someone would have fixed that.Now we're getting somewhere!!What are the reproduction steps? Can we get a screenshot of the incorrect graph or graphs?

Quote from: Twark_Main on 06/02/2024 05:39 amQuote from: InterestedEngineer on 06/02/2024 05:09 am[snip]Yes, we know. "Code smell."Quote from: InterestedEngineer on 06/02/2024 05:09 am2. There are a couple of "if this is hyperbolic do X" spots in the code that likely haven't been tested"Likely" Sprinkling in unsupported, question-begging probability words to prop up your argument has a bad "rhetoric smell" FYI.Quote from: InterestedEngineer on 06/02/2024 05:09 am5. The hyperbolic orbits don't appear to be graphing correctly. Which means they weren't tested or someone would have fixed that.Now we're getting somewhere!!What are the reproduction steps? Can we get a screenshot of the incorrect graph or graphs?It's reactions like these that argue for implementing McCabe complexity metrics in a development process so that a computer will tell someone their code is likely full of bugs instead of an experienced human "smelling" it.My dog is amused by the smelling analogy, BTW. He says smelling works just fine for finding food. One of which is bugs, coincidentally.

Is this your code?

Quote from: InterestedEngineer on 06/01/2024 01:24 amIdealized is good enough. It is irrelevant whether it's +/- a couple of days or a 0.5 km/sec.Looking at the (large) differences between various Earth-Mars conjunctions, I doubt it would be adequate. Also, 0.5 km/s is a lot!

Idealized is good enough. It is irrelevant whether it's +/- a couple of days or a 0.5 km/sec.

adjusting thrust angle

Here's a snapshot of a 30-100 day for departure Vinf.1. Why are there mid 2025, 2027, and late 2029 departures that aren't part of the normal window of Mars 2024, 2026, and 2028 conjunctions?2. Why are the high deltaV windows so narrow for the correct conjunctions in 2024, 2026, and 2028?3. I note it refused to give me an actual 30 day trip result.

You'll notice I've also excluded hyperbolic transfers (even having e > 0.98 was inducing some plotting weirdness, so I've kept everything within the regular elliptical transfers).

Do you know why there's plotting weirdness with hyperbolic transfers? I note that's what I got with the weird off-cycle pork chop transfers - only at hyperbolic speeds.

These algorithms are very touchy and ill-tempered, especially for multi-revolution orbits and at the transition between elliptic and hyperbolic orbits

From the video, I notice your paths are going "up and over" the Sun's poles. From this I gather you don't do broken plane transfers, only ballistic transfers.Check out these resources:https://hopsblog-hop.blogspot.com/2013/01/deboning-porkchop-plot.htmlhttps://physics.stackexchange.com/questions/123029/why-is-there-a-gap-in-porkchop-plotshttp://www.braeunig.us/space/ (section "Non-coplanar Trajectories")There's an implementation of the latter... for KSP. Selecting "Optimal" will perform both ballistic and broken plane calculations and return the cheapest option.https://alexmoon.github.io/ksp/https://github.com/alexmoon/kspEven that algorithm isn't quite optimal. It's actually better to do a hybrid strategy, with part of your plane change at departure and part of it during the mid-course burn. See:https://orbital-mechanics.space/orbital-maneuvers/plane-change-example.htmlhttps://space.stackexchange.com/questions/12997/saving-delta-v-by-splitting-plane-changing-manoeuvreIt's not perfectly optimal, but it's close. To find the exact optimal solution would require a 4-D binary hill climb for the mid-course burn X/Y/Z/time variables. At first I worried this would be too simplistic an approach, but further research reveals that's exactly how NASA solved the problem. https://ntrs.nasa.gov/api/citations/19940010378/downloads/19940010378.pdf (see "Optimizer" on page 16 / PDF page 28)Sorry for the number of links, but hopefully you find something useful in it.