Add some way for the user to view all information generated by the simulation. This is already relevant because there is currently no way to view mass flux as a function of length, though that number is being generated. Because you are now looking at a variable as a function of both time and position, the problem is in three dimensions and becomes harder to show on a simple graph. I'm picturing a separate window opening up (or maybe a different mode for the graph widget) that shows the desired value as a function of length at a time that is set with a slider below the graph. The graph should update instantly when the slider moves and images of each grain regressed to the appropriate level should be displayed.

Do some research into loosening the assumption that pressure is at steady state. It would be cool to (optionally) simulate things like startup pressure from a known igniter or burst disk, and also to estimate how pressure drops off after all propellant has been consumed.

Formalize the windows .spec file, and get a Mac build working

Apparently this line is added when running pip freeze on Ubuntu and should be removed:
"pkg-resources==0.0.0"

There should be a system for developing the large number of tools that are anticipated. Opening a dialog to enter a number, marking the motor as modified, and handling errors should all be provided so the individual tools don't have to do much more than actually apply their desired change.

It would be nice to view a cross section of the nozzle in the motor editor, especially once more parameters are added with #47.

Allow the user to export a CSV file of simulation data including whichever fields they want.

Instead of printing something when loading an existing propellant that differs from the library, there should be some dialog that allows the user to choose what to do.

Reminder to update the version to 0.2.0 and test loading in old files

Most of text is cut off. It looks fine on windows, but looks like this with Gnome running on arch.

Add a dialog that allows the user to change the diameter property of every grain.

Ideas for things we should consider refactoring:

• main.py: This is a given, we need to extract MainWindow and isolate code that doesn't include UI into a different class, maybe application or something.

• Folder Structure: This is related to the discussion in #56 about where to store default values. Often python projects or packages will have a package for the "overall" project, which can contain code or data common to all sub-modules. If we choose this refactor, our codebase would look like this:

.
+-- _openMotor
|    +-- _ui
|    +-- _motor
+-- main.py
+-- ... etc

This will solve the current issues with circular imports.
Another benefit to this is that we can add new modules, for example the thermo module for Cantera chemical equilibrium which I am planning to tackle soon (maybe post 0.4.0?). This also allows us to post openMotor as a package on pyPI so people can use our libraries and APIs programmatically.

• Style: We should follow PEP 8 style guide wherever possible. We don't have to follow all of it, for example snake_case everywhere is not necessary IMHO, but we should at least consider:

  • class names should be UpperCamelCase
  • line length <= 120 chars (?)
  • two newlines between each class definition
  • .. and more!
    We can use an auto-formatter for this if you feel inclined, Black is pretty good.

• Docstrings: We should try to include docstrings wherever possible, especially in the fmm code and motorlib. UI docstrings are not as crucial but they help.

• Everything listed in #53, but especially C* and per-motor settings.

More suggestions please! We don't need to tackle everything at once, this is just ideas for now.

It seems that the system for detecting that a motor file uses an existing propellant isn't comparing them correctly. It almost always detects that the propellant in the loaded file is different from the propellant in the library, causing the file to be unsaved immediately on opening.

I don't know the best way to handle the conversion on this.

This error shows up every time the application is started, though it doesn't seem to affect anything.

Near shutdown, FMM grains tend to spike up as their contours close when they are very close to the casting tube. Try changing the clean function slightly, or coming up with a new strategy to exclude these points.

The simulation should throw an error alert if there isn't at least one grain

Each motor file (or preferences?) should have a set of associated limits for pressure, mass flux, etc that generate alerts if they are passed.

The program should be able to tell if a file was generated in a past version and migrate its contents to the current specification for the file, if possible. This applies for motors, propellants, and preferences.

Allow the user to import a DXF or image or something to define the core geometry of a custom propellant grain.

There should be a geometry check that makes sure the fin corners don't intersect.

Hi Andrew,

I posted the following on the Rocketry Forum and have moved it to here. Hopefully that is ok.

I haven't used GitHub before, so bear with me. How do I set the issue type?

I've put together Zip file which contains my IREC team's characterization testing. A couple of notes:

• ProPEP 3 was used to determine propellant characterics - A&N etc.
• Their goal is a 98 mm 10 - 20 % N with a smoke grain.

The zip file contains the following:

• 1. *.txt - static test data. File name is the throat in 64's
• 2. *.bsx - Burnsim files - Propellant is 2019 IREC Blue
• 3. *.ric - openMotor files - Propellant is 2019 IREC Blue
• 4. 76mm Characterization Tests.xlsx - Test data. Average and Maximum Pressure calculated and burn time.
• 5. 98 2nd Static Test.bsx - Burnsim for next static test
• 6. 98 2nd Static Test.ric - openMotor for next static test
• 7. 98 2nd Static Test with smoke grain.bsx - Takes into account the 1" propellant delay grain
• 8. 98 2nd Static Test with smoke grain.ric - Takes into account the 1" propellant delay grain
• 9. 2019 IREC Test data.MTD2 - ProPEP3 - average pressure is used calculate A&N

General notes for the above

• For the static test burns, openMotor and Burnsim are close and compare well to the test data.
• However, they do differ in the total impulse and calculated thrust/force.
• Since I used average pressure to calculate A&N etc, Burnsim and openMotor max pressure matches the average pressure. Curious, do you use max or average pressure to calculate A&N?
• I believe this motor is a little on the erosive side.

IREC Test Data.zip

Ben

There should be a warning or error that comes up when an endburning grain has mass flowing into it.

Grains that are shorter than their web do not have the correct shutdown condition.

The first surface area call returns a value that is ~5% too large, leading to a KN/pressure/thrust spike that almost resembles erosive burning.

Add an "about" dialog that shows the logo, current version, and license information.

This apparently has something to do with UI scaling on Gnome. Will likely be fixed when the left menu bar is made larger to accommodate a duplicate button for #45.

Implement some model for erosivity. This will probably require more information from the user and be somewhat slow, so it should be optional. It will require grains to be sliced along the motor's major axis and for each slice to have a separate regression rate. It will still be easy to calculate volume and area with the "sliced grains", but performance will be bad for FMM grains due to how many contours will need to be calculated. This will require a lot of testing.

There should be a widget that takes in a perforated grain and displays the generated geometry. It should also be able to display the grain's regression pattern. The UI should be minimal as it will be used on the grain editing screen.

Though the file menu usually saves the user from this kind of error, it is possible to crash the program by trying to write to a read only file. There should be a popup to tell the user something went wrong.

It seems that other UI elements may need manual repaints to get them to redraw on OSX. The grain table is one example, and any others should be found. Try to find a solution at a higher level before just throwing a repaint into every update function.

Allow the user to export an image of the thrust/pressure/kn curve, and maybe add support for statistics to be overlaid on it.

I really like the designer and how the Face etc are updated in real time as you change the various design parameters.

I've been doing some testing of the grain editor with the latest build.

• End Burner - Doesn't display the tab showing Face/Regression/Area Graph. Should it?

• Errors- If you have any errors in the grain design, the errors are caught and reported when your "run" the sim. I believe it would be more user friendly if grain errors were displayed when the clicks on the Apply button.

• Add Grain button - When you click on "Add grain" it looks like the grain is added to the grid then the grain editor is displayed. If I cancel w/o editing or realize I picked the wrong grain type and wanted to cancel and not add the grain, the grain is still listed in the grid. Is it possible to first display the grain editor and then add the grain to grid when the user selects "Apply". Cancel would not add the grain.

Ben

The program should start up to a blank slate. The propellant selector should have a "-" option for when the current motor has None set as its propellant, and this should mesh well with deletion of the current propellant. This is also a good time to revisit all of the motor editor stuff and add some signals instead of calling the setup____ functions everywhere.

Until the detailed graph of stats is available, it is not currently possible to tell where the calculated peak mass flux is. There should be a field after the value itself that tells which grain it was found in.

Example:
Peak Mass Flux: 1.2 lb/(in^2*s) (Grain 4)

This causes a crash in the propellant editor when it tries to update c*.

The geometry calculations should not change for performance reasons, but it should be able to be displayed on the grain visualizer and reuse code for mass flux.

Unclear if it would save to the same location.

Ideas:

• Simulation settings (Ambient pressure, nozzle efficiency, burnout threshhold, erosive burning toggle, etc...) should be saved per-file, yet also have configurable defaults for new motors (a la OpenRocket).
• Same as above, with configurable simulation alerts
• Update UI to include "run simulation" button

Potentially breaking changes:

• Replace T with C* (keep molar mass as its used in nozzle exit calculations?), or, just add C* and use that wherever appropriate in the simulation.

@reilleya thoughts on each of these? I will add changes to the erosive burning branch

Motors currently do all calculations based on the propellant type of the first grain.

Confirmed to happen on load, probably happens on saving too.

The motor designation displayed in the motor stats list is shown like "H128.0" when it should be "H128".

Some (preferences, at least) are qWidgets for some reason.

We can use https://pypi.org/project/pyqt-distutils/0.5.2/ to help manage .ui files so they are statically compiled by setup.py. This is apparently more "pythonic" than using loadUi() (which is also quite slow, it essentially runs pyuic each time at runtime.

After the .ui files are compiled, we can then import the compiled python source code as a normal file. This enables better inspection in addition to a speed boost.

Thoughts?

Change how thrust is calculated. Calculations should take into account details like convergent/divergent section angles and throat length to reduce dependence on the "efficiency" that thrust is currently scaled by.

The simulation should detect error conditions like mass flow attempting to go through an endburning grain. If an error is encountered, the simulation should stop and tell the user what is wrong. There could also be user-configurable errors for limits like case max pressure and erosive mass flux being exceeded.

Provide the ability to duplicate a selected grain. If the user has selected a previously entered grain, pressing the "Add" button would add the grain.

These tools should allow the user to enter a desired KN (either initial or peak) that the nozzle throat will be adjusted to meet.

I'm using the unpacked version as start up time is a lot quicker.

Instead of reentering everything, I created the propellant "2019 IREC Blue" and modified each of the simulation files (ric) as follows:

1. Added "data:" as the first line
2. Indented all lines with 2 spaces
3. Appended the following
   type: !!python/object/apply:uilib.fileIO.fileTypes [3]
   version: !!python/tuple [0, 1, 0]

For some reason or other, the attached sim file will not load. Program aborts w/o any kind of a message. All of the other modified sim files load and execute correctly.

Still haven't figured out how to assign an "Issue".

Can't upload *.ric files directly. Had to change the extension to "txt". Is there anyway to attach ric files w/o changing the extension?

#24 does not load.txt

Add support for importing motors from burnsim files, and also support the creation of burnsim files using motors built in openmotor.