SpudFiles

ramses wrote:Since the project was canceled, wouldn't the code be releasable?

Sure, if it existed as a program of record. It doesn't as the sim itself wasn't funded (just the testing). It didn't work worth a damn anyways. Not worth your time.

And if you get a new LGG, will the old one be sold at a government surplus auction? I bet if everyone on this forum pitched in, we could buy it.

LGGs are regulated under ITAR. As such, it would be illegal for it to be sold in a useable condition. So... You really in the market for an LGG that's been cut up with a cutting torch or similar?

D_Hall wrote:LGGs are regulated under ITAR. As such, it would be illegal for it to be sold in a useable condition.

Wow. Mentioned by name... Reading through the list, some stuff seems to be ridiculous... bearings and bearing systems. CNC-adaptable machines.... Bismuth over 99.98%... Vacuum valves... What the heck?

Also, that is international traffic in arms. I live in the states. Does that change anything?

So... You really in the market for an LGG that's been cut up with a cutting torch or similar?

could you weld on some flanges while you're at it?

Or add a 6" porting poppoff valve to keep things under 2Km/sec, that I/we can weld shut later?[/i]

psycix wrote:Another thing I would like to see is a manual step size of time in the simulation, setting a longer and heavier calculation and being more accurate or, a shorter, less accurate one.
In GGDT I often see a graph made of straight lines shaping a curve, smaller steps would produce a smoother, and thus more accurate curve.

As far as I know, GGDT actually uses timesteps of 10 us. It just happens that the graph only plots every 25 timesteps, with straight lines between them.

D_Hall will need to confirm either way, but I believe that what you see on the graph is not indicative of the timesteps used in the actual simulation.

Ragnarok wrote:As far as I know, GGDT actually uses timesteps of 10 us. It just happens that the graph only plots every 25 timesteps, with straight lines between them.

D_Hall will need to confirm either way, but I believe that what you see on the graph is not indicative of the timesteps used in the actual simulation.

Correct. Plotting EVERY point results in ridiculous memory requirements so it only plots... yeah, every 25th point.

ramses wrote:Wow. Mentioned by name... Reading through the list, some stuff seems to be ridiculous... bearings and bearing systems. CNC-adaptable machines.... Bismuth over 99.98%... Vacuum valves... What the heck?

A lot of those kinds of things show up when the ITAR folks look at the shopping list(s) for those building nuclear weapons (that's how LGGs end up on the list).

Also, that is international traffic in arms. I live in the states. Does that change anything?

For a straight up purchase? Sure, it changes everything. But for a government auction, I believe the regs say that anything going out on an auction that shows up on the ITAR list must be damaged beyond repair before it is auctioned.

so how is beyond repair defined?

So your auctioning...junk/scrap?

rp181 wrote:so how is beyond repair defined?

Usually it involves cutting torches and components that require precision fit. For example, in a gun, the spec might call for the first 10% of the barrel to be cut longitudinally. Could it be repaired? Sort of.... But anybody who could repair that has demonstrated the tech to build their own.

Radar dishes are required to be smashed so that they can no longer focus a beam. Again, if you have the knowledge/equipment to repair it, you have the knowledge/equipment to build your own.

So your auctioning...junk/scrap?

In general? Yeah, we auction a lot of scrap metal. Last year they took something like 50 tons of it out of my facility alone. In this particular case, however, all you're seeing is the wishful thinking of some members. The project may be scrapped, but the gun won't be (it'll just be put in a warehouse until the next time it's needed....which is were it came from this time).

Yeah, That was wishful thinking. I need to get a job...

D_Hall wrote:Correct. Plotting EVERY point results in ridiculous memory requirements so it only plots... yeah, every 25th point.

You see, unlike some people, I do read and remember what others say on the forums.

I would suggest that you could try fixing it with a "below X timesteps simulated, plot every 10th point" situation, but I'm guessing you simply tell it to put aside the data from every 25th time-step as it's calculated, and you don't know how many timesteps you'll be using in advance to be able to do that kind of thing.

Given that GGDT will run up to 25,000 timesteps before giving up, that's already 1000 datapoints to store, so I don't blame you for only going that far.

That said, what about having some kind of sliding scale? That is, it stores every 10th timestep up to the 200th, then every 20th up to the 1000th, then every 50th up to the 2000th, then every 100th after that.
That would get rid of the "squared" off graphs if you're only plotting a couple of milliseconds worth of data points, but would also dramatically reduce the demands of storing the data from a lengthy simulation.

Whereas you can expect to be storing 800 data points from 20,000 timesteps, changing to a system like the above would cut that dramatically to just 260. (A further cut off to every 250th step after 10000 would make it just 200).

The graphs would look better, and the maximum memory required would be cut - there would be a minor increase in calculation time from the additional sorting out to do, but I think that would be relatively insignificant.

Of course, the uneven steps could make the export files look bloody funny. It's also extra work to fix a relatively minor aesthetics problem. Perhaps not my best idea.

Anyway, I'm rambling again.

Who cares if calculation takes 1 second or 5 seconds. I just want accurate results.
For plotting piston opening, an interesting graph if you ask me, you might want to put out every 5th step.

Computers are getting more powerful by the day, and GGDT tuned to the max will at most take 15 seconds on a crappy PC. On my PC it does it withing one second.
Even if it takes 15 minutes, who cares?

Maybe have an option to switch between "quick" and "accurate". Quick does it in a second like it does now, and accurate will spend a lot more time for optimal quality, plotting every 5th step, making the short timespan graphs surrounding the valve opening more useful.

One solution to the flattened graph problem is to just spline fit (or parabolic fit) the data. I would bet that just about any type of three point fit would make a graph that is within the plot line width of the original data. Easy enough to off load that fitting to the graphing routine. Computationally it would take basically zero time.

It's probably to late and you are committed to .Net, but Java (or JavaScript) is pretty portable across platforms. A GUI is easier to do in Java and graphing is pretty straight forward. It would be a bit slower but personally I don't think speed is an issue with HGDT or GGDT. Heck I run them on a creaky old win98 computer.


Does HGDT use the flame speed formula, IIRC, v=k(P^alpha)(T^beta)? I've been looking at my old models and I am starting to think that the P isn't pressure, it should be density (rho?). It doesn't make a huge difference in the calculation results but ... I suspect that in the original usage it is indeed pressure but because of how the speeds were measured as a function of T and P the term basically ends of being density and not pressure. In a close chamber the "p" term is constant during combustion because it is really the gas density (or related to the gas density).

How about including flame speed (or pseudo flame speed) as an input to HGDT? Be interesting to try to model MAP, hydrogen, acetylene and other fuels with a faster burn rate then propane. I suppose that would mean you would also have to include the heat of combustion and the stoichiometry. So it's probably more trouble than it is really worth. Still, a second tab with all those hidden values for advanced users?