Configurations & Simulations Tweaks to Make the Awesome State of OR Even More Awesomer

The Rocketry Forum

Help Support The Rocketry Forum:

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

tjkopena

Rocketship Games
TRF Sponsor
Joined
Feb 18, 2021
Messages
263
Reaction score
466
Location
Philadelphia, PA
In a potential futile attempt to extract something useful out of this thread, let me take a guess where the complaint is. While the latest betas have definitely eliminated some mouse clicks and smoothed the overall process of creating simulations, there is still an aspect that some might find bothersome/cumbersome/unintuitive.

Right now, a flight simulation consists of two separate entities: the motor configuration and the simulation, and this (I think) is the crux of the complaint. There is a one->many relationship between the two. Although the mouse clicks have been streamlined, there is still a two-step process to first create a motor configuration, then simulate using that configuration. Motor configurations include deployment options. The simulations have a separate set of editable parameters.

This is a very flexible arrangement, but splits all the information for a particular flight sim in two separate tabs. If I want to change a particular sim, I may have to bounce to a different tab to change the motor config.

An alternative, more direct approach would be to include motor configuration and deployment information as part of each sim. This is probably analogous to the way Rocksim does it, if I recall correctly. Create a new sim, select motors, set sim parameters, and go. Editing any parameter of a sim would all be in one place. This approach might sacrifice a bit of flexibility, and/or make it a little harder to share motor configs among multiple sims (I would need to think about a good way to do it). But it would probably be more straightforward. It would also lend itself to something more like a wizard UI to set up a sim.

I hope folks will let me know if I'm hitting (or missing) the mark here.

It took me a bit of play before I felt comfortable with the one-to-many relationships between rocket -> flight configuration -> simulations. So I could see many people finding it either confusing or not worth the hassle---"I just wanna pick a motor and sim it, let's gooo!!"

But the current structure is a reasonable compromise between usability and flexibility. I would hate to see it reduced to a simpler structure effectively denormalizing configurations and simulations. I think usability can be improved without making that sacrifice. Separately, the flexibility and power can also be increased without radical paradigm changes. It's going to take me a bit of time today to type out some thoughts, but I will do so. It's actually been on my to-do list already to pose a couple of these ideas based on some rocket design work I've been doing lately.

In any event, I really wanted to break (hopefully) productive discussion of this topic out from the originating thread, so here we are...
 
I am also used to the structure of multiple [motor/ignition/delay/recovery] configs for a given rocket, and multiple sim [location/wind/rail] options for any given config. It wasn't counter intuitive to me and is powerful. Power and complication are often inextricable.

Perhaps a 'simple mode' could be made to stream line the workflow, rather than rebuilding the interfaces.
 
Oh, and here's a thought - when changing motor/staging/recovery parameters in a config, OR gives you the option of changing it for one/all configs. I don't think the sim options ask the same thing - but probably should.: Change rod length for this sim, or all sims?
 
Ok, a thread on what I've been thinking, as I have to break it up into smaller individual posts.

The notional details shown in this walkthrough are based around a simple narrative of designing a rocket for an L1 flight.

Please forgive my crude UI sketches.
 
Overview
An overall change is to take the "main" design screen, optimize its use of space and clicks a bit, and then generalize and adopt its template for all the primary screens. As shown in the following diagram, that screen is made up of four major areas. I don't know what terminology is actually used for OR currently, so I'm labeling them as:
  • Workspace Tabs: How to navigate to different Workspaces, aspects of the overall design and analysis effort; the other three elements, the panes, are children of the tabs---though some are reused, each tab could have its own set of panes.
  • Components Pane: A view of and tools to manipulate the components of the current Workspace and their structure.
  • Edit Pane: Details and controls to define and alter the component currently selected in the Components Pane.
  • View Pane: A visualization of the current Workspace, usually the rocket design.

or-sketch05.png

Note that I've tweaked the Workspaces and associated tabs to:
  1. Rocket Design: As currently, the main place to model your rocket.
  2. Flight Configuration: Renamed to make more clear that motors are just one part of flight configuration, not "Motors & (and separately) Configuration" as the tab currently reads.
  3. Launch Parameters: This is new, breaking out aspects such as weather, location, and launch pad that are currently part of the simulation specifications and turning them into reusable inputs that can be used by multiple simulations, much like flight configurations.
  4. Simulations: The place for analyzing your rocket's flight performance.
Where possible, it's worth emphasizing the current workflow, preserved here, of more or less moving left to right through the workspace tabs in the course of a design, and of course looping back to iterate. I think part of the confusion people develop about configurations, etc., is that tabs don't present any particular ordering particularly strongly. You think you can jump straight from design to simulation, but you can't, you need configurations first. I'm not sure though if there is a better way to encourage and make more overt that flow while also maintaining the ability to hop around between the workspaces quickly.

Also note that the Components Pane always includes the same basic toolbar in each workspace to add, delete, duplicate, and rearrange components.
 
Rocket Design
What this looks like in the Rocket Design workspace, the default or main view of editing the rocket, is as follows:
or-sketch08.png

In this Design workspace, the Components and View Panes are as they are now. The Edit Pane adopts all the component editing functionality currently presented in a modal. This uses the screen and user time more efficiently---I can quickly hop around between different components more effectively than with the modal, both to look at details or to edit them; I don't have the modal obscuring part of the screen, etc.. The current panel of component creation buttons is an inefficient use of prime screen real estate. Once the basic architecture is laid out, you spend much more time looking at and editing details than adding components.

Instead, the panel of component creation buttons currently in that upper right pane pops up as a modal when you hit the Add button in the Components Pane of the Rocket Design workspace, which replaces Edit:
or-sketch10-alt.png

In an addition separable from the main thrust of this proposal, to the component editor (in the upper right pane) I've also added a Configurations tab:
or-sketch20-alt.png

By default a component is applicable in all flight configurations. However, in this tab I can select a subset of configurations to which it is to be applied. Each simulation is associated with a flight configuration, and its calculations would only include those components enabled for that flight configuration. Similarly, the standard rocket visualization View Pane would only draw, and the calculated stability and other numbers only account for, those components enabled for the currently selected configuration (dropbox in pane's upper right, as currently).

This feature enables a couple workflow and modeling enhancements:
  1. I can model several variants of a component and then quickly switch back and forth between them to evaluate the options & make design decisions (aesthetic, performance, or otherwise), rather than, say making multiple copies of the project.
  2. I can swap out components for different flight configurations. E.g., maybe some flights I want to use a streamer and others a parachute, or parachutes of different sizes. Maybe I need to add a mass component to the nose for some motors to hit a stability target, etc..
 
Flight Configurations
Moving on/right in the project workflow, the Flight Configurations workspace then looks like:
or-sketch30.png

I think the current Motors & Configurations screen fosters some of the confusion around flight configurations. E.g., it's got top level controls for manipulating the configurations, but then the Motors, Recovery, and Stages tabs are for manipulating any flight configuration. The labeling and the layout don't work to emphasize the idea that you're not just picking a motor, you're defining a whole set of design options that might change flight-by-flight.

The three-pane view presented here works to emphasize exactly that, in part by in some sense normalizing the view. Rather than several tabs which each let me manipulate combinations of configuration crossed by parameter, I select a configuration and then edit its parameters. They're visually & procedurally bound might tighter together as a package of options.

So, in this approach, the components of the Flight Configurations workspace are individual flight configurations. There's a list of them in the Components Pane with their given names and a short summation of each, from which I can select which one to work on, add new ones, etc etc.. The Edit Pane presents the motor selection, recovery parameters, and whatever else goes into defining a flight configuration. The View Pane shows the same rocket view as the Design Workspace because it's relevant and useful to see what impact motor selection, etc. having on the design and basic calculations.

For my particular example, I have three flight configurations:
  1. April Proto Flight in which I'm going to use an F67 for a first launch.
  2. G79 Test in which I ramp up the stress on the airframe.
  3. Cert Flight in which I put a baby H in there and see what happens.
Note that with the affordance outlined above to enable/disable rocket components per configuration, I can do things like include a mass component modeling the chute release for the latter two configurations. Currently in OR I can model the effect of the chute release through the recovery configuration, but I can't easily model that the proto flight won't need that component and its mass shouldn't be included.
 
Launch Parameters
Another change separable from the basic elements of this proposal, the new Launch Parameters workspace extracts some of the options currently included in Simulations and makes them reusable collections of values:
or-sketch40.png

This makes it somewhat easier to model and apply different conditions. . E.g., the request in the post above about having buttons to apply launch rod or other changes to all simulations aren't needed in this approach: You edit that parameter in a particular collection, and all the simulations associated with that collection receive the change.

Breaking these parameters out separately from the simulations also makes it more natural to have a personal library of launch parameters, unassociated with a flight configuration or proper simulation options. That could be either somewhat manually through exporting & importing, or as a database much like those of rocket components and motors. For example, I could have launch parameter collections modeling my MMX flights (12" launch rod at the soccer fields around the corner), LPR+MPR at PARA launches (3' rod, often very calm, location north of Philly), and bigger stuff at MDRA (6' rail, windier baseline, location in MD).

In this particular example, for this project I'm interested in three possible launch scenarios: A calm or windy day at PARA, and a calm day at MDRA.

You could continue decomposing and denormalizing into separate objects for launch pad config, location, and weather. But I think breaking out Launch Parameters to their own objects affords an interesting level of additional flexibility without becoming unwieldy.
 
Simulations
Finally, the Simulations workspace extends individual simulation definitions slightly as selections of flight configurations and launch parameters, and adopts the three pane screen template:
or-sketch50-alt.png

Promoting the graphs to the View Pane here I think makes this a much more focused, efficient, and useful screen, as well as looking cool.

In this example I've created simulations for the several combos of possible launches. E.g., the April Proto Flight and G79 Tests are planned to be at PARA and could be done on a calm or windy day. The Cert Flight though is only going to be done on a calm day, but could be at PARA or MDRA.
 
Conclusion
In summary, the main idea is that the potential confusion around flight configurations and simulations can be reduced by UI changes that better present them as objects collecting properties to be edited, rather than multiple tabs of data rows as flight configurations are currently. Adopting the same components/details/view three pane layout of the primary design screen throughout the others also aims to foster user comfort and familiarity. It emphasizes that we're doing the same thing---list components, edit details, visualize results---in each step of a simple process:
  1. We're listing rocketry components of the actual rocket and editing their details;
  2. We're listing a bunch of flight configurations for which we're picking motors, recovery, and other details;
  3. We're listing a bunch of relevant launch scenarios and setting their weather and other properties;
  4. We're listing what possible flights we want to analyze by picking pairs of flight configurations and launch parameters those as worth simulating, and editing options for those calculations.
Which in turn hopefully makes flight configurations and simulations more intuitive: They're objects with properties, rather than self-obscuring tabs of rows.

Extracting launch parameters into their own objects seems useful, and creates a very natural 4 step process: Design, prep (flight configurations), stage (launch parameters), launch (simulate). But it's not a necessary component of the main proposal.

Similar for the ability to enable/disable components for specific configurations. That's wholly separate from the rest of this. It could be done in the current UI, and in turn this proposed UI revision could be done without it.


I realize it's a fairly significant set of changes. That said, it's not a drastic reworking of the underlying models and other guts of OR. It's also perhaps a reasonable amount of UI changes, a lot of shifting existing UI detail panels into different containers rather than wholly new screens. But subsets of the changes are also separable, it's not an all or nothing proposal.

That's all I got. Thanks for reading.
 
Good work here, thinking about how to make the underlying concepts more transparent. I've always like that OR supported the notion of multiple flight configurations for a design, and multiple sets of parameters for the simulations. Even if OR was to be drastically re-architected (server-side computation and an HTML5 web front end, or as a plug-in module for a real CAD program like OnShape), these things would stay the same. So pushing this forward into the existing UI would be a great idea until we have couple of energized devs to start building the next gen simulator; the work would be a major contribution.

Edit: one tweak to the UI sketches would be that each object (group of settings like the launch params) should have a "Defaults..." button that takes you to a tab in the Settings dialog where you can view/set the defaults for that object. With only the "Reset to Defaults" and "Save as Default" buttons you have no way to view the defaults without overwriting your settings, since there's no "Revert". Over in the Settings tab you could have the ability to create multiple named sets of defaults that would be persisted and available for instant selection.
 
Last edited:
Oh, and here's a thought - when changing motor/staging/recovery parameters in a config, OR gives you the option of changing it for one/all configs. I don't think the sim options ask the same thing - but probably should.: Change rod length for this sim, or all sims?
This feature exists in beta.04. Just select (highlight) the desired simulations, right-click on the highlighted area and select edit, and make the changes. When you close the window, the changes are made to all selected simulations.
 
At some point, the differing UI on top of the core simulator ought to be a "public" or well known (stable) programming interface.

That way, you can use the skin you like, I'll use Impossible Mode, errr, another one...

And command line apps can run a range of sims, with vastly more complex varying parameters than would be practical to configure in a GUI.

I have numerous examples of this, from sim programs in other hobbies. So yeah, it's been done.

Just an idea...
 
This feature exists in beta.04. Just select (highlight) the desired simulations, right-click on the highlighted area and select edit, and make the changes. When you close the window, the changes are made to all selected simulations.
Nifty.

Does the motor/flight config UI work the same way in beta 4?
 
Does the motor/flight config UI work the same way in beta 4?

Yes, similarly, as do the components. Two examples, using the A simple model rocket example.

First example, go to the Motor & Configuration tab and select the center three motor configurations. Left-click Select motor, then change the motor to B4-2; when you left-click OK to exit, all of the selected motor configurations change to B4-2.

Second example, while in 3D view, on the Rocket design tab, on the component tree, select the nose cone and launch lug. Then, right-click on a highlighted area and select edit (this opens the Multi-component configuration window). Change the appearance color to blue, and watch the color of both components change. Multiple characteristics shared by different components can be simutaneously changed in this way.
 
@tjkopena: Great write-up! I will install OR beta 4 and work through your explanations hopefully this weekend. I think it might be a great way to discover the current OR workflow.

I have used OR for quite a while (old versions), but never efficiently per-se. If I'm working on a stock design just for sims, I grab someone else's file and tweak weight to get CG to my as-built CG and move on, which is all I've done in recent years. For the few scratch designs I've simmed, I usually just open a similar file and tweak. I'll use your explanations above to start with a blank canvas (albeit on an existing design, as that's my next project) and try to create and simulate from scratch.

If I don't reply back to this thread by Tuesday morning with comments on the workflow, please call me out in public (here or the town square where you live) to keep my butt in gear. You added great information and therefore if I commit to add feedback by Tuesday morning, I need to do it. FYI, if you go to your local town square and call me out for not submitting my comments on time, please be sure to mention OpenRocket and please post the video of that here for others to enjoy. :)

Thanks again for the thorough presentation.

Sandy.
 
This feature exists in beta.04. Just select (highlight) the desired simulations, right-click on the highlighted area and select edit, and make the changes. When you close the window, the changes are made to all selected simulations.

I just tried this out at the same time I was testing the recompile of MultiLevelWind that @thzero did.

It works - but I'd note that it has to be used with caution, as it's easy to delete info accidently.
Steps:
Add MultiLevelWind to Sim 11. Configure winds at several altitude. Close.
Select Sim 10 and Sim 11 for edit. Make no changes. Close
Re-open Sim 11 for edit. MultiLevelWind is gone - not present, no levels.

I did it twice to be sure.

Reverse check:
Clear MultilevelWind from both Sim 10 and 11.
Open Sim 10 and Add Multilevelwind, config some levels, close.
Select both Sim 10 and Sim 11. Right click and edit.
Make no changes. Close.
Open Sim 11 - MultiLevelWind and levels now in Sim 11.

So it works really well going down the Sim list. But not working in the up direction.
 
Back
Top