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

1. Fix the functions for the SLPC, SCPL, and PLSC L networks (change the paramaters to match with the format of our data)

2. Write the PCSL function

3. Create a function to find the number of L networks necessary (N) given a source and load resistance as well as a frequency range.

4. Write a function to broadband match two impedances given a source, load, central frequency, and N. (return a list of capacitances and inductances for the L networks)

We are almost to where we can start the physical building of the antenna! 

I've attached all the information I currently have regarding the building project. Some of it is messy work notes and some is well-structured.

I’ve attached the following files for the GENETIS building project:

• Building Dump.txt 
  • My working notes that I used while trying to simulate the antenna in XFdtd (very messy) 
• Building Dump of Useful Materials.txt
  • List of materials that I found regarding the building project like slides, elogs, etc.
• Simulating Building Model.txt
  • A writeup I made describing my process for simulating the antenna in XFdtd 
• Done with change materials.zip
  • Solidworks model of antenna

I also made a slide deck that contains the directory locations + has graphs HERE.

Physics plots were created for 300K events from the higher statistic simulation results for the 9_50, 13_84, 18_89, 19_96, and 29_87 antennae. 

The simulation was inaccurate because a discrepancy exists between the higher simulation physics plots and the physics plots created for the 300K event results currently in the GENETIS Loop. This can be seen in the attached pdf file. 

The simulation may have been inaccurate due to incorrect gain files. 

The higher statistic simulations must be rerun for the 9_50, 13_84, 18_89, 19_96, and 29_87 antennae.

Attached are images of the matching circuit schematic and PCB design. A parts list is also attached in .pdf and .csv format. The .csv format can be imported into Digikey if necessary.  

Table of component values:

I've completed laying out the PCB for the 14-rung matching circuit. Attached are png files of two PCB designs. One uses LPS5050 inductors while the other uses LPS6235 inductors. The dimensions shown are in millimeters. 

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. 

Hi all, 

The working copy of the user manual can be found here: https://www.overleaf.com/6955763886pjtkckprxsyp

It still need to be tested by someone new to see if edits need to be made. I have uploaded the copy that is finalized as of this day. Note if you click on the overleaf version that may be more up-to-date. This copy is added as a PDF so we can keep track of versions. 

                                                        General update

The following were the fixes we made to make AraSim run:

(1) As of March, the loop breaks at AraSim. We have found that our program XFintoARA.py does not properly format the output in the form that AraSim is looking for (as an input). Jorge gave us a sample AraSim input file to help us edit XFintoARA.py so that it formats the file correctly. Note that we found white space is also must match in order for the format to be correct. 

Now that we have fixed this, AraSim now runs. Attached is the following sample Jorge gave us of the proper AraSim inputs. If needed, it's available to refer back to. 

(2) After correcting the AraSim input file formats (outputs of XFintoARA.py), we ran it. It failed to finish running after hours of run time. We found that we were using default input parameters for AraSim -- which wasn't triggering in a timely fashion. Once we edited the parameters, it ran successfully. Note that this was not run within the loop. Confirmation of the full loop running has not been completed. 

The parameters of interest need to be edited in setup.txt. To see which file in AraSim I am referring to, please see the .txt file attached. Note that we will be editing the bash script to allow the user to change these input parameters there. The following red lines are what need to be set:

EXPONENT=21
NNU=100 // number of neutrino events
NNU_PASSED=10 // number of neutrino events that are allowed to pass the trigger
ONLY_PASSED_EVENTS=1 // 0 (default): AraSim throws NNU events whether or not they pass; 1: AraSim throws events until the number of events that pass the trigger is equal to NNU_PASSED (WARNING: may cause long run times if reasonable values are not chosen)
NOISE_WAVEFORM_GENERATE_MODE=0 // generate new noise waveforms for each events
NOISE_EVENTS=16 // number of pure noise waveforms
TRIG_ANALYSIS_MODE=0 // 0 = signal + noise, 1 = signal only, 2 = noise only
DETECTOR=1 // ARA stations 1 to 7
NOFZ=1
core_x=10000
core_y=10000

EXPONENT gives the energy of the neutrinos. Note that higher energies will have more pass, as the energies don't dissipate as rapidly. For now, we are running at this energy. Eventally, we will want to use the full Kotera spectrum. Otherwsie, we would be finding the performance of an antenna at only one energy. Just to check the loop, we are going to use EXPONENT=21 to get events to trigger faster. 

ONLY_PASSED_EVENTS decides which of the two options to use to determine when AraSim is finished running: (1) Throws 'NNU' number of events at antennas and stops regardless of how many pass (in this case ONLY_PASSED_EVENTS=0) , or (2) throws as many events at the antenna as needed until 'NNU_PASSED' number triggers (in this case ONLY_PASSED_EVENTS=1). Ie if this number is 10, we throw as many neutrinos at the antenna as necessary until 10 events trigger. Note that this can result in a longer run time. Additionally, a higher EXPONENT will make them trigger faster. 

TRIG_ANALYSIS_MODE is a setting that determines what is being thrown. Ie- 0=signal + noise (which is what we want, and is the 'real' case), 1=signal only (would make it run faster), 2=noise only (not of interest for us). 

                                                                To-Do List

(1) Commit version of XFintoARA.py since recent formatting change. 

(2) Figure out how to add in Kotera spectrum (note that we wont want to do this until the WHOLE loop is functional)

(3) Edit the bash script to recreat the setup.txt making the variables in red above an editable option in the top of the bash script. Ie our variables in red above will be at the top of the bash script. Later in the bash script we will need to have it create this .txt file with the user inputs for those variables. We can do this by either (1) creating a skeleton, or (2) creating another .sh script that is run in our XFLoop.sh -- which writes the first handfull of lines based on the user inputs for our variables in red above, and then pastes in the rest of what is unchanged in setup.txt. 

(4) Run the whole loop: update- we tried this today and keep getting a Veff-0 for our first antenna along with the error 

Warning in <TFile::Init>: no StreamerInfo found in /datapool/software/anita/lib/G__RootFftwWrapper_rdict.pcm therefore preventing schema evolution when reading this file.
Error in <TStreamerInfo::Build>: AraEventCalibrator, discarding: unsigned short* fAtriPeds, no [dimension]
others run as expected

(5) Work on the paper: Amy added a skeleton of sections to add for the GA. Date of completion should be in-line with APS. 

(6) APS talk slides. 

(7) Edit the manual and add: 

• The changes that will occur when task (3) is done.
• A sample of how AraSim inputs -- or XFintoARA.py outputs -- should look. 
• This stuff: http://radiorm.physics.ohio-state.edu/elog/GENETIS/8
• Max's AraSim plotting software (when it's done)
• Evelyn and Sophie's plotting software info (when it's done). 

(8) Finish Max's AraSim plotting software.

(9) Finish Evenlyn and Sophie's plotting softare. 

AraSim Simulations for Top 5 Antennas from 12/2022 Run with 3 million simulated events

Simulated using Arasim version currently used in GENETIS Loop

/fs/ess/PAS1960/BiconeEvolutionOSC/AraSim/
 

AraSim ROOT files stored in

/fs/ess/PAS1960/ROOT_Files_Higher_Stats/AraSim_Loop_122022/Feb_2023_Crazy_Sides/

Antennas simulated

• Generation: 13, Individual: 84
• Generation: 18, Individual: 89
• Generation: 19, Individual: 96
• Generation: 29, Individual: 87
• Generation: 9, Individual: 50

Results

Conclusion

Antenna from Generation 13 Individual 84 performed the best with these stats

# AraSim CSE Spring 2024 Work

## Goals 
The main goal was to get a working multithreaded version of the AraSim codebase working. Doing this, the hope was to learn how to multithread the code and get it in a good place to hopefully also integrate GPU's at a later date.

## Where is it at currently? 
A bulk of the work done was to functionalize the Connect_Interaction_Detector_V2 to allow for multithreading and to cleanup codebase. 

### Going through code added/changed
Helper functions for multiple parts of code. They went through and split it up into multiple parts. Putting line numbers when needed

Part 1: Clearning Antenna Data
Part 2: Determine gain channel
Part 3: solve ray tracing (Not Done)
Part 4: Process Ray Tracing Solution (Not Done)
Part 5: Calculate Signal Factors (Not Done)
Part 6: Calculate Antenna Gain Factors (Not Done)
Part 7: Process Frequency Domain Signal
Part 8A: Process Neutrino Events. Lines 908 - 1208 (Not Done)
Part 8B: Process Arbitrary Events. Lines 1209 - 1475 
Part 8C: Process Simple Pulser Simulation. Lines 1478 - 1747 (Not Done)
Part 8D: Process PVA Pulser Simulation. Lines 1751 - 2110 (Not Done)
Part 8E: Process Calpulser Event. Lines 2113 - 2445
Part 9A: Process Noise. Lines 2593 - 2955
Part 9B: Process Trigger and Mimic Waveforms. Lines 2994 - 3624

## What still needs to be done? 
- Multithreading still isn't working, multiple threads are writing data to the same place causing the program to crash. This need to be resolved to at least have a working prototype. 

- I believe for multithreading we need to mark explicitly where file/data writing is happening to be able to adjust to make thread-safe

- Double checking that new functions are passing variables in the correct way. The CSE students had this has a slight fear. 

- Some helper functions are still not completed (3-6, 8A, 8C, 8D) 

- Current completed parts of code are all in separate branches and need to be merged after double checking that variable passing is correct

The reviewer of the paper we are trying to publish (as well as other external colleagues we showed the paper to) asked about our minimum length we implemented in the loop. Currently, we cut off the length at a minimum of 37.5 cm for each cone (minimum of 75 cm for the full cone). There is an ELOG post from Amy that presented the reasoning for this ( http://radiorm.physics.ohio-state.edu/elog/GENETIS/81 ). We initially thought that we needed a minimum because the antennas were evolving to be small (around and lower than the minimum). We thought that XFdtd was being inaccurate at lengths lower than 37.5 cm, so we set that as a minimum. To see if we can replicate any strange behavior from XFdtd, I simulated antennas at and below our minimum length and generated plots of their antennas responses. The genes are listed below, corresponding to the patterns in the plot. The results do not look unusual (that is, not dissimilar to the other bicones we have generated, including the ARA bicone) and seem to show an improved sensitivity in the upward direction for shorter bicones. The equation we used to arrive at this minimum (f = c/(4L)) might be indicative of a maximum length rather than a minimum.

2.4892,37.5,-0.00142604,0.032832
4.64522,37.5,0.00153863,-0.14004
2.4892,34.5,-0.00142604,0.032832
4.64522,34.5,0.00153863,-0.14004
2.4892,31.5,-0.00142604,0.032832
4.64522,31.5,0.00153863,-0.14004
2.4892,27.5,-0.00142604,0.032832
4.64522,27.5,0.00153863,-0.14004
2.4892,23.5,-0.00142604,0.032832
4.64522,23.5,0.00153863,-0.14004
2.4892,19.5,-0.00142604,0.032832
4.64522,19.5,0.00153863,-0.14004
2.4892,15.5,-0.00142604,0.032832
4.64522,15.5,0.00153863,-0.14004
 

In my last post, I mentioned (1) our to-do list for adding the ARA hole constraints, and (2) that we've made a mistake upon implementing it. I've attached detailed steps of that to-do list that I've written, as well as an explanation for the correction that is currently being worked on. Please see the pdf attached for an explanation of corrections. 

After some work, I've gotten the physics of results plotting script provided by Dennis working to compare the ARASim outputs from an AREA run to a set of reference data for the ARA bicone (provided by Alex). Among the outputs is a histogram of of events triggered vs cos(theta_nu) (attached here). This is the plot that was previously presented in GENETIS talks in the physics of results discussion.

Here I compared the best individual from the AREA results (Blue- "source_2") that I have on hand (only the ARASim output files from the most recent generation ran are currently saved) with the ARA bicone reference data (Red- "source_1"). Both datasets included a total of 150,000 NNU. Note that the AREA run used was a single frequency test, meaning that the radiation pattern was held constant for all frequencies in the band.

Also attached for reference are the gain pattern of the associated individual from the AREA output and the violin plot of the run producing the data.

Here is some backlogged information as well as recent updates to our progress on AREA and its optimizations:

4/13/2023

We concluded our initial test of the AREA optimization loop. While analyzing our results, we noticed that most of our runs never reached our benchmarks for performance (chi-squared scores of .25 and .1) and that those that did contain abnormally high amounts of mutation. From previous runs using the GA for the GENETIS loop, we find that mutation and immigration (Note: AREA does not use immigration) usually play a smaller role in overall growth and are simply there to promote diversity. Crossover on the other hand is what handles the bulk of the growth done by the GA. Given our results ran counter to that, we decided to look further into the matter.

Upon looking at the fitness score files, we could see that mutation-created individuals did not perform well in the best run types, but the crossover ones did contain the bulk of good scores. This lines up with expectations. However, closer inspection revealed that these crossover-derived individuals had extremely similar fitness scores, which could indicate elitism in selection methods leading to a lack of diversity in solutions. We then looked at a run that used only crossover with one selection type (roulette), and found every individual to have identical (and poor) scores that were the same up to around the 4th decimal place. This is a strong case that the selection methods used are too elitist to grow a population properly. 

We dove into the AREA GA to take a look at the functions doing the selection methods, and discovered several issues potentially causing excess elitism in the GA. It seems that the roulette selection does not behave the way we have used in our other GAs. There appears to be no weighting of individuals; rather, a threshold fitness score is collected and only individuals with a fitness score above the threshold are selected. This causes elitism, as only the most fit individuals are likely to pass this threshold. Tournament was found to be similarly troubled, with a bracket size of ⅓ of the population. This is again very elitist, as it is very large, making it very likely that only the best individuals will be selected. Before we try to further optimize the AREA GA, these selection methods should be addressed and fixed.

For roulette, we propose implementing a similar weighting scheme for individuals as is used in the PAEA GAs that gives preference to the most fit individuals, but still allows others to be selected to encourage diversity of solutions.

For crossover, we propose decreasing the bracket size. This would allow a more diverse range of individuals to be selected through “winning” smaller brackets that would have a lower probability of including top performing individuals.

4/20/23

We (Bryan and Ryan) met to work on improving the selection method functions in the AREA algorithm. 

For roulette selection, we added weighting by fitness score, as is done in the other GENETIS GAs, in an effort to prevent it from disproportionately selecting the most fit individuals only to become parents. As a first test, we ran an abbreviated version of the test-loop code, printing the fitness scores of the parents selected by the roulette method. The fix appears to have passed this initial test, as the fitness scores showed more variety and in the case of roulette crossover two unique parents seemed to be selected.

For tournament selection, the only change necessary appeared to be decreasing the bracket size of the tournament(s), which in turn encourages other individuals besides the most fit to be selected as parents, therefore increasing diversity of solutions. We ran out of time to test this change fully, so we will pick up here in our next meeting.

Looking further ahead, we will plan to work on refactoring the AREA algorithm to use the same functions as the other GENETIS GAs wherever possible. In the meantime, this working version can still be used for feature development so that progress is not halted.

5/11/2023

Upon looking at the results of the recent optimizations, our best runs are still taking over 40 generations to reach an optimized score. Given the speed of AraSim, this is still too slow to be considered optimal. Comparing this test loop run to the ones run on by the broader GENETIS GA, our best runs for the AREA GA are worse than the worst runs from those optimizations. As such, we have decided to pause optimizing the AREA GA in favor of adding it to the broader GENETIS one. As of today, we have finished a rough version of the generating function necessary to create new individuals. We have also started progress on the constraining functions and scaling functions that will be necessary to generate the spherical harmonics used to find the gain and phase. Once these functions are complete, we should be able to transplant this GA back into our test loop for AREA and resume optimizations.
 

• Run Type
  • AREA
• Run Date
  • 04/05/2022
• Run Name
  • 20220405fahimi5run2
• Why are we doing this run?
  • to see if the linear dependence on frequency was properly implemented
• What is different about this run from the last?
  • Under closer examination, the previous run of AREA appeared to not linearly depend on frequency, so we recompiled the GA in order to fix this
• Symmetric, asymmetric, linear, nonlinear?
  • N/A (AREA run)
• Number of individuals (NPOP)
  • 50 individuals
• Number of neutrinos
  • 10,000 per seed
    • 4 seeds per individual
• Operators / Selection methods used (% of each)
  • roulette crossover 50%
  • roulette mutation 16%
  • tournament crossover 18%
  • tournament mutation 16%
• Are we using the database?
  • N/A (AREA run)
• Result
  • There is a problem with how the GA has assigned the Veff values, resulting in many individuals being assigned zero Veff, however the linear dependence seems to have been implemented successfully

Note: We also ran a run called 20220405fahimi5run1, which was a short test run with a very low amount of individuals and neutrinos which seemed to work fine; as in the linear dependence seemed to work.

• Run Type
  • AREA
• Run Date
  • 04/05/2022
• Run Name
  • 20220405fahimi5run2
• Why are we doing this run?
  • to see if the linear dependence on frequency was properly implemented
• What is different about this run from the last?
  • Under closer examination, the previous run of AREA appeared to not linearly depend on frequency, so we recompiled the GA in order to fix this
• Symmetric, asymmetric, linear, nonlinear?
  • N/A (AREA run)
• Number of individuals (NPOP)
  • 50 individuals
• Number of neutrinos
  • 10,000 per seed
    • 4 seeds per individual
• Operators / Selection methods used (% of each)
  • roulette crossover 50%
  • roulette mutation 16%
  • tournament crossover 18%
  • tournament mutation 16%
• Are we using the database?
  • N/A (AREA run)
• Result
  • There is a problem with how the GA has assigned the Veff values, resulting in many individuals being assigned zero Veff, however the linear dependence seems to have been implemented successfully

Note: We also ran a run called 20220405fahimi5run1, which was a short test run with a very low amount of individuals and neutrinos which seemed to work fine; as in the linear dependence seemed to work.

• Run Type
  • AREA
• Run Date
  • 01/18/22
• Run Name
  • 20220118fahimi5run1
• Why are we doing this run?
  • to see if the linear dependence on frequency was properly implemented
• What is different about this run from the last?
  • attempted to evolve gain pattern as a linear function of frequency
• Symmetric, asymmetric, linear, nonlinear?
  • N/A (AREA run)
• Number of individuals (NPOP)
  • 50 individuals
• Operators / Selection methods used (% of each)
  • roulette crossover 50%
  • roulette mutation 16%
  • tournament crossover 18%
  • tournament mutation 16%
• Are we using the database?
  • N/A (AREA run)

• Run Type
  • AREA
• Run Date
  • 04/19/22
• Run Name
  • 20220419fahimi5run1
• Why are we doing this run?
  • Check to see if stringReplacement2.py changes were successfull
• What is different about this run from the last?
  • added below code in order to create a fitness file inside of each generation to display the fitness scores for just that generation, as opposed to just having one big file full of all the generations.
    f2 = open(source + "/" + "gen_{}".format(gen) + "/fitnessFile_gen_{}".format(gen) + ".txt", 'a')
    f2.write(','.join(mean_Veff_array) + "\n")
    f2.close()
• Symmetric, asymmetric, linear, nonlinear?
  • N/A (AREA run)
• Number of individuals (NPOP)
  • 12 individuals
• Operators / Selection methods used (% of each)
  • roulette crossover 50%
  • roulette mutation 16%
  • tournament crossover 18%
  • tournament mutation 16%
• Are we using the database?
  • N/A (AREA run)