Single stage rockets:
Without confirming the accuracy of the values (just comparing to pre-PR designs), this PR appears to function as expected without any anomalous behavior; single fin rockets do not always have matching Cd values.

Multi-stage rockets:
Changing fin count with open analysis window or turning a stage on/off.

or turning a stage on/off.

That issue was already addressed in #1477 and fixed in #1478. The exception when changing the fin count is however new, I'll look into it.

@hcraigmiller could you elaborate on how I can recreate the NullPointerException when changing the fin count?

My steps:

1. Open 'Three-staged rocket' example file
2. Open Component Analysis window
3. Move to 'Drag characteristics' tab
4. Open the fins from the sustainer stage
5. Change the fin count
   No error... Is it possible you first turned of the stage, turned it back on and then changed the fin count? In that case, I get the exception, but that has nothing to do with this PR, and is because of [Bug] NullPointerException in the component analysis window when disabling a stage  #1477

After further testing, simplified steps (using Build 770):

1. Open Three-staged rocket example (closing Rocket configuration pane),
2. Open Tools -> Component analysis pane,
3. Left-click Drag characteristics, then
4. On that pane (or the display stages pane), turn off any stage in any order and the error occurs.

The error only occurs when turning a stage off; when turned back on no error occurs.

I concur that the error has nothing to do with the fin count, it was just coincidence. I will be testing further.

4. On that pane (or the display stages pane), turn off any stage in any order and the error occurs.

Yes, so that's #1477, which you can just ignore. So for your further testing please do not touch the stage selector buttons :)

Functions as expected, not so much of a slight anomaly as a question found.

It appears that the pre-total Cd results are not being mathematically rounded at .001 before the percentage of the total is calculated. Because of this, the total Cd percentage can be a full percentage point higher or lower than if the pre-total results were rounded before the percentage of the total is calculated (the results still add up to 100%). This is apparent when compared to a spreadsheet, but I don't know whether this will be a user issue or not.

I would suggest a small change that would make it more in line with the treatment in the "Stability" tab: show pressure, base, friction, and total Cd per instance, and add an aggregate total Cd column (this last would have the same content as the current "Total Cd" column

I would suggest a small change that would make it more in line with the treatment in the "Stability" tab: show pressure, base, friction, and total Cd per instance, and add an aggregate total Cd column (this last would have the same content as the current "Total Cd" column

Interesting that you mention this, because I just noticed that the instance mass only seems to work for pods . For instance for a fin set, the instance mass and aggregate mass are the same, but for a nose cone inside a pod set, the aggregate mass is the nose cone mass times the number of pod instances. Is this how it should work? And should the same behavior be applied for the drag tab (the instance CD only differs from the aggregate CD for podsets, not for individual fins of a finset)?

Interesting that you mention this, because I just noticed that the instance mass only seems to work for pods . For instance for a fin set, the instance mass and aggregate mass are the same, but for a nose cone inside a pod set, the aggregate mass is the nose cone mass times the number of pod instances. Is this how it should work? And should the same behavior be applied for the drag tab (the instance CD only differs from the aggregate CD for podsets, not for individual fins of a finset)?

Ping @JoePfeiffer

That is how it's intended to work, but now that you raise the question it isn't clear it should be.

The program regards a fin set as a single entity -- it is a single fin set, not three individual fins. So what the component analysis says is correct; the instance mass is the mass of the whole fin set.

But a user is likely going to be expecting the instance mass to be the mass of a single fin, while the aggregate is the mass of all three. That might well be a better way to express it to the user.

Since it's now correctly reporting how the simulation is calculating finset instances, let's merge it. We may want to revisit whether we want the component analysis to present an instance mass of a single fin to the user, as discussed above.