Sunday, April 24, 2011
Update 4/24
Sara, Nick, and I met with Ian over the stats, and we're chugging through. I brought the methods section to writing group for discussion, and the revised copies are still trickling back in. We're getting there! Yay!
Thursday, April 21, 2011
And the hits just keep on coming...
Hey again,
As you have no doubt heard by now, I've got the complete data set. It is a glorious 250,000 lines of data (plus, I've tested it in R and it works beautifully!).
Still working on how exactly to do the stats, but now that the data are in a useful format, this part should be fairly straightforward (hopefully). Also, I've been getting help from both Ian and Eli so this thing is as good as done!
-Nick
As you have no doubt heard by now, I've got the complete data set. It is a glorious 250,000 lines of data (plus, I've tested it in R and it works beautifully!).
Still working on how exactly to do the stats, but now that the data are in a useful format, this part should be fairly straightforward (hopefully). Also, I've been getting help from both Ian and Eli so this thing is as good as done!
-Nick
Monday, April 18, 2011
Stats coming along
Hey everyone,
I just had a fruitful meeting with Eli Swanson (another grad student from the Holekamp lab) concerning our statistics and how to work with the tremendous amount of data in R.
At this point, it looks like the multiple regression with ANOVAs is our best bet. This will essentially tell us how each response variable is affecting things like percent signaling, fitness, etc...
The good news is that this should be far less complicated than I was initially thinking it would be (or at least now I just understand it better). I'm going to start writing my R scripts now that I understand what needs to be done (as soon I'm done for the day here in the lab).
I'll continue to keep you all updated on this process as things happen.
-Nick
I just had a fruitful meeting with Eli Swanson (another grad student from the Holekamp lab) concerning our statistics and how to work with the tremendous amount of data in R.
At this point, it looks like the multiple regression with ANOVAs is our best bet. This will essentially tell us how each response variable is affecting things like percent signaling, fitness, etc...
The good news is that this should be far less complicated than I was initially thinking it would be (or at least now I just understand it better). I'm going to start writing my R scripts now that I understand what needs to be done (as soon I'm done for the day here in the lab).
I'll continue to keep you all updated on this process as things happen.
-Nick
Saturday, April 16, 2011
Otherness and Fury: The Avida LAN party progress report
So, we've spent the last several hours running scripts on the hpcc gateway. We decided to go with plan B (running two runs: one with signaling and one without). We've got a good portion of our data and most of the runs are completed (or in process). Also, Alex is working on scripting something to make the tremendous volume of data more usable.
As far as the writing is concerned, we have completed a draft of the methods section, the title and abstract, and the acknowledgements all in the requirements for PLoS
We have made some progress on the statistics portion of the project as well.
Also, toad-panther and eel-worm.
Gnome-fria
Sara ended the evening with a Pfennig-fox, culminating in a bloody lip.
As far as the writing is concerned, we have completed a draft of the methods section, the title and abstract, and the acknowledgements all in the requirements for PLoS
We have made some progress on the statistics portion of the project as well.
Also, toad-panther and eel-worm.
Gnome-fria
Sara ended the evening with a Pfennig-fox, culminating in a bloody lip.
Friday, April 15, 2011
Update: 4/15
I met with Phil today to go over the methods from his point of view. His main suggestions were to target PLoS papers on artificial life, and he sent me one nice example paper to use as a reference.
I also met with Louise today to go over the methods draft. She suggested adding in a figure of how signaling works and details on some of the defaults. She also suggested that the introduction should set up the methods, so Sara and I may be working closer tomorrow.
Overall, Louise is "extremely excited" to see the results, and I think Phil is, too, so let's hope we get some!
I also met with Louise today to go over the methods draft. She suggested adding in a figure of how signaling works and details on some of the defaults. She also suggested that the introduction should set up the methods, so Sara and I may be working closer tomorrow.
Overall, Louise is "extremely excited" to see the results, and I think Phil is, too, so let's hope we get some!
Thursday, April 14, 2011
Update: 4/14
With the issues on Teragrid, we're pursuing the HPCC. Those accounts have been set up for all members of our projects, and at least one of us falls into the priority BEACON group. Alex is working on getting the HPCC together for us to all use.
I took Sara's introduction to writing group. The main comments/criticisms were to focus the intro more and to include detailed paragraphs on the hypotheses and rationale for the project. Sara is revising this soon based on the comments.
Nick, Sara, and I met today to figure out how we want to graphically represent the data. we have a decent idea, so Nick is working on coding this and the associated stats.
Nick, Alex, Sara, and I are meeting at Nick's place Saturday to try to scrounge up some data and have a general working party on this project. With the numerous setbacks and challenges we've already had (and surmounted), all I can say is wish us luck!
I took Sara's introduction to writing group. The main comments/criticisms were to focus the intro more and to include detailed paragraphs on the hypotheses and rationale for the project. Sara is revising this soon based on the comments.
Nick, Sara, and I met today to figure out how we want to graphically represent the data. we have a decent idea, so Nick is working on coding this and the associated stats.
Nick, Alex, Sara, and I are meeting at Nick's place Saturday to try to scrounge up some data and have a general working party on this project. With the numerous setbacks and challenges we've already had (and surmounted), all I can say is wish us luck!
Sunday, April 10, 2011
Update 4/10
Hey All,
As an update, Phil was out of town Friday, so Alex and I did not meet with him, however, I am working on the methods (based on the methods of published Avida papers) and Alex has gotten the genomes written and everything seems to be coming together.
Keep up the good work, guys!
As an update, Phil was out of town Friday, so Alex and I did not meet with him, however, I am working on the methods (based on the methods of published Avida papers) and Alex has gotten the genomes written and everything seems to be coming together.
Keep up the good work, guys!
Sunday, April 3, 2011
Update
Hey Everyone, I've got a few updates to share will you all:
As far as TeraGrid goes, I'm on! I had a little bit of trouble connecting at first, but Dirk Colbry (the TeraGrid campus champion) was able to help me connect via ssh. Unfortunately, I'm having issues getting Alex's version of Avida onto TeraGrid (security issues with the scp command in ssh) so I will have that figured out by Monday or Tuesday.
I haven't been able to get Alex's Avida running on my computer anyways (I was testing it in the meantime and "Permission Denied" for some reason). This I will also try to have fixed by early this week.
Lastly, I've spoken with Ian about the statistics and he says we just have to wait until he goes over linear modeling and such during lecture. So unfortunately, there is no working too far ahead on the stats end (for now).
Once this is all figured out, I should be good to go. I'll continue to keep everyone updated on my progress/issues!
As far as TeraGrid goes, I'm on! I had a little bit of trouble connecting at first, but Dirk Colbry (the TeraGrid campus champion) was able to help me connect via ssh. Unfortunately, I'm having issues getting Alex's version of Avida onto TeraGrid (security issues with the scp command in ssh) so I will have that figured out by Monday or Tuesday.
I haven't been able to get Alex's Avida running on my computer anyways (I was testing it in the meantime and "Permission Denied" for some reason). This I will also try to have fixed by early this week.
Lastly, I've spoken with Ian about the statistics and he says we just have to wait until he goes over linear modeling and such during lecture. So unfortunately, there is no working too far ahead on the stats end (for now).
Once this is all figured out, I should be good to go. I'll continue to keep everyone updated on my progress/issues!
Friday, April 1, 2011
Signaling implementation in Avida
The code is, for the most part, done. Here's how we've implemented things:
The short version:
Organisms can both signal and receive signals. Signals are sent to everybody around them, and the best mate is chosen from all the received signals.
When organisms divide, their reproductive materials are preserved on a shelf labeled by the cell the organism was in; when another organism wants to mate with that organism, it retrieves a copy of most recent reproductive materials stored in that cell's shelf.
Initially, we require that signals be received to mate; later, we turn it off, and anyone who doesn't receive a signal (either doesn't try or didn't get a signal) just chooses a random shelf.
The long version:
We added two new instructions -- mate-signal and mate-receive. Organisms can do either or both, as often as they want.
When mate-signal is executed, a message (piggybacking off of the existing messaging code) is broadcast to all organisms within a certain radius of the sender. Only a certain number (default 8) of signals are 'remembered', the oldest signal is forgotten first. The message contains the cell ID of the signaler.
When mate-receive is executed, a message is selected from among all those received. Currently it's selected at random, I'm going to change that to by merit this weekend. The message -- the cell ID of the signaler -- is stored as mateID in the receiver's phenotype. During this procedure, all received signals are 'forgotten' (mostly for coding convenience, as the only code I dug deep enough to find for that datatype was a pop). With pure random selection this forgetfulness seemed like it might become an interesting analogue for attention, but if we switch to choosing by merit it shouldn't make any difference. I'm still a little worried that choosing by merit may have unintended consequences, I haven't fully thought out where that pressure will be applied.
If the organism has received no signals, mateID is instead set to -2 to indicate a failed receive. (I need to change this slightly, as it will currently overwrite any previous successful receives!)
When an organism divides via divide-sex, it goes into the birth chamber and checks in with our new (and awkwardly named) cBirthMateSelectHandler_GameteStorage. This mate selection class first stores the offspring created by the divide -- the gamete, more or less -- in an array indexed by the parent's cell ID. Gametes are stored until overwritten by another entry for that cell ID.
If the organism has received a signal, it checks to see if a gamete is available for the cell ID stored in its mateID: if yes, it's used to generate offspring; if not, mating fails. (Note that here, organisms that have signaled but not yet divided will not have stored their gametes; in this case, very early in the sim the spot will be empty, and for the rest of the sim will contain the gamete of a dead organism. This should be rare enough to not cause problems.)
If the organism has not received a signal, we check the new SIGNAL_RECV_NECESSARY_TO_MATE configuration parameter. If it's true, mating fails. If it's false, this organism chooses a random cell ID; if a gamete is stored for this cell ID, it's used to generate offspring; if not, mating fails (and this case should be pretty rare).
And that's it. Now (well, after I make the above mentioned small changes) we have to get it running on something, make sure we can get the data we need out of Avida without further modification (we may need to set signaling to a task, for example), and then see if Avida can find any holes in our model that need to be patched up.
The short version:
Organisms can both signal and receive signals. Signals are sent to everybody around them, and the best mate is chosen from all the received signals.
When organisms divide, their reproductive materials are preserved on a shelf labeled by the cell the organism was in; when another organism wants to mate with that organism, it retrieves a copy of most recent reproductive materials stored in that cell's shelf.
Initially, we require that signals be received to mate; later, we turn it off, and anyone who doesn't receive a signal (either doesn't try or didn't get a signal) just chooses a random shelf.
The long version:
We added two new instructions -- mate-signal and mate-receive. Organisms can do either or both, as often as they want.
When mate-signal is executed, a message (piggybacking off of the existing messaging code) is broadcast to all organisms within a certain radius of the sender. Only a certain number (default 8) of signals are 'remembered', the oldest signal is forgotten first. The message contains the cell ID of the signaler.
When mate-receive is executed, a message is selected from among all those received. Currently it's selected at random, I'm going to change that to by merit this weekend. The message -- the cell ID of the signaler -- is stored as mateID in the receiver's phenotype. During this procedure, all received signals are 'forgotten' (mostly for coding convenience, as the only code I dug deep enough to find for that datatype was a pop). With pure random selection this forgetfulness seemed like it might become an interesting analogue for attention, but if we switch to choosing by merit it shouldn't make any difference. I'm still a little worried that choosing by merit may have unintended consequences, I haven't fully thought out where that pressure will be applied.
If the organism has received no signals, mateID is instead set to -2 to indicate a failed receive. (I need to change this slightly, as it will currently overwrite any previous successful receives!)
When an organism divides via divide-sex, it goes into the birth chamber and checks in with our new (and awkwardly named) cBirthMateSelectHandler_GameteStorage. This mate selection class first stores the offspring created by the divide -- the gamete, more or less -- in an array indexed by the parent's cell ID. Gametes are stored until overwritten by another entry for that cell ID.
If the organism has received a signal, it checks to see if a gamete is available for the cell ID stored in its mateID: if yes, it's used to generate offspring; if not, mating fails. (Note that here, organisms that have signaled but not yet divided will not have stored their gametes; in this case, very early in the sim the spot will be empty, and for the rest of the sim will contain the gamete of a dead organism. This should be rare enough to not cause problems.)
If the organism has not received a signal, we check the new SIGNAL_RECV_NECESSARY_TO_MATE configuration parameter. If it's true, mating fails. If it's false, this organism chooses a random cell ID; if a gamete is stored for this cell ID, it's used to generate offspring; if not, mating fails (and this case should be pretty rare).
And that's it. Now (well, after I make the above mentioned small changes) we have to get it running on something, make sure we can get the data we need out of Avida without further modification (we may need to set signaling to a task, for example), and then see if Avida can find any holes in our model that need to be patched up.
Subscribe to:
Comments (Atom)