A ThrustCurve.org Python API: Any Interest?

[martinjaymckee]

I've been doing a few projects recently that have required optimizations of complex rockets ( one a fully parametric R/C rocket glider design ), but could stand very simple simulations. So, I wrote a very basic 1-dof simulator that had all the hooks I needed to do the optimizations. There was one part that I didn't want to hack together, however -- engine information access. So, I wrote a fairly complete library to read in RASP format files and another API (Application Programmer Interface) to interact with the thrustcurve.org servers using their web API ( beautiful thing that it is! ).

It's written in python and, thus far, supports the full searching and download API's. I haven't actually implemented the metadata API ( I haven't needed it, myself ), but it wouldn't be difficult to do so. I'm just wondering if anyone else would be interested in a python library for this being made available. If so, I really need to polish a bit and write some real documentation, and example programs, but I'd be happy to do so. I've found it useful in my work. If anyone else wants to deal with thrust curves ( the data and the website ) in python, I think they may find it useful too.

Of course, I'd also be open to additional features and changes that would make it more widely applicable. As with all projects, I have my set of pet ideas, but I'd love to know what sort of things other people might find useful to add.

Cheers,
Martin Jay McKee

 

[dhbarr]

I would absolutely love to be able to programmatically search thrustcurve , and sample Python would be a perfect hook. Some examples:

• All 13mm motors sorted by burnout weight
• All 29mm motors sorted by ISP
• Any motor that will fit in rocket_X's motor mount which has minimum and maximum constraints on burn time, peak thrust, average thrust

Etc. Etc. Sure would be a great first step for selection as opposed to just adding every variant in OR.

 

[JohnCoker]

Nice work!

The metadata API is useful to populate search selections (otherwise the client would have to hard-code the options). You can see an example in the web mash-up:
www.thrustcurve.org/apidemo.shtml

 

[JohnCoker]

I would absolutely love to be able to programmatically search thrustcurve , and sample Python would be a perfect hook. Some examples:
Etc. Etc. Sure would be a great first step for selection as opposed to just adding every variant in OR.

Have you tried the existing ThrustCurve.org search and motor guide features? I believe they provide a good way to narrow down the possible motors to a short list to perform full simulations on.

 

[martinjaymckee]

In reverse order here.... I have to agree that the current web-based search is excellent for quickly narrowing down a list of "sim-worthy" engines. Part of the reason that I haven't completed the API to a more polished state is that I simply haven't been able to justify the effort of trying to improve on the search capabilities for my own uses. That having been said, I definitely think there are places that the API is useful -- in automated sim cases.

I personally think that the meta data API is one of the coolest features of the whole API set. Again, as I haven't needed it, I haven't implemented it either. Then again, I always knew that I would implement it before really releasing my Python library in full. The other feature that I see as missing is the ability to read RockSim files into my engine component. Most of the engines on ThrustCurve have RASP available, but not all. It's a shame to not be able to read everything -- the API allows you to download it though.

I'll do a bit of work on a more complete library release ( at least get the meta-data API integrated ), come up with a couple of examples and first draft documentation, and get something posted for people to take a look at.

Martin Jay McKee

 

[dhbarr]

Have you tried the existing ThrustCurve.org search and motor guide features? I believe they provide a good way to narrow down the possible motors to a short list to perform full simulations on.

I have, and they do; I just want m04r p0w3r!

 

[JohnCoker]

The other feature that I see as missing is the ability to read RockSim files into my engine component.

You also have the option of getting just the parsed data points, which saves the time of building a parser. (Take a look at that mash-up I put together.)

 

[martinjaymckee]

John,
I hadn't noticed the parsed data point option, thanks. I was already working with RASP, so I had a parser... plus, it's a dead simple format to parse. For the moment, I think I'll try to wrap up the version that downloads RASP format since it works already and maybe do raw data points soon.

Martin Jay McKee

 

[dhbarr]

Have you tried the existing ThrustCurve.org search and motor guide features? I believe they provide a good way to narrow down the possible motors to a short list to perform full simulations on.

For instance, I was just a moment ago curious about being able to sort G-class motors: by minimum hardware weight; by maximum hardware weight; by minimum propellant weight; by maximum propellant weight.

There's like 100 of 'em, and I don't want to page through everything

Anyhoo! If someone wants to tell me what the heaviest propellant-weight and heaviest total-weight G motor is, I'll have a number I can feed into my design for a dual-G FAR101 two-fin model rocket

 

[JohnCoker]

True enough; it'll be hard to add every possible value to the lists to allow interactive sorting. (I was thinking that you could search for G motors then use the sort controls in the result columns, but weights aren't listed.)
https://thrustcurve.herokuapp.com/motors/search.html?impulseClass=G

 

[dhbarr]

True enough; it'll be hard to add every possible value to the lists to allow interactive sorting. (I was thinking that you could search for G motors then use the sort controls in the result columns, but weights aren't listed.)
https://thrustcurve.herokuapp.com/motors/search.html?impulseClass=G

Ahh, but in my brief overview of the APIs I wasn't able to find weights exposed. I have no problem writing an appropriate client, I just want to avoid curling a bunch of stuff and then building parsers for each format. I know it's a bit esoteric, but here we are ^_^ Expressed differently, I don't want to build a different interface to this very fine data; I want to say "Here, go to this place and do the thing that I did!"

Alternately, I could just slurp the data pages into a spreadsheet and filter for my own use. Seems disrespectful of the data collection, though.

 

[martinjaymckee]

I've been busy building a house, starting a new job and attempting to recover from a major system failure that destroyed both my main storage and both backups! So the API is in the wind until I get my drive to a data-recovery service (and, hopefully they can get something from one of the backups....). What I did with the API for a situation like this was to do the minimal search I could on whatever variables were there in the search API and bring in all of the results. Then, on the client side, do the remainder of the search, on things like propellant weight. It was working reasonably well at cutting down the number of engines that it pulled down if you were sorting by, at least, class or diameter.

Martin Jay McKee