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

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):

Will sent me some info on how to install PUEOsim. I attached a markdown file he sent for how to install PUEOsim. He also sent the path to pre-compiled installation of PUEOsim. Here's the path to the pre-compiled installation: /users/PAS0654/wluszczak/PUEO_shared

Here is his full message, which details that you must also run set_env.sh before running PUEOsim:

a pre-compiled version is located at /users/PAS0654/wluszczak/PUEO_shared . Inside that directory, there's a set_env.sh script that you will need to source before running anything (hopefully this works, though there's a high probability you might run into permissions issues with the dependencies).

To run PUEOsim, use the following (see here for instructions: https://github.com/PUEOCollaboration/pueoSim):

./simulatePueo -i {inputFile} -o {outputDirectory} -r {runNumber} -n {numberOfNeutrinos} -e {energyExponent}

The outputs will be root files, but it should be possible (either modifying our own version directly or with a script) to print out the effective volume to a .txt to read.

This is a duplicate post of a previous post from the end of 2020 where I listed the important runs with some of their details in a table (as below). I am extending this table to include the important runs that have been conducted since this post. This includes the run used for the paper as well as the curved run done earlier this year.

In order to access the data for these runs, you can find them by going to this directory: /fs/ess/PAS1960/BiconeEvolutionOSC/BiconeEvolution/current_antenna_evo_build/XF_Loop/Evolutionary_Loop/Run_Outputs

Some of these runs can also be accessed in the old project space directory, though they should all be contained in the above directory. Here's the path if interested: 

The runs are contained in directories available in the above path. Use caution when listing files in some of these directories--some contain many files (primarily the .uan files -- more recent runs are better organized), which means it may take a long time to list files/directories.

Today I removed some of the run directories which had very little or no data or weren't worth keeping around. There are still a few that I think can be removed, but I'm keeping them until we can get a consensus that they can definitely be removed. Below I listed the names and descriptions of the runs that I think we should definitely preserve going forward. In general, the more data contained in the run directory, the more important it is to keep around. 

We are trying to do a short run of the asymmetric bicone so that we can see how it tries to evolve the antenna when the minimum length is lowered from 37.5 cm to 10 cm. Currently, there is a problem with the loop in the asymmetric version. Attached is the run detail file.

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

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. 

 

In this post, I'm going to give step by step instructions on everything you need to do to run the loop. See Julie's thesis for the most recent iteration of this manual. Also refer to entry 123 for a list of some errors we have encountered historically in the loop and how to resolve them, though some fixes may be outdated.

Running the loop

Getting started

Assuming you have followed the instructions from the onboarding tutorials, you should be ready to access OSC through the interactive website. Instead of using ssh to access OSC, the loop requires that you go to this website: https://ondemand.osc.edu/ . Login with your usual OSC credentials. Once there, you will need to request a Lightweight Desktop by clicking on "Interactive Apps" at the top of the page. See the screenshots attached for how to do this. Old documentation may refer to the Lightweight Desktop as a VDI.

You can request up to 24 hours for a Lightweight Desktop, and it should begin almost immediately. After you request it, the website will take you directly to the waiting page. You can navigate to this page yourself by clicking "My Interactive Sessions" at the top of the ondemand page. When the job begins, you will see a blue buttong that says "Launch Lightweight Desktop". Click it and you should have a new tab open that brings you to a remote desktop environment on OSC that you interact with through your browser. 

New runs

If you're starting a new run for the first time (that is, beginning from generation 0), you will need to edit the script that runs the loop. Here is the path:  /fs/ess/PAS1960/HornEvolutionOSC/GENETIS_PUEO/BiconeEvolution/current_antenna_evo_build/XF_Loop/Evolutionary_Loop/Loop_Scripts/Asym_XF_Loop.sh . At the top of the script is a list of variables that can be changed. See the first screenshot attached here.
For a new run, you must change the variable <RunName>, which is the first variable in the list. It should be in quotes and the convention is to start the name off with the date of the run, using YYYY/MM/DD format--this will always keep everything in chronological order when listing directories with <ls>. Other variables are explained in the comments next to them in Asym_XF_Loop.sh and you should change them depending on the type of run you are conducting. 

To begin the loop, type in the command ./Loop_Scripts/Asym_XF_Loop.sh from the Evolutionary_Loop directory.

When the loop begins, you will be asked to press any key. After you hit a key, the loop will run Part A, which executes the GA using the <start> mode. It will then automatically move on to Part B, which creates the antennas in XFdtd. XF will ask you if you want to specify a location for the XF file to be saved. Click <No>. The loop will automatically save the XF directory into the run directory when it finishes with the first part of part B. In principle (that is, barring errors that stall the loop or interruptions due to the VDI job ending), you will never need to manually enter anything to the loop for it to run beyond this point. 

However, if it is your first time using XF, you will need to set the max GHz setting upon startup to 2 instead of the default 10. 

Continuing Runs

After starting a new run, the loop will run automatically. When your Lightweight Desktop job ends, you'll need to get another one repeat the steps above. You will not be prompted for any input. 

Stepping Back

At times, you may want to continue the loop from an earlier point or interrupt the loop and step back. Usually you'll only want to do this within a generation, but it's possible that you will encounter an error or bug at the end of a generation and wish to return back to that point to remedy it before continuing forward in the next generation. This is a very tricky and delicate process that requires a lot of attention to detail. In the future, we'd like to make an option for the loop to do this automatically when given input at the beginning, but implementing that will take a long time and will be very sophisticated.

The state of the loop is recorded in the savestate file located here: /fs/ess/PAS1960/HornEvolutionOSC/GENETIS_PUEO/BiconeEvolution/current_antenna_evo_build/XF_Loop/Evolutionary_Loop/saveStates . The file will be named <Run_Name>.savestate.txt . In it, you will see three numbers. The first one represents the current generation of the loop. The second one represents the state of the loop, that is, which part in the generation it is currently on. The third one represents the individual it is processing. In practice, the third number is rarely relevant, and is almost always 1, though it can be used for Part B, where the loop is processing individuals sequentially, so if it was interrupted on individual eight (for example) you can change the number to be 8 so that it will pick up where it left off without needing to redo the first seven individuals.

If you want to step back to an earlier state in a generation, you'll need to interrupt the loop and revert the state by changing the second number in the savestate file. This is NOT all you will have to do, however. Because of the way files are edited and moved around during states, you will need to manually revert files to be in the format or location needed by the earlier state. 

For example, you may need to revert from state 2 (when XF is creating the antenna geometries) to state 1 (when the GA generates new individuals). In this case, you'll need to edit the savestate file to change the second number from a 2 to a 1. Then, you'll need to change the generationDNA.csv file in Generation_Data to use the values from the previous generation, since the GA will have overwritten that file and uses it to determine what individuals are to be selected from. To do this, you'll need to locate the <gen>_generationDNA.csv file from the previous generation in the <RunName> directory in Run_Outputs. This is should be found here:  /fs/ess/PAS1960/HornEvolutionOSC/GENETIS_PUEO/BiconeEvolution/current_antenna_evo_build/XF_Loop/Evolutionary_Loop/Run_Outputs/<RunName>/Generation_Data . 

The above is a relatively simple example of how to step back in the loop. Stepping back from a late state to an early state will be more complicated, though if you're willing to sacrifice run time you can pretty easily follow the above to just restart a generation. Stepping back to a previous generation will be explained in a future update to this post.

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  

Work in progress. Update on H-pol XF design. The first plot is the gain pattern with ferrite rod sets (blue) vs. with nothing but the copper plates. 
The second plot is the gain pattern with everything but the ferrite rod sets vs. with nothing but the copper plates.
The ferrite rod sets function to narrow the gain pattern.

How To Update PueoSim For GENETIS:

First, whoever updates pueoSim needs access to pueoBuilder, pueoSim, and niceMC on GitHub (ask Will for permissions).

Once you do, go into the peuoSim directory at /fs/ess/PAS1960/buildingPueoSim/

and source set_env.sh

`source set_env.sh`

Then, we want to make copies of the files we are currently modifying for the GENETIS loop.

For PueoSim v1.1.0 these are:

1. nicemc/src/EventGenerator.cc  # Modified to create custom output root files to calculate errors

2. pueosim/test/simulatePueo.cc # Modified to stop the simulation of the LF antenna which is not needed for GENETIS

3. pueosim/src/Seavey.cc # Modified to read in custom gain files

4. pueosim/src/pueo.cc # Modified to read in custom gain files

5. pueosim/include/Seavey.hh # Modifies to read in custom gain files

Currently, I store copies of these in the `/fs/ess/PAS1960/buildingPueoSim/backups` directory in case somebody accidentally overwrites the files in pueoBuilder. 

Once you’ve made the copies, you can run `./pueoBuilder.sh` from the `/fs/ess/PAS1960/buildingPueoSim/pueoBuiler` directory. This will rebuild pueoSim and niceMC, pulling the latest updates from GitHub. 

You may need to delete the pueoSim and niceMC directories in order for the builder to pull the latest version from GitHub. Or, if it’s being really stubborn, move the whole pueoBuilder directory to a temporary location and run the builder from scratch with 

`git clone git@github.com:PUEOCollaboration/pueoBuilder` and then `./pueoBuilder.sh`

Then, you will need to reference the copies of the changed files to make changes to the new version of pueoSim. Hope this doesn’t cause too much of a headache, and when you’re done, return to the /fs/ess/PAS1960/buildingPueoSim/pueoBuiler directory. 

Then you simply type

`make install`

then

`make`

And now, pueoSim should be ready to run!

EventGeneratior.cc Changes and Rationale:

PueoSim’s default output ROOT files are very large and therefore time-consuming to parse through to get the information we need to calculate effective volume and errors. So, we want to create a custom ROOT file with only the variables we want, greatly increasing the speed of the analysis.

To do this, we want to create a new TFile with corresponding TTree and TBranches that will store the loop.positionWeight, loop.directionWeight, and neutrino.path.weight. Then, we want to fill the Tree when a detector is triggered and write the results to the file at the end of the loop.

Sample code for initializing the TFile:

simulatePueo.cc Changes and Rationale:

By default, pueoSim v1.1.0 runs a simulation for the normal antenna and a low-frequency (LF) antenna. As GENETIS is evolving for the main antenna, we are not interested in using computation time to simulate the LF antenna. So, we comment out the lines that initialize the LF detector in this file.

Seavey.cc, Seavey.hh, and pueo.cc Changes and Rationale:

As of pueoSim v1.1.0, the simulation software only has the ability to read in one antenna. This is a problem, as we want it to be able to read in files for any antenna we make. So, we need to change these scripts to be able to read in whatever gain files we want.

The convention the loop uses is to input gain files in the format of 

vv_0_Toyon{runNum}

hh_0_Toyon{runNum}

…

In the ./pueoBuilder/components/pueosim/data/antennas/simulated directory

So, the main change is getting the runNum variable into Seavey.cc file where the gains are read. Currently, we define a global variable at the stary of pueo.cc and pass it into where Seavey is called. This means we have to add runNum as a parameter in Seavey.cc as well as Seavey.hh. Finally, we change the name of the read-in files to be in the above format AFTER dividing runNum by 1000 (this is because pueoSim uses the run number as a random number generating seed, so we divide runNum by 1000 to be able to read in the same gain patterns for multiple seeds of the same individual).

Note: We used to change pueoSim to output a veff.csv file. We now handle this calculation by analyzing ROOT files, so this change is no longer necessary. 

How To Update PueoSim For GENETIS:

First, whoever updates pueoSim needs access to pueoBuilder, pueoSim, and niceMC on GitHub (ask Will for permissions).

Once you do, go into the peuoSim directory at /fs/ess/PAS1960/buildingPueoSim/

and source set_env.sh

`source set_env.sh`

Then, we want to make copies of the files we are currently modifying for the GENETIS loop.

For PueoSim v1.1.0 these are:

1. nicemc/src/EventGenerator.cc  # Modified to create custom output root files to calculate errors

2. pueosim/test/simulatePueo.cc # Modified to stop the simulation of the LF antenna which is not needed for GENETIS

3. pueosim/src/Seavey.cc # Modified to read in custom gain files

4. pueosim/src/pueo.cc # Modified to read in custom gain files

5. pueosim/include/Seavey.hh # Modifies to read in custom gain files

Currently, I store copies of these in the `/fs/ess/PAS1960/buildingPueoSim/backups` directory in case somebody accidentally overwrites the files in pueoBuilder. 

Once you’ve made the copies, you can run `./pueoBuilder.sh` from the `/fs/ess/PAS1960/buildingPueoSim/pueoBuiler` directory. This will rebuild pueoSim and niceMC, pulling the latest updates from GitHub. 

You may need to delete the pueoSim and niceMC directories in order for the builder to pull the latest version from GitHub. Or, if it’s being really stubborn, move the whole pueoBuilder directory to a temporary location and run the builder from scratch with 

`git clone git@github.com:PUEOCollaboration/pueoBuilder` and then `./pueoBuilder.sh`

Then, you will need to reference the copies of the changed files to make changes to the new version of pueoSim. Hope this doesn’t cause too much of a headache, and when you’re done, return to the /fs/ess/PAS1960/buildingPueoSim/pueoBuiler directory. 

Then you simply type

`make install`

then

`make`

And now, pueoSim should be ready to run!

EventGeneratior.cc Changes and Rationale:

PueoSim’s default output ROOT files are very large and therefore time-consuming to parse through to get the information we need to calculate effective volume and errors. So, we want to create a custom ROOT file with only the variables we want, greatly increasing the speed of the analysis.

To do this, we want to create a new TFile with corresponding TTree and TBranches that will store the loop.positionWeight, loop.directionWeight, and neutrino.path.weight. Then, we want to fill the Tree when a detector is triggered and write the results to the file at the end of the loop.

Sample code for initializing the TFile:

simulatePueo.cc Changes and Rationale:

By default, pueoSim v1.1.0 runs a simulation for the normal antenna and a low-frequency (LF) antenna. As GENETIS is evolving for the main antenna, we are not interested in using computation time to simulate the LF antenna. So, we comment out the lines that initialize the LF detector in this file.

Seavey.cc, Seavey.hh, and pueo.cc Changes and Rationale:

As of pueoSim v1.1.0, the simulation software only has the ability to read in one antenna. This is a problem, as we want it to be able to read in files for any antenna we make. So, we need to change these scripts to be able to read in whatever gain files we want.

The convention the loop uses is to input gain files in the format of 

vv_0_Toyon{runNum}

hh_0_Toyon{runNum}

…

In the ./pueoBuilder/components/pueosim/data/antennas/simulated directory

So, the main change is getting the runNum variable into Seavey.cc file where the gains are read. Currently, we define a global variable at the stary of pueo.cc and pass it into where Seavey is called. This means we have to add runNum as a parameter in Seavey.cc as well as Seavey.hh. Finally, we change the name of the read-in files to be in the above format AFTER dividing runNum by 1000 (this is because pueoSim uses the run number as a random number generating seed, so we divide runNum by 1000 to be able to read in the same gain patterns for multiple seeds of the same individual).

Note: We used to change pueoSim to output a veff.csv file. We now handle this calculation by analyzing ROOT files, so this change is no longer necessary. 

Attached is a .txt file you can find in the Evolutionary_Loop directory as Loop_Error_List.txt. It's a list of the current errors we sometimes experience in the loop, along with how to fix them if you encounter them while running. If people encounter errors that aren't in the list, let everyone know in the #genstudents chat on slack and update the file with the error message and when it was encountered (what state the loop was in) and the possible cause and solution if you know it. 

We want to automate tests in pull requests in GitHub to run unit tests on individual functions to ensure they return the expected results. This will help prevent bugged code from being pushed to working branches. We will add a list of unit tests to this ELOG as we design them.

Here are a collection of antenna gain patterns with the antenna power source located at various heights at 500 MHz. The heights are indicated in the name of the images and were located at 3cm, 6cm, 12cm, and 24cm from the base. One thing to note is that the power source becomes longer as a function of height (since it's connected to the ridges, which slope back). 

The 3D gain plots attached show the gain becoming more uniform until we get to the last one, where it seems to reinvert and be much stronger in the upward direction than below. I'll update this post with some polar slices for a more complete comparison between them.

EDIT: 07/17/23

I've made a few adjustments and added plots of them.

• First, I separated the ridges. Previously, the ridges touched at their inner corners. This electrically connected them and may be why we saw very high peaks in the first set of impedance plots. You can see the plots named Separated_Impedance_<x>_cm.png.
  • This appears to have lowered the peaks considerably and also shifted them to lower frequencies. The peaks are still high when the source is placed high.
  • We seem to be developing another peak at higher frequencies, although this also existed in the previous tests for the high sources.
• After this, I added a waveguide and positioned the source between the extensions of the ridges into the waveguide. I've also added a picture that shows the waveguide in the geometry. 
  • The sources here are positioned from 1 cm below the ridges to 8 cm below the ridges. The naming convention is the same as above, except it includes "Waveguide" in the name.
  • The peaks are considerably lower here and seem consistent as we place sources further down. They are all below 500 Ohms, compared to as much as 4000 Ohms in the previous tests.

EDIT: 08/10/23

I've been trying more tweaks to the design to get rid of the peaks we see in the plots below. I'm having trouble actually getting the impedance to match close to the 50 Ohm value we expect from the cable. The best case situations seem to come from when the ridges are still touching, which we don't want. Here are the properties I've been changing:

• Ridge positions (gene in GA)
  • We don't want the ridges to touch, but I can't get them to be very far from each other anyway. The minimum wavelength in our bandwidth would be 20 cm, but that's close to the size of the bottom of the antenna for when we make it large, so the separation is still small.
  • When the ridges do touch is actually when I get the best matching,
• Bottom size (gene in GA)
  • I've been changing the size of the bottom of the antenna. This is something that can change substantially between individuals in the GA, so even if I find a good value for this, the impedance it gives wouldn't be the same for all individuals we see in an evolution.
  • This does seem to move the location of the impedance peak (in frequency) but I can't seem to get it fully out of band.
• Waveguide length
  • I've been changing the length of the waveguide between 3 cm and 10 cm. We said that somewhere in the middle should be the most reasonable (the example antenna we saw looked to have a waveguide of ~5 cm long). It seems like the source position is more important.
• Source position
  • I've been moving the position of the power source inside the waveguide. This seems to move around the peak and can lower its height, but I haven't been able to get peaks lower than ~400 Ohms, except in cases where the ridges are in contact.

I've added a picture of the best impedance I managed to get, but this involved an antenna with a small base and ridges touching. My next step is to just try a grid search by making many antennas automatically and simulating them all to look for any that have a nice impedance in our band. 

As of 01/30/2020, the proposal was submitted! The project description and summary are attached below. 

Bicone Loop Status Update: 

The loop currently runs; however, it does seem that if AraSim jobs are left to run while the user is away, it doesn't properly write one or more of the flags, and makes the loop get stuck at AraSim. We must then re-run from that state by manually editing the Save State text file. 

The loop currently has the following additions implemented.

• Functionalized loop (XF_Loop_AraSeed.sh)
  • Cleaner bash script which runs smaller bash scripts, instead of one massive script. 
  • Submits multiple AraSim jobs in parallel for each individual to increase speed. 
    • Ie if 100k neutrinos are thrown per individual ($NNT=100000, $Seed=10) we can, say, break it up into a "seed" of 10 -- which then submits 10 jobs with NNT=10k for each individual. 
  • Still needs this to be fixed: The AraSim run in Gen 0 that gets Veff for the ARA actual bicone input file is not currently being seeded. It is just submitting one job the following way.
    • If NNT=100000 and Seed=10 (ie 10 jobs with 10k neutrinos), it will only run AraActualBicone as 1 run with 10k neutrino number (ie NNT/seed=NNT_New).
• Save State 
  • After every "part" -- ie part a, part b, etc -- of the loop, we save state by writing a series of numbers to a text file. 

    • ${gen}, ${state}, {indiv}

  • If the loop is killed for any reason during the process, the text file is read in, and the loop can continue forward from the last completed item/section. 

  • This saves the state after every individual runs through XF. 

• Antenna sizing

  • The larger the antenna, the longer XF takes to run. A true-to-size ARA antenna takes anywhere from 1.5 to 2 hours per individual. 

  • What we've done: Allowed us to scale the antenna by a factor of "x".

    • If we make the gaussian centered around something, say, 5 times smaller than the ARA antenna size, we then make the frequencies 5 times larger. This should have the same effect. 

    • This also means we've had to scale these sizes back up when plotting. 

    • Still needs this to be fixed: all of this has been hardcoded in! We need to make these variables in the MANY places we need to adjust for this scaling. See the to-do list below for details. 

Moving forward, I will be doing the following:

1. Getting our less coding-savvy teammates familiar with bash, python, and c++. This will be crucial for us when we start adding more parameters to our GA. 
2. Mastering XF (along with Alex, and Alex). 
3. Getting the team to clean up some messy coding done during the proposal hustle. 
4. Fixing some errors. 
5. Teach the ENTIRE team git. 

TO-DO List

The following is our coding to-do list:

1. Get our Ara sim error fixed (Alex, Julie) 

   1. It seems that if AraSim jobs are left to run while the user is away, it doesn't properly write one or more of the flags, and makes the loop get stuck at AraSim. We must then re-run from that state by manually editing the Save State text file.

   2. We are going to try to get XF to run at the command line so that we can submit it as a job. This would alleviate us using an interactive job. We *hope* this would fix the error since the user wouldn't be "gone" while utilizing a GPU in an interactive job. 

      1. Alex emailed XF to ask a few questions! Stay tuned!

2. Make Hardcoded directories variables.

   1. Xmacros (use sed command) 

   2. All over bash script functions.

   3. AraSim job files (sed command?)

3. Make the following variables in the bash script:

   
   In xmacros/simulationPECmacroskeleton_prototype.txt (use sed command):

   Grid spacing=0.1
   Frequency= factor of n higher 
   This factor of "n" higher in frequency has to be the same as the Multiplier_factor in the roulette algorithm AND the same as GeoFactor in fitnessFunction_ARA_amy.cpp.
   
   
   

   In roulette_algirithm.cpp

   Length = 50cm/Multiplier_factor; 
   STD= 15cm/Multiplier_factor 
   Radius = 1.5cm/Multiplier_factor; 
   STD= 0.75cm/Multiplier_factor 
   
   Also the "Multiplier_factor" line 89.
   
   This "Multiplier_factor"has to be the same as the GeoFactor in fitnessFunction_ARA_amy.cpp AND the same as the factor higher in frequency in the xmacro.
   ​NOTE:THIS MUST BE RECOMPILED AFTER CHANGING.
   
   
   
   

   In fitnessFunction_ARA_amy.cpp:

   GeoFactor=2 
   This GeoFactor has to be the same as the Multiplier_factor in the roulette algorithm AND the same as the factor higher in frequency in the xmacro
   NOTE: THIS MUST BE RECOMPILED AFTER CHANGING.
   
   
   

4. Get rid of all code we are not using anymore.  

   1. Currently using: XF_loop_AraSeed.sh

      1. Look at what items are being called in here, and remove old versions such as XF_loop_Prototype.sh, XF_loop_Functionized.sh, and the related scripts. 

      2. These can temporarily moved to on "old code" directory and we can delete once we finalize the loop. 

5. Turn tournament on in the GA. 

6. Parallelize the AraActualBicone job.

   1. The AraSim run in Gen 0 that gets Veff for the ARA actual bicone input file is not currently being seeded.

Atttendance: Julie, Max, Cade, Suren, Evelyn, Sophie

Today's tasks:

Max works on AraSim section (needs to do more research and reading)

Julie, Suren, Sophie, Evelyn work on plotting software to plot gain patterns of indiviudals

Cade preps impuse XF code to be implemented

To-Do list:

I. Divide up sections on paper, and work on them. See http://radiorm.physics.ohio-state.edu/elog/GENETIS/1 for section assignments. 

II. Implement impuse code. 

• This will require us to change XFintoARA.py so that it takes less output files. 
• Is there anything else different with the output files?

III. Finish Evelyn and Sophie's plotting software.

• This means also puting it onto Nutau, and adding in lines to the bash script (both to move and save the images, and to run the code!)

Here are things we can do if we are waiting for Remcom:

I. Change sides of bicone to be sinusoid instead of lines.

II. Take known bicone parameters and put it through AraSim to check if it's working properly.

• This also means we should make plots with it to triple check. 

III. Test GA and make it maximize other paramaters to see how it does.