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.
FreeformFinSetTest.testFreeformCMComputation_triangleOnTransition
was broken with the last merge. This change updates the expected
area for the fin tab to be the area of the triangle under the
curve as well as update the new CG contants in the tests.
Identified in #631
Signed-off-by: Billy Olsen <billy.olsen@gmail.com>
Use the information provided in the getActiveInstances() in order to
calculate the length of the rocket. This change takes each component
instance and uses the component bounds and the instance's transform
in order to determine the instance's actual bounds. The length is
then calculated as the difference between the min and max X values,
using the BoundingBox.
Note, this particular change special-cases a few of the components
in order to get the right length. It is preferred to revisit each
special case in subsequent patches in order to keep this patch set
minimal for the time being.
The length calculations are already stressed during unit tests, but
the results are a bit more accurate and thus the unit tests are
updated to reflect the new values.
Fixes#452
Signed-off-by: Billy Olsen <billy.olsen@gmail.com>
