Programming =advanced=

[teflonrocketry1]

Originally posted by Jerry Irvine
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

Jerry,

Thats only about 82 files that need to be redone; the problem is its going to take me a while to finish this task. Are there a few files you need or would like to see done right away?

Tim Van Milligan of Apogee Rockets has mentioned to me there will be a new version 8 demo software released with RockSim version 8. Do you want to wait for the release of this new edition of the demo software?

Bruce S. Levison, NAR #69055

 

[teflonrocketry1]

Forgot to post the file again, here is the RockSim version 5 file for the US Rockets Scout model.

Bruce S. Levison, NAR #69055

 

[Jerry Irvine]

Originally posted by teflonrocketry1
Jerry,

Thats only about 82 files that need to be redone; the problem is its going to take me a while to finish this task. Are there a few files you need or would like to see done right away?

Tim Van Milligan of Apogee Rockets has mentioned to me there will be a new version 8 demo software released with RockSim version 8. Do you want to wait for the release of this new edition of the demo software?

Bruce S. Levison, NAR #69055

Yes I want to wait. Not only do you not need that much work, the real solution is a seamless way to get people to try and love Rocsim.

Jerry

 

[JRThro]

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.

I'll admit that I'm really not conversant with XML and its many uses, but how is your motors.xml file any more useful than your motors.txt file? They are both just as human-readable, etc... I don't see the benefit of using XML for this particular file, but I'm sure there are other examples where the benefit would be blindingly obvious even to me.

I'm an engineer, not a programmer, though I have done some programming/scripting in proprietary systems from time to time.

 

[Milo]

The flat file example is a propreitary document that requires a propreitary parser. I'd have to write a parser for each file that exists.

With the XML approach I can use any XML parser on the market to parse the file. I can also use many industry standard technologies on the parsed document such as XSLT, XPath, etc.

In my .NET world I could take this document and read it directly into an ADO.NET dataset and manipulate the data and then write it back out as XML. I would not be able to do this with the format shown in previous posts without a tremendous amount of work.

With the XML I could throw together an engine file viewer in probably an hour. In fact I may just do that tonight for fun.

Also with XML I can define a schema for the file that defines data types, required fields and other validation information so that I can determine if an engine file is not just well-formed XML but also a "valid" engine file.

 

[Jerry Irvine]

Originally posted by Milo
The flat file example is a propreitary document that requires a propreitary parser. I'd have to write a parser for each file that exists.

With the XML approach I can use any XML parser on the market to parse the file. I can also use many industry standard technologies on the parsed document such as XSLT, XPath, etc.

In my .NET world I could take this document and read it directly into an ADO.NET dataset and manipulate the data and then write it back out as XML. I would not be able to do this with the format shown in previous posts without a tremendous amount of work.

With the XML I could throw together an engine file viewer in probably an hour. In fact I may just do that tonight for fun.

Also with XML I can define a schema for the file that defines data types, required fields and other validation information so that I can determine if an engine file is not just well-formed XML but also a "valid" engine file.

To be fair the layer of code that manipulates the dats in a rocket specific way could just as easily (almost) read and import several file formats as inputs.

But I do not disregard XML as everyone I have discussed this with for the past 5 years has mentioned XML.

The problem is in that time we neither have a standard nor a means to manuiplate a series of runs for a particular rocket with a variety of motors, my pet project.

Jerry

 

[rstaff3]

Originally posted by Milo
The flat file example is a propreitary document that requires a propreitary parser. I'd have to write a parser for each file that exists.

With the XML approach I can use any XML parser on the market to parse the file. I can also use many industry standard technologies on the parsed document such as XSLT, XPath, etc.

In my .NET world I could take this document and read it directly into an ADO.NET dataset and manipulate the data and then write it back out as XML. I would not be able to do this with the format shown in previous posts without a tremendous amount of work.

With the XML I could throw together an engine file viewer in probably an hour. In fact I may just do that tonight for fun.

Also with XML I can define a schema for the file that defines data types, required fields and other validation information so that I can determine if an engine file is not just well-formed XML but also a "valid" engine file.

You should grab the WRASP/Rsim format, and then take the extra fields Jerry mentioned as extensions.

 

[Milo]

Jerry,

Yes true you could make a data layer... but are you going to make this layer available to the public? Say in a .NET or COM component.

How about in all the various languages and forms that XML parsers have currently available? Java and .NET for example.

If you deliver just an XML file people could write programs in Java that execute on Linux for example.

I say just give me the file and let me pick the technology I favor to get things done. If you trap me behind your propreitary data layer my options become more limited.

 

[Milo]

Originally posted by rstaff3
You should grab the WRASP/Rsim format, and then take the extra fields Jerry mentioned as extensions.

Where is this format? I don't use WRASP/Rsim.

 

[rstaff3]

OOPS, I forget I'll see where this is defined and either post or mail it.

 

[rstaff3]

Here it is

General file features:

1. The files are standard ASCII text files consisting of printable ASCII data lines followed by DOS or UNIX style line terminators. (<CR><LF> or <LF>).
2. Any data line preceded by a semi-colon is treated as a comment line and ignored.
3. Text strings cannot contain embedded spaces.

The file layout:

Engine 0

Engine 1

…

Engine n

The Engine description layout (keyed to example below):

NAR engine code (D12)
Engine casing diameter in mm (24)
Engine casing length in mm (70)
Ejection delays delimited by "-"es (0-3-5-7)
Mass of propellant in kg (0.0211)
Total mass of engine (pre-launch) (0.0438)
Manufacturer (name or abbr.) (E)
Thrust data pairs (time in sec and thrust in newtons); thrust of zero is last entry (ist entry = 0.040 1.000)

Example:

;This is a comment
D12 24 70 0-3-5-7 0.0211 0.0438 E
0.040 1.000
0.080 3.000
0.120 5.000
0.160 10.000
0.200 15.000
0.240 22.700
0.280 22.700
0.304 15.000
0.357 13.000
0.500 10.500
1.500 9.440
1.550 0.000

 

[Milo]

I gave it a shot...

I created two tables in SQL Server and loaded the file you gave me twice to show what multiple engines would look like.

I then read this info into an ADO.NET dataset and then wrote the data out to an XML file. The two tables are related by the EngineId.

How's this look:

 

[Milo]

Here is the .NET C# code used to make this file (just the method I wrote... not the entire program):

 

[rstaff3]

On first glance this looks great. The only thing I noted is the time value in the time/thrust pairs are not durations, but rather are elapsed times. can you provide me with a web reference so I can get a better context of what ADO.NET is/does. Thanks.

PS, I attached another sample file which holds Rsim data for the new Loki motors.

 

[Milo]

Good point... I didn't use Time because it is a key word in SQL Server. I'll change it to ElapsedTime.

I'll add some of this other data and upload another file.

 

[Hospital_Rocket]

Milo,

At one point you suggested an RFC to see if a standard could be built for this type of work as applied to rocketry.

I wonder if there is enogh critical mass in vendors to embrace a standard. As far as I know, this is a niche market with maybe a half dozen publishers. I'm enjoying the exploration of the subject....

And now back to .NET101 for rocketry enthusiasts.

A

 

[Milo]

Ok here you go:

ADO.NET is part of the .NET Framework. Surely you have heard of the .NET Framework.

Learn all you want and more here.

 

[rstaff3]

Barely heard of it Thanks for the link.

 

[Milo]

Sorry rstaff... a better ADO.NET link here.

As for the RFC it was just a suggestion for Jerry to call for one. The vendors could benefit from a standard I believe but it would be up to them to get together and make it happen. I think from a user standpoint that it would be great to be able to swap engine files from product to product.

 

[rstaff3]

I seem to keep going back to the engine files, I guess because they are simpler - i.e. I understand their contents. However, what would be even better is to be able to share the design files for a given rocket. The mechanics of this sharing seems to be simpler than other aspects. For instance, the various packages have different functionality implemented. The developers would have to define what constitutes a basic sim (for instance the parameters that all of them use, and which are the bare minimum to define the design and run a sim) vs. the 'add ons' (extensions). Since Rsim is further advanced that SpaceCAD in some respects, the later would have to be able to 'ignore' the parameters it does not use. This of course raises the question of why you'd want to import said sim if the other package would not really be able to process it completely.

Since the number of hobbiest packages are small, I wonder if Rocksim would consider it an asset to further assist other developers to follow their model? (i.e. by accepting their input for modifications to their format) Still, the XML model for Rocksim is available and some vendors are implementing add-on packages. Nothing would stop the others from using this model, but without coordination, each version of Rocksim would just break the other packages.

</ rambling mode OFF>

I guess if someone took the ball and wrote something up, then the comments from the vendors would answer all my questions.

 

[Milo]

It is hard for me to suggest anything further. I don't use any of the products myself so I don't know where there issues lie or if there is any benefit to standardizing the files.

I can picture the softwares in question having different features and as such I may like the way Rsim does one thing while I may like the way SpaceCAD does another. Being able to swap my basic sims back and forth between the two could be useful. And likewise if I wanted to create my own little utilities I could easily do that with the XML files.

You're describing pretty much what happens to all standards. A consortium puts out a standard and companies like MS extend them and try to add value to their products so you will buy them.

I'm personally starting to like the idea that my data is mine and I should be able to use it how I see fit. For example... if I write a Word document it would be great if it would just store it as XML and then I can simply apply an XSLT to it and display it on the web.

 

[rstaff3]

I find this discussion interesting so I can't help but put by 2c in. However, getting this going will require a determined individual.

BTW, I thought I heard Word was going to transition to an XML format. Of course, this is probably then transferred to a proprietary binary format so other can't read it.

 

[Milo]

Yes Word 2003 has XML capability... that was a bad example.

 

[Jerry Irvine]

Originally posted by Milo
Sorry rstaff... a better ADO.NET link here.

As for the RFC it was just a suggestion for Jerry to call for one. The vendors could benefit from a standard I believe but it would be up to them to get together and make it happen. I think from a user standpoint that it would be great to be able to swap engine files from product to product.

Step #1: Idendify the vendor universe

Step #2: Propose a baseline version 1 proposal

Step #3: modify the proposal; based on vendor feedback to get some, any 100% consensus
.
Step #4: Do a Version 1.1 standardization effort.

Step #5: Identify issues, make corrections and go to Version 1.2 standard

Jerry

 

[Milo]

Sounds like a plan... if everything goes right in about 18-24 months if you're a vendor and your program doesn't support the standard you may find your sales going down.

As a suggestion... ensure you bring namespaces into the mix so people can extend it and not worry about naming collisions. Rsim could use "rsim", SpaceCad could use "scad" or something. The standard could use "std" maybe.

(I'm no XML expert by no means and perhaps it has shown but I know that namespaces are defined and used for just about any standard)