The previous code was just a bit odd and non-standard + variable (and probably unefficient). Decided to replace it with standard Java functions instead.
Some parts of the program need only the bounding box of aerodynamic parts (most parts of the program), but a couple others need the bounding box and length of all components
Fixes unit test errors by changing hardcoded values to the values the
new code outputs. The new code is believed to be correct so this should
be alright.
Change to use a LinkedHashMap instead of a HashMap in the
FlightConfigurableParameterSet. This ensures that the ordering is
consistent with the way the user added the flight configurations.
This will also be true for when reading the flight configurations from
a file. Additionally, to preserve the ordering, do not sort the
FlightConfigurationIds in getIds().
Fixes#845
Signed-off-by: Billy Olsen <billy.olsen@gmail.com>
Commit 936333a2 re-introduced the AxialMethod.ABSOLUTE as an offset
method but did not update the corresponding unit test. Add in the
expected offset value for AxialMethod.ABSOLUTE.
Fixes#931
Signed-off-by: Billy Olsen <billy.olsen@gmail.com>
Commit 312e90 updated finset count and tests for FinSets but not
the TrapezoidFinSetTest.testMultiplicity()
Signed-off-by: Billy Olsen <billy.olsen@gmail.com>
TrapezoidFinSet fin count was reduced to 1 in previous commits in order
to fix a bug. The actual problem was that the instancecount was not
persisted in the ork file. This change restores the default to 3.
Fixes#850
Signed-off-by: Billy Olsen <billy.olsen@gmail.com>
mass calculations now correctly treat the center-of-mass offset as relative to the individual
component (whereas, previously, it was an absolute offset / relative to the center of the rocket)
testAlphaIIIStructure
Three fins in finset, so Ixx and Iyy are reduced by a factor of 3
Ixx reduced from 5.2771946530250825E-5 to 1.7590648843416942E-5
Iyy reduced from 1.3580770106050167E-4 to 4.526923368683389E-5
Total rocket MOI changed to Ir=1.8763734635622462E-5 and
It=2.1238394331365588E-4
testFalcon9HComponentMOI
Three fins in finset, so
finset rotational MOI changed from 0.00413298 to 0.001377661595723823
finset longitudinal MOI changed from 0.01215133 to 0.004050443797127646
testFalcon9HeavyBoosterLaunchMOIs
Two finsets, each three fins. Each finset's MOI are reduced as in
testFalcon9HComponentMOI, resulting in change to totals
Ir=0.013480523485489424, It=0.07017476021288252
testFalcon9HeavyBoosterSpentMOIs
Two finsets, each three fins, as above
Ir=0.010420016485489425, It=0.06398514917026163
testFalcon9HeavyBoosterStageMassOverride
Two finsets, each three fins, as above
Ir=0.007100144485489424, It=16.030625168315694
testFalcon9HeavyComponentCMxOverride
Two finsets, each three fins, as above
Ir=0.007100144485489424, It=0.047289449862727435
testFalcon9HeavyComponentMassOverride
Two finsets, each three fins, as above
Ir=0.026027963480146098, It=0.35928666329363634
I added parameter and return value desriptions for the method
StringUtil.isEmpty(String s).
Also, I added a test class StringUtilTest to test this method
(this method didn't have a test before).
It turns out that the assumption of radial symmetry is absolutely pervasive in our CP calculations. Looking at FinSetCalc.calculateNonAxialForces(), we don't actually compute the CP of a fin -- we calculate its X value, and pin it to Y=Z=0.
The only exception to this is in BarrowmanCalculator.calculateNonAxialForces(), where the pinning only takes place if there are three or more fins in a FinSet. If we remove the test for number of fins in the FinSet, we are in essence making the assumption that there are more fins *somewhere* which will end up being radially symmetric.
