Updates and Results Talks and Posters Advice Ideas Important Figures Write-Ups Outreach How-To Funding Opportunities GENETIS
  GENETIS, Page 10 of 13  ELOG logo
New entries since:Wed Dec 31 19:00:00 1969
ID Date Authordown Subject
  96   Mon Jul 27 16:52:20 2020 Alex MDaily Update 7/27/20
Name Update Plans for Tomorrow
Aelx M

Leo, Julie, and I merged the two dev branches (Antenna_Database and asymBicone) onto master. I think I resolved all of the conflicts and successfully merged. I'm going to start testing by running each setting (original, database, and asymmetric) through generation 1 to make sure that they give the correct results as the previous test runs and that they have all of the correct files they need to run correctly. Once I'm done with this I'll implement the changes I outlined last week (on the 21st I think) and begin a real run.

I helped Ryan with the paperclip algorithm. We found the error in the roulette algorithm and it now gives results comparable to tournament mode. There is a bug that needs to be fixed (Ryan changed a variable to be taken as an input, but it's giving different results when we input the same values as it had before and neither of us can tell why) but otherwise the script looks much better than last week with the roulette fix. 

I'm going to finish getting confirmation that the master branch works for each of the settings for the loop. Then I'll be ready to implement the fixes and start a real run, beginning with the symmetric setting with the database. 
Alex P    
Eliot    
Leo    
Evelyn    
Ryan Issues with low roulette fitness scores have been resolved (there was just an issue with checking the sum compared to the random number) and it has comparable scores to tournament after similar amounts of runs. Then I started work on fine-tuning the mutation function. Early results seem to suggest that having a high mutation rate gets closer to the optimal score faster but lower mutation rates will get closer given longer amounts of time. Finally, Alex concluded that the max fitness score for these paperclips is 9 (or more specifically one less than the number of segments), and some runs after 1000 generations are reaching into the 8.99*** for high scores and averages. So the goal for me this week is to try to reach that point faster (hopefully within 100 gen).  Continue fine-tuning parts of paperclips to find optimal methods. If I reach that, write a bash script to autorun tests. 
Ben    
Ethan    

 

  97   Thu Jul 30 15:36:54 2020 Alex MDaily Update 7/30/20
Name Update Plans for Tomorrow
Alex M

Tested the database setting for the symmetric loop. It ran well and gave correct results, so all that's left to test is the asymmetric loop (going to start that momentarily). 

Julie and I helped Ben and Ethan set up a git repository for AREA and gave a brief review of using git.

Assuming that the asymmetric setting isn't too dificult to get working on the master branch, I'll be able to start collecting real data. I'll need to implement the fixes I outlined last week on Wednesday (see the ELOG post), but those should be quick changes. I'll start by using the database for a symmetric bicone with 10 individuals per generation.
Alex P    
Eliot    
Leo    
Evelyn    
Ryan    
Ben    
Ethan    

 

  98   Mon Aug 3 16:39:56 2020 Alex MDaily Update 8/3/20
Name Update Plans for Tomorrow
Alex M I fixed the issues I outlined a little while ago that we needed to resolve before starting a real run. I started a real run with 10 individuals for up to 20 generations using the database for a symmetric bicone. The name of the run is Machtay_20200803_Master_Symmetric_Database_Real (whew!). Right now it's on gen 2 and plots are on drop box (see the link at the bottom).  I'm going to keep the run going and hopefully be most of the way to 10 generations by the end of tomorrow. Julie and I also discussed some potential improvements that can be made to the loop. For one, there's some consolidation and cleaning up that should be done of the main directory. We were also speculating about a way that we could quickly see when AraSim jobs fail and rerun them in real time rather than waiting for all the jobs to finish to realize we need to rerun.
Alex P    
Eliot    
Leo    
Evelyn    
Ryan Continued working on the bash script to automate runs for paperclips.  Finish the bash script and do the runs and start combing through the results. 
Ben    
Ethan    

Dropbox link: https://www.dropbox.com/home/GP_Antennas/Updates/DailyFitnessScoreImages/Machtay_20200803_Master_Symmetric_Database_Real

  99   Tue Aug 4 17:30:09 2020 Alex MDaily Update 8/4/20
Name Update Plans for tomorrow
Alex M I've continued the run I started yesterday. I ran into a bug where the LRT plots weren't being made but it should be fixed now. The loop is on generation 10, but it hasn't really converged or shown a clear pattern. We'll keep this run going until at least gen 15 probably. If we finish this run, I can start another run using the asymmetric version. The goal would be to do a similar number of generations using the asymmetric length first, followed by adding on the asymmetric opening angle.
Alex P    
Eliot    
Leo    
Evelyn    
Ryan    
Ben    
Ethan    

 

  100   Wed Aug 5 16:08:40 2020 Alex MDaily Update 8/5/20
Name Update Plans for Tomorrow
Alex M

Continued running the loop up to gen 15. I also adjusted the LRTPlot script so that it can slightly spread the points along the generation axis so that you can see overlapping points, but I still need to implement this in the loop. 

Helped Ryan design the bash script for running through paperclip many times. It's working and he ran it for a while to get ~1000 outputs checking the performance of different mutation sizes. Next he'll parse through them to find what sigma appears best.

Amy suggested that I make it possible for the roulette algorithm to record the mutations and parents for each individual so that we can get a better sense of the history of the evolution, so I'll work on that tomorrow. If it looks to be working, I'll start a run with an asymmetric length.
Alex P    
Eliot    
Leo    
Evelyn    
Ryan Completed bash script for automating runs and generated 1100 txt and csv (each) files of runs to be able to see how the ratio of roulette to tournament and standard deviation in the mutation function affect the fitness scores after 100 generations.  Work on writing a program to go through the txt files and collect the information of the highest fitness score, stored in line 6 of each one,  and figure out which combination of parameters gives the highest average.
Ben    
Ethan    

 

  101   Fri Aug 7 14:16:01 2020 Alex MDaily Update 8/7/20
Name Update Plans for Monday

Alex M

   

Alex P

   

Eliot

   

Leo

   

Evelyn

   

Ryan

   

Ben

   

Ethan

   

 

  102   Mon Aug 10 16:12:28 2020 Alex MDaily Update 8/10/20
Name Update Plans for Tomorrow
Alex M Over the weekend I tried making some fixes we discussed. I fixed the roulette algorithm (the symmetric version) so that the random number generator is only set once and then passed to functions. It will now print the values in the generator to files to be plotted. I tried running the loop over the weekend with these fixes but the AraSim jobs kept failing. So today I consolidated the two loops and I started working on a fix for AraSim that will automatically check if an AraSim job fails in real time while the loop is running and resubmit it so that we don't get stuck waiting for the jobs to rerun.  I'm going to finish the AraSim fix tomorrow and then try starting a run. I'm going to be out on Wednesday and Thursday, so I'll need someone else to keep the run going.
Alex P    
Eliot    
Leo    
Evelyn    
Ryan Created a program that combed through all the files, got the average high score of each set of parameters, and saved that information in a master file to quickly use for finding which parameters worked best.  Create the programs to make the desired graphs we wanted.
Ben    
Ethan    

 

  Draft   Tue Aug 11 19:56:45 2020 Alex MDaily Update
Name Update Plans for tomorrow
Alex M

I worked on fixing the AraSim issue today. I think I have it resolved. Essentially, I made a second set of flags that the loop will look for and use the first set of flags to tell the loop which error files to look at to look for the phrase "segmentation fault." If it sees that phrase, it resubmits the job. Otherwise, it makes the second flag. Once all of the flags have been made, the loop can move on. I tested it by manually putting the phrase inside one of the error files to make sure it would catch it and resubmit the job. 

I started a new run (partly to further test the fix, but primarily to get real data). It has the fixes we discussed last week at the GENETIS meeting (ex: mutations shouldn't repeat anymore).

I'm going to be out tomorrow and Thursday so someone needs to pick up my run. I'll make sure I open permissions tonight so that anyone can run it tomorrow. If you have questions you can slack me, but I probably won't be able to respond til super late.

If there are issues with AraSim jobs failing without resubmitting, see the instructions below.

Alex P    
Eliot    
Leo    
Evelyn    
Ryan    
Ben    
Ethan    

Instructions for persisting AraSim errors:

Even if we still have the problem where AraSim jobs fail and the fix doesn't catch them, you can still run the loop as long as you manually step back in the loop. Here's what you have to do:

1. Exit the loop (ctrl-c).

2. Clear the following directories in the RunName directory: AraSimFlags, AraSimConfirmed, (gen)_AraSim_Errors, (gen)_AraSim_Outputs. 

3. Revert the save state (second number goes to 5). This let's you resubmit the AraSim job.

4. Run the loop again (make sure you're still in an interactive job).

  105   Fri Aug 28 16:31:56 2020 Alex MFirst Results Slides

Here's a power point I showed today at the GENETIS meeting for the two most recent runs we did. The first run was symmetric and we ended it at 15 generations. The second one is ongoing and is shown up through generation 9 on the power point.

Attachment 1: GENETIS_Meeting_Loop_Results_2020_08_24.odp
  106   Mon Aug 31 18:32:21 2020 Alex MDaily Update 8/31/20
Name Update Plans for tomorrow
Alex M

I started working on the slides for our meeting with Wolfgang this Friday. I'll share it via one drive/email/slack tomorrow for comments from everyone.

Over the weekend I finished the asymmetric length run. I still have a couple of fixes to make on plotting scripts, so I'll update those plots tomorrow after making the fixes. I also started a new run today using both an asymmetric length and an asymmetric opening angle. The plots aren't automatically uploading to dropbox anymore because we hit our limit, so I'll have to add them manually. You can see the asymmetric run on dropbox under  Machtay_2020_08_27_Asymmetric_Length_Real_Run(SECOND REAL RUN).

I'll finish up and share rthe power point with everyone and then fix up the plotting scripts and continue the current run. I also need to try getting onto the UW super computer in advance of the ARA bootcamp on Wednesday/Thursday. 
Alex P    
Eliot    
Leo    
Evelyn    
Ryan    
Ben    
Ethan Futher worked on documentation of the genetic algorithm. Ben is currently doing a big run to test the program. Once the big run is finished, we will look at the data and attempt to fix any issues that may arrise.

 

  107   Wed Sep 9 17:28:54 2020 Alex MUpdate 9/9/20
Name Update Plans for tomorrow
Alex M

I've been working on readying the loop for the transition to slurm. OSC is switching from its current job managing software (torque/moab) to slurm, which uses some different commands but is functionally similar. Since we have places where jobs are called in the script, I've been changing them (with a backup copy of those files that we know works on torque). 

Right now I'm testing all of the changes I've made on the space OSC has set aside for playing with slurm. I have changes in all of the places I think they belong, but I need to make sure there aren't typos/different commands from what I've used. 

I'll keep testing the changes I've made for slurm. I'll also try to organize some of the dfferences I've found in using slurm vs torque (for example, requesting an interactive job) so that everyone can see them and be able to find out what to use when OSC makes the switch (Pitzer changes on the 22nd, Owens is in November I think).
Alex P    
Eliot    
Leo    
Evelyn    
Ryan    
Ben    
Ethan    

 

  108   Mon Sep 14 17:23:26 2020 Alex MGENETIS Update 9/14/20

I just wanted to give an update on what I've been doing today for GENETIS. I went ahead and recorded myself running the loop. It should be useful for new people we're onboarding but I also went through a whole generation, which I think is interesting for everyone to understand the timescale of each part of the loop. I'm making a small edit (I have no clue how to edit videos haha) so once I'm done I'll try to send it via email and post it on slack. I also started a long run Amy requested using antennas which are asymmetric in length and opening angle and 50 individuals per generation. Since it has so many individuals it will take a long time to go through each generation. I also had to decrease the number of AraSim jobs (thus increasing the number of neutrinos per job) because otherwise we'd be submitting too many jobs and have a lot of them blocked, holding us back from running. If anyone has problems with me using up too many jobs let me know and I can try to decrease the numer of jobs per individual futher (right now I have 10 jobs per individual with 3000 neutrinos per job, which gives us 500 AraSim jobs per generation).

  119   Fri Nov 20 17:50:05 2020 Alex MWorking Meeting 11/20/20
Alex M We worked with Amy to track down the error we were getting with the AraSim fix. Alex P and I had gotten AraSim to compile, but running gave the error (at the bottom). We did a binary search for the source of the error and determined it comes from the if statement around line 640 in Report.cc:

if ( event->Nu_Interaction[0].LQ > 0 && (fabs(viewangle-signal->CHANGLE_ICE)<=settings1->OFFCONE_LIMIT*RADDEG) ) {
Ryan Kept testing different rations of tournament and roulette. A trend seems to appear that while full roulette was the worst run overall, it rises until a ratio of about 8R:2T with a max score of 99.22% match and then it slowly falls from that point. Need to do more testing to verify averages and to fix strange segmentation faults in crossover when running 6T and 8T ratio. 
   
   
   
   
   

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 ()
===========================================================

  123   Wed Dec 2 15:24:39 2020 Alex MGuide for Loop Errors

Attached is a .txt file you can find in the Evolutionary_Loop directory as Loop_Error_List.txt. It's a list of the current errors we sometimes experience in the loop, along with how to fix them if you encounter them while running. If people encounter errors that aren't in the list, let everyone know in the #genstudents chat on slack and update the file with the error message and when it was encountered (what state the loop was in) and the possible cause and solution if you know it. 

Attachment 1: Loop_Error_list.txt
Below is a list of errors we may encounter in the loop as of 11/25/20:

Error: "Pre-while, pre-for"
Description: This is an error you'll encounter after AraSim has "completed." The loop will hang after outputting "Pre-while" and then "Pre-for." This comes from the fitness function--the loop is indicating that it is inside the fitness function right before it enters the two loops it runs over the AraSim data. Hanging here indicates that there was an issue running AraSim. Specifically, it indicates that at least one of the jobs for the *first* individual in AraSim failed. 

Potential causes:
This may be caused by an issue in generating the gain files used for AraSim. These gain files are placed in the AraSim directory under the names a_{num}.txt, where {num} represents the individual number. You can check a_1.txt in the AraSim directory and see if it's complete (if it isn't, you can usually tell just by opening the file and seeing that only two lines have been printed to it).

One way of looking for the cause of this error is to look at the job error files. Inside the {runname} directory are directories containing the error and output files from the AraSim jobs. These are .../{gen}_AraSim_Errors and .../{gen}_AraSim_Output, where {gen} is the generation number. One example of an error message I've seen in the error files was 

"
terminate called after throwing an instance of 'std::out_of_range'
  what():  basic_string::substr
/var/spool/slurmd/job2345909/slurm_script: line 37: 171196 Aborted                 (core dumped) ./AraSim setup.txt $runNum outputs/ a_${num}.txt > $TMPDIR/AraOut_${gen}_${num}_${Seeds}.txt

"

This appeared in all of the error files for the first individual's jobs. 

Resolution:

The best way to resolve this is to start by checking the error files. In the case of the error message above, it would be best to go to the AraSim directory and check for the a_{num}.txt file. If you see just one (ex: a_1.txt), then that's likely to be the culprit (especially if the file is obviously not completely filled)--these files should be removed, so if one is left it may not have been moved correctly, likely due to permissions errors. Remove the a_{num}.txt file and restart from the AraSim job submissions (potential speed up: add part of the error message to the self-correcting phrases in Part_D2_AraSeed.sh to only rerun those individuals).

It's also possible that the issue was caused in XF. Make sure you follow the instructions above and start back at stage 2 to restart from the beginning of XF if starting back from AraSim doesn't work. Try to take notes on the differences you see to add to this.

It's also notable that this may be caused by permissions issues. Every time someone is handing the loop off to someone else, the OpenPermissions.sh script should be run (passing the {runName} as an argument). Look in that script to determine which files need to have open permissions. If the person with ownership of the closed files isn't available to open them, you can remove them and start back from where they would have been created. This usually occurs in AraSim and the AraOut files in Antenna_Performance_Metric should have their permissions fixed or be removed (for that generation only).

*****************************************************************************

Error: <Loop hangs while outputting dimensions and fitness scores>

Description: 
This is similar to the error above, except that instead of hanging on the first individual, it hangs on some later individual. 

Resolution: 
The instructions for resolving this should be the same as the ones above. This seems to be less common and is usually resolved by the self-correcting code in Part_D2. Regardless, if you encounter this error the first step should be to follow the instructions below in case there is just one or a handful of failed AraSim jobs. If that doesn't work, step back to stage 5 to resubmit the AraSim jobs after clearing out the possible offending files. If that doesn't work, step back to XF (you can always just step back to XF at the beginning if you're unsure that stepping back to AraSim will resolve this to potentially save time).

It's also possible that there is an error in just a handful (or even just one) of the AraSim jobs. This might be caused by opening permissions after someone has already taken over running the loop. In this case, you might be able to start the loop back up without needing to resubmit all of the AraSim jobs or step back all the way to XF. To do this, you'll need to figure out which AraSim job failed. Check the AraSim error files and output files for that generation (specifically, check to see if one is *missing*). You should be able to figure out which individual the loop is stuck on by counting how many sets of dimensions and fitness scores were printed to screen before the loop started hanging. Go to /Antenna_Performance_Metric (inside .../Evolutionary_Loop) and list all of the AraOut files corresponding to that individual and check them to see if any of them appear incomplete (AKA don't have an effective volume at the bottom).

Once you find the individual jobs that failed, you can set up the loop to only rerun those jobs. First, go to the AraSim flags directory inside the RunName directory and populate the the flags like so:

>for i in `seq 1 <NPOP>
>do
>for j in `seq 1 <jobs per individual>
>do
>echo <gen> > ${i}_${j}.txt
>echo $i >> ${i}_${j}.txt
>echo $j >> ${i}_${j}.txt
>done
>done

This will populate all of the flag files needed for AraSim to move on. Remove the flag files corresponding to the identified failed AraSim jobs. Next, go into the AraSim error file directory in the RunName directory (/<gen>_AraSim_Errors) and replace any text inside the error files corresponding to the failed AraSim jobs with the phrase "segmentation violation" (spelling and capitalization matter!). This is one of the phrases used in the self correcting part of the loop in Part_D2 and indicates to the loop to resubmit the AraSim job for that individual. 

After doing this, you should be able to return to .../Evolutionary_Loop and change the savestate in /savestates to 6 from 7. Now you can start back the loop and it will tell you that it's waiting for the AraSim jobs to finish. After 1/2 minutes it will notice that the error files have "segmentation violation" in them and will resubmit only the AraSim jobs you specified as having failed.

*****************************************************************************

Error: "cannot connect to X11 forwarding" (or something to that effect)

Description: 

This usually occurs during XF, but it may occur during the display of plots. In the case of plots being unable to display, the loop should still be able to operate, though plots might not update. However, if this message occurs during XF the data for the gain patterns for the antennas won't be properly created. This can occur at the first opening of the XF GUI or on the second part (after the xfsolver jobs have run).

Potential causes: 

First, you should make sure that you are logged in to OSC using <ssh -XY userID>. The -XY allows x11 forwarding, which is needed for the XF GUI to appear. Also remember to indicate that you need X11 forwarding when requesting your interactive job (using --x11). It's also possible that your connection to the X11 forwarding can be interrupted after a long time (I've seen the loop work for several generations over multiple interactive job submissions and then suddenly get this error). 

Resolution: 

My advice is to log out and back in to OSC each time your interactive job ends. This is an uncommon error but it's easy to miss. Once you've logged back in, you'll need to restart the save state back to the part of XF where you got this error (either 2 or 3 depending on which par the error appeared in).

*****************************************************************************

Error:  

  124   Mon Dec 7 22:51:08 2020 Alex MImportant Runs

Today I removed some of the run directories which had very little or no data or weren't worth keeping around. There are still a few that I think can be removed, but I'm keeping them until we can get a consensus that they can definitely be removed. Below I listed the names and descriptions of the runs that I think we should definitely preserve going forward. In general, the more data contained in the run directory, the more important it is to keep around. 

Name Description Symmetry NPOP Generations Roulette/Tourney Crossover Reproduction  Mutation  Penalty Neutrinos  
Machtay_20200824_Real_Run

First real run with significant amounts of data after the summer improvements.______________________________________

Symmetric 10 15 100% Roulette 100% 0% 100% Yes 100k  
Machtay_20200827_Asym_Length_Run First asymmetric length run after summer improvements. Asymmetric length 10 17 100% Roulette 100% 0% 100% Yes 100k  
Machtay_20200831_Asym_Length_and_Angle Asymmetric length and angle run after summer improvements. Asymmetric length and angle 10 42 100% Roulette 100% 0% 100% Yes 150k  
Machtay_20200911_Symmetric Longer symmetric run with fewer neutrinos. Symmetric 10 35 100% Roulette 100% 0% 100% Yes 30k  
Machtay_20200914_Asymmetric_50_Individuals Longer asymmetric run with fewer neutrinos. Asymmetric (all dimensions) 50 26 100% Roulette 100% 0% 100% Yes 30k  
Machtay_20201016_Symmetric_Improved_GA First run using improvements to GA based on Ryan's paperclip/fast loop analysis. Symmetric 50 10 50/50 75% 10% 15% Yes 30k  
Machtay_20201023_300K_Nus_50_Individuals Started with all identical individuals to demonstrate evolution; replaced penalty with hard cutoff. Increased Nus for higher fitness score precision. Asymmetric (all dimensions 50 25 50/50 75% 10% 15% No 300k  
                       
                       

 

 

  126   Tue Jan 19 19:00:30 2021 Alex MLatest Run Details/Running on Slurm

OSC managed to figure out our issue with running XF from an interactive job on Slurm. Previously, we were losing our connection to x11 forwarding. The solution is to use sinteractive instead of srun to obtain an interactive job. Here's the syntax:

sinteractive -A PAS0654 -t <time> -N 1 -n 8 -p serial

The -p serial flag denotes the type of partition to request. It's important to specify this, as otherwise it will default to the debug node, which has a limit of 1 hour.

 

We're going to begin a new run. The title is Machtay_2021_1_15_NPOP50_Asym . It is using the latest version of the GA Ryan has been working on (Latest_GA_Asym.cpp). We're using 6% reproduciton, 72% crossover, and 22% mutation. We are using 80% roulette selection. This correlates to the three numbers passed into the GA being 3 36 8 (since we're using 50 individuals).

  128   Fri Jan 29 15:59:21 2021 Alex MLoop Demonstration Video

Here's the video I made a few months ago demonstrating how to run the loop. There might be some changes that have been made since then, but they'll generally be minor so it should still be representative of what running the loop looks like. It might need to be shared with you through the Microsoft drive service OSU gives us in order to view it, so either message me on Slack or email me at machtay.1@osu.edu and I'll share the link through there.

https://drive.google.com/file/d/1yL_eH_w2hXNt7J7YOwS5xl3ZHwGyl5JR/view

  129   Thu Mar 11 15:41:52 2021 Alex MRunning The Loop Updated

Because of issues we were having with XF when running at the command line, we've shifted to running through a Pitzer VDI (see here: https://ondemand.osc.edu/pun/sys/dashboard/batch_connect/sys/bc_desktop/vdi/session_contexts/new).

The VDI will give you a mirror of a desktop running on OSC's side, so things like XF will run much faster. You can open a terminal by clicking the black box at the bottom of the screen and then run the loop like normal (./Asym_XF_Loop.sh). This has the added benefit of making it possible to exit out of your browser, close your laptop, or turn off your computer without interrupting the run, since the process is running on OSC's side rather than piping to your computer.

  130   Mon Mar 15 13:05:22 2021 Alex MCurrent Run

We are currently running the loop using the improved parameters. The parameters are as follows:

50 individuals
80/20 Roulette/Tournament
6% Reproduction, 72% Crossover, 22% Mutation

Also note that individual 5 of generation 1 had its fitness score altered because one of its AraSim jobs didn't finish in time (and we would have had to wait 5 hours for it to rerun). To remedy this, I replaced the effective volume for the job with the average of the effective volumes from the other jobs for individual 5 (essentially meaning that it ran with 270k neutrinos instead of 300k). There is a .txt file in the directory titled Run_Notes.txt containing this message (and which will contain additional messages on similar things should they arise).

Run directory: /fs/project/PAS0654/BiconeEvolutionOSC/BiconeEvolution/current_antenna_evo_build/XF_Loop/Evolutionary_Loop/Run_Outputs/Improved_Parameter_Run_2021_03_09

  131   Fri Mar 19 17:39:47 2021 Alex MNew Run

We began a new run using the same parameters as the previous one (see the last ELOG entry). The previous one ran for 8 generations. The difference between this run and the last one is that we have added in the polarity fix for AraSim Brian and Jorge gave us (copying the correct Report.cc and Report.h files into our AraSim version). Here are the run parameters:

Run Paramaters:
50 individuals
80/20 Roulette/Tournament
6% Reproduction, 72% Crossover, 22% Mutation
Run for 10 generations, then implement Jorge and Brian's fix for polarization in AraSim for the next run
ELOG V3.1.5-fc6679b