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>
Stages need to be activated correctly in order to properly
calculate the mass for all components that contribute to
the current launch scenario.
This change ensures that all of the stages from the top-most
stage to the currently active stage are set as activated when
stage mass is being calculated.
Signed-off-by: Billy Olsen <billy.olsen@gmail.com>
Fix the number of motors that are reported. A previous change made
the MotorMount.getMotorCount() return the number of motors which
have been configured. However, according to the javadocs of the
MotorMount interface, the getMotorCount() method is supposed to
return the number of motors that a MotorMount can take for
configuring it. This restores the InnerTube and BodyTube getMotorCount
behavior and adds a new getMotorConfigurationCount() method to
provide the new behavior.
Additionally, the stageMass calculations in the DesignReport were
using a deprecated method which does not return proper component
weights. Change this to use the MassCalculator.calculateLaunch(...)
method, which is consistent with the RocketPanel behavior.
Signed-off-by: Billy Olsen <billy.olsen@gmail.com>
Add unit tests to cover some of the FlightData object and
some of the calculations. This specifically covers the bits
for FlightData.getGroundHitVelocity() where the ground hit
velocity is calculated from a FlightDataBranch consisting
of a series of data points and events occuring during flight.
Signed-off-by: Billy Olsen <billy.olsen@gmail.com>
