OHM Trajectory Optimization Tool v1.1.2

[sraque]

Arrowstar,

It would be useful to see the arrival information. If you have time to do that, it would be much appreciated. Having that would allow the students to do some interesting and realistic trade-offs. For example, since the departure C3 is usually provided by the launch vehicle, and larger launch vehicles have higher costs, it can allow a trade-off between launch vehicle capability/cost and integrated propulsion mass since integrated propulsion is the primary method for orbit injection around the target body.

Regarding creation of SPICE files. I will post a step-by-step later today. I have it in my notes, but it is not user-friendly. You log into a UNIX system and work at a command line.

-Steve

---------- Post added at 07:46 PM ---------- Previous post was at 07:01 PM ----------

Go to JPL Horizons Website:
http://ssd.jpl.nasa.gov/?horizons

Click on the TELNET link (you need to have a telnet client on your system) or enter “open horizons.jpl.nasa.gov 6775”

You will be connected.

Type “?” for instructions. We will be using the DES= search for asteroids

Type DES=2001 US16 (this is that particular asteroid’s name, you can enter any valid search term)

When it prompts that it has found it, hit Enter to confirm

It will spit out some basic data. At the top, is a number before the name. This is its ID Number (89136 in the case of 2001 US16)

It prompts you for some options, type “S” to select the PK option

It asks for an email address. Enter it, but we don’t end up using it, so its no problem

In response to the next prompt for TEXT format, answer NO to get a binary file (BSP)

Enter start and end dates for when you want the SPICE file to be valid

It crunches the data and then lets you know that it is done

It asks if you want to add more objects to the same file. Answer as you wish.

It now replies that you have 30 minutes to retrieve the file via anonymous FTP and it gives you an address. Write this down! The file has an auto-generated name. You will want to change this once you save it to your system.

You will note a [M]ail option. This does not mail the file, only some output data.

Retrieve the file via FTP, and you’re done.

I know that this produces a valid SPICE binary since I have used these as data files for Satellite Toolkit, but they are binary files, and I don’t have a way to read them (although I haven’t dug into JPL’s SPICE toolkit).

-Steve

 

[Wishbone]

SPICE toolkit is a must and there are utils to do anything you like with binary kernels, but I'd like to have a bit more control over the order of loading/furnishing. Could this be done by checking for a meta-kernel in the spice libs directory and loading only it if it exists (e.g. TrajOptTool.ker) and defaulting to the old behavior if it is not there?

EDIT: Can only guess that the bug with the asteroid _may_ be related to its name, and how TOpTool and/or MICE treat names...

 

[Arrowstar]

sraque: Two notes. First, I'll go ahead and add some GUI controls to allow you to output arrival velocity magnitude for the LAST body on the flight plan. There will be two plots: one for Type I transfers and one for Type II transfers. Second, I should really toss out the disclaimer that I don't have the resources to do a lengthy validation of everything, and so while I try to squish bugs where I see them, I'm only one developer who's also a grad student. By all means use this in your class (that sound awesome!), but buyer beware at the same time.

I'll try to take a look at your custom kernel problem as well. See what I can find. Would you mind posting your kernel that you created to somewhere (maybe PM it to me, or toss it up somewhere on the internet, or whatnot) so I can replicate what you had exactly?

Wishbone: Two notes for you. This weekend you'll get your new Lambert solver with multiple revolutions possible. Also... can you explain to me what meta kernels are and what you'd like to see the code do with them? I'm not familiar with the term or what you're suggesting. Thanks!

EDIT: The new v1.1 edition should be out this weekend at some point. Most of the work has been taken care of, I just need to add a few things and update the documentation where necessary. sraque, you may wish to use this version for your class since it's at least 5 times faster when computing swing-by maneuvers. Enjoy

EDIT2: sraque, if your students want to provide feedback on the user experience of the Tool, that'd be pretty cool and very helpful for me. No pressure obviously, just thought I'd toss it out there.

 

[sraque]

I sent a PM. Hope it gets through. We will look for the new version in a few days. Thanks for being so helpful!

-Steve

 

[Arrowstar]

1) I downloaded a custom SPICE file (.bsp) for one of the candidate asteroids (2001_US16). I got this file by logging into JPL Horizons and getting it to generate the bsp file for the date range of interest. When I load it into the Traj Op. tool, it does not display a name. It shows that two SPK files were loaded. It shows a new entry after MARS, but it just has --> and then blank space. Any idea why a name or number doesn't appear?

Alright, I think I've taken care of this. It took some minor investigation, but here's what I've found:

0) Object names are built into the MICE toolbox directly.
1) Object NAMES are not stored in BSP files, only the NAIF ID number of the object.
2) Object names can be manually added by placing a specially formatted text file into the SPICE_Libs directory. There's info on how to do this in the MICE toolbox's documentation.

Since I'd like this to be easy to use as a tool, here's what I've done. If the object name is not found internally, then the tool takes the ID number of the number and assigns the ID that "name". So, for example, with your 2001 US16 example, the code will now output this when you click the "Show Loaded Bodies List" button:

The following bodies have loaded kernel data:
-->MERCURY BARYCENTER
-->VENUS BARYCENTER  
-->EARTH BARYCENTER  
-->MARS BARYCENTER   
-->JUPITER BARYCENTER
-->SATURN BARYCENTER 
-->URANUS BARYCENTER 
-->NEPTUNE BARYCENTER
-->PLUTO BARYCENTER  
-->SUN               
-->MERCURY           
-->VENUS             
-->MOON              
-->EARTH             
-->MARS              
-->2000624           
-->2089135           
-->2089136

I grabbed a SPICE file with three asteroids in it from the HORIZONS telnet system. The one you want in the list above is 2089136, as the ID of that asteroid is 89136. 20- is appended to ID numbers for certain types of bodies, it appears. You'll have to bear with me on that, there's nothing I can do there.

Anyway, you can now type in '2089136' in the Body Name boxes of the Flight Plan to plan trips to those bodies. I'll go ahead and get this modification uploaded. Let me know if you already downloaded the v1.1 package before this writing, I'll email you the updated executable so you don't have to pull all 200+ MBs again.

How does this sound?

 

[PeterRoss]

I'm afraid the problem with axial numbers I've reported earlier still persists in the 1.1 version. If you are zooming at the graph the axial numbers are changing correclty, but if you'll try to move it using 'hand' tool you'll find the same effect as it was in the old version.
Sorry for bringing bad news

 

[sraque]

This is fabulous! I wouldn't bother about the 20- "issue" if I were you. It is part of the standard naming convention by JPL.

I don't have the 1.1 package yet, so I'll get it and try it out.

-Steve

 

[Arrowstar]

I'm afraid the problem with axial numbers I've reported earlier still persists in the 1.1 version. If you are zooming at the graph the axial numbers are changing correclty, but if you'll try to move it using 'hand' tool you'll find the same effect as it was in the old version.
Sorry for bringing bad news

Confirmed. Ugh! This bug is like a cockroach, it will not go away. :lol: Thanks for reporting it.

sraque: Good to hear.

 

[Mandella]

so you don't have to pull all 200+ MBs again.

Speaking of that, is there any way to separate the executable from the massive libraries as a standard option in downloading? Not only are some of us on limited bandwidth, but it just takes so dang long to pull down the whole thing!

:lol:

Not to mention Orbit Hanger's bandwidth costs...

 

[Arrowstar]

Speaking of that, is there any way to separate the executable from the massive libraries as a standard option in downloading? Not only are some of us on limited bandwidth, but it just takes so dang long to pull down the whole thing!

:lol:

Not to mention Orbit Hanger's bandwidth costs...

Unfortunately, no. The licensing on the runtime library dictates that it must be included with the packaged software. It's the only way I can distribute it legally. Sorry.

---------- Post added 01-30-11 at 12:40 AM ---------- Previous post was 01-29-11 at 06:57 PM ----------

Update on the axial numbers bug (above): I've got a fix for it, I'll get it out at some point soon, hopefully. I guess we'll call this v1.1.1, as there are a few other minor bug fixes, as well.

 

[Mandella]

Unfortunately, no. The licensing on the runtime library dictates that it must be included with the packaged software. It's the only way I can distribute it legally. Sorry.

Just a thought, but could it be done this way?

Put the executable and library in one package, thus satisfying the licensing requirements. Then in another download put the executable alone (I am assuming the executable and supporting files are not burdened with a restrictive license). The user would have to download the first package first, then only need to download and plug in the executable for later patches.

Obviously I have not read the exact terms of the license you are working under, so feel free to ignore this suggestion if it just isn't allowed.

Really enjoying this tool, by the way. Great work!



Also: is there any good source for dates post 2053? I know I can calculate it forwards using synodic data, but that takes a bit of the fun out of it.

 

[Arrowstar]

Just a thought, but could it be done this way?

Put the executable and library in one package, thus satisfying the licensing requirements. Then in another download put the executable alone (I am assuming the executable and supporting files are not burdened with a restrictive license). The user would have to download the first package first, then only need to download and plug in the executable for later patches.

Obviously I have not read the exact terms of the license you are working under, so feel free to ignore this suggestion if it just isn't allowed.

Really enjoying this tool, by the way. Great work!



Also: is there any good source for date post 2053? I know I can calculate it forwards using synodic data, but that take a bit of the fun out of it.

Thanks for the nice words. I thought about what you suggested regarding packaging, and it's not a bad idea. I do want to limit confusion on patches and that sort of thing, but perhaps I'll consider it for this next point revision. You're right, it would be easier for everyone!

Regarding data availability: if JPL doesn't have, then probably not. sraque pointed out how to use the JPL Horizons Telnet system a few posts back. You may be able to use that to generate data that goes out beyond 2053, but I can't say for certain how much farther. And sadly, if JPL doesn't have it, it probably doesn't exist (at least not in a form that could be used by my tool).

 

[Wishbone]

D/loaded and played a bit at lunch (am reading NAS nuke propulsion committee report and gleaning the Neptune mission mass requirements from there). Looks nice and computes faster, haven't encountered the freeze bug yet, although the window could benefit from lower height (still have to wiggle the title bar with my 1440x900 resolution to be able to see all the buttons). Have I said that the documentation is visually pleasing and readable?

 

[Arrowstar]

D/loaded and played a bit at lunch (am reading NAS nuke propulsion committee report and gleaning the Neptune mission mass requirements from there). Looks nice and computes faster, haven't encountered the freeze bug yet, although the window could benefit from lower height (still have to wiggle the title bar with my 1440x900 resolution to be able to see all the buttons). Have I said that the documentation is visually pleasing and readable?

Sounds good. I'll see what I can do about the height of the window. I use a 1920x1200 display, so occasionally I forget the average person usually doesn't run so high!

---------- Post added 02-02-11 at 04:20 PM ---------- Previous post was 02-01-11 at 08:19 PM ----------

Updated to version 1.1.1:

Version 1.1.1 – Bug-fix release. The zooming/panning issue with axis tick mark numbers on graphs should be eliminated. The B-Plane plot legend has been moved and updated to show additional information. Other minor tweaks.

The window height is now under 900 px, so I'm hoping that's enough to be helpful. See the development thread for links to the full download, as well as the v1.1 -> v1.1.1 patch.