reilleya / openmotor Goto Github PK
View Code? Open in Web Editor NEWAn open-source internal ballistics simulator for rocket motor experimenters
License: GNU General Public License v3.0
An open-source internal ballistics simulator for rocket motor experimenters
License: GNU General Public License v3.0
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.
Some (preferences, at least) are qWidgets for some reason.
The motor designation displayed in the motor stats list is shown like "H128.0" when it should be "H128".
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
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.
The simulation should throw an error alert if there isn't at least one grain
This causes a crash in the propellant editor when it tries to update c*.
Allow the user to import a DXF or image or something to define the core geometry of a custom propellant grain.
Formalize the windows .spec file, and get a Mac build working
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:
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?
Add support for importing motors from burnsim files, and also support the creation of burnsim files using motors built in openmotor.
These tools should allow the user to enter a desired KN (either initial or peak) that the nozzle throat will be adjusted to meet.
It would be nice to view a cross section of the nozzle in the motor editor, especially once more parameters are added with #47.
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.
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.
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)
Apparently this line is added when running pip freeze on Ubuntu and should be removed:
"pkg-resources==0.0.0"
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.
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.
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:
The zip file contains the following:
General notes for the above
Ben
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.
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.
Confirmed to happen on load, probably happens on saving too.
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.
Unclear if it would save to the same location.
There should be a warning or error that comes up when an endburning grain has mass flowing into it.
Add a dialog that allows the user to change the diameter property of every 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.
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:
UpperCamelCase
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.
This error shows up every time the application is started, though it doesn't seem to affect anything.
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.
Reminder to update the version to 0.2.0 and test loading in old files
I don't know the best way to handle the conversion on this.
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.
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.
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.
Motors currently do all calculations based on the propellant type of the first grain.
Ideas:
Potentially breaking changes:
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
Grains that are shorter than their web do not have the correct shutdown condition.
Allow the user to export an image of the thrust/pressure/kn curve, and maybe add support for statistics to be overlaid on it.
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.
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.
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.
There should be a geometry check that makes sure the fin corners don't intersect.
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.
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.
Allow the user to export a CSV file of simulation data including whichever fields they want.
Add an "about" dialog that shows the logo, current version, and license information.
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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.