Attendance: Julie Rolla, Alex M. 

Today Alex and I met to discuss how to move forward given the COVID-19 restrictions. We have resent out a message polling people's schedules to create online working sessions. Here is what we are planning:

Once we collect times for each group, we will have separate meetings for all of these entities. This way it's easier for us to meet without all having different items to discuss/work on. All of these will be zoom meetings moving forward. Meeting info will be announced shortly!

Tasks for "the Loop Group":

1. Make wall time a variable for XF sim.
2. Test current software edits.
   1. Such as item #1 above
   2. Make sure the bottleneck function is working.
      1. Right now it seems to be working; however, we keep hitting a wall time error. If we can make the wall time a variable then we can be sure the bottleneck function is working, and the wall time is truly the error. 
3. Get Ruby working on XF
   1. when I type:
      /usr/local/xfdtd/7.8.1.4/remcom/bin/xfdtd        I get:

      Info: Using latest available version (7.8.1.4)
      Info: Running /usr/local/xfdtd/7.8.1.4/remcom/XFdtd_7.8.1.4/bin/xfdtd 
      Error: Unable to find executable to run.  This command must exist

4. Get Alex's account of Ruby working. 
   1. He received an email and is still unable to log in. He is touching base with them again. 

Tasks for "the Training Group":

1. Julie and Alex need to finish the C++ project! 

For each new student joining the group, we ask them to onboard by completing each of the following items in the order given:

(1) Go to osc.edu and request an account

• https://www.osc.edu/supercomputing/portals/client_portal/self_signup_for_accounts
• Fill out the info and for the Project Code put PAS1960 (and PAS0654 if you're able to do both).

(2) Complete the following tutorials and reading. Note that the order of these does not matter, however, I would suggest "how to use Git" comes last, as it is the lease important for you to start. Finally, I advise you work on a tutorial concurrently with reading the pages assigned below from my Dissertation. 

• OSC tutorials
  • Because this project uses a lot of computation power, we run on the Ohio Super Computing Center's clusters. Please utilize these tutorials to learn more. 
• Read Julie's Dissertation pages 1-9, 12-20 (starting at section 1.5.2), 28-37 (starting at section 2.3)
  • Feel free to read chapter 3, as it has the history of this project and goes into details of our most up-to-date endeavors. This is optional and not mandatory. 
• Complete the introduction to Bash project
• Complete the introduction to Python Project
• How to use Git (optional)
  • Git is a resource used for version control when writing software. See more for an introduction here: https://www.simplilearn.com/tutorials/git-tutorial/what-is-git
  • BEFORE reviewing this power point, I highly advise you take the code academy class https://www.codecademy.com/learn/learn-git. We use Git and GitHub to keep records and versions of the changes we make, so reverting back to other versions is doable. 
• Make sure to get an XFdtd license on OSC
  • See instructions here 

(3) Finally, review the full manual and complete the bullets below. The full manual is Appendix A of Julie's Dissertation.

• Appendix A of my dissertation is our manual and acts as the holy grail of our research. Anything you need can be found here (from where our info exists on the web, to how to run the code). 
• Once you have read this through entirely, we advise you log on to OSC and explore the code for PAEA in PAS1960. Once you have done so, complete this homework by making a copy of this google doc and filling it out on your own. 

Once these are completed, the students are ready to start helping. This is all of the coding information and basic background information on evolutionary algorithms students must know to be proficient in assisting. 

Other useful materials we have may include:

1. Our old GENETIS manual 
   1. This is somewhat out of date; however, it does have information on the general working on the loop. 
2. Julie's candidacy paper 
3. Complete the writing a genetic algorithm in C++ project
   1. This is still a work in progress! I'll complete it shortly!
4. Read chapter 3 of this book (more if you have time) by Eiben and Smith, "Introduction to Evolutionary Computation" for a quick introduction. The book should be available electronically from a university library.  Let us know if you can't find it there.
5. Get to know XFdtd
   1. XFdtd manual is also attached; however, the link above (in 5) is more useful for coding a .xmacro.
       

Important notes:

MAC USERS: Using a GUI when connecting to OSC via SSH from your terminal.

You will need to set up X11 forwarding. Otherwise, when you go to plot via SSH, they will not display (they don't forward from OSC to your machine). If you are unable to run GUI's on OSC through your computer's terminal, follow these instructions:

1. In your own system's terminal, type: sudo vi /etc/ssh/sshd_config
2. Search for the following line: X11Forwarding no
3. Change it to: X11 Forwarding yes. Save the file and exit.
4. In your own system's terminal, type: sudo systemctl restart sshd
5. For a Mac, download and install XQuartz.
6. Connect to OSC using ssh -XY username@hostname.
7. You can test that this works by typing 'xeye' or 'xclock' in the terminal when logged into OSC. 

Now you should be able to use OSC's GUIs.

PC USERS: 

As a PC user, there are a few things you need to do:

(1) Enable the Windows Subsystem for Linux on your device (https://developerinsider.co/stepwise-guide-to-enable-windows-10-subsystem-for-linux/#:~:text=To%20enable%20the%20Windows%20Subsystem,list%20here%20and%20click%20OK.)

(2) Get Bash on Ubuntu installed on your machine. You are going to need to have Bash on Ubuntu installed prior to starting these trainings; otherwise Bash commands will not be recognized.

•  https://ubuntu.com/tutorials/install-ubuntu-on-wsl2-on-windows-10#1-overview

(3) Get X11 forwarding working. Otherwise, when you go to plot via SSH, they will not display (they don't forward from OSC to your machine).

• Follow these steps here.  
  • http://courses.cms.caltech.edu/cs11/misc/xwindows.html
• Change your config file. To do so, in terminal (with Bash on Ubuntu open) 
  • type: sudo vi /etc/ssh/sshd_config
  • Then change '#X11Forwarding no' to '#X11Forwarding yes' and save it.
    • https://www.businessnewsdaily.com/11035-how-to-use-x11-forwarding.html
• Make sure Putty and Xming are running every time before you ssh in. Use Xlaunch application to run Xming and press yes to everyrthing.
  • Xming should now be running as a background task.
  • Open PuTTY and open the pre-saved like you saved in PuTTY. (This will open a Bash terminal that asks for your OSC login password.)

Most of our students 

(1)Ubuntu doesn't come with X11 forwarding on its own. So you can install Xlaunch

xeyes -display :0

This is a general update. Most of our recent meetings have been to teach the students to use Git properly, or to answer questions on the training modules. 

Update

1. Git Update: I recently cleaned up our Git and GitHub so that we have a better way to develop this code. Once I cleaned it up the goal is to educate all of the students to properly use Git so we develop code correctly moving forward. The repository had become quite a mess. The students were constantly developing on a branch, and never merging it back to the main branch. This means that we never had a working copy that we could run on while edits were being made in parallel. I attempted to merge the edits to the main branch with the hopes of getting this functioning so we could evolve while working on the bottleneck function; however, it looks like someone with poor knowledge of Git edited the main branch and we had an abundance of merge conflicts. 

What I've done now is reset the repository so that all merge conflicts are resolved and a working copy exists on the main branch. I've also added a .gitignore that will ignore all data files. Git doesn't like these because (1) it hates when tracked files disappear -- ie when we delete trial run data, if someone accidentally pushed it then Git complains-- and (2) it means it we constantly are adding more untracked files (every single new file we make is untracked and then gets tracked, like the flag files). So, I've had it only track useful code. 

The goal once I train the other on Git is to move the place of the data files and make it it's own git repository (once we start doing fewer trial runs so we won't lose important data). If the others learn to check the status of files before pushing them, they can make sure they don't push useless trial data sets, and either (1) delete them, or (2) add them to the .gitignore.

As for now, we successfully have the working, run-able copy on the main branch now. When any more revisions are made (e.g. the talk of adding the wall time variable), we can branch and edit on that so we still run. 

2. Evolution/bottleneck update: We got the loop working to the point that it can run all the way through a generation without fatal problems. The only potential problem we can see right now is if we need to go backward in the savestate. We're working on making that not a problem--the solution is to better organize the output files and data, which we were interested in anyway. Right now we are running with 10 individuals in each generation. Alex got through 2 generations without a problem, so he'll keep running but now we're trying to make some of these more minor fixes so we may have to stop the run. Alex does have plots (they don't look great, but at least they're being made correctly without error). At the moment we are swimming in GPUs. We haven't had much trouble at all this week with getting them, so that's why we were able to get 2 generations done between around midnight last night and 2ish today; not sure how long that will persist, but Pitzer has had relatively little usage whenever we've looked lately.

Comments on the plots: We're discussing this now, we don't think the individuals should really be color coded/separate on the legend because it is not like they follow one individual across multiple generations; however, we do need to label the dotted line. Another thing we were considering is decreasing the penalty factor for when the cones are too big for the hole. If we get something with a much much better Veff but it's only slightly larger than the hole, it might be worth it to help that one stick around a little bit more.

3. Wall time Variable Update: Also, last week Carl and Alex talked about the variable wall time again. We decided the best idea is to start by implementing a variable wall time based on the cylindrical volume that he mentioned before, but in the future, we might also be able to check the time of each GPU job and then plot it against the dimensions of the cone/cylindrical volume to get a better estimate of the wall time for each job

Meeting Attendance: Julie, Alex M., Alex P, Eliot, Leo, Evelyn, Mitchell, Ryan. 

Today is the deadline for confirming our attendance at the virtual APS meeting. Alex M. will be confirming and we will be orienting ourselves so that we can have some results. Here is our to-do list for today:
 

1. Create a method for automatically adding our plots to dropbox each day. 
   • The way we are going to do it is by adding the command: mail -s "Test Subject" someemailaddress@gmail.com < testScript
     • We will create a random email to use for this that will only be receiving emails from this command. 
     • We are trying to find and set up a client that as soon as this random email address receives an email, it uploads it to the Dropbox here. 
   • This is still being worked on. 
2. Start developing a database of old antenna runs and parameters, and pull data from that for any repeat dimensions. 
   • This should speed up some of our run time. 
   • We want to create a database of old antenna dimensions and their associated UAN files. That way, if we repeat an antenna geometry very closely, instead of re-submitting a job to produce the gain patterns, we can pull from one that has already been created.
   • This should limit:
     • The number of jobs we have to submit.
     • The number of GPU hours/minutes we have to request and wait for.
   • These should probably still be run through AraSim, however, since the energy could change from run to run.
3. Keep running and collecting data. 
   • Do we want to run and have data for 20ish generations with 10 individuals for APS?
     • We have already made some progress on this so we could likely make more generations for APS if we keep going. 
   • Do we want to instead switch to doing something like 20 individuals even if we get fewer generations completed?

Notes apropos developing our database for antenna info. This is how we are going to do it, and what we need to develop in our code:

1. Add all info to csv files.
   • The csv files will have columns: length, radius, theta, uan file directory and name (ie /file/location/database#/).
   •  # will be the row that this matches the L, R, Theta within the csv file
   • Inside /file/location/database#/ will be all the uan files for each frequency for these dimensions. 
     • We need an "if/else" statement in the bash script that tells the code to look in this csv file (read it in). 
       • IF the produced L, R, Theta match any of those that currently exist, save the 4th column (file location) to a variable (say we call it ExistingUan=/file/location/database#/). 
         • Then cd ExistingUan
         • Make a loop that:
           • does CP /file/location/database#/gen_individual_freq.uan BiconeEvolutionOSC/BiconeEvolution/current_antenna_evolution/XF_Loop/Evolutionary_Loop/Run_Outputs/$RunName/ (ie to the file name and location that XFintoAra.py reads. This will make sure that it has the data as if we actually completed the XF simulations for the antennas that had repeat sizes from our past runs (I mean past by runs we may have EVER done -- not past generations). 
             • We need to copy ALL of the frequency uan files for that individual into Run_Outputs/$RunName 
       • Else fill another line in that csv file with the L, R, Theta of this individual so we can keep it for later. 
         • mkdir the new directory /file/location/database#/
         • Add the name of this new directory (ie database#) to the 4th column on the csv file next to the correlating L, R, Theta.  
         • Then submit the XF job for this individual. 
         • Once it finished the XFSolver job and produces the .uan files (for each frequency), do a loop that:
           • cp individual_freq.uan /file/location/database#/gen_individual_freq.uan
             • Note that I wrote to cp individual_freq.uan instead of gen_individual_freq.uan. Note that XF produces it as individual_freq.uan, and it is changed to gen_individual_freq.uan when we move it into the Run_Outputs/$RunName directory.
             • So you can do it either (1) after it moves it to Run_Outputs/$RunName with the name gen_individual_freq.uan, or (2) before it moves the file with the name individual_freq.uan. 
2. We need to make a new directory that holds all of these database# directories and their uan files, and the csv file the "if/else" statement checks. 
   • We need to add this new directory to the .gitignore!

Note that Pitzer usage over the weekend was much better! Maybe weekends are our best time to run? Today (Monday) has been a little bit worse. 

Over the past few days the following items have been accomplished:

• We got the jobs to stop canceling on OSC.
  • Issue was the destination command for the error and output files for the GPU jobs inside the GPU job script; we fixed it by taking it out.
    • This issue was causing jobs to fail. They are no longer failing, and the loop is working again.
• Set up a way to be able to automatically upload both the L, R, Theta plots and the Fitness Score plot to dropbox as we work.
  • Set up an email that automatically uploads to dropbox under the folder GP_Antennas/Updates/DailyFitnessScoreImages when you send an attachment with that email.
  • We added this command into the loop:
    mail -s "Subject" dropbox.2dwp1o@zapiermail.com < FScorePlot2D.png
    • It automatically has it upload an image when the loop finishes a generation. It's currently so that the file will be named whatever the subject of the email is so we can control that by whatever is after the -s command. It's currently set to not overwrite.
  • Still need to add the Veff plot to dropbox. 
• Made gitpush.sh and gitpushforce.sh
  • Each time one of us pushes changes to GitHub, it makes a permssion lock on the directories. From now on, after looking at what files are changed (using git status. Remember to make sure to add any data files missed to the .gitignore)users should do:
    • git add .
    • git commit -m "add message" or git commit --amend --no-edit
    • Then run: ./gitpush.sh if you made a full new commit, or use ./gitpushforce.sh if you amended this edit to the previous commit. They both exist in: /fs/project/PAS0654/BiconeEvolutionOSC
      • These files run the git push or git push -f commands and then immediately run a chmod to change permissions after. 
• Alex is starting the APS slides!
  • He should be sharing them shortly. I told him to look at Suren's from last year for guidance. 
• We have started working on adding the feature that pulls non-unique (ie repeat parameter) individuals from an antenna database. 
  • It's currently being developed on the Antenna_Database branch in git. 
  • Alex has started writing c++ code that reads in the csv file and appends unique items to it. 
  • Comments from Amy we need to remember: 
    • Doing "==" on doubles is bad!
    • We want this "likeliness" to be between 1 and 10% (start with 10%). 
      • Remember: is this difference between L stored and new L a fraction of the wavelength?

The students have been meeting to work out the summer schedule. We are dividing into to groups:

(1) Paper writing: Julie, Alex M., Alex. P

• We need Amy to start an overleaf draft (she has the premium version that allows you to share with more than 1 person)

  • https://www.overleaf.com/5612932179jzykrkvztqnb

• In tomorrow's collaboration meeting (Now Fridays at 3pm) we are going to request discussion on an outline

(2) Adding wall time variable structure: Eliot, Evelyn, Leo (Alex P. will help oversee)

• In order to prepare group (2) Alex M. has been going over the edits he started and is discussing his code. We also are taking some time to catch them up on the current code -- ie how it runs, what all of the pieces involved do -- so that they can know how to test the code after edits are made, and where each essential piece may lie. We will be going over this for the next few days in good detail. 
• Group (2) will then be coming up with a scheduled time each day that they will be coworking on zoom. This will work the same as if they were sitting in an office together. They'll announce this time to everyone once it is set.

Alex P, Alex M, and I are going to push to rapidly finish this antenna database so that the others can create a new branch to work on the wall time variable with. This will leave us very busy for the next few days. 

We met today for a long time and pushed to catch up. The following is what we have done:

(1) Worked for a bit on our current tasks. They will work on these current tasks before they start on their summer projects. 

• Antenna database (Julie, Alex P., Alex M.)
• Worked on a paper outline (Julie, Alex M.)
• Worked on wall time variable (Eliot, Evelyn, Leo)

       Note I also have to: (1) Fix merge conflict and make sure students are good about only editing the dev branch moving forward. (2) Get branches and GitHub set up for both the asymmetric bicone and the non-linear bicone. 

(2) Went over the details of how the loop works as a group.

• Went over how each piece works.
• Went over how to run it. 
• Went over best ways to test new edits. 

(3) Went over summer tasks.

• Eliot: Add parameters to bicone (ie make bicone asymmetric)
• Julie & Alex M.: Paper, and helping others
• Alex P.: Frequency database for AraSim (to speed up AraSim)
• Evelyn & Leo: Make non-linear bicone (wiggly sides) 

Today's Summer 2020 daily update:

Julie: Since I  won't be doing GENETIS work every day necessarily, I'll add myself down here with a blurb when I am working with the others. I will also be continuing my daily updates on Dropbox for non-GENETIS specifics. 

Paperclip Antenna (Ryan and Evelyn working on it):

• https://github.com/gp-antennas/Sph._Harmonics_And_Paperclip

Asymmetric Bicone (Leo and Eliot working on it):

• https://github.com/JulieRolla/GENETISBicone

AREA (Ben working on it):

• Github? We need to ask Steph where their past work exists.
• See AREA thesis attached

Symmetric Bicone(Alex M. and Alex P. working on it):

• https://github.com/JulieRolla/GENETISBicone

https://drive.google.com/drive/folders/1iDamk46R2_oOLHtvsOg4jNy05mCiB7Sn?usp=sharing

For PAEA Algorithm:

Part I: Complete as soon as the run starts

Run details: Please answer all of the questions below!

• Run Type
  • Answer here whether or not it's AREA (Gain pattern evolution) or PAEA (Bicone evolution)
• Run Date
  • Add answer here
• Run Name
  • Add answer here
• Parameters evolved
  • Add answer here
• Why are we doing this run?
  • Add answer here about what we are testing
• What is different about this run from the last?
  • Add answer here with info on what we are doing differently from the last run
  • Example: We are testing a new operator, we are changing the percentages of each selection method used, etc.
• Symmetric, asymmetric, linear, nonlinear (what order):
  • Add answer here (say N/A if this is an AREA run)
• Number of individuals (NPOP):
  • Add answer here
• Number of neutrinos thrown in AraSim (NNT):
  • Add answer here
• Operatiors used (% of each):
  • Add answer here
• Selection methods used (% of each):
  • Add answer here
• Are we using the database?
  • Add answer here. This can be found in the main bash script within the variables section. (Answer N/A for AREA run)

Please upload the text file with all run details before closing this!

Part II: Complete as soon as the run ends

Results: Once this run completes, please upload the plot(s) to this post as an attachment, as well as a general explanation of the results. 

• Summary and comments on results
  • Add thoughts on what we should do next here!
  • Example: "It seems like we are seeing minimal evolution. We should take a step back and try to see why we don't see improvement. Once we trouble shoot, we can start a new run to investigate."
  • Example 2: "Run looks good! Our best individual is in generation #12. Attached are the CAD drawings of that individual."

**Upload all plots, run parameter text files (file that has run settings saved), CAD models of best indivduals, etc**

For AREA Algorithm:

Part I: Complete as soon as the run starts

Run details: Please answer all of the questions below!

• Run Type
  • Answer here whether or not it's AREA (Gain pattern evolution) or PAEA (Bicone evolution)
• Run Date
  • Add answer here
• Run Name
  • Add answer here
• Parameters evolved
  • Add answer here
• Why are we doing this run?
  • Add answer here about what we are testing
• What is different about this run from the last?
  • Add answer here with info on what we are doing differently from the last run
  • Example: We are testing a new operator, we are changing the percentages of each selection method used, etc.
• Single frequency run or run with broadband frequency dependence:
  • Add answer here
• Number of individuals (NPOP):
  • Add answer here
• Number of neutrinos thrown in AraSim (NNT):
  • Add answer here
• Operatiors used (% of each):
  • Add answer here
• Selection methods used (% of each):
  • Add answer here
• Any other things to note?
  • Add answer here

Please upload the text file with all run details before closing this!

Part II: Complete as soon as the run ends

Results: Once this run completes, please upload the plot(s) to this post as an attachment, as well as a general explanation of the results. 

• Summary and comments on results
  • Add thoughts on what we should do next here!
  • Example: "It seems like we are seeing minimal evolution. We should take a step back and try to see why we don't see improvement. Once we trouble shoot, we can start a new run to investigate."
  • Example 2: "Run looks good! Our best individual is in generation #12. Attached are the CAD drawings of that individual."

**Upload all plots, run parameter text files (file that has run settings saved), gain patterns of the two best and two worst individuals, etc**

Input File Format for pueoSim (Also ICEMC)

Frequency Range: From 200 MHz to 1500 MHz incrementing by 10 MHz steps

There are 8 different files that are required for pueoSim. They are:

vv_0: Max Gain at each Frequency, Vertical Polarization

hh_0: Max Gain at each Frequency, Horizontal Polarization

vh_0: Max Gain at each Frequency, Vertical to Horizontal Polarization

hv_0: Max Gain at each Frequency, Horizontal to Vertical Polarization

vv_el: Gain at Theta Angles [5, 10, 20, 30, 45, 90] for each Frequency, Vertical Polarization

vv_az: Gain at Phi Angles [5, 10, 20, 30, 45, 90] for each Frequency, Vertical Polarization

hh_el: Gain at Theta Angles [5, 10, 20, 30, 45, 90] for each Frequency, Horizontal Polarization

hh_az: Gain at Phi Angles [5, 10, 20, 30, 45, 90] for each Frequency, Horizontal Polarization

Currently XF doesn't output all the information we need to create all these files. The only files able to be made from current XF outputs are vv_0, vv_el, and vv_az. Once we have the correct XF Outputs, it shouldn't be too much of a hassle to fix the current translation code.

Format for each of the files are the same. One column is Frequency (Hz) and the other is Gain. Attached are example files vv_0 and vv_el to visually see the format, though the frequency range is the current ARA range and not the final PUEO range as I am using ARA data to make these files. The files are named vv_0 (no .txt or .csv or any extension) and vv_el

Link to Google Doc with this information: https://docs.google.com/document/d/1iRUF6hIEyQfMK0LL21caRuHPgXYP30ZdkSkFv_-Y8R0/edit

I've been building in XF and have ran into some issues but currently have the following completed:

- Struts are placed, though they are not evenly spaced and the same. I have contacted XF to try and figure out how to get rotation/patterns to do what we need

- Circuit components and circuit board are in the xf file, though the components are not on the circuit board (I'm not totally sure how to put them on, that's the next step). The circuit components should be of spec, I looked up the part numbers from the previous ELOG post and grabbed the values from the manufacturer.

Here are the things that have not been completed/need answered:

- How to evenly space the struts connecting the shape (as stated previously, I've contacted XF to figure out how to do this easily. Im just bad at modeling in XF)

- Add circuit components to circuit board

- Add voltage and ground connections to the circuit board

- On the circuit diagram, figure out J1 and J2 connections. Meaning, which one connects to the signal from the cable and which connects to the other cone that is used as ground?

To see current antenna build go to: " /users/PAS1977/jacobweiler/GENETIS/XFzone/straightened_antenna_for_Jack.xf "

Attached are pictures in case there are issues pulling up model in XF. :)

# 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

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.

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. 

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 is a pdf of physics plots generated for the 9_50, 13_84, 18_89, 19_96, and 29_87 crazy sides individuals along with another containing information on the amount of triggered events and effective volumes for each individual. The crazy sides individuals were simulated for 3 million events using the same Arasim version as is currently in the loop.

After discretizing and straightening the sides of the curved antenna that performed the best (Generation 13, individual 84) and running the antenna through AraSim, the following results and physics plots were generated.