Verification tests check that the simulation model has been implemented consistently. In other words, verification tests check that the math of the simulator is consistent with the intended governing equations. These tests do not test that the governing equations are appropriate in the first place, which is done through BlasterSim’s validation tests.
Every time step, BlasterSim performs internal consistency checks to alert the user if the simulation is becoming inaccurate in a detectable way. If an error is detected, BlasterSim terminates the simulation and prints out the return code. These checks are made in the check_sys subroutine of cva.f90. See § 1.5 for details.
BlasterSim contains hundreds of run-time assertions which perform deeper internal consistency checks. These additional checks are disabled in the released versions of BlasterSim for speed but are enabled during all developer testing runs for debugging purposes.
BlasterSim is periodically tested with randomly generated input files, which is called fuzz testing. Fuzz testing has mostly improved BlasterSim’s robustness and had no impact on the correctness of the result. Before fuzz testing, BlasterSim would crash on certain inputs either due to mass or energy going negative in a control volume, the energy conservation tolerance being violated, or an invalid floating point operation, for example. These errors were mostly solved by adding stricter input validation to catch physically impossible inputs (that the fuzz tester itself can not know are physically impossible), better internal error detection and reporting, adding adaptive time stepping in response to mass and energy conservation errors reaching a certain threshold, and improving the numerical stability of floating point operations. These robustness improvements will be useful when design optimization is added as an optimizer is similar to a fuzz tester in that it will try many strange inputs, and BlasterSim not crashing is necessary for the process to continue.
Variables in BlasterSim are assigned units like meters or seconds, allowing the Fortran compiler to check for inconsistencies. This is achieved through a system called genunits which generates a custom Fortran module containing the required Fortran types [15, 16]. This system has proved useful to locate bugs as the compiler will often know precisely where the unit inconsistency is. A failing test will rarely provide such precision.
Some examples will illustrate how this works from the programmer’s perspective. Consider the following Fortran code:
The units module contains Fortran derived types and associated operations which allow for unit checking. When test_units_pass.f90 is compiled and run, the following output is produced:
However, consider what happens the velocity v is given the wrong unit:
test_units_fail.f90 will not compile, returning the following when compiled with gfortran :
The compiler error message quickly tells the programmer that this code has a bug. In this case, the bug is in the variable definition and not in the highlighted line, however, often the compiler will identify precisely which term in the line has the bug.
The specific units used in cva.f90 and BlasterSim’s core simulation procedures otherwise are SI units. BlasterSim input and output may use other units, but the genunits types themselves represent SI units.
The test suite mentioned at the start of § 3 has 390 the vast majority of which are verification tests checking that various functions and subroutines of BlasterSim produce the expected results. This section details some of the more important verification tests.
To test that the time integration in BlasterSim is working correctly, an exact solution for a simple case was constructed. This case has only two control volumes, one for the barrel, and one for the atmosphere. See figure 3.1 for an illustration of this test case.
The barrel is initially filled with pressurized gas and the projectile has both dynamic and static friction pressure set to . The tube has a constant cross-sectional area of , so the volume of the barrel is . The gas is ideal with a constant ratio of specific heats, , and the process is adiabatic, so in the barrel [8, p. 129, eq. 3.53]. So for any time , the pressure in the barrel is
| (3.1) |
which can be rearranged and simplified to
| (3.2) |
where and are the initial pressure and projectile position, respectively.
The equation of motion of the projectile is
| (3.3) | ||||
| (3.4) |
The trick can be applied to solve this nonlinear differential equation for as a function of rather than . Substituting in the trick returns
| (3.5) |
Now integrate from an initial velocity ():
| (3.6) |
Evaluating the integrals returns the projectile kinetic energy as a function of :
| (3.7) |
In terms of the projectile velocity, the result is
| (3.8) |
This case was implemented in test_cva.f90 in the subroutine test_exact. For s, the numerical error was measured at m/s, which is negligible. The numerical order-of-accuracy was measured at , which is close to the theoretically expected order-of-accuracy of for the RK4 integrator. In other words, not only does BlasterSim closely match the exact solution, but BlasterSim’s numerical error decreases at the theoretically expected rate as the time step decreases. This is the most rigorous test that can be made with an exact solution. For more information on order-of-accuracy verification, see Roy [10, § 2.3].
In figure 3.2, a constant velocity () plunger is approaching the end of the plunger tube. In BlasterSim, a constant velocity plunger can be created by making the plunger have infinite mass, so no force will be able to change the plunger’s velocity. The mass flow rate out of the plunger tube is set to a constant defined so that it perfectly balances the plunger mass flow rate:
| (3.9) |
Note that is negative here, so is positive. Because , , and , are constant, is necessarily also constant. The internal energy and temperature also end up being constant due to the balance of the mass flow rate, but the derivation is omitted for brevity.
Equation 3.9 will necessarily be the mass flow rate as approaches 0 because there will be no volume to absorb the difference between the plunger mass flow rate and the mass flow rate out of the plunger tube, so this test case should approximate conditions as the plunger approaches impact. Note that for numerical reasons, the minimum position of the plunger will be , which is greater than zero, as discussed in § 2.1.9, so will not actually approach zero.
The solution before impact is:
| (3.10) | ||||
| (3.11) | ||||
| (3.12) | ||||
| (3.13) | ||||
| (3.14) | ||||
| (3.15) |
where is the initial plunger position.
The plunger impacts the end of the plunger tube at time
| (3.16) |
The solution after plunger impact might not be possible to express in closed form and is not of particular interest aside from the plunger velocity after impact, .
The solution in this case is simply a series of linear algebraic equations, and BlasterSim solves these equations extremely accurately even for large time steps. Consequently, the order-of-accuracy test used in § 3.1.5 can not be applied as the numerical error is negligible. After the plunger has moved for s (which is well before plunger impact), the error in is kg, the error in is J (negligible compared against the expected energy of J), the error in is m, and the error in is m/s. The error in is s. Immediately after impact, the error in is m/s.