Asym Straight Sides (from the paper - Generation 23, Individual 8)

(inner radius, length, opening angle in radians)

2.08711,89.924,0.0161734
0.30175,45.3616,0.0910478

individual found in 

/fs/project/PAS0654/BiconeEvolutionOSC/BiconeEvolution/current_antenna_evo_build/XF_Loop/Evolutionary_Loop/Run_Outputs/AraSim_Polarity_Fix_2021_03_19/AraSim_Polarity_Fix_2021_03_19.xf/Simulations/001108/Run0001/

Attached is a spreadsheet with the information on the parts we need for the N=14 matching circuit board.

https://docs.google.com/spreadsheets/d/1x8dX3tNE-WSHjH_slj_EH4XsHcAnCVC05XiRBFPtIUc/edit#gid=0

Here we will record where we obtained the ARA bicone antenna response files we use as our baselines. We want to record where we found them/who gave them to us and how they were generated (either through simulation or from actual tests).

Attached are the XF files for the top 5 individuals from the 2022_12_29 crazy sides run. In order from best to 5th best: 

1: Gen 29 Indiv 87

2: Gen 19 Indiv 96

3: Gen 13 Indiv 84

4: Gen 9 Indiv 50

5: Gen 18 Indiv 89

These can also be found in /fs/ess/PAS1960/BiconeEvolutionOSC/BiconeEvolution/current_antenna_evo_build/XF_Loop/Evolutionary_Loop/Run_Outputs/2022_12_29/2022_12_29.xf in the corresponding directories. 

We began a new run of the curved sided GA. Previously, we conducted a run just like this in July of 2022 (titled 2022_07_15_Latest_Greatest). In that run, we made substantial updates to the loop, including using the latest version of AraSim. However, we discovered after the run (which had a very flat fitness score growth curve) that we had not modified AraSim to take in gainfiles appropriately (so it was just evaluating the ARA bicone repeatedly). We've fixed this issue and a few more (see the github repository for the issues that exist and have been resolved) and are redoing this run. The run details will look much the same as that one and are visible in the attached file. Here is the location of the directory where the data for this run will be stored: /fs/ess/PAS1960/BiconeEvolutionOSC/BiconeEvolution/current_antenna_evo_build/XF_Loop/Evolutionary_Loop/Run_Outputs/2022_12_29

For a list of changes made in this run compared to previous ones, see this ELOG post on the previous run: http://radiorm.physics.ohio-state.edu/elog/GENETIS/186

Variables of Evolved Antennas

Wall variables:
S -- length of bottom of the walls
m -- slope of the walls (currently set to 1)
H -- height of walls
x0, y0, z0 -- 3D coordinates of the bottom of the ridge
xf, yf, zf -- 3D coordinates of the top of the ridge
Beta -- curvature of the ridge

Antenna Walls

S is half the side length of the bottom wall
m is the slope of the outer wall
H is the max height of the outer wall

Current Constraints:

S < 50cm
H < 50cm
m = 1

Antenna Ridges

x_0, y_0, z_0 are the innitial points of the inner most part of the ridge
x_f, y_f, z_f are the final points of the inner most part of the ridge
tau is the parametric time range beta is the slope of the curve of the ridge

Current Constraints:

tau = 0.26
x_f = S
0 < x_0 <= x_f
0 < y_0 <= x_0
0 < y_f < z_f
z_0 = 0
0 < z_f <= H
(4/30) * z_f < beta < 7 * z_f (for z_f in meters, designs will 'compile' in xfdtd above this upper limit, but the curve is functionally a line for all values greater)

Here are the changes that have been made in this (and the preceding) run relative to what we have been doing before.

1. The newest version of AraSim has been implemented.
   1. This was done because AraSim has gone through significant changes since 2019 that make it more accurate and makes it run faster.
2. The minimum length has been decreased to 10 cm per side.
   1. This was done because we previously tested shorter lengths for a response to the reviewer when we submitting the paper to Phys Rev D. Previously, we thought that going below 37.5 cm would lead to unreliable results, but we are reassured that that is not the case now.
3. The GA is recording the parents and operators used to generate individuals.
   1. This should allow us to look back and make a "history" of the evolution by seeing where genes come from in each generation.
4. The number of individuals has been increased to 100 per generation.
   1. Ryan demonstrated that a higher number of individuals does lead to a substantial improvement in the speed at which the evolution converges. 
      1. We previously thought that it did not make a big difference. However, that was done by measuring the average maximum fitness score. If we measure how many generations it takes for the evolution to reach a benchmark score, we find that more individuals helps significantly.
5. The number of neutrinos per individual has been increased to 600k.
   1. This was done to make the fitness scores more precise. At 300k neutrinos, we expect an error of around 0.2. This will cut things down closer to 0.1, which may help us decrease the number of outlier measurements without increasing run time too much because of the AraSim speed up.

This run may take longer than previous runs due to the increased number of individuals. There may need to be modifications made to resolve or work around AraSim errors that delay the loop (due to the auto-resubmit function). Find the details of the run attached.

This is the plot for the run type that had the best performance in the most recent optimization run that was completed. The most optimized runs from these collections are decided by which run types achieve a chi-squared value of 0.1 in the fewest generations (correlating to about a 0.9 fitness score). However, the genetic algorithm does not use Chi-squared directly, instead trying to maximize the fitness score (which uses a chi-squared in the denominator) that simulates the error we see in arasim. This fitness score is usually maximized at 1.0 but the simulated error can push the score slightly beyond this. This test was conducted with a simulated error of 0.1. This optimization holds the selection methods steady at 2 tournament 2 roulette and 6 rank selected individuals per 10 selection events. The changing parameter values are in the amounts of Reproduction, Crossover, Immigration, and mutation (rate and width) that the GA performs each generation. Each generation uses 100 individuals. In the graph below, the dotted lines are the minimum Chi^2 values at each generation, solid lines are the maximum fitness score. Each color represents a different run using the same parameters and dotted and solid lines sharing the same color represent the same run. The prevailing trend in the tests leading up to this test has been that the most optimized runs have low amounts of reproduction, high amounts of crossover, and they have been pushing the boundaries of the mutation rate and gaussian width of those mutations and this run follows that trend. The ranges of values we tested over were 0-12R, 88-100C, 15-25M_Rate, and 3-7 sigma, up from the previous test. This run took an average of 16.8 +/- 11.9 generations to reach the 0.1 chi-squared benchmark, the next closest run took 20.3 +/- 10.9 generations to reach the same point, while the most optimized run from an earlier test came in as the 10th best run taking 21.9 +/- 14.4 generations. The graph shows the behavior of this by showing large improvements in early generations that tend to quickly plateau around the maximum value before oscillating around the peak it reaches. Oscillations could be caused by either small mutations around our answer and displacement from the simulated error. The Chi-squared values show a much smoother behavior with smaller oscillations at the end of the run, which helps demonstrate the impact of the error on the behavior.

Here is our current assumption of the antenna angles needed for the icemc inputs. 

The first part of designing the matching crictuit was choosing a frequency range to match over. We chose 100 MHz to 1000 MHz.

The geometric mean of this range in 316.227 MHz, which is the ideal frequeny to match to.

Then, we need the impedance of the antenna we are matching to.

The data for the best antenna is found in 

/fs/project/PAS0654/BiconeEvolutionOSC/BiconeEvolution/current_antenna_evo_build/XF_Loop/Evolutionary_Loop/Run_Outputs/AraSim_Polarity_Fix_2021_03_19/AraSim_Polarity_Fix_2021_03_19.xf/Simulations/001108/Run0001/output/SteadyStateOutput

The files begin at 83.33 MHz and increment by 16.66 MHz, so file 14 (316.57 MHz) is the best choice for matching.

This antenna has Impedance Z = 229.839 -i151.515 ohms

From here, we need to decide a design architecture for the matching circuit. Since the real component of the impedance is greater than the source's (50 ohms, the standard for electrical sources), a natural design is a lowpass downward circuit. 

Next, we decide on a number of L networks to cascade in the circuit design, or how many 'rungs' in the ladder.

The purpose of these rungs is to artificially lower the ratio between the source impedance and the load impedance, as the closer these values, the broader the range of frequencies we can match.

The formula to calculate this is 

N = ln(Rl/Rs)/ln(1+Q^2)

where 

Q = ((Rl/Rs)-1)^½

Rs = real source impedance

Rl = real load impedance

For the given values, N is 14.

From here, we have all the information to find the capacitances and impedances for each L network in the ladder circuit.

The proccess of calciulating these values starts with finding the desired ratio between the impedances. 

ratio = Q^2+1

Which we can use to create a list of 13 impedances between the source and load (corresponding to 14 rungs), each Q^2+1 times larger than the last. Then we can use the formula for a single lowpass downward match between the impedances of each rung. 

All of this process is described in /users/PAS1960/dylanwells1629/improved_match_maker.py

The key functions PCSL, calcN, and broadbandMatchLP

Here is a PDF with a summary/log of my work trying to integrate an ice shell surrounding the bicone antennas in the GENETIS loop. I made gain patterns of the ARA bicone with the ice shells and without them, showing the impact of the ice on the antenna's gain. Having an ice shell changes these patterns, which are also dependent on the radius of the shell. I showed that convergence on the gain patterns and expected features start ocurring for shells with radii larger than 10 meters. I also keep track of the computation time which increases with bigger shells.

Note: I also add PowerPoint slides that contain all the graphs that I made. The PDF does not contain some of those since I didn't think they were coherent with my write-up, but I may be making an omission. 

 

Comparing Inputs:

Frequency Lists:

Ara - 83.33MHz - 1066.70 MHz, step = 13.33MHz

IceMC - 200MHz - 1500MHz, step = 10MHz

Number of files read in:

Ara - 1

IceMC - 8

Formating of files:

Ara - Theta, Phi, Gain (dB, thetra), Gain (theta), Phase (theta) 

IceMc - Frequency, Gain (dB)  (Different files cover different thetas and phis)

File Type:

Ara - .txt

IceMC - no suffix (file with 2 columns of text)

Other notes for IceMC inputs:

IceMC reads in 8 different files for gain.

vv_0  hh_0  vh_0  hv_0  vv_el  vv_az  hh_el  hh_az

Found in ../anitaBuiltTool/components/icemc/data

vv_0 = gains for vertical polarization

hh_0 = gains for horizontal polarization

vh_0 = gains for v → h cross polarization

hv_0 = gains for h → v cross polarization

vv_el = v polarization, e angle

vv_az = v polarization, a angle

hh_el = h polarization, e angle

hh_az = h polarization a angle

for e angle and a angle  in 

       0. 0

1. 5

2. 10

3. 20

4. 30

5. 45

6. 90

(iterates 1 to 6)

Comparing Outputs:

IceMC - veff is in second column in veff+runName+.txt file (in the outputDirectory directory)

Ara - veff is at the bottom of the AraOut.txt file

Here are some reading materials about HPol antennas:

This paper discusses some initial HPol designs that were tested in a prototype station of ARA.  We went with the slotted cylinder design.  

Here you can see what the RNO-G experiment in Greenland has considered.

We can add other sources here as we find them.

Running IceMC:

Go into the directory ../anitaBuildTool/build/components/icemc/

And run the command

• ./icemc -i {inputFile} -o {outputDirectory} -r {runNumber} -n {numberOfNeutrinos} -t {triggerThreshold} -e {energyExponent}

*May need to chmod -R 775 ../anitaBuildTool/comonents/icemc/ if you get a permissions error

inputFile:

Must be the full path to the file

Config files are found in ../anitaBuildTool/components/icemc

Ex: /users/PAS1960/dylanwells1629/anitaBuildTool/components/icemc/inputs.anita4.conf

Config files are found in ../anitaBuildTool/components/icemc

outputDirectory:

Will be made in ../anitaBuildTool/build/components/icemc/ by default, specify full path otherwise.

runNumber: 

The run number.

numberOfNeutrinos:

The number of neutrinos generated in the simulation. 

Can be found in inputs.conf

Default is 2,000,000.

#How many neutrinos to generate

triggerThreshold:

Threshold for each band for the trigger. 

Default is 2.3

#thresholds for each band- this is only for the frequency domain voltage trigger.  If using a different trigger scheme then keep these at the default values of 2.3 because the max among them is used for the chance in hell cuts

energyExponent:

The exponent of the energy for the neutrinos

Can be found in input.conf 

Default is 1020

# Select energy (just enter the exponent) or (30) for baseline ES&S (1) for E^-1 (2) for E^-2 (3) for E^-3 (4) for E^-4 (5) for ES&S flux with cosmological constant (6) for neutrino GZK flux from Iron nuclei (16-22)not using spectrum but just for a single energy (101-114)use all kinds of theoretical flux models

Installing IceMC:

I: Getting anitaBuildTool

Clone the anitaBuildTool repository (https://github.com/anitaNeutrino/anitaBuildTool) to your user.

• git clone https://github.com/anitaNeutrino/anitaBuildTool

II: Get the Anita.sh file onto your user.

 Either copy the file from /users/PAS1960/dylanwells1629/Anita.sh

• cp /users/PAS1960/dylanwells1629/Anita.sh ~

or create a new file Anita.sh with the following code

# .bashrc

# Source global definitions

if [ -f /etc/bashrc ]; then

. /etc/bashrc

fi

#this modules were originally loading in both the env.sh, and bashrc_anita.sh files. This was redundant so it was added here, and removed from the others.                                          

 module load gnu/7.3.0

module load gnu

module load mvapich2

module load fftw3

#module load python/3.6-conda5.2

module load cmake

PATH=$PATH:$HOME/.local/bin:$home/bin

export PATH

export CC=`which gcc`

export CXX=`which g++`

export FFTWDIR=/fs/project/PAS0654/shared_software/fftw3/gnu/6.3/mvapich2/2.2/3.3.5

export ANITA_SOURCE_DIR=~/anitaBuildTool/

export ANITA_UTIL_INSTALL_DIR=~/anitaBuildTool/

export ICEMC_SRC_DIR=~/anitaBuildTool/components/icemc/

export ICEMC_BUILD_DIR=~/anitaBuildTool/build/components/icemc/

export DYLD_LIBRARY_PATH=${ICEMC_SRC_DIR}:${ICEMC_BUILD_DIR}:${DYLD_LIBRARY_PATH}

export ROOTSYS=/fs/project/PAS0654/shared_software/anita/owens_pitzer/build/root

# User specific aliases and functions

#This env.sh is for running the BiconeEvolution GENETIS software. This should only be un-commented if you are running GENETIS software. When you do this, comment out env.sh.                      

#source ~/new_root_setup.sh

source /fs/project/PAS0654/shared_software/anita/owens_pitzer/build/root/bin/thisroot.sh

#source /cvmfs/ara.opensciencegrid.org/trunk/centos7/setup.sh

#module load python/3.6-conda5.2

#BiconeGENETIS directory shortcut SHARED                                                                                                                                                           

alias GE='cd ../../../fs/project/PAS0654/BiconeEvolutionOSC/BiconeEvolution/current_antenna_evo_build/XF_Loop/Evolutionary_Loop/'

#emacs Alias                                                                                                                                                                                       

alias emacs='emacs -nw'

#root alias                                                                                                                                                                                        

alias root='root -l'

#Alias                                                                                                                                                                                             

alias l="ls"

alias python='/cvmfs/ara.opensciencegrid.org/trunk/centos7/misc_build/bin/python3.9'

Then source the file

• source Anita.sh

Note: You will need access to PAS0654 for this step or you will get a permissions error.

III: Running the build tool.

Go into the anitaBuildTool directory

• cd anitaBuildTool

And run the building script

• ./buildAnita.sh

Note: There will be an error if you source files for running Ara in your .bashrc

Comment these out and restart your terminal before running the build. (remember to source Anita.sh before running the build tool. You could also source Anita.sh in your .bashrc)

Error if you source files for running Ara:

CMake Error at components/libRootFftwWrapper/cmake_install.cmake:238 (file):

  file INSTALL cannot copy file

  "/users/PAS1960/dylanwells1629/anitaBuildTool/components/libRootFftwWrapper/include/AnalyticSignal.h"

  to

  "/cvmfs/ara.opensciencegrid.org/v2.0.0/centos7/ara_build/include/AnalyticSignal.h":

  Read-only file system.

Call Stack (most recent call first):

One of our foundational questions tied to the optimization of the GA has been "How many individuals should we simulate". Up to now, our minds were made up for us by the speed of arasim being great enough that the time cost of simulating individuals was great enough that the improvements made from having more were not enough to justify the slowdown. However, with the upgrade to the faster, more recent version of arasim, I decided to re-examine this. This was also spurred on by the fact that the last time I ran this test we were testing GA performance by final generation metrics rather than by how many generations it took to reach a benchmark. So in one of my optimization tests, I tracked this data. 

To start, using the same run proportions, using a .5 chi-squared benchmark, the average time across all 89 run types used in this run was 25.4 generations for 50 individuals as compared to 8.3 generations running the same test for 100. Furthermore, the minimum number of generations for 50 individuals was 4.8 while using 100 individuals yielded 2.4. So on average running 100 individuals was about 3 times fast at reaching this benchmark than with 50. And when comparing the best result regardless of run type, 100 individuals was still 2 times quicker than the min for 50 individuals. Finally, the run that yielded an average of 2.4 generations for 100 individuals took an average of 29.2 generations with 50 individuals or roughly 12 times the generations. 

For the test we will discuss, we ran 89 different run types that all used 60% rank, 20% roulette, and 20% tournament selection respectively. These test had the following ranges:

6-18% of individuals through reproduction (steps of 3%)

64-88% of individuals through crossover (steps of 12%)

0-10% mutation rate (steps of 5%)

1-5% sigma on mutation (steps of 1%)

These tests also used our fitness scores with simulated error of .1 to imitate arasim's behavior and as such we used the chi-squared value to evaluate these scores as there is no error on those values. 

Comparing this same test with a tighter chi-squared benchmark of .25, we see similar results. On average 50 individuals took 37.1 generations to reach this point while 100 individuals took 16.0 generations. Similarly, the minimums amount of gens for 50 individuals was 15.4 while 100 individuals was 5. Finally, the corresponding run for the 5 generation min with 100 individuals took 41.8 generations with 50 individuals. These correspond to speed up's of 2.3, 3.08, and 8.36 respectively. 

This data implies that on average, independent of run type, we should expect to have to use 2-3 times fewer generations while running 100 individuals than we would running 50 individuals but we could see up to 8-12 times fewer generations to reach benchmarks. Another data set using a different set of selection methods was also tested for this and again yielded similar results, though overall the runs from the first batch were better across both 50 and 100 individuals and so those results are likely to be more indicative of the parameters we use in a true run. 

The data being examined in these results can be found here: https://docs.google.com/spreadsheets/d/1GlfnjQSO6VI8MuUGYTUcLkjwDZU98nyFFysgTTfVFOE/edit?usp=sharing  

Update to previous ELOG post for Effective Volumes and Errors for AraSim simulations for antennas from Paper_Run and Curved_Sides.

AraSim version compiled ~11/2021 and the (old) GENETIS version

Here are the column definitions:

• The first column indicates the antenna being described. For example, XF_model_21_20 was the 20th individual in the 21st generation for the run discussed in the paper. Curved_side_1 was the best performing individual from the curved run done in February 2022. Curved_Side_1_Quad_Zero indicates the curved individual with its quadratic term set to 0. Curved_Side_1_Straightened indicates the curved individual with the quadratic term set to zero and the linear term modified so as to keep the outer radius the same as it originally was (that is, for Curved_Side_1).
• The next three columns are the measurements for that individual.
  • The first one idicates the mean effective volume of the runs done for that individual. There were ~300 runs, each of 10,000 neutrinos.
  • The second column indicates the standard deviation of the mean (the previous column). This was measured by taking the standard deviation of the effective volumes (the line that says test Veff(ice) in the AraOut file) from all 300 runs (that is, Sigma(mean - x_i)/Sqrt(300)).
    • example of line:
      • Veff(ice) : 5.25337e+09 m3sr, 5.25337 km3sr
  • The final column indicates the average of the errors on the effective volume measurements from the AraOut files (the line that Veff(water eq.)) divided by Sqrt(300) for each of the 300 jobs (that is, Sigma(x_i/Sqrt(300))/300).
    • example of line:
      • And Veff(water eq.) error plus : 0.552722 and error minus : 0.552722
         

Note: Previously, the best curved individual (according to the run data) had been excluded (instead, we had the 2nd-6th best individuals). This has been corrected, with the order corrected. 

Also find attached a file called full_resimulate_DNA.csv . It contains the DNA for the top five curved individuals, the DNA for those same individuals with their quadratic term set to 0, and the DNA for those individuals with the quadratic term set to zero and the linear term modified to maintain the same outer radius as in the original run. 

Finally, the three images show the original best curved bicone (Curved_Side_1), the best curved bicone when its quadratic gene was set to 0 (Curved_Side_1_Quad_Zero), and the best curved bicone when its quadratic gene was set to 0 *and* its linear gene was changed to keep the same outer radius (Curved_Side_1_Straightened).

We have chosen XF_Model_23_08 to be the one actually built for testing. This was decided based on the data presented here. XF_Model_23_08 was the highest scoring individual in the paper run. Because the paper data was generated using the old version of AraSim, it was decided that using those results would make the most sense for which antenna to build. This would also mean that we can compare directly to the best individual in the paper. This individual was chosen over the curved sided inviduals because it has a higher fitness score, both when using the old version of AraSim and the new version.

We have started a new run. Here is the directory: /fs/ess/PAS1960/BiconeEvolutionOSC/BiconeEvolution/current_antenna_evo_build/XF_Loop/Evolutionary_Loop/Run_Outputs/2022_07_15_Latest_Greatest

This run is a substantial overhaul. It is a curved run using the latest parameters from Ryan's optimization loop. Here is a list of important changes:

1. The newest version of AraSim has been implemented.
2. The minimum length has been decreased to 10 cm per side.
3. The GA is recording the parents and operators used to generate individuals.
4. The number of individuals has been increased to 100 per generation.
5. The number of neutrinos per individual has been increased to 600k.

This run may take longer than previous runs due to the increased number of individuals. There may need to be modifications made to resolve or work around AraSim errors that delay the loop (due to the auto-resubmit function). Find the details of the run attached.

The second-best individual in this evolution was Bicone 22 from generation 40. This individual is, in fact, a fascinating case as we shall see. But to start the story of this individual we will go back to generation 38 in order to demonstrate some of the peculiarities. 

In generation 38 there were two bicones of no renown,  Bicone 11 and Bicone 17. Bicone 11 was a fairly average individual that was ranked 23rd with a fitness score of 4.72016. Its DNA was {*6.16084, ***79.663, 0.0015434, -0.107765} for side one , and {0.308809, 39.6742, -0.0084247, 0.40629} for side two. One day, by chance it met Bicone 17, another average bicone ranked 24th with a score of 4.71877 and DNA {**2.32499, 79.663, -0.00224948, 0.192602} for side one, and {0.308809, 39.6742, -0.0084247, 0.40629} for side two. These two individuals eventually became the parents of two antennas: Bicone 16 and Bicone 17 of generation 39.

Bicone 16 eventually grew to have been ranked 3rd in fitness score of 4.95323. It’s DNA ended up being a complete balance of its parents sharing side one with Bicone 38.11{2.32499, 79.663, -0.00224948, 0.192602} and side two with bicone 38.17 {0.308809, 39.6742, -0.0084247, 0.40629}. Bicone 16 was an individual with high aspirations and hoped to be reproduced. But alas, it was not meant to be. But bicone 16 came upon some amazing luck, it was selected with itself for crossover. This meant that bicone 16 was able to provide two identical surrogates to survive into the next generation. This is where this Bicone fulfilled its full potential. 

The twin bicones were named Bicone 22 and Bicone 23 in generation 40. Being clones, they shared all their DNA with Bicone 39.16. However, due to some circumstances, they had slightly different fitness scores. Bicone 23 managed a very respectable 5.0117 fitness score and was ranked 2nd in the generation. But not to be outdone Bicone 22 managed to score a 5.17014 and ended up being the second-best performing individual of all time. Being so successful, the two bicones ended up producing 8 children between the two groups.

Bicone 23 was the first to crossover and had 2 children with its partner Bicone 25 (4.64409). These were Bicones 4 and 5. Bicone 4 was ranked 39th with a fitness score of 4.60251 and still shared the DNA of its second side with its grandparent Bicone 38.17 as well as most of its first side with Bicone 38.11 {2.32499, 79.663, -0.00213879, 0.192602} {0.308809, 39.9608, -0.0084247, 0.40629}. Bicone 5 on the other hand, was ranked 14th with a fitness score of 4.80535 and it still shared a lot of DNA with its grandparents {6.16084,53.0851,-0.00224948,0.0534469} {0.966617,39.6742,-0.0084247,0.40629}.

Bicone 22 had 6 children of its own with various other Bicones. These were; With Bicone 8.40 (4.82423) Bicone 8, ranked 11th with a fitness Score of 4.81784 and DNA {2.32499, 75.9855, -0.00224948, 0.192602} {0.966617, 39.6742, -0.00320023, 0.213833}; Bicone 9, ranked 7th with a fitness score of 4.88966 and DNA {6.10508, 79.663, -0.000594616, 0.0351901} {0.308809, 42.4246, -0.0084247, 0.40629}; With Biocone 16.40 (5.01137) Bicone 12, ranked 12th with a fitness score of 4.81705 and DNA {6.42695, 75.9855, 0.0015434, -0.107765} {0.308809, 39.6742, -0.00320023, 0.213833}; Bicone 13, ranked 2nd with a fitness score of 5.0344 and DNA {2.32499, 79.663, -0.00224948, 0.192602} {0.966617, 42.4246, -0.0084247, 0.40629}; With Bicone 4.40 (4.66578) Bicone 34 ranked 3rd with a fitness score of 4.99864 and DNA {0.66148, 73.5522, -0.000594616, 0.00582814} {0.966617, 39.6742, -0.0084247, 0.40629}; and finally Bicone 35, ranked 22nd with fitness score 4.74955 and DNA {2.32499, 79.663, -0.00224948, 0.192602} {0.308809, 42.4246, -0.0084247, 0.40629}

Upon inspection of the children in generation 41, you will see that none of the children surpassed their parent individual with the highest fitness score. They do however tend to have fitness scores around or above their second parent's score. Therefore, it is likely that the children's lower fitness score is due to a mismatch of genes. If we look at the rainbow plots provided, we can see that the genes of the worst-performing child are not dissimilar to those of individuals that scored higher than 5. This would imply that the fitness score found could be due to variations in Arasim similar to those seen from individuals 16.39 to 22/23.40 despite them being identical. Though it also could be possible that the graphs do not have a fine enough display to be able to clearly tell some of the genes apart. 

*Gene originating from Bicone 38.11

**Gene originating from Bicone 38.17

***Gene originating from Bicone 38.11 and 38.17 that is shared between the two.

Amy: We want to nail things down in places where we still have hypotheses for what could have happened.  For example, "This would imply that the fitness score found could be due to variations in Arasim similar to those seen from individuals 16.39 to 22/23.40 despite them being identical. Though it also could be possible that the graphs do not have a fine enough display to be able to clearly tell some of the genes apart."  These two hypotheses can easily be distinguished by running with higher statistics and looking at the numbers rather than relying on the resolution of the display.

Amy: Also, at each stage, I was looking for the random numbers that were generated that led to the selection of the fractions of the population that were used for each type of selection and operator.