Results and Conclusions

Much of our project relied on qualitative evaluations of the on-screen simulation. During development of the simulation, we paid close attention to graphical issues. One example of a graphics bug we encountered was the drawing of water cells around each nucleus. Using the built in fillRect() function resulted in a flashing-like effect where the water and the nucleus overlapped. To resolve this, we created a new fillRectAroundCircle() function which bitmaps the non-overlapped areas to draw.

Another graphics bug we encountered was the black-streak issue we discussed in the Issues and Optimizations subsection within Software Design. Here we faced a quality issue where black trails were left on screen by neutrons. The initial solution for this ended up being too costly in terms of timing-–we couldn’t afford to redraw every cell on every frame. We took a two-pronged approach to first reduce the frequency of this issue, then to divide up the redrawing strategy to a few areas of the screen on each frame. We believe this to be the right trade-off in terms of quality and simulation timing.

Otherwise, there are no qualitative issues with our simulation, including flickering, stuttering, concurrency issues between cores, or unintened bugs in the simulation accruacy.

One of the original design goals for the project was to be able to recreate both controlled and uncontrolled nuclear fission chain reactions. We successfully implemented every simulation feature we originally intended. Furthermore, these features were able to work cohesively to simulate both controlled and uncontrolled fission chain reactions.

Using the auto setting for the control rods, the simulation works to maintain the target number of neutrons. On the other hand, we can use the manual setting to override this control and remove the control rods all the way–simulating a Chernobyl-like situation where the control rods get stuck. This absolutely results in a runaway reaction, reaching over 1000 neutrons on screen–about 20 times the amount in a stable reaction.

The simulation is more than capable of meeting the 30 fps deadline in most cases. Within 200 neutrons on screen, we have about 20000 µs of spare time to yield. This spare time does “evaporate” quickly under runaway reaction scenarios. This could easily be handled with an overclock on the RP2040. However, we thought it was befitting of the meltdown scenario to run into framerate issues.