Erosivity simulation

[reilleya]

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.

[tuxxi]

A good (yet fairly old) resource for this is Universal Behaviour in Erosive Burning of Solid Propellants by Mukunda and Paul (1997). IIRC their model is mass flux threshold based, and requires only Mu (dynamic viscosity of gasses) in addition to standard propellant information.

They recently updated their model to better align with finocyl erosivity data, as seen here.

I will begin implementing this unless you would enjoy tackling it :)

[reilleya]

Sounds good! This is one of the major features that I hope to see in openMotor. I think we should pick a model that minimizes the amount of additional information that the user has to find, because very few people have information past a&n for their propellant. This isn't to say that we shouldn't strive for accuracy, but I value people actually being able to use the feature over using the fanciest model available. My goal is to be able to predict the thrust curve of this motor: This was a fairly high aspect ratio 6" motor that had two long BATES grains and a finocyl at the nozzle end. The current simulation is able to get the burn time and general shape of the thrust curve about right, but it predicts too low of a burn rate towards startup and too high of a burn rate at the end, which I think can be attributed to erosion. If we are able to simulate this motor more accurately, I will be very happy. I have some other data I have collected on large motors that we can compare against.

[tuxxi]

Luckily for us, Mu is a combustion gas constant similar to k, so it is theoretically possible to find it for any propellant if you enter the ingredients into CEA or ProPEP. A stretch goal for post-1.0 could be implenenting an interface to CEA so users would not have to fiddle with that piece of junk.. I messed around with wrapping cea2.f with a more modern API but it's a hassle.

I will investigate if there is a value of Mu that we can use as an assumed constant for unknown propellants (similar to how BurnSim deals with specific heat ratio and molar mass)

[tuxxi]

Would it be possible to send the motor files and test data for that motor so I can test the erosive burning branch? Things are looking OK right now, but there's a few very weird bugs I haven't worked out yet...

[reilleya]

The data is mostly located on the wiki here: https://wikis.mit.edu/confluence/display/RocketTeam/Propulsion+Subteam. Each propellant page linked to at the bottom has links to motors made with that propellant. Of particular interest are these motors: https://wikis.mit.edu/confluence/display/RocketTeam/OW-152-8G+%231 and https://wikis.mit.edu/confluence/display/RocketTeam/OW-98-FIN1+%231, which were extremely erosive. The filters we used on our pressure transducers at the time caused a lag in pressure data, so the erosive spike was not captured in the pressure data for the second motor and has to be inferred from thrust.

I was thinking that we could use memoization to speed up calculating regression data, which I imagine is super slow given how many slices a grain is cut into. Each grain could track a table of regression depths vs contour lengths that it adds each result to. We would have to round regression depth to some number of digits so values actually get reused, but I think this could make it way less slow. Thoughts?

[tuxxi]

I've got erosive burning mostly working now. Here's what it looks like for the sample motor:

Before: no erosive burning: After: erosive burning:

I think that the erosive fraction is a bit too high but we can tune it with test data. Which reminds me, @reilleya can you upload oM ric files of the motors you guys tested?

[benrussell11]

Maybe it's my eyes, the two graphs look the same to me.

Ben

On Fri, May 3, 2019, 7:53 PM tuxxi [email protected] wrote:

I've got erosive burning mostly working now. Here's what it looks like for the sample motor:

Before: no erosive burning: [image: No erosive burning] https://camo.githubusercontent.com/6cb1a931a3f8c55b0eb6e80590b5e5c4de1e9826/68747470733a2f2f692e696d6775722e636f6d2f6f6e4433706d472e706e67 After: erosive burning: [image: Erosive burning] https://camo.githubusercontent.com/6cb1a931a3f8c55b0eb6e80590b5e5c4de1e9826/68747470733a2f2f692e696d6775722e636f6d2f6f6e4433706d472e706e67

I think that the erosive fraction is a bit too high but we can tune it with test data. Which reminds me, @reilleya https://github.com/reilleya can you upload oM ric files of the motors you guys tested?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/reilleya/openMotor/issues/31#issuecomment-489273113, or mute the thread https://github.com/notifications/unsubscribe-auth/AL4HO6B6HKLMOLFVR3AVUD3PTTGBNANCNFSM4HGRTBRQ .

[reilleya]

Looks great! I definitely agree that it is turned up a bit far there, as I wouldn't expect to see too much erosion on a 2 grain motor with that aspect ratio. I was expecting that it would track the regression of each slice separately throughout the entire burn and take into account the different levels of regression of each position along the length while calculating KN, but it seems to get decent results taking the max of the slice burn rates and using it for the overall burn rate.

Here are some files:

• First is the motor that I compared in the image above. It shows both an erosive spike and increased burnrate before the finocyl burns out, and appears to thus have less propellant left in the second half of the burn. The raw data is attached, which is formatted time(ms): force (n), pressure (psi). This is the raw data, so there are minutes of junk before and after the motor fired. flight.ric.txt flight_raw.txt
• Next is the first motor I linked to above. It had very high mass flux due to the cores not being stepped enough and exhibited extreme erosion in both the form of a spike and high burn rate. It appears the burnrate is about 2x what the characterization data for the propellant suggests. These cores were picked before I knew about the issues with burnsim's 'peak mass flux' output always being calculated at the base of the motor, and the main reason I started openMotor (apart from curiosity) was the realization spawned by this motor that burnsim was doing peak mass flux so wrong. The raw data is linked to on the wiki page above, and the .ric file is here: bad.ric.txt
• Finally, the other motor that I linked to above was a monolithic finocyl that followed the predicted pressure/thrust curves out of burnsim well except for a significant spike at startup. It did have a <2 port-throat ratio, which may have been part of the problem, but it also had pretty high mass flux at startup. The raw data is on the wiki and the .ric file is here: finocyl.ric.txt

I can come up with a few other examples when I have time, but you can also look around on the wiki because some of the motors have .bsx files on their pages that can now be imported :). I also requested data from a few people on TRF to see if they have more examples you can test against. Thanks again for taking this, it is probably the feature I want the most out of openMotor. I want this program to be the tool for simulating high l/d motors, and this is a big step towards that objective!

[reilleya]

@tuxxi I fully understand if your interests have shifted, but I was wondering if you had any intent to return to this soon. If not, no problem, and I'll probably take over this issue. If you do want to start again, you'll find that I cleaned up both the ui and motorlib quite a bit on the staging branch and that it might be worth it to start fresh as decent amount has changed. Let me know sometime soon if possible, as the v0.3.0 release is almost done save for this addition. Thanks!

[reilleya]

Moving this to v0.4.0 so I can get v0.3.0 out sooner.

[tuxxi]

@reilleya Hey, I hope you've been well. Things have been a bit crazy for me. I'm sorry I was unable to get back to you for so long - my interests have not necessarily shifted, but I'm not sure I can contribute until maybe the fall.

[reilleya]

@tuxxi No worries at all, and I hope you can get things sorted out! I appreciate the work you did for the project and look forward to maybe getting some more commits in the future.