ELOG GENETIS

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

GENETIS

Fields marked with * are required
Entry time:	Tue Feb 3 18:01:41 2026
Author*:
Subject*:
<p> <table width="98%" align="center" cellspacing="1" style="border:1px solid #486090;"> <tbody> <tr> <td cellpadding="3px" style="background-color:#486090; font-weidht:bold; color:white;">Quote:</td></tr> <tr> <td cellpadding="10px" style="background-color:#FFFFB0;"><p>This is a general update. Most of our recent meetings have been to teach the students to use Git properly, or to answer questions on the training modules. </p> <p> </p> <h1 style="text-align:center"><u>Update </u></h1> <p><strong>1. Git Update: </strong>I recently cleaned up our Git and GitHub so that we have a better way to develop this code. Once I cleaned it up the goal is to educate all of the students to properly use Git so we develop code correctly moving forward. The repository had become quite a mess. The students were constantly developing on a branch, and never merging it back to the main branch. This means that we never had a working copy that we could run on while edits were being made in parallel. I attempted to merge the edits to the main branch with the hopes of getting this functioning so we could evolve while working on the bottleneck function; however, it looks like someone with poor knowledge of Git edited the main branch and we had an abundance of merge conflicts. </p> <p>What I've done now is reset the repository so that all merge conflicts are resolved and a working copy exists on the main branch. I've also added a .gitignore that will ignore all data files. Git doesn't like these because (1) it hates when tracked files disappear -- ie when we delete trial run data, if someone accidentally pushed it then Git complains-- and (2) it means it we constantly are adding more untracked files (every single new file we make is untracked and then gets tracked, like the flag files). So, I've had it only track useful code. </p> <p>The goal once I train the other on Git is to move the place of the data files and make it it's own git repository (once we start doing fewer trial runs so we won't lose important data). If the others learn to check the status of files before pushing them, they can make sure they don't push useless trial data sets, and either (1) delete them, or (2) add them to the .gitignore.</p> <p>As for now, we successfully have the working, run-able copy on the main branch now. When any more revisions are made (e.g. the talk of adding the wall time variable), we can branch and edit on that so we still run. </p> <p> </p> <p>2. <strong>Evolution/bottleneck update: </strong>We got the loop working to the point that it can run all the way through a generation without fatal problems. The only potential problem we can see right now is if we need to go backward in the savestate. We're working on making that not a problem--the solution is to better organize the output files and data, which we were interested in anyway. Right now we are running with 10 individuals in each generation. Alex got through 2 generations without a problem, so he'll keep running but now we're trying to make some of these more minor fixes so we may have to stop the run. Alex does have plots (they don't look great, but at least they're being made correctly without error). At the moment we are swimming in GPUs. We haven't had much trouble at all this week with getting them, so that's why we were able to get 2 generations done between around midnight last night and 2ish today; not sure how long that will persist, but Pitzer has had relatively little usage whenever we've looked lately.</p> <p> </p> <p>Comments on the plots: We're discussing this now, we don't think the individuals should really be color coded/separate on the legend because it is not like they follow one individual across multiple generations; however, we do need to label the dotted line. Another thing we were considering is decreasing the penalty factor for when the cones are too big for the hole. If we get something with a much much better Veff but it's only slightly larger than the hole, it might be worth it to help that one stick around a little bit more.</p> <p> </p> <p>3.<strong> Wall time Variable Update:</strong> Also, last week Carl and Alex talked about the variable wall time again. We decided the best idea is to start by implementing a variable wall time based on the cylindrical volume that he mentioned before, but in the future, we might also be able to check the time of each GPU job and then plot it against the dimensions of the cone/cylindrical volume to get a better estimate of the wall time for each job</p> <p> </p> <p> </p> <p> </p> <p> </p></td> </tr> </tbody> </table> </p><p> </p> Encoding: HTML ELCode plain Suppress Email notification

Attachment 1:
Drop attachments here...

ELOG V3.1.5-fc6679b