Simulation instability causes crash

[skygering]

When the simulation is unstable, sometimes, I see this error message:

ERROR: LoadError: BoundsError: attempt to access 94-element Vector{Subzero.Status} at index [102]
Stacktrace:
  [1] getindex
    @ ./essentials.jl:13 [inlined]
  [2] fuse_floes!(floes::StructArrays.StructVector{…}, max_floe_id::Int64, floe_settings::FloeSettings{…}, Δt::Int64, rng::Xoshiro)
    @ Subzero ~/.julia/dev/Subzero/src/physical_processes/simplification.jl:243
  [3] simplify_floes!(model::Model{…}, max_floe_id::Int64, simp_settings::SimplificationSettings{…}, collision_settings::CollisionSettings{…}, floe_settings::FloeSettings{…}, Δt::Int64, rng::Xoshiro)
    @ Subzero ~/.julia/dev/Subzero/src/physical_processes/simplification.jl:366
  [4] timestep_sim!(sim::Simulation{…}, tstep::Int64, start_tstep::Int64)
    @ Subzero ~/.julia/dev/Subzero/src/simulation_components/simulation.jl:204
  [5] run!(sim::Simulation{…}; logger::Nothing, messages_per_tstep::Int64, start_tstep::Int64)
    @ Subzero ~/.julia/dev/Subzero/src/simulation_components/simulation.jl:291
  [6] run!
    @ ~/.julia/dev/Subzero/src/simulation_components/simulation.jl:286 [inlined]
  [7] macro expansion
    @ ./timing.jl:279 [inlined]
  [8] run_time!(simulation::Simulation{…})
    @ Main ~/.julia/dev/Subzero/examples/simple_strait.jl:80
  [9] top-level scope
    @ ~/.julia/dev/Subzero/examples/simple_strait.jl:100
 [10] include(fname::String)
    @ Base.MainInclude ./client.jl:489
 [11] top-level scope
    @ REPL[10]:1
in expression starting at /Users/skylargering/.julia/dev/Subzero/examples/simple_strait.jl:100
Some type information was truncated. Use `show(err)` to see complete types.

I think that the instability is causing some of the floes to be removed and therefore, when it is time to fuse them, the floe list is all screwed up.

[skygering]

Potentially on timesteps where we both fracture and simplify, we might have this problem since the floe list is changed within the fractures floes. We need to add the "fuse" field to the fractured floes, or remove them from the fused list... Or, we need to fuse before we fracture, right after the collisions in the first place.

[sdbrenner]

I receive the same error in some tests with instability (kinetic energy growth) that occurs when the timestep is too large. I can reproduce this in simulation: energy_conservation_test_error.txt (note that the extension is changed from .jl to .txt so that I can attach it).

This simulation has most physical settings turned off (including fracturing), with floe_floe_max_overlap = 1.0, and in a doubly-periodic domain.

Note that:

1. If I decrease the timestep from Δt = 10 to Δt = 1 (and adjust nΔt to produce the same total simulation length), then I no longer receive this error (I think floes don't intersect enough to try and fuse)
2. The initial floe array size is 248. I receive the error attempt to access 244-element Vector{Subzero.Status} at index [257]
3. If I close the domain (replace all PeriodicBoundary with CollisionBoundary) then I no longer receive this error regardless of Δt values that I tested (as high as Δt = 1000)

Based on the last point, I suspect that the issue is related to the ghost floes included for periodic boundaries