| |
ID |
Date |
Author |
Subject |
|
|
Draft
|
Sun Mar 29 08:55:02 2026 |
Dylan Wells | Guide to Updating pueoSim | How To Update PueoSim For GENETIS:
First, whoever updates pueoSim needs access to pueoBuilder, pueoSim, and niceMC on GitHub (ask Will for permissions).
Once you do, go into the peuoSim directory at /fs/ess/PAS1960/buildingPueoSim/
and source set_env.sh
`source set_env.sh`
Then, we want to make copies of the files we are currently modifying for the GENETIS loop.
For PueoSim v1.1.0 these are:
-
nicemc/src/EventGenerator.cc # Modified to create custom output root files to calculate errors
-
pueosim/test/simulatePueo.cc # Modified to stop the simulation of the LF antenna which is not needed for GENETIS
-
pueosim/src/Seavey.cc # Modified to read in custom gain files
-
pueosim/src/pueo.cc # Modified to read in custom gain files
-
pueosim/include/Seavey.hh # Modifies to read in custom gain files
Currently, I store copies of these in the `/fs/ess/PAS1960/buildingPueoSim/backups` directory in case somebody accidentally overwrites the files in pueoBuilder.
Once you’ve made the copies, you can run `./pueoBuilder.sh` from the `/fs/ess/PAS1960/buildingPueoSim/pueoBuiler` directory. This will rebuild pueoSim and niceMC, pulling the latest updates from GitHub.
You may need to delete the pueoSim and niceMC directories in order for the builder to pull the latest version from GitHub. Or, if it’s being really stubborn, move the whole pueoBuilder directory to a temporary location and run the builder from scratch with
`git clone git@github.com:PUEOCollaboration/pueoBuilder` and then `./pueoBuilder.sh`
Then, you will need to reference the copies of the changed files to make changes to the new version of pueoSim. Hope this doesn’t cause too much of a headache, and when you’re done, return to the /fs/ess/PAS1960/buildingPueoSim/pueoBuiler directory.
Then you simply type
`make install`
then
`make`
And now, pueoSim should be ready to run!
EventGeneratior.cc Changes and Rationale:
PueoSim’s default output ROOT files are very large and therefore time-consuming to parse through to get the information we need to calculate effective volume and errors. So, we want to create a custom ROOT file with only the variables we want, greatly increasing the speed of the analysis.
To do this, we want to create a new TFile with corresponding TTree and TBranches that will store the loop.positionWeight, loop.directionWeight, and neutrino.path.weight. Then, we want to fill the Tree when a detector is triggered and write the results to the file at the end of the loop.
Sample code for initializing the TFile:

simulatePueo.cc Changes and Rationale:
By default, pueoSim v1.1.0 runs a simulation for the normal antenna and a low-frequency (LF) antenna. As GENETIS is evolving for the main antenna, we are not interested in using computation time to simulate the LF antenna. So, we comment out the lines that initialize the LF detector in this file.
Seavey.cc, Seavey.hh, and pueo.cc Changes and Rationale:
As of pueoSim v1.1.0, the simulation software only has the ability to read in one antenna. This is a problem, as we want it to be able to read in files for any antenna we make. So, we need to change these scripts to be able to read in whatever gain files we want.
The convention the loop uses is to input gain files in the format of
vv_0_Toyon{runNum}
hh_0_Toyon{runNum}
…
In the ./pueoBuilder/components/pueosim/data/antennas/simulated directory
So, the main change is getting the runNum variable into Seavey.cc file where the gains are read. Currently, we define a global variable at the stary of pueo.cc and pass it into where Seavey is called. This means we have to add runNum as a parameter in Seavey.cc as well as Seavey.hh. Finally, we change the name of the read-in files to be in the above format AFTER dividing runNum by 1000 (this is because pueoSim uses the run number as a random number generating seed, so we divide runNum by 1000 to be able to read in the same gain patterns for multiple seeds of the same individual).
Note: We used to change pueoSim to output a veff.csv file. We now handle this calculation by analyzing ROOT files, so this change is no longer necessary. |
|
|
Draft
|
Fri Mar 27 01:38:52 2026 |
Jacob Weiler | XF Antenna Drawing Progress 08/02/2023 |
| Quote: |
|
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. :)
|
|
|
|
Draft
|
Thu Mar 26 15:56:22 2026 |
Julie Rolla | GENETIS Planning Meeting |
| Quote: |
|
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:
| Group name |
Tasks |
Participants |
Times per week to meet |
| Loop Group |
Running the loop, updating software, getting plots |
Julie, Alex M., Alex P. |
2 |
| Lecture |
Attend Leo's lectures |
Full group |
1 |
| Training (Python, c++, and Bash projects) |
Completing the training modules (Alex M. and Julie will be answering questions) |
Mitchell, Ryan, Evelyn, Eliot, Julie, Alex M. |
2 |
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":
- Make wall time a variable for XF sim.
- Test current software edits.
- Such as item #1 above
- Make sure the bottleneck function is working.
- 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.
- Get Ruby working on XF
- 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
- Get Alex's account of Ruby working.
- He received an email and is still unable to log in. He is touching base with them again.
Tasks for "the Training Group":
- Julie and Alex need to finish the C++ project!
|
|
|
|
Draft
|
Thu Mar 26 02:18:17 2026 |
Ryan Debolt | Multigenerational Narrative draft 2 | This is a multigenerational tracing of our second-best individual's parents and children:
The second-best individual in this evolution was Bicone 22 from generation 40. This individual is, in fact, a fascinating case as we shall see. But to start the story of this individual we will go back to generation 38 in order to demonstrate some of the peculiarities.
In generation 38 there were two bicones of no renown, Bicone 11 and Bicone 17. Bicone 11 was a fairly average individual that was ranked 23rd with a fitness score of 4.72016. Its DNA was {*6.16084, ***79.663, 0.0015434, -0.107765} for side one , and {0.308809, 39.6742, -0.0084247, 0.40629} for side two. One day, by chance it met Bicone 17, another average bicone ranked 24th with a score of 4.71877 and DNA {**2.32499, 79.663, -0.00224948, 0.192602} for side one, and {0.308809, 39.6742, -0.0084247, 0.40629} for side two. These two individuals eventually became the parents of two antennas: Bicone 16 and Bicone 17 of generation 39.
Bicone 16 eventually grew to have been ranked 3rd in fitness score of 4.95323. It’s DNA ended up being a complete balance of its parents sharing side one with Bicone 38.11{2.32499, 79.663, -0.00224948, 0.192602} and side two with bicone 38.17 {0.308809, 39.6742, -0.0084247, 0.40629}. Bicone 16 was an individual with high aspirations and hoped to be reproduced. But alas, it was not meant to be. But bicone 16 came upon some amazing luck, it was selected with itself for crossover. This meant that bicone 16 was able to provide two identical surrogates to survive into the next generation. This is where this Bicone fulfilled its full potential.
The twin bicones were named Bicone 22 and Bicone 23 in generation 40. Being clones, they shared all their DNA with Bicone 39.16. However, due to some circumstances, they had slightly different fitness scores. Bicone 23 managed a very respectable 5.0117 fitness score and was ranked 2nd in the generation. But not to be outdone Bicone 22 managed to score a 5.17014 and ended up being the second-best performing individual of all time. Being so successful, the two bicones ended up producing 8 children between the two groups.
Bicone 23 was the first to crossover and had 2 children with its partner. These were Bicones 4 and 5. Bicone 4 was ranked 39th with a fitness score of 4.60251 and still shared the DNA of its second side with its grandparent Bicone 38.17 as well as most of its first side with Bicone 38.11 {2.32499, 79.663, -0.00213879, 0.192602} {0.308809, 39.9608, -0.0084247, 0.40629}. Bicone 5 on the other hand, was ranked 14th with a fitness score of 4.80535 and it still shared a lot of DNA with its grandparents {6.16084,53.0851,-0.00224948,0.0534469} {0.966617,39.6742,-0.0084247,0.40629}.
Bicone 22 had 6 children of its own with various other Bicones. These were; Bicone 8, ranked 11th with a fitness Score of 4.81784 and DNA {2.32499, 75.9855, -0.00224948, 0.192602} {0.966617, 39.6742, -0.00320023, 0.213833}; Bicone 9, ranked 7th with a fitness score of 4.88966 and DNA {6.10508, 79.663, -0.000594616, 0.0351901} {0.308809, 42.4246, -0.0084247, 0.40629}; Bicone 12, ranked 12th with a fitness score of 4.81705 and DNA {6.42695, 75.9855, 0.0015434, -0.107765} {0.308809, 39.6742, -0.00320023, 0.213833}; Bicone 13, ranked 2nd with a fitness score of 5.0344 and DNA {2.32499, 79.663, -0.00224948, 0.192602} {0.966617, 42.4246, -0.0084247, 0.40629}; Bicone 34 ranked 3rd with a fitness score of 4.99864 and DNA {0.66148, 73.5522, -0.000594616, 0.00582814} {0.966617, 39.6742, -0.0084247, 0.40629}; and finally Bicone 35, ranked 22nd with fitness score 4.74955 and DNA {2.32499, 79.663, -0.00224948, 0.192602} {0.308809, 42.4246, -0.0084247, 0.40629}
Bellow, I have attached the rainbow plot with the parameters occupied by individual 4 in gen 41 which was again ranked 39th in that generation. From this, we can see that while in its own generation it was a poor performer, overall it was upper middle of the pack. However, because of the density of other better performing antennas in this region, it is hard to distinguish which genes in this antenna are contributing the most to the drop in fitness score compared to its siblings and parents.
*Gene originating from Bicone 38.11
**Gene originating from Bicone 38.17
***Gene originating from Bicone 38.11 and 38.17 that is shared between the two. |
|
|
Draft
|
Wed Mar 25 21:22:00 2026 |
Ryan Debolt | How many individuals to use in the GA. |
| Quote: |
|
One of our foundational questions tied to the optimization of the GA has been "How many individuals should we simulate". Up to now, our minds were made up for us by the speed of arasim being great enough that the time cost of simulating individuals was great enough that the improvements made from having more were not enough to justify the slowdown. However, with the upgrade to the faster, more recent version of arasim, I decided to re-examine this. This was also spurred on by the fact that the last time I ran this test we were testing GA performance by final generation metrics rather than by how many generations it took to reach a benchmark. So in one of my optimization tests, I tracked this data.
To start, using the same run proportions, using a .5 chi-squared benchmark, the average time across all 89 run types used in this run was 25.4 generations for 50 individuals as compared to 8.3 generations running the same test for 100. Furthermore, the minimum number of generations for 50 individuals was 4.8 while using 100 individuals yielded 2.4. So on average running 100 individuals was about 3 times fast at reaching this benchmark than with 50. And when comparing the best result regardless of run type, 100 individuals was still 2 times quicker than the min for 50 individuals. Finally, the run that yielded an average of 2.4 generations for 100 individuals took an average of 29.2 generations with 50 individuals or roughly 12 times the generations.
For the test we will discuss, we ran 89 different run types that all used 60% rank, 20% roulette, and 20% tournament selection respectively. These test had the following ranges:
6-18% of individuals through reproduction (steps of 3%)
64-88% of individuals through crossover (steps of 12%)
0-10% mutation rate (steps of 5%)
1-5% sigma on mutation (steps of 1%)
These tests also used our fitness scores with simulated error of .1 to imitate arasim's behavior and as such we used the chi-squared value to evaluate these scores as there is no error on those values.
Comparing this same test with a tighter chi-squared benchmark of .25, we see similar results. On average 50 individuals took 37.1 generations to reach this point while 100 individuals took 16.0 generations. Similarly, the minimums amount of gens for 50 individuals was 15.4 while 100 individuals was 5. Finally, the corresponding run for the 5 generation min with 100 individuals took 41.8 generations with 50 individuals. These correspond to speed up's of 2.3, 3.08, and 8.36 respectively.
This data implies that on average, independent of run type, we should expect to have to use 2-3 times fewer generations while running 100 individuals than we would running 50 individuals but we could see up to 8-12 times fewer generations to reach benchmarks. Another data set using a different set of selection methods was also tested for this and again yielded similar results, though overall the runs from the first batch were better across both 50 and 100 individuals and so those results are likely to be more indicative of the parameters we use in a true run.
The data being examined in these results can be found here: https://docs.google.com/spreadsheets/d/1GlfnjQSO6VI8MuUGYTUcLkjwDZU98nyFFysgTTfVFOE/edit?usp=sharing
|
|
|
|
Draft
|
Wed Mar 25 02:48:02 2026 |
Alex Patton | GENETIS Daily Updates | Today's Summer 2020 daily update:
As a note, today OSC was down so productivity was more limited
| Name |
Update for Today |
Plans for Tomorrow |
| Alex M. |
Mostly just wrote more on the paper in the Genetic Algorithm section. I added some citation that we used in ICRC but there are still more places that should have citations.
|
I might check tonight when OSC is back up to try to push in more updates to the loop because I wanna get Evelyn and Ryan started on running the loop. Putting in those fixes is a big priority because we want to be able to correct the potential issue with XF simulation folders being overwritten and thus uan data not corresponding to the write individuals. The two big things for me in the loop are getting the simulation data to save correctly (and also putting that in the database) and testing that we can replicate results using the specific seed. I'll probably only focus on loop stuff tomorrow.
|
| Alex P. |
Got up before OSC was down to check progress of overnight run, it seems to have worked but I noticed a problem with the database that it wasn't writing to it probably due to a permissions issue but I would have to run another time to see. Shouldn't have affected data but just the use of the database. Run got up to 8 generations with non-zero fitness score which is positive and seems to have fixed the error we originally encountered. Talked to Eliot about pointers and possible errors but was unable to look at the specific error because it is on OSC.
|
Tomorrow plan is to continue to work on database functionality and continue run to get more generations, also want to add the ability to add more plots than just the fitness score to the dropbox automatically. Plots: upload all plots (Fitness, LRT, vEff), remove legend, upload penalized red/green plot too, take off legend, add units to Fitness |
| Leo |
|
|
| Eliot |
Read about pointers and vectors in C++. Talked to Alex P a bit, and have some ideas of things to change to get the GA running. Began reading about antennas. Mostly a down day due to OSC being down.
|
Will implement changes to GA and continue familiarizing myself with how XF reads these values.
|
| Evelyn |
|
|
| Ryan |
|
|
|
|
|
Draft
|
Wed Mar 25 00:11:25 2026 |
Alex M | Daily Update 7/24/20 |
| Name |
Update |
Plans for Monday |
| Alex M |
|
|
| Alex P |
|
|
| Eliot |
|
|
| Leo |
|
|
| Ryan |
|
|
| Evelyn |
|
|
| Ben |
|
|
| Ethan |
|
|
|
|