Programming =advanced=

[Jerry Irvine]

Programming

I have used, and worked with folks that have used, various programs such as SpaceCAD, Rocsim and others.

I used to be the sole seller of rocket software in the 80's and was in the process of standardizing file formats for motors and rockets so variouis programs could share common data.

Today that scheme has NOT been implemented by anyone and every program needs a customized database of motors and rockets.

I would like to restart the open effort to standardize a file format for motors and rockets that each program can share.

Jerry

 

[illini]

If not a standard file format, then maybe what your looking for - and what I believe could be useful - is a standard ontology: https://www-ksl.stanford.edu/kst/what-is-an-ontology.html.

There are free ontology development tools out there, like Protege (which I think comes from Stanford). Protege is very useful for creating ontologies in a formal language like OWL (think of it as XML on steroids). Once the ontology is standardized and adopted, knowledge sharing between software programs that conform to the standard should be straightforward. Might be a nice way to modularize and mix-n-match applications.

 

[rstaff3]

Jerry - I'd be interested to know how the Rocksim motor file differs from the one you mentioned. And I think standardization is a good thing.

Having worked around data format standards at NASA, IMO they can become more trouble than they are worth for a small simple application. KISS is good. XML for instance may be good for a lot of stuff, but I am still a big fan of flat files, with simple text formatting.

Here our opinion is worth a lot less that the authors of the 2 - 3 of the most commonly used programs. I'd think that the Rsim folks might be willing, since they even have converted their design files to XML. The benefit of XML is evident through the extensions that our teflonrocketry has come up with.

 

[polaris]

If you look at open source material like you see at Source Forge, I think you’ll find the XML proves to be a very handy way to define a standard interchange format.

It seems to me once a format is coupled with a logical data model, it winds up defining a protocol. As long as the implementation adheres to the protocol, isn’t implementation a relatively minor issue?

 

[cls]

good discussion about XML for the rockets. I'd like to see better use of it for "subassemblies" and for carting around simulation data.

also we could encapsulate "launch conditions". I fly regularly in 4 different places, with 4 very different altitudes, humidities, temperatures, etc. would be nice to have "presets" for those places


let's talk about motors: it seems like the ENG file format is a quasi-standard. as far as I can tell, that format was set up originally in DATA statements in Harry Stein's BASIC code. Jerry?

anyways, there's a few things ENG doesn't do, like provide enough data points for longer burn motors. (a few other nits, can't recall right now, arrgh.)


perhaps the way to move forward is to provide specifications and interoperable source code.

how about XML & Java code in SourceForge? anyone join me?

 

[mike_bar]

Originally posted by Jerry Irvine
I would like to restart the open effort to standardize a file format for motors and rockets that each program can share.

Jerry has a fine idea here.
I'm not a programmer so I do not know how to manipulate XML files.
I am an end-user whom knows much about flat files, either fixed width, comma or tab delimited. That is my area of expertise.
If you programmers like XML better then go for it.

 

[rstaff3]

My comment's above were based on the motor definitions only, the wider definition of the rocket and simulation parameters is certainly a bigger issue. Note that Rsim now used an XML file for these purposes.

This is a great topic for discussion.

 

[Milo]

XML would be great for all of this. It removes all the proprietary nature to the files. XML would allow me to easily create HTML pages using XSLT to show motor data or whatever.

With XML the possibilites would be endless.

 

[brianc]

Originally posted by Mike_BAR
Jerry has a fine idea here.
I'm not a programmer so I do not know how to manipulate XML files.
I am an end-user whom knows much about flat files, either fixed width, comma or tab delimited. That is my area of expertise.
If you programmers like XML better then go for it.

XML is simply text. Once you get your head around the tags, you'll
find it's very similar to flat files.

off on a tangent- Has anyone published a DTD for an .eng file?

 

[hokkyokusei]

Originally posted by Mike_BAR
Jerry has a fine idea here.
I'm not a programmer so I do not know how to manipulate XML files.
I am an end-user whom knows much about flat files, either fixed width, comma or tab delimited. That is my area of expertise.
If you programmers like XML better then go for it.

The tags in XML are only really a way of delimiting the data. Think of them as "super commas"

 

[illini]

Originally posted by hokkyokusei
The tags in XML are only really a way of delimiting the data. Think of them as "super commas"

Right. Ontology languages like OWL are a way of beefing that up a bit, by allowing you to express the relationships between tags. Leads to an object-oriented knowledge representation, complete with inheritance and other OO features. Where it might become useful is when one program requires a more detailed knowledge representation than the "standard" provides. If that's not likely to be needed, then XML is the way to go.

 

[Milo]

Originally posted by brianc
off on a tangent- Has anyone published a DTD for an .eng file?

Actually DTD has fallen out of favor. XML Schemas with an eye toward DSD is the way to go.

 

[rstaff3]

Originally posted by hokkyokusei
The tags in XML are only really a way of delimiting the data. Think of them as "super commas"

Or even super HTML.

 

[Jerry Irvine]

The ones we did in the 80's were these:

EDX file (motor)

00 MRev 01......:
01 Designation..: F101T
02 Data date....: 10/11/97
03 Manufacturer.: AeroTech
04 Cost.........:
05 Grain type...:
06 Propellant ID:
07 O.D..........: 0.95
08 Case Len.....: 4.9
09 Wgt Units....: G
10 Specs........: T
11 Wt Prop. gms.: 44.8
12 Load Wt. gms.: 80.6
13 Burn time....: 1.130
14 Favg Lbs.....: 17.808
15 Favg Newtons.: 79.214
16 TotImp Lbsecs: 17.6596
17 TotImp Ntsecs: 78.554
18 REM1.........: Copyright Tripoli Motor Testing 1997 (www.tripoli.org)
19 REM2.........: provided by ThrustCurve.org (www.thrustcurve.org)
20 Time /Thrust.: 0.04 16.687
20 Time /Thrust.: 0.12 18.108
20 Time /Thrust.: 0.21 18.807
20 Time /Thrust.: 0.29 19.533
20 Time /Thrust.: 0.38 19.735
20 Time /Thrust.: 0.46 19.745
20 Time /Thrust.: 0.54 19.658
20 Time /Thrust.: 0.63 19.382
20 Time /Thrust.: 0.71 18.984
20 Time /Thrust.: 0.79 18.331
20 Time /Thrust.: 0.88 17.032
20 Time /Thrust.: 0.96 5.075
20 Time /Thrust.: 1.05 0.066
20 Time /Thrust.: 1.13 0.000
61 Mass Fraction: 0.556
62 Isp lb/s/lb..: 176.596
63 Rating.......: 79-F-79
64 Pct Full.....: 96% F

ALX file (rocket)

00 ARev 01......: 08-01-90
01 Name.........: 400ROCKT
02 Description..: 4" X 72" MIN CDA ROCKET
03 Max Dia......: 4.00
04 Rocket Length: 72
05 Len/Dia ratio: 18
06 Drag Method..: D
07 CD File......:
08 LLug.........: N
09 Avg Sub CD...: .411
10 Elevation....: 2000
11 Pressure.....:
12 Temperature..: 80
13 Motor.#/Type.: 1 L2000USR
15 Launch wt....: 9.03
16 Max wt.......: 30
17 Increment....: 1.0
18 Ground launch: Y
19 Air start alt:
20 Air start vel:

I am sympathetic to XML advocates but I am also symphathetic to .txt advocates.

I am more inclined to do multiple entries per file rather than separate files (as was done in the 80's and as Rocsim does) these days, but I am more agnostic on that point.

So long as the format supports BOTH XML and .txt as interchange formats, religion will not get in the way of programming.

After all, exporting or importing both is trivial to the programmer.

Jerry

https://www.v-serv.com/programs

 

[Jerry Irvine]

Originally posted by cls

let's talk about motors: it seems like the ENG file format is a quasi-standard. as far as I can tell, that format was set up originally in DATA statements in Harry Stein's BASIC code. Jerry?

Stine established some but not all fields I identified.

I approached a part-time programmer named Fred Brennion with this idea in the 80's and he established the actual EDX and ALX file formats under my direction. I drove to his workplace at Excel-a-rate many times at my own expense to give him guidance on the programs I was the "publisher" of and which the co-author Charles E. Rogers agreed to "promote" with ads. We split the tiny profits. In fact, were there any profits?

So I would attribute the specific implementation to Fred Brennion.

It does an N number of relevent inflection points known as JEND points for "Jerry's endpoints". There are far more generic names for it I am sure.

Here are some of my favorite motor files.

00 MRev 01......:
01 Designation..: I40USR
02 Data date....: 07-27-90
03 Manufacturer.: U.S.ROCKETS
04 Cost.........: 60.00
05 Grain type...: CORED ENDBURNER (ME)
06 Propellant ID: 671
07 O.D..........: 2.125
08 Case Len : 8
09 Wgt Units....: G
10 Specs........: T
11 Wt Prop. gms.: 320
12 Load Wt. gms.: 512
13 Burn time....: 15.00
14 Favg Lbs.....: 9.54823
15 Favg Newtons.: 42.4705
16 TotImp Lbsecs: 143.223
17 TotImp Ntsecs: 637.058
18 REM1.........:
19 REM2.........:
20 Time /Thrust.: 0.00 44.00
20 Time /Thrust.: 3.50 5.00
20 Time /Thrust.: 14.90 5.00
20 Time /Thrust.: 15.00 0.00
61 Mass Fraction: .625
62 Isp lb/s/lb : 203.0
63 Rating.......: 637-I-42
64 Pct Full.....: 99% I


00 MRev 01......:
01 Designation..: G8USR
02 Data date....: 07-27-90
03 Manufacturer.: U.S.ROCKETS
04 Cost.........: 15.95
05 Grain type...: CORED ENDBURNER (ME)
06 Propellant ID: 671
07 O.D..........: 1.125
08 Case Len : 5
09 Wgt Units....: G
10 Specs........: T
11 Wt Prop. gms.: 60
12 Load Wt. gms.: 90
13 Burn time....: 15.01
14 Favg Lbs.....: 1.55149
15 Favg Newtons.: 6.90106
16 TotImp Lbsecs: 23.2879
17 TotImp Ntsecs: 103.585
18 REM1.........:
19 REM2.........:
20 Time /Thrust.: 0.00 6.30
20 Time /Thrust.: 1.50 1.30
20 Time /Thrust.: 15.00 1.30
20 Time /Thrust.: 15.01 0.00
61 Mass Fraction: .667
62 Isp lb/s/lb : 176.1
63 Rating.......: 104-G-7
64 Pct Full.....: 29% G

00 MRev 01......:
01 Designation..: I65USR
02 Data date....: 07-27-90
03 Manufacturer.: U.S.ROCKETS
04 Cost.........: 60.00
05 Grain type...: D
06 Propellant ID: 571
07 O.D..........: 2.125
08 Case Len : 8
09 Wgt Units....: G
10 Specs........: T
11 Wt Prop. gms.: 320
12 Load Wt. gms.: 500
13 Burn time....: 9.00
14 Favg Lbs.....: 15.1811
15 Favg Newtons.: 67.5255
16 TotImp Lbsecs: 136.63
17 TotImp Ntsecs: 607.730
18 REM1.........:
19 REM2.........:
20 Time /Thrust.: 0.00 26.00
20 Time /Thrust.: 1.50 26.00
20 Time /Thrust.: 9.00 0.00
61 Mass Fraction: .640
62 Isp lb/s/lb : 193.7
63 Rating.......: 608-I-68
64 Pct Full.....: 90% I

 

[Milo]

I threw this together based on one of your examples.

If you download this, rename it to motors.xml and view with IE you'll get a nicely formatted XML document. As you can see it is text based and easy to understand.

This is a very simplified example.

 

[DynaSoar]

Originally posted by Jerry Irvine
Programming

I have used, and worked with folks that have used, various programs such as SpaceCAD, Rocsim and others.

I used to be the sole seller of rocket software in the 80's and was in the process of standardizing file formats for motors and rockets so variouis programs could share common data.

Today that scheme has NOT been implemented by anyone and every program needs a customized database of motors and rockets.

I would like to restart the open effort to standardize a file format for motors and rockets that each program can share.

Jerry

Each program already has its own data structure. Creating an intermediate data structure and file format is an unnecessary step because those programs remain and continue to use their structures and formats. It's unnecessary because you'd have to export to this intermediate type and import into a new program.

Eliminate a step: translate from an existing type to another existing type. The only way this is not more efficient is if you also intend to create another entire program. And still that program would require those export and import functions if not to become yet another different program with its own unique (though maybe open) file type.

In the practical sense this would require determining or obtaining the structures of the various programs. In the case of SpaceCAD, this is fairly trivial -- the data files are text files and easily viewable (as well as fairly readable). The engine database is a concatenated .eng file, or so similar as makes little difference.

Rocksim .rkt files are similarly viewable, although slightly less readable. Its data is also text (.eng and .csv) files and includes definitions in seperate files (at least in v. 5). There's an engine file "compiler", but I've not investigated its function.

That covers the majority of software and files available. Conceptually trivial, but hardly trivial to who ever attempts to learn them both and devise a translator. Harder would be determining how to handle those things one program can do that another can't.

This is not to say an open source type progam that can handle these programs' data files and more is not a good idea. It'd have to start with the translations and also perform the design/modeling functions. This is a far from trivial task. It would be a scaled down version of something like OpenOffice. I suspect the number of qualified, available and interested programmers would be far less for this than for an office suite. I'd love to be shown wrong.

Interchangeability is a matter of functionality, and that means people can use it. Standardization for the purpose of interchangability is only efficient if that intermediate step has its own functionality. Standardization for its own sake creates its own problems to solve, and remains "standardization" only in the definition of its creators, while becoming "yet another" to everyone else; this would only not be so if "everyone else" disappeared. Given the two programs above with their followings, and especially with the amount of useful data created by each, that's not going to happen, nor should it.

 

[teflonrocketry1]

There isn't that much difference between a .txt file and an XML file. All the tricks for simulating things like tube fins, ring tail fins, side pods, boost gliders, fins on fins, and even parallel staging are based on using a word processor to manipulate XML files out side of the RockSim program. Other software companies have been able to exploit the XML files exported from RockSim for example: AeroCFD, AeroFinSim, and SmartSim. Since the RockSim XML format is already in use and has been accepted by other programmers maybe RockSim (Apogee) should set the standards for the file format we use!

Bruce S. Levison, NAR #69055

 

[cls]

Bruce, that's what I had in mind. we should start by producing an open source parser for existing XML format (and "serialization methods", the output functions) and let it all go from there. of course other formats like txt and edx/alx could be translated in to the "canonical" XML.

 

[hokkyokusei]

Originally posted by Jerry Irvine

I am sympathetic to XML advocates but I am also symphathetic to .txt advocates.

(snip)

So long as the format supports BOTH XML and .txt as interchange formats, religion will not get in the way of programming.

But XML is just text. It's human readable.

 

[Milo]

Originally posted by teflonrocketry1
Other software companies have been able to exploit the XML files exported from RockSim for example: AeroCFD, AeroFinSim, and SmartSim. Since the RockSim XML format is already in use and has been accepted by other programmers maybe RockSim (Apogee) should set the standards for the file format we use!

I tend to agree with this. It's the old "If you build it, they will come" adage. Basing your engine files on open standards (XML) can only be advantagous. True there would be a lot of work up front and it may take one or two more generations of software to get you there but I would bet that programs that don't follow this open trend will get left on the shelf.

I prefer XML because like I said earlier I can then use XSLT to transform these documents into anything I want, be it HTML or another data format all together including the old flat file formats you're currently using.

 

[Jerry Irvine]

I do not object to Rocsim or whatever becoming a defacto standard. I just want SOME standard. I would prefer that standard has some of the fields I added to my .EDX files.

Things like motor diameter, length, mass, curve inflection points, ILP format code (80G40-8F), etc.

On a separate issue Rocsim seems to have errors that need to be squashed.

"That has happened to me and several people before. I don't know what does it but it's something in rocksim. The program usually says something like: "One of the components was made with an older version of rocksim. Discarding the component." Or something like that. Then the program crashes."

Full version or the trial version?

Here are some Rocsim files for U.S. Rockets kits:

https://www.v-serv.com/usr/images/U.S.RocketsKitsRocsim.zip

Jerry

 

[Milo]

Originally posted by Jerry Irvine
I do not object to Rocsim or whatever becoming a defacto standard. I just want SOME standard. I would prefer that standard has some of the fields I added to my .EDX files.

Things like motor diameter, length, mass, curve inflection points, ILP format code (80G40-8F), etc.

I agree with you here. It will not be much of a standard if nobody uses it. Standards should be made by a consortium of the major players in the industry in question.

The standard should form a good base and when accepted vendors can extend it to suit their needs to create value. If they think their extensions warrant inclusion in the standard then it should be brought to the consortium for consideration.

Sounds like it is time to put together a formal RFC.

 

[powderburner]

With the rest of you guys talking about all this fancy programming, I am a little afraid to ask: does anyone just tinker around with stuff like EXCEL spreadsheets?

I like the simplicity. If I want to get fancy I can build TMOASS (the mother of all spread sheets). I can add sketches if I want. But I don't see anyone else using EXCEL?

BTW, I agree with just about all the comments already posted above, including the desire to standardize on *something* (whatever it is) and all pitch in toward one system. Sounds great.

 

[polaris]

Originally posted by Milo
I threw this together based on one of your examples.

If you download this, rename it to motors.xml and view with IE you'll get a nicely formatted XML document. As you can see it is text based and easy to understand.

This is a very simplified example.

That’s a nice job for just “throwing something together”.

As far as the standards part of it is concerned, there seem to be two kinds of standards: de jure (by law or right) and de facto (by fact or existence). To me de jure standards that are supported by an industry wind up having two virtues – vendors support them and they are “open”. It looks like there are several de facto standards that could be adopted by such a group as the basis for a de jure stand (ENG files for example).

Also de jure standards can go beyond the simple data definition to include “meaning” and performance. I believe meaning in this sense includes acceptable value ranges, relationship between fields etc. Performance is just that how well things perform.

I suppose you could drive it farther – into an industry data model. That way logical database or file structures could also be included. But that’s a really big topic.

BTW – great topic!

 

[Hospital_Rocket]

PowderBurner.

If you use spreadsheets for analysis, perhaps a new thread would be in order. You can do some rather sphisticated analysis using Excel. Share with us some examples of what you have done The geeks than then throw a TWEAKFEST and betwixt us we can probably develop some powerful toos.

Yes XML is a great open source standard, however there is also room for those who want to develp tools that function in existing applications.

Al

 

[teflonrocketry1]

Originally posted by Jerry Irvine
I do not object to Rocsim or whatever becoming a defacto standard. I just want SOME standard. I would prefer that standard has some of the fields I added to my .EDX files.

Things like motor diameter, length, mass, curve inflection points, ILP format code (80G40-8F), etc.

On a separate issue Rocsim seems to have errors that need to be squashed.

"That has happened to me and several people before. I don't know what does it but it's something in rocksim. The program usually says something like: "One of the components was made with an older version of rocksim. Discarding the component." Or something like that. Then the program crashes."

Full version or the trial version?

Here are some Rocsim files for U.S. Rockets kits:

https://www.v-serv.com/usr/images/U.S.RocketsKitsRocsim.zip

Jerry

Jerry,

The RockSim files at your site were created using RockSim version 6. I tested them, they open for me using versions 6 and 7 of the software. The files will not open with the demo version or the full version of RockSim version 5. I get the same effect where the program wrongly states that "this file was created with a previous versio nof RockSim. If you save this file, it will be save in the current RockSim format. Previous versions of RockSim will not be able to read it. Then I get the message An unknown rocket part ID was read from this file. The offending part has been ignored. After several of these messages I then get RockSim has caused an error in ROCKSIM.EXE. RockSim will now close. Is this what you are experiencing?

Since RockSim version 5 and the demo version are not compatible with the .XML file format there is no simple work around for this problem as the software versions are not backward compatable. I have attached a file that I created from scratch with RockSim version 5 for the USR Microc rocket. It should open under version 5 of the software and the demo version.

Bruce S. Levison, NAR #69055

 

[teflonrocketry1]

I forgot to attach the file! So here it is:

Bruce S. Levison, NAR #69055

 

[Jerry Irvine]

Originally posted by teflonrocketry1
Jerry,

The RockSim files at your site were created using RockSim version 6. I tested them, they open for me using versions 6 and 7 of the software. The files will not open with the demo version or the full version of RockSim version 5. I get the same effect where the program wrongly states that "this file was created with a previous versio nof RockSim. If you save this file, it will be save in the current RockSim format. Previous versions of RockSim will not be able to read it. Then I get the message An unknown rocket part ID was read from this file. The offending part has been ignored. After several of these messages I then get RockSim has caused an error in ROCKSIM.EXE. RockSim will now close. Is this what you are experiencing?

Since RockSim version 5 and the demo version are not compatible with the .XML file format there is no simple work around for this problem as the software versions are not backward compatable. I have attached a file that I created from scratch with RockSim version 5 for the USR Microc rocket. It should open under version 5 of the software and the demo version.

Bruce S. Levison, NAR #69055

Yes. My main personal concern of course is USR Rocsim newbies download the demo version (of course) and my files (of course) and get skunked.

Care to do that for dozens of files

Going forward I hope the fix happens in the Rocsim demo version. It seems logical the program should be backward compatible with files since they are on many websites for many oddball rockets.

Jerry

 

[rstaff3]

Bruce, if you update any of Jerry's files, please email them to me so I can get them updated on EMRR. TIA

PS I already grabbed this one