Opinions: Automatic simulation running in OpenRocket

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

Sampo

Well-Known Member
Joined
Jun 1, 2010
Messages
199
Reaction score
12
Hi,

We're considering some future UI designs and development paths for OpenRocket on the development mailing list, and I wanted to ask for opinions and comments from the TRF crowd as well.

One idea we've had to simplify the UI and workflow would be that whenever you make any changes to the rocket or simulations, OR would automatically run the simulations in the background. This could simplify the workflow, reduce button presses, and remove potential confusion caused by plotting obsolete data. Essentially, whenever you plot anything it is up-to-date.

Today's CPUs have to much power and cores that you probably wouldn't even notice the simulations being updated.

Do you think this would assist in your workflow or would it hinder something?

The only thing I can think of that would be prevented would be comparing the effect of rocket designs by running one simulation, changing the design, running another simulation and comparing the results. I think here a better solution would be to open the design twice, edit one design and compare those.

Opinions?


Cheers,
Sampo N.
 
I think that would be great! However if you add this, then I also think you need a way for the user to set default launch conditions, like rod length, altitide, weather, etc.

About the comment about comparing designs, could you give the user the option to not automatically run the sims. Then they can just manually run them if they want to do compares.
 
Hi,

Saving default launch conditions is (finally) coming in the next release.

Having a user-selectable option of background simulation would be possible, but is more work and might clutter the UI. If there's no strong case for not running the simulations automatically, I'd rather not provide a separate option for this.

Cheers,
Sampo N.
 
Saving default launch conditions is (finally) coming in the next release.

yeah!

Having a user-selectable option of background simulation would be possible, but is more work and might clutter the UI. If there's no strong case for not running the simulations automatically, I'd rather not provide a separate option for this.

no problem. it was just a suggestion.
 
I'd also like it if you added automatic calculation of the optimal delay. there was a thread asking about this feature a little while ago.
 
I love this idea, kind of like background compilation. I also like Derek's suggestion about an option to optimize the delay.

One other suggestion I want to make is a possibility of reordering simulations and motors. I like to order motors in ascending order, by impulse or letter and avg thrust, rather then the order I though of them for a particular rocket. I would like to make the same suggestion for simulations--I'd like to be able to reorder them, or even sort them on the motor(s) I'm using.

Ari.
 
One other idea is to add the delay (or time from burnout to apogee) as a column to the simulation pane. There's a "time to apogee" column, but without knowing the burn time of every motor, it's hard to estimate delay from that.

Ari.
 
+1 being able to resort the order of simulations afterwards; I also like the idea of background running.
 
Hi,
Having a user-selectable option of background simulation would be possible, but is more work and might clutter the UI. If there's no strong case for not running the simulations automatically, I'd rather not provide a separate option for this.

Your strong case is that five minutes after the release, people will be pestering you for it. I'll probably be one of them. ;)

Isn't this what the Run Simulations button is meant to do, anyway? ;)
 
Last edited:
The only thing I can think of that would be prevented would be comparing the effect of rocket designs by running one simulation, changing the design, running another simulation and comparing the results. I think here a better solution would be to open the design twice, edit one design and compare those.

Opinions?

So, which is easier; Hitting the button to re-run the sim (after a design/condition change), or opening up another version of an edited rocket to do your comparison?

My preference would not to have an automatic update run in the background, but to leave both on the flight sim pane and include a notation of some sorts in an additional column to differentiate a version 2 (?) simulation. That way, I have my comparison right there to look at on the same screen. I am brand new at this, so maybe I'm missing something?

Off topic question: Why is it that in the Launch conditions window, under Atmospheric Conditions, when I un-check the standard atmospheric conditions button and plug in my own... that no matter what I put in (ie.. very high air temperatures), I always get a lower apogee?

OpenRocket is a wonderful piece of work!!
 
One other suggestion I want to make is a possibility of reordering simulations and motors. I like to order motors in ascending order, by impulse or letter and avg thrust, rather then the order I though of them for a particular rocket. I would like to make the same suggestion for simulations--I'd like to be able to reorder them, or even sort them on the motor(s) I'm using.

One other idea is to add the delay (or time from burnout to apogee) as a column to the simulation pane. There's a "time to apogee" column, but without knowing the burn time of every motor, it's hard to estimate delay from that.

I love both of these ideas.

OpenRocket is a wonderful tool. Thanks so much for putting all the work and effort into it (to the entire team).
 
I hate programs that magically assume they know what I want them to do. If I want to rerun a sim, I'll rerun the sim. Don't guess and assume that I want it done.

Today's CPUs have to much power and cores that you probably wouldn't even notice the simulations being updated.

I'll be honest, I hate this line of thinking -- it's what leads to code bloat and inefficient processing. "RAM is cheap, we'll just tell the user to add more RAM" "Processors are fast enough, it won't cause any issues" Until you're on a system that's constrained for other reasons.

Keep the application lightweight, don't do extraneous tasks in the background, and don't assume to know what the user wants to do.

-Kevin
 
Sampo - once again thanks so much for thinking of the TRF users.

I do think there are some areas of the UI that could use some work.

For example the Rocket design > Add new component area (upper right) takes up a lot of screen space. This could perhaps be better utilized with something like a tool bar.

When you mention updating simulations in the background, I'm not sure how that might improve the UI.
I actually like the flow of making a change - then seeing the result by pushing the Run Simulation button, even though that can be a bit tedious. This forces me to test my design changes one at a time if I want to see the effect they have. Otherwise I could run the sim after making multiple changes, if I'm not concerned with the effect of each change.

I'm happy to hear the ability to save launch parameters is coming in the next release - a very desirable feature.

The ability to sort the simulations by clicking on the heading would be very nice. I would like to click on "apogee" for example, and have the simulations sorted from lowest to highest. Another click to reverse the sort high to low. Would be great if all the headers worked like this.

Others have suggested a optimized delay calculation. This would also be a nice feature.

Thanks again for your time and consideration!

-Scott
 
I'm not usually one to poo-poo on an idea, but I really don't think that automatic sims running in the background is all that necessary. It's a neat feature, and it would speed things up, but there is something to doing things the tedious way: Builds discipline and makes you think more.

Also I have to disagree on the statement "Today's CPUs have to much power and cores that you probably wouldn't even notice the simulations being updated". To me a better written program is the one that uses the least amount of code to do the same job as a bloated warthog of a program. It's still better to keep a program lean and mean. Openrocket is a damn good program Sampo. I use it religiously. So far every update is a improvement over the last version, and I'm sure that everybody involved wants this to continue. I just don't think that doing more automatic background calculations is the way to go.
 
Last edited:
Sampo - once again thanks so much for thinking of the TRF users.

I do think there are some areas of the UI that could use some work.

For example the Rocket design > Add new component area (upper right) takes up a lot of screen space. This could perhaps be better utilized with something like a tool bar.

When you mention updating simulations in the background, I'm not sure how that might improve the UI.
I actually like the flow of making a change - then seeing the result by pushing the Run Simulation button, even though that can be a bit tedious. This forces me to test my design changes one at a time if I want to see the effect they have. Otherwise I could run the sim after making multiple changes, if I'm not concerned with the effect of each change.

I'm happy to hear the ability to save launch parameters is coming in the next release - a very desirable feature.

The ability to sort the simulations by clicking on the heading would be very nice. I would like to click on "apogee" for example, and have the simulations sorted from lowest to highest. Another click to reverse the sort high to low. Would be great if all the headers worked like this.

Others have suggested a optimized delay calculation. This would also be a nice feature.

Thanks again for your time and consideration!

-Scott

^^^^^+1 or 2
 
Hi,

Today's CPUs have to much power and cores that you probably wouldn't even notice the simulations being updated.

Do you think this would assist in your workflow or would it hinder something?

Opinions?


Cheers,
Sampo N.


Good for leading edge computers but please include an option to not use this, for those who have bleeding edge technology. :blush: :grin:
 
Good for leading edge computers but please include an option to not use this, for those who have bleeding edge technology. :blush: :grin:

^^^^ Definitely! OR works fine as it is on my 7 y/o Dell laptop... don't wanna let out the magic smoke. ^^^^
 
Hi,

This feature shouldn't interfere with using the software, just make the CPU churn out something useful while it would otherwise be bored.

One definite reason for an enable/disable option is that simulation listeners may affect thing outside of the software. For example, I've written a simulation listener that talked with our actual flight computer, feeding it with simulated data and receiving control commands back. In such cases you need to exact control of when the simulations are run.

Cheers,
Sampo N.
 

Latest posts

Back
Top