We began a new run for a symmetric bicone antenna. The purpose of this is to satisfy the most recent comments from the reviewer on the paper. We are using the same GA as for the paper with the same parameters. I will update this post soon with more details about this run. There is a run_details file attached, but please wait for me to update this post with more specifics as the version of the GA being used is less connected to the details presented in that file.

The data can be found here: /fs/ess/PAS1960/BiconeEvolutionOSC/BiconeEvolution/current_antenna_evo_build/XF_Loop/Evolutionary_Loop/Run_Outputs/2023_02_20_Symmetric_Run .

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.

Today was the first day of the GENETIS Hackathon. We are spending several days this week specifically tackling the PUEO project to get it into full form (or close to it). Here is a progress update after day 1.

Alex

I am working on the xmacro script for the ANITA antenna. Before today, we had a working xmacro script to make the geometry of the ANITA horn antenna. Now I am trying to modify it to make it 1) more true to the actual ANITA antenna (in terms of which parts are electrically connected) and 2) add in the power source and sensors so that we can get simulation results. I've attached the xmacro script here along with a picture of the geometry and some gain patterns. There are four ridges in the antenna. They are all connected by the outer walls of the antenna. However, only the ones directly across from each other are connected by a load (in this case, a power source, since we simulate as a radiator). So we have two power sources, one connected each "ridge bicone". 

In making this, I have generated some gain patterns. I want to test a few cases to see if the results coming from XF seem reasonable, though I don't know what I should expect the gain pattern to look like when I've done things correctly. Here are the options I'll compare:

1. Just use one "ridge bicone".
2. Use two "ridge bicones" with the walls but just one power source.
3. Use two "ridge bicones" without the walls and two power sources.
4. Use the full form, with two "ridge bicones", walls, and two power sources.

Case (4) is the one I expect to be correct. However, when I simulate that, I get a slightly asymmetric gain pattern compared to what I expect (I expect symmetry across the "ridge bicones"). You can see from the attached image that there is a strange preference in one corner. My guess is that this has to do with which ridges are set to be ground and which are set to 1V (the potential). Feel free to ask me for more details about these figures/scripts on slack and I'll fill them in on here. I'll clean up the script and add in full test cases later this week.

The image of the antenna I attached is a bird's eye view. The green lines represent the power sources I've connected between the ridges. They do appear to overlap, but my understanding is that they are not actually affecting each other (they should just be a representation of the power sources). 

The image of a gain pattern (which is 3D and also a bird's eye view) is for the case of the antenna with both power sources and the walls remaining (the antenna is still shown too, to demonstrate the asymmetry of the gain pattern). This is well outside of the frequency range ANITA cares about (83 MHz), and I haven't looked closely at the higher frequencies yet, but I still am surprised by the asymmetry. I'll update tomorrow with more gain patterns to compare.

Dylan and Jacob

Dylan and Jacob are working on the bash scripts for the PUEO loop. They are taking the parts of the bicone loop that are specific to ARA/bicones and changing them to be specific to the PUEO loop. 

All the bash scripting outside of implementing the new software we’re developing should now be complete (we just need to debug when we do test runs). The new GA is implemented into the PUEO loop. We tried and failed to build a version of pueoSim on our own. Will has provided us with a precompiled version and instructions for installing it on our users as well as access to the necessary pueoBuilder repo. Jacob and Dylan are scheduled to go through the installation with him on Thursday at 4pm in his office, M2024.

We have also found that peuoSim currently only outputs root files. So, we will need to create a conversion script or modify pueoSim for when we implement it into the loop. Currently, using IceMC looks to be the easiest way to get a test run going. For the next steps, we have a plan for making IceMC read in a variable file path name to avoid recompiles and issues with parallelization (Alex has given us the path to look at how ARA does it). Then, we will work on installing pueoSim and testing its current viability.

Bryan

Upon checking the existing plotting scripts used for previous GENETIS work, it appears that they can be used for PUEO with minimal changes. In order to test the plotting scripts, sample output data from the PUEO loop is needed, or at least test data that mimics the form of the output for the PUEO loop. After more progress is made with installing an MC package and the PUEO loop can be run to produce test outputs, the plotting scripts can be tested and implemented in the bash script.

Today was day two of the GENETIS hackathon. See the previous entry for details on day one. 

Alex

I continued working on the XF scripting for the PUEO horn antenna. Amy showed me an actual horn antenna from ANITA in Lisa's office so I could get the dimensions and see how the loads (power sources in XF) were offset. Offsetting the power sources led to fixing the asyemmtry problem from yesterday. I tested offsetting the loads by various heights and found that they all give the same gain patterns except for when they overlap, proving that they were interfering with each other when they crossed.

There is still, however, an asymmetry between the x and y axes (but the gain patterns are now symmetric across either of them). This is more reasonable, though I'm not positive that it should be this way. I attached an image of the gain pattern to show this asymmetry. Note that it is still at 83 MHz, which is well outside the PUEO bandwidth, but higher frequency gain patterns show the same thing (but they have more nodes so they're harder to look at). I attached images from the x-axis, y-axis, and above of the gain pattern. One way to check this will be to compare to the data stored in PUEOsim/icemc and see if they demonstrate similar asymmetries.

My next step is to test the constraints we've decided on using the script. I'll try out a few different values of the parameters and then if everything is working I'll use the GA Ryan and Dylan wrote to generate many individuals and have XF make the models for them. We don't necessarily need to see the simulation outputs from those XF runs, we just need to see if we run into error. Beyond that, we need to figure out how to extract the proper gain data from XF to create the same format that PUEOsim and icemc use. 

Amy also mentioned that we should add the opening angle of the horn antenna as a gene. This may be a little tricky but should be doable. Once we are set with the current XF script and changing the data formatting to match what PUEOsim and icemc need, I'll work on adding that as a gene.

Dylan and Jacob

We tried to get IceMC running and able to read in gain files -  we failed. Something was wrong with my make files and Jacob’s c++ compiler, so neither of us got a working version of IceMC. We then switched gears to focus on pueoSim. I created a branch on the nicemc github to output a veff.txt in the format of IceMC, so we can reuse the already-made code. Jacob and I also have been trying to install pueoSim, but we’ve been running into many errors and issues from the “C++ Gods”. For the next steps, I will finish the veffective branch and create a pull request. Then, I will work on a branch to make it so pueoSim can read in a variable path  to the gain files.

Ryan

Tuesday: Created a new branch on the PEUO repository, version0.0,  and placed the repository in the same location as the Ara one for familiarity. I also added an alias to this directory onto the genstudents channel if people would like to add the path to their .bashrc's. I then went through the the Evolutionary_Loop directory and cleaned up any residual Ara based files that were not needed to run this loop. This will make navigating and troubleshooting easier as we finish building. This branch was then commited and pushed to the github and submitted a pull request.

This entry will serve to summarize what tasks we've completed and still need to complete after last week's GENETIS hackathon.

Alex

My focus was on the XF scripting for making the PUEO antenna. Before last week, we had a script which made the geometry of a PUEO-like antenna. The xmacro script has been modified in the following ways:

• Now includes power sources connecting the ridges that are opposite each other. 
• Generalized to use variables without hardcoding.
• Reads in data from the output files of the PUEO GA.
• Loops over all read in antennas to set up all of the simulations at once.

At this point, the script for setting up the simulations of the PUEO loop is just about ready for use. The only change to be made is to the frequency list. The script for printing out the gain data is also ready, though it only prints out the gain in theta and phi, not the cross polarization.

Here are some outstanding points that need to be hammered out, though they impede the quality and accuracy of a run rather than the actual functioning of the loop.

• The shape of the ridges in the generated antennas from the GA are considerably different from the PUEO antenna.
  • This is likely something that can be fixed by adjusting the constraints--the subspace of the parameter space that leads to PUEO-like ridges may be very small as-is.
  • You can see an example of an antenna from the GA attached (viewed from slightly below). It looks dramatically different. This seems to be due to constraints on the height and width being too small, but the ridges are also clearly misshapen. 
• The curve on the ridges looks like it needs some work.
  • For very PUEO-like antennas, the slopes look reasonable, but they do flare in or out slightly. This is more dramatic for ridges that deviate from PUEO's significantly.
  • My best guess is that the parametric form of the curves is placing the curves in a plane that is different from the rest of the ridge. This should be fixable by somehow constraining the curve to a given plane.
• The simulation still only outputs polarization data for theta and phi, not the cross polarization.
  • It looks like XF naturally gives us the theta and phi polarization. It's not clear how to get the cross polarization gain (which we think means the gain when the signal is at 45 degrees).
  • One idea is to redo the simulation but with the antenna rotated 45 degrees in the azimuth. But I'm not certain that that iwll work.
  • Amy indicated that the correct way to do this is by simulating the antenna with just one power source at a time.
    • Leaving the VPol source would produce the VV and VH data and leaving the HPol would produce the HH and HV data (HV and VH could be flipped!).
• Currently, the antennas have a fixed opening angle. We'd like to add this as a parameter, though at the moment it might be ok to forego that.  
• We need to make sure that the power sources aren't too close together (fixed!).

To do for this week:

1. Modify the script to make two simulations for each antenna, each with only one power source.

2. Adjust the constriants on the parameters to fix the curvature.

3. When we begin a run, we will want to just evolve the height and the inner side length (these determine both the inner side length and the outer side length).

Dylan and Jacob

Dylan and Jacob focused on getting PUEOsim/icemc working, which will be the simulation software needed for the PUEO loop. Here's a summary from Dylan:

• Plotting and bash scripts should be mostly good to go.
• Currently have 4/5 of the PUEO prerequisites for pueoBuilder, and the GENETIS-specific code is ready to implement and test when it's built. I’m trying to build the correct root version one more time before today’s meeting, and if it fails again I’m going to ask Will.
• The main thing left is to get the correct version of root installed, which while annoying, shouldn't take too long

To do for this week:
1. Once PUEOsim is working, run it with the usual settings to get the default performance. It will need to be submitted as a job array (ask Alex for help with this if you need; ask Will for advice on how many neutrinos to run).

This is an entry for the usual Wednesday working meeting GENETIS holds. We are largely carrying on from last week's hackathon hammering out the remaining pieces that need to be fixed. See the previous ELOG post for a list of those.

Alex

Amy pointed out on the Monday call that the proper way to simulate the ANITA antenas is to use one source at a time. I modified the script I had so that it makes two simulations per antenna. The first one will use the power source connected to the "VPol" ridges and the second one uses the one connected to the "HPol" ridges. After checking this, it looks like the asymmetry I had pointed out before fell away. In other words, I think XF only wanted to use a single power source anyway. So now we should be able to produce the VV, HH, VH, and HV data that icemc and PUEOsim need.

Ryan and I also worked a bit on the slopes of the ridges. We experimented with the parameter that affects the curvature, which seems to be able to be too large. But many of the designs still look to have almost no slope and many still caved inward rather than sloping outward. We're still working on figuring out what causes that, but I think it means we need another constraint on distance of the top of the inner ridges from the center. 

We also tried figuring out why the sides of the curved part of the ridges don't stay in the same plane as the straight part of the ridges. I'm confident that they do stay in a single plane (I attached a Mathematica notebook that shows as much by finding that the torsion of the curve is zero; for some reason I couldn't print it to a PDF). We think that we should be able to rotate the curve into the same plane as the straight part of the ridge, but I haven't figured out how yet.

 Nick and I continued working on the HPol antenna. We want to check if there are any other things in Steph's example XF file that are significant to the results of the simulation (versus just being there as a representation of the model). It looks like there are, and Nick is working to figure out what they are by deleting them (in a copy) and generating simulation results for them to compare to the original. Otherwise, the most significant parts (the copper plates) are now being made in a script and just need to be connected to one another.

Dylan

I tried to build root from source again and ran into an error 3 hours into the build. I messaged Will and asked if he knew anything about the error. I then reran the build with Will's suggested change and ran into the same error 3 hours later. I did, however, manage to build pueo by sourcing the installation of root in Will's shared pueo directory. I'm now testing getting a txt output file from the simulation as it turns out my initial solution didn't work.

Update:

I got a working version of root installed. Also, I was able to modify pueoSim to output a veff.txt file. Now, I need to modify where it reads in the gain files, and then modify the icemc specific bash scripts to work for pueosim.

At the main GENETIS meeting yesterday, we collected the last few things that need to be worked out in order to get the PUEO loop in working order. Here's a list

• Skeletonize the xmacros (Alex)  04/10/23 In progress

  • This involves substituting some of the text to be variables that are replaced by the loop for each generation. 

  • Requires some slight modification of Part B1 in the loop.

• We need to modify PUEOsim to read in different gain files (Dylan) Changes made 04/10/23  Testing to be done.

  • Currently, PUEOsim reads in files like vv_0, vh_el, etc. It needs to be modified to take in the gainfiles as arguments and read different ones for each individual.

  • Requiers slight modification of the batch job scripts, but these are relatively small

• Slight modification on the fitness score read in script (Dylan)  Changes made 04/10/23  Testing to be done.

  • Now that PUEOsim is working and has been modified to output txt files with the effective volume, we just need to slightly amend the the fitness score script to read from those files.

• Fix Ezio's comments on XFintoPUEO.py and modify to read in outputs from two files (Jacob) 04/10/23 in progress, further work this week

  • Since we are running XF twice (once for each power source), we need the conversion script to read in from two files and print out to 8 files (vv_0, vh_el, etc)

The reviewer asked us to run the loop again but for just symmetric antenna designs. We have completed that run and have results ready. We still need to resimulate the top five individuals, which I'll update this post with later. I attached the violin plot (though it should be fixed to not let the legend overlap the data). See this previous entry for the details of the run: http://radiorm.physics.ohio-state.edu/elog/GENETIS/198

We have the PUEO loop in working order, though there are a few errors in accuracy and efficiency. We started a preliminary run with few individuals and neutrrinos as a large scale test that may still give us some useful data. 

For this run, we are only evolving the inner side length (10cm to 25 cm) and height (10 cm to 50 cm). The walls are slanted at 45 degrees, so the outer length is completely defined by those two. The ridges are kept at 6 cm wide and 4 cm from the walls at the base. The curvature is set to 0,1 and the ridges are set to have the same height as the walls. 

At the moment, we are using 24 individuals and 300,000 neutrinos. I'll update this ELOG post with more details from the run as they emerge.

I've started a run of the PUEO loop to get some data for evolving the antenna width and height. We are running with 24 individuals, each with 400k neutrinos at an energy exponent of 19. Here is the output directory: /fs/ess/PAS1960/HornEvolutionOSC/GENETIS_PUEO/BiconeEvolution/current_antenna_evo_build/XF_Loop/Evolutionary_Loop/Run_Outputs/2023_05_01_Test_5

It's very important to note that the cross-pol data being used still comes from the data already stored in pueosim. This is because our extremely low cross polarizations were causing us to have no effective volumes. There's likely some issue in what values from XF we are choosing as our crosspols.

Here are the run details for the latest PUEO run we've started. There are still some bugs that need to be worked out, which are detailed on the github. Here is the directory where the data is stored: /fs/ess/PAS1960/HornEvolutionOSC/GENETIS_PUEO/BiconeEvolution/current_antenna_evo_build/XF_Loop/Evolutionary_Loop/Run_Outputs/2023_05_08

This run uses 50 individuals per generation with 400k neutrinos per individual at an energy exponent of 19. Only the inner side length and outer sidelength are being evolved (which evolves the height since the opening angle is fixed). 

Issues With Part E (Dylan):

The Plots were not automatically created for the first generation. After a quick look through, I found that the fitness score and v effective csv files were being moved before they were copied, so the files didn’t end up in the correct place. Additionally, the errorbars.csv file was not being created, so I made a temporary fix to create a file of 0 error bars to allow for plotting the values while I work on getting the real error values. 

Update: I have modified Will’s script for reading the root file outputs, so it can now read them to output a CSV file with the effective volume along with its positive and negative errors. This script does the same and more as the fitnessfunctionPUEO.py, so I will replace it in the loop when there is downtime. Additionally, this script means we don’t need to output a veff.csv file from pueoSim. I will now work on creating a less “janky” version of my pueoSim change for reading in the gain files, so I can get Will to officially add it to pueoSim and we can pull any updates in the future.

Update, Implementing the new script into Part E:

The rootAnalysis.py script is very picky with environment variables. So, first I had to load and then unload a version of python to make sure the default version is loaded. Then, I moved the sourcing of set_plotting_env.sh to later in the script to avoid having an alternate version of root sourced while running (this would cause errors). Then I source the environment for pueosim (path hardcoded, change when loop isn’t running) and loop through the rootAnalysis.py program for each individual in the generation. This will output a ${gen}_fitnessScores.csv and a ${gen}_errorBars.csv in the run directory for plotting script to use. Because it outputs these automatically, I commented out the old methods we used to create these files and removed the temporary error bar fix as well.

Another Update:

We paused the loop. I changed the hardcoded parts, and we pushed the new updates to the github. I will make comments on the changes later today. 

Wednesday:

It seems like the loop is still not creating the csv files or plots for generation 1 or 2. Alex gave me the error message. The python script rootAnalysis.py had an issue with the include Geoid.h line. This was caused by sourcing the wrong things while trying to get the script working. I found that I only changed my local pueoSim environment to include the fftw installation to the $PATH and $LD_LIBRARY_PATH variables. So, I changed /fs/ess/PAS1960/buildingPueoSim/set_env.sh as well. Also, I found that the include statements in rootAnalysis.py were missing the PAS1960 portion of the path. After fixing these, and adding a missing ‘/’ to the output file path, I manually ran the rootAnalysis.py program for the 2023_05_08 run, mimicking the portion of the bash script that runs it in Part_E. It outputted the correct files in the correct format. I then ran the FScorePlot script. The median line for the ViolinPlot seemed wrong, and the FScorePlot was too scrunched with a y start of 0; I will need to change these.

Plotting Update (Dylan):

Ok, plots still aren’t being made, and I’m not running the loop, so I don’t have access to the error messages, so I’ll go through everything one by one. For Veff_Plots, this isn’t being made as there are currently no vEffectives.csv. This isn’t a big deal, as it’s just a copy of FScorePlot, but I added the creation of vEffectives.csv to rootAnalysis.py anyway. Next, I noticed that runData.csv, which is required for a couple of the plots was not being made. I looked, and the version of gensData.py had the old values for the skiprows when reading in the fitnessScores and generationDNA files, something that was overlooked when we merged the version I was developing with the version Alex was developing on. I can’t access the directory or the file, I think this is why it was overlooked in the merge. I created a temporary PUEO version in Antenna_Performance_Metric (I’m also fine with it just living here permanently). 

Also, the csv files are now in the GenerationData/ directory in the run directory? This affects every plotting script and they will not work without changes. I don’t know why this was changed or if this change is permanent?

Next, ok apparently, VariablePlots isn’t even a file in the loop? We really need to use GitHub better. 

I moved my local version of the program into the loop and it ran fine manually.

I am forsaking the Generation_Data directory, so I changed the rainbowPlotter and dataConverter scripts to read in a location to match all the other plotting scripts. They both also ran fine manually. 

Note: The rainbowPlotter script should be able to create a gradient from the minimum fitness score to the maximum fitness score. (currently, the range is hardcoded and this can cause basically a mono-color graph.)

FScorePlot should be good

The bash script was inputting 5 variables into colorplots when the pueo version only takes in 4 (this is also something that was already fixed before the merge.) It also requires the vEffective.csv files. After copying over the fitnessScore.csv files to vEffective.csv files, it ran fine. (The vEffective.csv files will be made automatically by rootAnalysis.py in the future)

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.

Here are my recommended starting genes for the initial generation of the upcoming run (confirmed that these will produce a working antenna in XF). We want to use the lowest values we can because we expect that a larger (namely, taller) antenna will perform better:

S, H, x0, y0, yf, zf, beta
7.50000,50.0000,1.0000,1.00000,1.00000,50.0000,0.2

• S: Half the side length of the bottom of the antenna
• H: height of the antenna
• x0: distance of the bottom of the ridge from origin
• y0: width of ridge at the bottom
• yf: width of ridge at top
• zf: final height of the ridge (cannot exceed H)
• beta: a curvature parameter for the ridges

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. 

We are beginning a new run with several improvements to the ARA VPol loop to try to evolve antennas that are optimally matched just by their geometry. To do this, we are evolving with the RealizedGain instead of just Gain in the Xmacros (thus taking into account impedance mismatch). We also have the speed up that parallelizes the AraSim jobs on each run. Attached is the run_details.txt file, but the GA parameters are subject to change. Here is what they are to begin:

We have a population size of 50 individuals per generation.

Selection operators (NUMBER selected by each):

• Roulette: 10
• Tournamente: 10
• Rank: 30

Genetic Operators (NUMBER generated by each):

• Reproduction: 6
• Crossover: 36
• Immigration: 8
• Mutation: 2
  • Sigma: 5%

Beam patterns with ARA bicone contained in a cylinder of air surrounded by a shell of ice.

 

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. 

 

• 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/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/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)