ELOG - Daily Update 7/13/20

Updates and Results Talks and Posters Advice Ideas Important Figures Write-Ups Outreach How-To Funding Opportunities GENETIS

GENETIS

List | New | Edit | Delete | Reply | Duplicate | Find | Config | Help

This is a draft message, edit and submit it to make it permanent

Message ID: 87 Entry time: Mon Jul 13 15:34:40 2020

Author:	Alex M
Subject:	Daily Update 7/13/20

Name	Update	Plans for Tomorrow
Alex M	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).	We'll try finishing up this run and doing Eliot and Leo's run. If we can get results fast, we can start merging. Our intention is to start a real run on Wednesday. That would likely take ~1.5 days.
Alex P	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.	Continue running this overnight to get results and hopefully start merging tomorrow or at least start the process of setting up for the merge and finishing up any of these runs.
Eliot	Began a final test run with constant separation to ensure 2 chromosome loop is working before we merge. Stopped during gen 0 to implement progrid in arasim. Thanks Alex M! Continued the run from just before arasim. Had very slow progress due to bad wifi connection. I kept getting kicked off OSC! So far everything looks good but wifi made for a shotty test at best. Name is FERSTL_20200713_PREMERGE_TEST. Lastly, commited one last time before we merge. Had some issues with that as always but believe I have it worked out.	Will try to run a couple more gens on that run and begin merging with the Alexs.
Leo
Evelyn
Ryan	Created a temporary mutation function to test to see if the convergence problem from Friday would be resolved. For the most part, it did resolve the problem and the function has not converged onto a single paperclip and the fitness scored being produced are higher than before. However, I noticed that in test runs with on average greater than ten individuals (usually) the individuals being chosen are the same every run regardless of fitness scores and it seems to be causing the scores to stall out. for example in a run of 100 generations the 90th-100th generations would only pick the 0th and 1st individual for all ten chosen. Even when seeding the random number generator, this appears to be happening and I am not sure why. Some runs with higher chances of mutations seemed to have this effect happen later than ones with low mutation chance but so far this just seems like a correlation and not causation.	Fix the aforementioned issue. Then, rework the mutation function to more closely model the one in bicone's roulette algorithm.
Ben
Ethan

ELOG V3.1.5-fc6679b