Alex M

Alex P

Eliot

Leo

Evelyn

Ryan

Ben

Ethan

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.

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.

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. 

Leo and I continued working on the roulette algorithm for the asymmetric bicone to try to get the evolved generations to match the original and database ones. We went through the mutation part of the algorithm and made sure we were rrunning all of the random number sequences in the correct order (for example, we need to make sure that if we define variables A and B from a random number generator, that in both cases we define A first, then B). We also had to make sure that we were using these random sequences the same number of times (for example, we don't want to define A once in the original/database versions and twice in the asymmetric version when the asymmetric version is set to evolve symmetric antennas--this puts the random number generator "off sequence" relative to how it is in the original/database version). We tested this with the gen 0 DNA and effective volumes (which matched with the results from the original/database runs) to evolve generation 1 and got it to match. I'm currently running the loop to test this over multiple generations.

Julie and I met with Ben to talk about AREA. Yesterday, Ben was able to generate the 0th generation of individuals and then run AraSim from a job to get effective volumes. Today, we focused on editing the scripts to work for OSC job submissions (he wrote the one he used yesterday; we modified the main script today and will continue to do so). We edited it so that we could submit the main script as a job which then submits other jobs for the arasim portion and waits for those jobs to finish before continuing on (since it needs those effective volumes for its fitness score). We're going to keep incrementally fixing the main script so that it can run over multiple generations as a job submission without errors.

I have a doctor's appointment in the morning, but maybe Leo can continue my current run. Once it's done, optimally we would work with Julie to get everything merged so that we can start a real run (we also have to implement the changes I outlined in the ELOG post a couple days ago before we do a real run/merge--most of those are pretty simple).

Julie and I will take a look at the paperclip script Ryan's been writing to see if we can help him figure out why the roulette algorithm is giving such worse fitness scores than the tournament algorithm (~ fact of 2 worse). 

The arasim jobs I submitted over the weekend kept failing. I've been looking for the cause but I can't pinpoint it right now. The issue arose on Friday when I overwrote the version of Report.cc on Eliot's user with the one we have on the databse branch (but I don't think there were realy differences aside from comments). Before I had done this, we were getting effective volumes that differed from the ones we got on the database branch. Now, the araSim jobs are just failing after 5 seconds of running. And now I'm getting an error when I try to recompile AraSim (I might need Eliot to do this?). 

I tried getting an interactive job so I could confirm that things are still working on the database branch, but I couldn't get it because it was blocked. I think that was because we had too many concurrent jobs running, which has happened a couple times over the past week-week and a half or so.

We may have found the error in the asymmetric bicone. It appears there may have been two problems. First, the setup for the simulation_PEC.xmacro script in the asymmetric version appears to have been slightly different in that the positions of the cones, relative to the positions of the coordinate systems, are different from in the other versions of the loop. This was giving different uan and gain files than the previous runs did. We fixed this, but it revealed another potential issue: in order to evolve the separation distance, we need to make it so that the coordinate systems use the separation genes. This wasn't implemented in the asymmetric version, so there would have always been a disparity in the position of the cones relative to their coordinate systems when compared to the database version of the simulation_PEC.xmacro. I have a work around for when we don't evolve the separation distance, but if we want to evolve it we need to change this script.

Second, the version of Report.cc in AraSim on Eliot's user differed from the one in the database version. The other files agreed, so I copied our version into his directory and started a run with that. It's running now and should take ~1 hour before I can see if this has fully fixed the issue.

(See below the table for a review of the past couple of days since ELOG has been down.)
We may have found what was causing the error in Eliot and Leo's version. They were getting 0 effective volumes. I edited their output macroskeletons to use pro grid (I figured it was the default setting, but it looks like not). This seems to have fixed the issue with their .uan files having all 0s and 180s for the phase and -300 gain. However, it wasn't writing to the vEffective.csv and fitnessScores.csv files correctly. We realized they may have needed to recompile. We did that and ran a preliminary tset, where we got some promising results. The effective volumes and fitness scores seem to have been read out and plotted correctly, but they didn't appear to match the previous two runs Alex P and I did. That might be because we were messing around with the save state sloppily. Currently, Eliot is rerunning from the beginning with the intention of seeing if it will go all the way through generation 0 smoothly. From there, we'll need to compare the effective volumes and fitness scores with the previous two runs Alex P and I did (although I can confirm that the generation 0 DNA matches). Then we'll need to let it run for a few more generations to make sure it evolves the same individuals those two previous runs evolved.

If it looks like these fixes worked and the effective volumes are being made correctly and the same individuals are evolved as in the previous two runs Alex P and I did, then we'll be ready to start merging. The first step will be to fix a merge conflict on the asymmetric bicone branch. Then, we'll have to carefully merge and resolve merge conflicts. The order should be that the asymmetric bicone branch merges onto the database branch, which will then merge onto the master branch. Once that's done, we'll be able to do a proper run.

The name of this run is Data_Base_Test_7_10.

The name of the previous run we are comparing against is Length_Cutoff_Test_3.

Alex and I continued running the loop for the database test. We ran into an error over the weekend that was affecting generations after gen 0. Alex fixed it this morning and continued the run. 

The goal of this run is to test the database. We are comparing it to the previous run we did last week to make sure that we get the same individuals. We're using the same parameters as the previous run: NPOP of 8, separation distance of 0.05 cm, and the same roulette algorithm (AKA the same seeds). In principle we should generate the same DNA for the individuals. 

Starting in generation 2, we have a divergence--one of the individuals is different from generation 2 of the previous run. We think this is because there is noise in AraSim (I don't think we can turn the noise off when we're using the effective volume). This makes the probabilities of choosing each individual different and allows different ones to be chosen even though the random number being selected is the same. Oveall it looks ok and we're going to keep the run going to see if it converges to the same individuals as the previous run after a few more generations.

I also wrote a bit in the paper. I took a look at the paper Amy sent on the effective volumes to try to understand it better. I think I understand it, but I'm trying to see how the equation we used in AREA in the proceeding is related (what the weights represent). 

I made a fix to the database over the weekend when I noticed it was incorrectly counting the array indexes for counting failures. And then I found an error in our output.xmacro generation when making one for the database with the simulation number fix and that xmacro wasn't using the right bounds. We got the database version working through multiple generations. On the second generation the individuals matched exactly to our previous run except one individual. Looking at the fitness scores of the previous run, the parent individual in the previous generation had a fitness score of .18 compared to 4's of other parents, so it's reasonable that it wouldn't get picked from another run of the algorithm. While the GA is seeded so that it makes the same changes when it picks the same parent individuals, the fitness scores vary slightly between these two runs which alter how the parent individuals get picked especially when it comes to smaller fitness scores like this. 
Also fixed an issue on Eliot and Leo's copy of AraSim, the extrapolation issue we found earlier hadn't been implemented on their branch so to make sure all the tests before merging were accurate we made that change.

The name of this run is Data_Base_Test_7_10.

The name of the previous run we are comparing against is Length_Cutoff_Test_3.

Yesterday we started a run of the database version of the loop. The goal was to use it to replicate the results from the run we finished yesterday using the same parameters (NPOP=8, SEEDS=10, bicone separation = 0.05 cm). We initially ran into problems with the databse which we fixed this morning. We successfully completed the 0th generation, but then the .uan files for the next generation weren't created properly. Alex and I will try to resolve this. Amy suggested we only need to run 6-7 generations to confirm that we get the same results as from the previous run. The 0th generation agreed with the 0th generation of the previous run (in terms of DNA; the effective volume/fitness score plots looked similar, but there is slight room for noise in AraSim so the exact values are slightly different; but overall they look very similar). I also confirmed that the generation DNA is the same in generation 1 of the current database run as in the previous run.

The name of this run is Data_Base_Test_7_10.

The name of the previous run we are comparing against is Length_Cutoff_Test_3.

The top priority right now needs to be with fixing the error in the database version that is causing the uan files to be made incorrectly. Once that is fixed, we can continue the run and confirm that we get the same results After that, we'll have Eliot and Leo run their version using the same parameters to confirm that they get the same results as the previous two runs. From there, we'll merge the branches and begin a real run.

The first real run will use NPOP=8, 3 dimensions (LRT), a separation distance of 3 cm, and will run for up to 15 generations. We'll also fix the issue of the mutation standard deviation (see yesterday's update for the three differences between our current runs and the future real runs). 

Our goal is to get as much real data as possible next week. I'm confident that we can have at least one with 3 dimensions (LRT) done by next Friday (we'll shoot for 15 generations, but if it seems to converge between 10-15 we can stop it). 

If we can finish that run, we can start another run using 4 dimensions, where we add an option to make the bicone assymetric in length (L1L2RT). These are the runs we're hoping to use in the paper.

Finished running the loop for 15 generations. The last plots are on Dropbox under Length_Cutoff_Test_3. There are three things to fix before running this version of the loop again. See below the table.

We started running the next step, which is the database version. 

Julie, Ben, Ethan, and I all met to talk about AREA. We started going through the code to understand it, but we're stuck because we don't know if AraSim Lite is actually in the directory or not.

I started rewriting the AREA section.

I'll keep the run going, but I might have to stop it and look for bugs if the evolution doesn't track with the previous run. We named this one Data_Base_Test_7_9.

Continued the run from yesterday. Alex P and I applied the changes we made to the bash script for fixing the bugs we found in the simulation number to the database version. Once we get 15 generations of data for this run we'll start testing the database version. Once that works we'll have Eliot and Leo run their version with only 3 genes and if we get the same genes all around we'll be able to merge the asymmetric branch with the database branch and then merge with master. I also fixed up a bug I found in one of the plotting programs that meant it was missing the first individual, it should be good now.

Ryan and I talked a bit about how to apply crossover and mutation to the paperclip. I'm not sure that crossover makes sense, but I think it's possible. He's going to start by doing crossover of the chromosomes and then when that's working he can try crossing over the genes (this is where I'm not sure things make sense, but who knows). Then he can implement mutation in that function.

Julie and I spoke with Ben about AREA and started helping him siftt through all the files. We're going to meet with Ethan tomorrow to catch him up to speed and start reviewing the bash script that runs all of AREA.

Finish this run, test the database. I'll meet with Julie, Ben, and Ethan to talk about AREA. Also, Eliot and Leo found a potential issue in the roulette algorithm that I asked them to look at, so we might try making a fix in there and see if that allows our mutations to be more reasonable. Alex and I are going to have to meet with Eliot and Leo soon so we can all work together on merging our branches and resolving merge conflicts.

Found a bug while running the loop, fixed it and starting running again. Added a few things to the paper.