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.
