New algorithm for `reproduce!` which utilizes `sort!` has issues

[HakanBrian]

Recently I updated reproduce! with a different algorithm which uses sort! to sort both keys and sampled keys, then copies the offspring back into the same population. Theoretically as long as we are sorting this should work because the sampled keys are a subset of keys and are of the same length.

The issue is that when running a simulation with a high variance in the mutation of traits, somehow NaN gets adopted by some individuals, which results in an error when trying to sample the next population. Also, NaN should simply not be occurring regardless.

Comparing this with our previous algorithm, which copied the original population, then copied individuals from the copied population back into the original as the offspring. This method should produce the same results as the new method, but as you can see, we do not run into the same issue somehow.

My guess is that If the mutation introduces NaN values, and these values are not handled before sorting, they can cause problems in the sorting process. On that note, we should investigate whether the previous methods ever ran into NaN values.

[HakanBrian]

After further testing, it seems NaN values are introduced in behav_eq. This issue seems to be present because the solver detects instability and aborts.

This is the case whether the solver is on the CPU or GPU. However, the error message pertaining to instability is only reported when on the CPU, whereas the GPU simply gives you back NaN.

Going back to the solver, it aborts because it receives outrageous values from mutate! and thus encounters instability when solving the ODE. Therefore, a simple solution would be to create a better bound for the normal distribution used in mutate!.