Slides shown at experts building meeting Aug. 2nd, 2023.

Here are some reading materials about HPol antennas:

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

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

We can add other sources here as we find them.

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

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

Here are some preliminary results from testing the effect of error on growth in the GA. For this test, we start with a simulated error of 0.5 because our true fitness score is bounded between 0.0 and 1.0. From here, we simulate doubling the number of neutrinos by reducing the error by root(2), then root(4), and observed the growth on the fitness scores plots. We did these three tests with both 50 and 100 individuals (plots starting with 30 use 50 and starting with 60 use 100). Looking at the plots, we can see that the only plot that shows growth is 100 individuals with halved error (corresponding to 4 times the number of neutrinos). In fact, it took going to root(25) (corresponding to 25 times the number of neutrinos) to observe comparable growth with 50 individuals. This leads us to believe we likely need to increase both neutrinos and individuals to see meaningful growth in our GA. Further tests are required to see how consistent these results are. Another test, though unrealistic, we ran 1000 individuals with the root(25), this test was optimized in around 10 generations, this could be seen as a maximum performance standard.

William Luszczak  1:30 PM

This is the directory with the current PUEO antenna data files: https://github.com/PUEOCollaboration/pueoSim/tree/main/data/antennas. Each type of antenna will need several files:

• vv_0 and hh_0 describe the on axis v and h pol gain as a function of frequency. Gain is listed as a multiplicative factor (not in dB, if I'm remembering correctly)
• hv_0 and vh_0 describe the on axis cross polarization gain
• vv_az and hh_az describe the off-axis gain via multiplicative factors of the boresight gain. These are currently listed as a function of frequency for reference angles of 0,10,20,30,40,50,60,70,80, and 90 degrees, though we can always adjust the reference angles if needed.
• vv_el and hh_el are similar to above, but for gain as a function of elevation angle instead of azimuthal angle.

So for example, the total vpol gain in a particular frequency bin for a signal incident at azimuthal angle az and elevation angle el would be vv_0(f)*vv_az(f, az)*vv_el(f, el)

New

1:31

We can also potentially adjust this if it would be more convenient for the GENETIS people to output antenna information in a different format (or at different reference angles or whatever). The important thing is that the boresight h, v, and cross pol gains are all defined, as well as the off-axis response (as a function of azimuth and elevation)

Recording of training on XFdtd by Alex Machtay on July 12, 2023.

https://osu.zoom.us/rec/share/FVKiTcQrRh8NLNYJADwugy0H2VjDo8ZlBsH16sJAGv2JINNwxxzyNfo5ueqVgOTO._XErF57Kz8KOM3a5

This link will expire in 120 days so note that we need to post a permanent recording.

Here's the GitHub repository with examples of Xmacros: https://github.com/Machtay/XFdtd_Scripts 

The reviewer for the paper we recently submitted mentioned that our step sizes at which we are measuring the gain in XFdtd may be too large. They pointed out that there appear to be "lobes" at 400 MHz. I ran the antenna we presented in the paper through XFdtd using a step size of 5 degrees (what we've been doing) and a step size of 1 degree (the reveiwer's recommendation). Attached are antenna responses for these two different step sizes at 200 MHz and 400 MHz. Qualitatively, there are noticeable differences in the "jaggedness" of the 400 MHz plot and how extreme the minima and maxima appear, but the basic shape is preserved. We can try to do a more quantitative analysis (ex: run these through AraSim), but doing so may be more time intensive than necessary considering that AraSim may require 5 degree steps and that adding these images to an appendix may be sufficient anyway.

We have 2 physical XF flash drive keys in existence. These are non-replaceable and cannot be lost! Until further notice, the keys are held by:

(1) Cade Sbrocco (sbrocco.6@buckeyemail.osu.edu )

and

(2) Abasi Brown (brown.7146@buckeyemail.osu.edu)

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

 

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

Most of our students 

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

xeyes -display :0

Attendance: Julie, Alex M., Alex P., Cade, Scott.

What we have done today:
(1) Fixed Concerns regarding copying the output .uan files properly so they are not overwritten. (see #8 in this elog entry: http://radiorm.physics.ohio-state.edu/elog/GENETIS/22 for details on the error). This was corrected in part E as:

for i in `seq 1 $NPOP`

do

    for freq in `seq 1 60`

    do

    #Remove if plotting software doesnt need                                                                                                                                                             

    #cp data/$i.uan ${i}uan.csv                                                                                                                                                                          

        cp Antenna_Performance_Metric/${i}_${freq}.uan "$WorkingDir"/Run_Outputs/$RunName/0_${i}_${freq).uan

    done

done

And in the "looping part" -- ie part G we have corrected it to say the following. Note that every time we run an iteration/generation in the loop, it writes the name of the output files the exact same (individual_frequencystep.uan). It will overwrite these files in the next generation unless we move them and rename them like so. We don't want this, because we will likely want to plot the gain patterns of the individuals we like (gain pattern data is in the .uan files). 

 for i in `seq 1 $NPOP`

        do

            for freq in `seq 1 60`

            do

    # Gens data used to create a .csv file for the uan file for gain plotting                                                                                                                            

    # cp Antenna_Performance_Metric/$i.uan ${i}uan.csv                                                                                                                                                   

                cp Antenna_Performance_Metric/${i}_${freq}.uan "$WorkingDir"/Run_Outputs/$RunName/${gen}_${i}_${freq}.uan

            done

        done

(2) Added scale factor "A" (actually called "Scale Factor" in our bash script and fitnessFunction_ARA.cpp), and the generationDNA.csv as an input file (this file is where the radii of all individuals in the current generation live).

• We have added this as a variable in the fitnessFunction_ARA.cpp. It now runs as a flag pass in when it runs in the bash script. In section E:

./fitnessFunction.exe $NPOP $ScaleFactor $AntennaRadii/generationDNA.csv $InputFiles #Here's where we add the flags for the generation

and in the looping part (part G):

     ./fitnessFunction.exe $NPOP $ScaleFactor $AntennaRadii/generationDNA.csv $InputFiles #Here's where we add the flags for the generation

and at the top where variables are declared:

RunName='Julie_12_2_2'           ## Replace when needed                                                                                                                                                  

TotalGens=6                     ## number of generations (after initial) to run through                                                                                                                  

NPOP=4                          ## number of individuals per generation; please keep this value below 99                                                                                                 

FREQ=60                         ## frequencies being iterated over in XF (Currectly only affects the output.xmacro loop)                                                                                 

NNT=10000                          ##Number of Neutrinos Thrown in AraSim                                                                                                                                

ScaleFactor=1.0                   ##ScaleFactor used when punishing fitness scores of antennae larger than holes used in fitnessFunctoin_ARA.cpp 

Note that every time the roulette algorithm runs, it's written into generationDNA.csv. We copy those right before rerunning the roulette alg in the next generation -- ie cp generationDNA.csv Run_Outputs/$RunName/${gen}_generationDNA.csv -- so that each generations parameters don't get overwritten. However, the current generation's parameters live in generationDNA.csv until the roulette alg runs in the next generation, so we can read in that file to the fitnessFunction_ARA.cpp file to determine the constraint (ie R_antenna) 

(4) Implemented Alex P.'s version of his optimized AraSim. This is now fully functional in the loop. 

NOTE: WE HAVE MADE A MISTAKE! WE MADE THE CONSTRAINT THE R-VALUE WE READ IN FROM THE GENERATIONDNA.CSV FILE. THIS IS NOT THE RADIUS WE THINK IT IS! WE NEED TO DO SOME TRIG ON IT TO FIX IT!!

Attendance: Julie, Alex P., Cade, Alex M., Mitchell, Evelyn (Go team!)

I. Adding Constraints on the in-ice hole size.

Today we worked on adding constraints on the drilled hole size. Our plan is to do so by penalizing the fitness scores of indiviuals with a radius larger than that of the hole in the ice. Ie in fitnessFunction_ara.cpp we would have:

if R_antenna>=R _hole

fitnessScore =fitnessScore x (e^{-[A(R_antenna-R_hole)/R_hole)]^2}) 

else

fitnessScore= veff (or whatever way we decide to calculate the fitness score in the future, if this ever changed)

Where "A" is a constant we can adjust to tweak how heavy the penalty is. Other things to do in order to make this work:

(1) Make constant "A" a variable in the bash script. 

• Do this the same way $NPOP is used in the roulette algorithm cpp program! :)

(2)Read in the roulette algorithm output file for your radius of the antenna. 

• Note that this isn't a super obvious thing. Right now our roulette alg outputs are saved as $(generation)_filename.csv. So, for the first gen -- ie gen 0-- it will be 0_filename.csv. For the second gen -- ie gen 1-- it will be 1_filename.csv...etc. This means we need to make sure the fitness score calculator has a way of knowing what generation we are on, in order to be sure it is grabbing the correct radius for each individual (not that of an old generation). 
   

We will be working on this more in our meeting tomorrow. As for now, the game plan has been to make comments on what we should be adding in the correct sections of fitnessFunction_ara.cpp (and will be doing the same in the bash script shortly, too --ie XF_Loop.sh). 

II. Adding Ara Values to Plot. 

We haven't started this yet, but it is something we need to do. When we plot Veff vs Generation, Theta vs Generation, and R vs Generation we need to add in the value of these for the current ARA bicone as a baseline for our evolutions.

Note: All of the contents over the last month need to be added to the manual! DO NOT FORGET!

To Do List:

We want to keep testing the loop. Right now, we are using a cpu running at half scale. This gives estimated times for each antenna of up to 2 hours. GPUs are suddenly hard to come by, so if we are relegated to using CPUs we'll probably need to scale down considerably.

Evelyn, Ryan, and Mitchell are probably going to be ready for the python project soon. If someone is around on Friday to help them they should be able to finish the bash project.

One idea is to run all the inital xmacros in the interactive job and then submit a GPU job that runs all the xfsolver command. With the hope that not having the GPU in the interactive job will make it easier to get the interactive job and to get the GPU for a shorter time because it would only be needed for a smaller segment. This would especially help with running larger amounts of individuals.

AraSim EField project Error:
 

 *** Break *** segmentation violation

===========================================================
There was a crash.
This is the entire stack trace of all threads:
===========================================================
#0  0x00002b845aeb445c in waitpid () from /lib64/libc.so.6
#1  0x00002b845ae31f52 in do_system () from /lib64/libc.so.6
#2  0x00002b84562bebf4 in TUnixSystem::StackTrace() () from /cvmfs/ara.opensciencegrid.org/trunk/centos7/root_build/lib/libCore.so
#3  0x00002b84562c13ea in TUnixSystem::DispatchSignals(ESignals) () from /cvmfs/ara.opensciencegrid.org/trunk/centos7/root_build/lib/libCore.so
#4  <signal handler called>
#5  0x000000000044fd70 in void std::vector<double, std::allocator<double> >::emplace_back<double>(double&&) ()
#6  0x00000000004c3c0e in Report::Connect_Interaction_Detector(Event*, Detector*, RaySolver*, Signal*, IceModel*, Settings*, Trigger*, int) ()
#7  0x0000000000436eb3 in main ()
===========================================================

The lines below might hint at the cause of the crash.
You may get help by asking at the ROOT forum http://root.cern.ch/forum
Only if you are really convinced it is a bug in ROOT then please submit a
report at http://root.cern.ch/bugs Please post the ENTIRE stack trace
from above as an attachment in addition to anything else
that might help us fixing this issue.
===========================================================
#5  0x000000000044fd70 in void std::vector<double, std::allocator<double> >::emplace_back<double>(double&&) ()
#6  0x00000000004c3c0e in Report::Connect_Interaction_Detector(Event*, Detector*, RaySolver*, Signal*, IceModel*, Settings*, Trigger*, int) ()
#7  0x0000000000436eb3 in main ()
===========================================================

The following items from our to-do list have been successfully completed. Below this list, you can find the remaining urgent items for our proposal due date of 1/28 (items must be completed with plenty of time to spare). 

Completed items: 

*Note* please check the highlighted item. This one still must be verified. 

1. Made software plot Theta VS Gen
2. Fixed current L and R plots
   1. These now have correct axis labels, a legend, and connect data for each individual between generations.
3. Produced Veff for ARA's actual bicone parameters. 
   1. Made XF_Loop.sh submit a job for the ARA gain AraSim input file in BiconeEvolutionOSC/AraSim/Ara_Bicone6in_outputs.txt
   2. STILL MUST: Make sure that the "wait function" has been properly edited to consider the submission of this extra job in the first iteration of the loop. (Not sure if $NPOP+1 instead of $NPOP fixed it correctly) ----> CADE SHOULD LOOK AT THIS :)
4. Added plotting software for V_eff VS Generation (includes ARA's actual bicone V_eff as generated in #3).
5. Fixed the ARA hole constraint in fitnessFunction_ARA.cpp -- ie fixed the calculation to consider the correct radius "r". See http://radiorm.physics.ohio-state.edu/elog/GENETIS/28 for details. 
6. Successfully made energy a variable in setup.txt. 
   1. used the same "sed" format as before in the bash script (XF_Loop.sh).
7. Pushed to Github. 

Items to still do:

1. Save CAD models in XF: Due 1/15                                                   ------>(Cade-- second most urgent one)
2. Stop plots from popping up during run: Due 1/15                            ------>(Alex P.)
3. Add "save state" idea to loop: Due 1/15                                         ------> (Cade and maybe Alex P can help -- This is the most urgent one)
4. Figure out why fitnessFunction_ARA.cpp isn't plotting: Due 1/15     ------>  (Julie, and Alex M)
5. Run the loop and evolve for results: Due 1/24                               ------>(Alex M, Mitchell, Cade)
6. Write proposal: Final Due 1/28                                                   ------> (Amy, Kai, Julie)

Note that the people running the loop (Alex M, Mitchell, Cade) should be producing plots and saving them. Please save all plots in this dropbox folder: https://www.dropbox.com/home/GP_Antennas/NSF%20Proposal%20Plots%20(1_28_2020)

When submitting plots, please make a new folder in there and label it "Date_of_run, Energy, Generations, Individuals". For example, my folder within this dropbox link would be: "1_10, 10^19, 10, 5". I have made sample folders in this dropbox link if needed.

You can export the plots from OSC to your machine (using CP command) or can type "display NameOfPlot.png" then screenshot and crop your plot to upload to dropbox.