Results UI Expansion.

[AstroChuck]

In order to support advanced features like #34 and igniter behavior we'll need to model and track the volume of the motor. This itself is straightforward (and already done), but there isn't currently a good place to display it to the user. We're also missing other parameters that burnsim displayed such as volume loading, core L/D, and web. These ultimately aren't critical values, but they're nice to have and will get OpenMotor closer to feature parity with BurnSim. I'm looking for feedback on adding a new tab to the results widget that displays motor data like this. I'm also planning to track exposed liner here. A paint mockup of the proposed UI is attached for comment. The slider performs the same functionality as on the 'Grains' Tab.

A little planning now will help avoid UI 'sprawl' as more features get added, so we can plan out where things like erosive burning options go, potential CEA integration, adding somewhere to track grain spacers, somewhere to add igniters, etc.

[reilleya]

Overall, I like this a lot. I was planning to add a nozzle tab to the results widget for 0.4.0 that would show erosion/slag buildup once I get those features working, as well as exit pressure and other neat stuff like that. My thoughts/concerns are:

• How do we avoid redundancy of information between the grain, nozzle, and motor tabs? I think we would be fine as you pitched it here, but as stuff gets added it would be easy for it to run away as you said.
• How do you represent complex geometries from the side like that? I can't think of a great way without doing some actual 3D rendering, and I think that would be beyond the scope of the software. Have any thoughts?
• I specifically chose to exclude core L/D because it seems kind of ambiguous for motors with multiple core diameters and especially complex geometries. This kind of follows the theme I noticed with burnsim, which is that it was probably built with mostly very simple grain geometries in mind. I think the grains tab is a good place to show web on a grain-by-grain basis over time. Want to make an issue ticket for adding it to the grains tab?

[AstroChuck]

The nozzle could have it's own page, or it could go on this page, but I lean towards the former, especially if we add a slag deposition/throat erosion model. To avoid redundancy between tabs I propose the following scheme, with the disclaimer that I just thought it up, and haven't fully developed it: We create a tab for discrete parts of the simulation such as 'Grains', 'Nozzle', Motor', and maybe some day 'Igniter' 'Case' 'Liner' and who knows what else. In addition there is a 'graph' tab. The graph tab essentially does what it does now. We can eventually tidy it up by creating containers that can be expanded or collapsed to hide more esoteric values. All of the other tabs have the slider currently seen on the grains tab, a graphic of what the part of the motor is doing, and a table of values such as current time step, maximum, minimum, initial, i.e. whatever the useful cases of the values are. When dividing the content, we should aim to display the values at the lowest tier component of the motor that exhibits it. Impulse, for example, would move to the motor tab, while propellant web and Core L/D would be added to the grains tab. If we rigorously plan out the next few releases I'd be down to mock up the UI's all at once so they exhibit some semblance of cohesion. Otherwise we can add things and plan a UI refactor at Release 0.7 or something. This latter might ultimately result in more useable software as we'd get user feedback, at the expense of a couple 'messy UI' releases. As far as how to display complex geometries in the motor, to be honest, I'd planned to slice any of the offset ones in such a way that they always have part of the core visible, and for the finocyl and star geometries I'd planned some form of grayscale to indicate the geometry. The technical details were assumed to be a problem that several hours on stack exchange could resolve (I vaguely had some notion of doing some math on depth of regression mapped to grayscale?). There may not be a 'better' solution and when I'm designing a motor I think a cross section view like that is helpful, even if it doesn't capture 100% of the information. I'd be down to try implementing it and maybe another user can find a cleaner way to display complex cores. Ultimately this feature will help show the phenomenon involved with erosive burning which I think will be useful both for debugging and sanity checking that feature.

I specifically chose to exclude core L/D because it seems kind of ambiguous

I agree. And I don't have a clear answer. There may be a 'rated' L/D formula that exists or we could invent, since I'm pretty sure it's just a heuristic that people have been using since before complicated geometries, or we could tell people that we give them better versions of that information and to get with the times. The per grain idea sounds good. I'll add that ticket.

As an aside, I believe a large portion of the user base for this software is probably using it to make BATES motors with fairly straight-forward geometries. I don't think that's an excuse to develop features that don't work for everything we support, but it might be worth keeping in mind.

[benrussell11]

I agree with Charlie. I believe most user of Burnsim are not using complex grain geometries. Bates and finocel …

Although I don’t know what the new start ups are using.

Ben

From: Charlie Garcia notifications@github.com Sent: Thursday, August 15, 2019 2:41 AM To: reilleya/openMotor openMotor@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [reilleya/openMotor] Results UI Expansion. (#114)

The nozzle could have it's own page, or it could go on this page, but I lean towards the former, especially if we add a slag deposition/throat erosion model. To avoid redundancy between tabs I propose the following scheme, with the disclaimer that I just thought it up, and haven't fully developed it: We create a tab for discrete parts of the simulation such as 'Grains', 'Nozzle', Motor', and maybe some day 'Igniter' 'Case' 'Liner' and who knows what else. In addition there is a 'graph' tab. The graph tab essentially does what it does now. We can eventually tidy it up by creating containers that can be expanded or collapsed to hide more esoteric values. All of the other tabs have the slider currently seen on the grains tab, a graphic of what the part of the motor is doing, and a table of values such as current time step, maximum, minimum, initial, i.e. whatever the useful cases of the values are. When dividing the content, we should aim to display the values at the lowest tier component of the motor that exhibits it. Impulse, for example, would move to the motor tab, while propellant web and Core L/D would be added to the grains tab. If we rigorously plan out the next few releases I'd be down to mock up the UI's all at once so they exhibit some semblance of cohesion. Otherwise we can add things and plan a UI refactor at Release 0.7 or something. This latter might ultimately result in more useable software as we'd get user feedback, at the expense of a couple 'messy UI' releases. As far as how to display complex geometries in the motor, to be honest, I'd planned to slice any of the offset ones in such a way that they always have part of the core visible, and for the finocyl and star geometries I'd planned some form of grayscale to indicate the geometry. The technical details were assumed to be a problem that several hours on stack exchange could resolve (I vaguely had some notion of doing some math on depth of regression mapped to grayscale?). There may not be a 'better' solution and when I'm designing a motor I think a cross section view like that is helpful, even if it doesn't capture 100% of the information. I'd be down to try implementing it and maybe another user can find a cleaner way to display complex cores. Ultimately this feature will help show the phenomenon involved with erosive burning which I think will be useful both for debugging and sanity checking that feature.

I specifically chose to exclude core L/D because it seems kind of ambiguous I agree. And I don't have a clear answer. There may be a 'rated' L/D formula that exists or we could invent, since I'm pretty sure it's just a heuristic that people have been using since before complicated geometries, or we could tell people that we give them better versions of that information and to get with the times. The per grain idea sounds good. I'll add that ticket.

As an aside, I believe a large portion of the user base for this software is probably using it to make BATES motors with fairly straight-forward geometries. I don't think that's an excuse to develop features that don't work for everything we support, but it might be worth keeping in mind.

— 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/114?email_source=notifications&email_token=AL4HO6D6ZNAB4KVTBZNV3NDQET27TA5CNFSM4ILYYR7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4K7Q5A#issuecomment-521533556 , or mute the thread https://github.com/notifications/unsubscribe-auth/AL4HO6FUHPVS7BDPHQGGEJLQET27TANCNFSM4ILYYR7A . https://github.com/notifications/beacon/AL4HO6DC3ZTWCPQYRKKYK63QET27TA5CNFSM4ILYYR7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4K7Q5A.gif