Robust-first Computing Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
**Bio**

I'm a new graduate student in the CS department here at UNM.  I did my undergrad in CS here (graduated May 2014) with a minor in Business (yeah, yeah).  "Mad-man" science like aritifical intelligence/life are part of what lured me to computing in the first place.  I would say I'm much more interested in algorithms, paradigms, as opposed to some common interests like specific languages or games.  I've been at Sandia as an intern for a year now; my group is mostly CS people that do various kinds of real-time data analysis software.

Contact: jvick3@unm.edu

[[people:james_vickers:project_submission|Project submission]]

[[people:james_vickers:crit3|Crit 3 materials]]

[[people:james_vickers:crit2|Crit 2 materials]]

[[people:james_vickers:crit1|Crit 1 materials]]

[[people:james_vickers:researcher_pres|Alife researcher presentation materials]]

Current title/abstract:

//Adaptive isolation for protection in the Movable Feast Machine//

The //Movable Feast Machine// (MFM) is a computational platform which encourages robustness and scalability by limiting the read/write access of its //Elements//.  Even with this spatial access restriction, writes performed by these Elements can have adverse effects to important computations.  We present an //Adaptive Isolator// to robustly separate Elements, proving very useful for prolonging their presence and integrity.  The Adaptive Isolator provides strong protection with minimal overhead to the overall system.  

--------------------------------------------------------------------------------

**Journal**

-------------------------------------------------------------------------------

**11/21/2014**

As I was writing my paper a few days ago, I found myself trying to explain why my Isolator's 
are programming to only do their swapping routine (//Bubble Repulsion//) when they are at a particular
distance from an Element (R-1).  I could not for the life of me come up for why that was...I had 
originally done it because I thought I had seen it acting unstable without this check.  It was kind
of an artifact of previous failed implementations of Bubble Repulsion.  I decided to remove this
restriction and test it out.  It appeared to work well, better even.  I'm just about done re-running
my experiment script with the slightly modified behavior; it looks like the protection performance
of Isolator got better with this change.  It basically allows more Isolator's to engage in repulsion
by allowing them to do so regardless of their distance from their protectee Atom.

**Edit:** Wow, allowing Isolator's at any distance to repulse (rather than just R-1) improved the 
protection performance pretty significantly.  You can see the difference in some of my graphs, but the 
//half-lifes// really tell the tale.  I define half-life as the time in AEPS it takes for half of the Atom's in an experiment to be wiped out (by Eraser, usually).  A couple notable comparisons between limited and full repulsion:

Eraser Distance 4, Inner Radius 3: \\
Limited repulsion: Data Half-life = 2565, Eraser Half-life = 175\\
Full repulsion:    Data Half-life = 16150 (+ 529.6%), Eraser Half-life = 180 (+ 2.9%)\\
**Note: Eraser half-life doesn't change much because with Eraser Distance of 4, Isolator cannot surround it for long!**\\

Eraser Distance 1, Inner Radius 2:\\
Limited repulsion: Data Half-life = 5001, Eraser Half-life = 18765\\
Full Repulsion: Data Half-life = 17155 (+ 243.0%), Eraser Half-life = 39245 (+ 109.1%)\\

I'm very happy with this improvement.  It makes the algorithm simpler, and yet do its job a lot better.  What's not to like?


-------------------------------------------------------------------------------

**11/05/2014**

Just made a chunk of .mfs files (16) for use with an experiment script.  All of the setups begin with some some Elements spaced across the grid such that no two are within an Event Window of each other, except Isolator's which are directly next to their intended protectee.  Each tile has the same pattern of these Element's on it, which is symmetrical itself.  I made 4 that have 8 Data and 8 Eraser per tile, varying the Eraser distance from 1-4 for each different .mfs file.  I then also have 12 setups that have 8 Data, Eraser, and Isolator, with single Isolator's placed directly next to the Data's, and varying the Eraser distance and inner radius of the Isolators to cover all combinations.

Example of one of these setups for a single tile:
(Orange = Eraser, Purple = Isolator, Blue = Data)

{{:people:james_vickers:tile.png?nolink&300|}}

I also made a key change to my adversary, Eraser, that I've been considering for a while.  Until now, Eraser would only set non-Eraser sites to Empty; this means that without other things around that destroy stuff (like Dreg), the number of Eraser's is constant.  I had started to feel this was 'unfair' in some way, so now Eraser's will also erase each other - now being a brute is a two-edged sword.

-------------------------------------------------------------------------------

**10/29/2014**

Just made a video of an interesting little usage of Isolator.  It starts off with a dense mass of Wall, with one Isolator on the outside.  The Bubble Replusion algorithm of Isolator breaks up that mass until they are all (almost) completely isolated from each other.  Video here:

https://www.youtube.com/watch?v=0RZ9BoWmisA&feature=youtu.be

-------------------------------------------------------------------------------

**10/26/2014**

Just finished writing a nice little script that takes those /tmp/dddd/tbd/data.dat files and plots the amount of specified elements versus time in AEPS.  This is the first real Python program I'm written, and I must say I'm impressed with the language.  The script takes args like this:

./plot_element_counts.py <data file> <title of plots> <spaced list of Element names>

e.g.

./plot_element_counts.py /tmp/xxxx/tbd/data.data "a nice title" "Data" "Creg" "Empty"

Which will make plots of counts versus AEPS for Data, Creg, and Empty.  I think the script is general-purpose enough that most everyone in the class will find it useful for their project, so I think I'll ask Ackley if it's OK to share it.

-------------------------------------------------------------------------------

**10/20/2014**

Crit 2 went well, but the way I explained my algorithm made it seem impossible.  It is not impossible, but works in kind of a funny way that I should probably tweak a little to make more sensible.  An Isolator I, when it sees an Element e0 at R-1 and some other Element e1 that has a distance of at least R from e0, increases the X and Y offsets of e0 from I //if they are non-zero//.  This must be the only time that an Isolator actually swaps the Element away, when it is aligned with it in either X or Y.  Basically the code for computing the offset looks like this (kind of clunky):

  SPoint away_offset, away_site;
  s32 site_X = site.GetX();   // site is the Element at distance R-1 from this Isolator
  s32 site_Y = site.GetY();
  if (site_X < 0)   // make offset in X be one unit away from this Isolator
     away_offset.SetX(-1);
  else if (site_X > 0)
     away_offset.SetX(1);
  else
     away_offset.SetX(0);  // the key part, only time swap will actually work is when one offset is 0
  if (site_Y < 0)  // make offset in Y be one unit away from this Isolator
     away_offset.SetY(-1); 
  else if (site_Y > 0)
     away_offset.SetY(1);
  else
     away_offset.SetY(0);
  away_site = site + away_offset;
  if (window.IsLiveSite(away_site) && away_site.GetManhattanLength() <= R)
  {   window.SwapAtoms(site, away_site);
  }
  

----------------------------------------------------------------------------------------------------------

**10/18/2014**

Last night I tried a big change to Isolator to try and make "Isolator bubbles" repel from each other.  An Isolator seeing some non-Isolator Element E at distance D will look at all sites of at least distance R-D+1, which should be outside of the Event Window of E.  If an Isolator is seen at any of those locations, Isolator swaps E in the opposite direction of the located Isolator.  This setup is extremely unstable though and doesn't really accomplish repulsion.  The issue I think is that when E moves, Isolators are frequently left behind for a bit as they have not gotten an Event yet.  The remaining Isolators that do see E then also see these 'artifact' Isolators and swap E away from them.  The result of that is that E is constantly being swapped around and its location is wildly unstable and tends towards edges or corners of the grid.  Brief video of this here; it doesn't do justice of just how fast and violent it looks in real time though.

https://www.youtube.com/watch?v=K7po96EMpVo&feature=youtu.be

Back to the drawing board... 

-------------------------------------------------------------------------------

**10/14/2014**

Made big changes to my abstract and title.  Gutted a lot of the abstract and really tightened up the language.  I think it's getting there.  Also made the title very short - 9 words including "Movable Feast Machine", which I kind of feel is necessary to include.

{{:people:james_vickers:project_abstract_v3.pdf| Project Abstract, v3}}

--------------------------------------------------------------------------------

**10/8/2014**

I have demonstrated that I can make Isolator successfully defend Elements from a simple brute Element such as my prototype Eraser.  Sadly, I did it in kind of a 'cheap' way.  Now when Isolator sees an Element of type Eraser, it removes it from the MFM.  This means that any other Element surrounded by Isolators is very unlikely to ever be within an Event Window of an Eraser, and is therefore safe from them.  This tactic is cheap in the sense that it relies on knowing the type of Eraser.  I'm thinking the next step for this little guy is more complicated; start giving Isolators some knowledge about the Element they are protecting (probably regardless of type), such which direction it is relative to them.  That way, when Isolator sees an Element coming towards its nucleus and it doesn't know what to do with it, it could swap it in the opposite direction of its nucleus to keep it away from it.  I could also see such a behavior being useful in reverse, as if an outside Element is deemed 'good' to the Element the Isolator is surrounding, Isolator could swap that Element to be next to the nucleus.  I've put Isolator up to some pretty extreme tasks of protecting, say, a single Data against an entire grid of Erasers.  So far it seems to do that job quite well.

--------------------------------------------------------------------------------


**10/6/2014**

Made a couple edits to my project abstract and title from the feedback in class today.  I removed the overly-strong claims of perfect isolation in the MFM and of making a system "more predictable".  Also cleaned up and removed some redundant or otherwise unexpressive language.  Second version is here:

{{:people:james_vickers:project_abstract_v2.pdf|}}

-------------------------------------------------------------------------------

**10/5/2014**

Just implemented a simple "Eraser" Element to pit against my Isolator.  Eraser has an Element Parameter "Erase Radius", and when called to act, erases (sets to Element Empty) any non-Eraser non-Empty site within that distance of itself.  My idea is to see how Isolator can protect its 'nucleus' from such a simple brute.  So far, the news isn't great; Isolator is kind of "too nice" to be an effective protector.  It won't write itself to occupied sites in order to protect its nucleus at present.  The result of this is that a nucleus such as Data and Eraser both get surrounded by Isolator, but not enough distance is provided to prevent Eraser from seeing the interior Data atom.  I'm thinking maybe Isolator can be changed up so he sees Eraser coming from the outside and destroys it.  Or perhaps Isolator can destroy any Element that gets too close to it's "cell wall" that isn't the same type as its nucleus.

--------------------------------------------------------------------------------

**10/2/2014**

Made a first draft of my project abstract.  

{{:people:project_abstract_v1.pdf|}}

-------------------------------------------------------------------------------

**9/27/2014**

On Thursday, Trent helped me design and implement the next version of my "Isolator" Element.  There was a bug for a while that made it do nothing (except delete itself immediately upon seeing another Element), but that got straightened out.  Came out good!  Basically acts like a cell or bubble that follows Elements around.  Description of the behavior and a demo is up here:

https://www.youtube.com/watch?v=UooM9zbyN4I&feature=youtu.be

Update: Fixed some implementation errors and made the Isolator only wander/die if it is not currently surrounding some Element (i.e. sees one in its Event Window).  Longer video with interaction with various MFM Elements here (including a shark/fish egg drop style challenge):

http://youtu.be/h4KwxWkJ3Nw

-------------------------------------------------------------------------------

**9/24/2014**

Just finished a first-attempt at an "Isolator" Element that will surround other Elements with itself.  The behavior of this first version is to look at every site within R-1 of its Event Window (all but the furthest) - if it sees anything that isn't Empty or itself, it copies itself to the furthest sites in its Event Window.  This simple version does a good job of surrounding Elements (and re-surrounding them, even if Isolators are destroyed), but it makes a very tight region around the Element.  Also, this version has no reproduction or similar population regulation functions.  Brief video of its behavior is here, interacting with Wall:

https://www.youtube.com/watch?v=0oUjI-enSyQ&feature=youtu.be

-------------------------------------------------------------------------------

**9/23/2014**

Talked with Ackley today about narrowing/improving my research idea.  Now I'm thinking I want to focus more on the 'quarantining' aspect of it rather than the 'virus spread' aspect.  Most of the stuff I was looking to implement with the virus - it's lifespan, spread, interaction with the host - aren't things I was looking to study or thought could have a novel or useful computation associated with them.  Quarantiner, however, is interesting.  Now the idea is to make Quarantiner a kind of general-purpose isolation Element - something that encloses Elements (perhaps configurable which one or it decides when it sees the first one, not sure yet) in a bubble.  I think it will do this by surrounding itself around the Element(s), then adding layers around that initial bubble in order to make it large enough such that Elements within cannot see anything outside of the bubble.  If the bubble is thick enough, these Elements cannot see outside from their Event Window.  I'm still kind of thinking about how Quarantiner's can coordinate to surround groups of Element's, and maybe if they could move around as a group after making a bubble, sort of like a cell or membrane.  I'm also thinking about how a Quarantiner could act as a kind of valve or mediator between the things in it's bubble and the outside world.

-------------------------------------------------------------------------------

**9/18/2014**

Yesterday at the "MFM coder bootcamp", Trent helped me brainstorm on how to make my virus idea more of a strong alife project and also how parts of it might work with the MFM architecture.  These are the Elements I envision at present:

**Virus**: 
  * Seeks to spread and infect **Host** Elements
  * Has a "lifespan" Element Parameter that specifies how long it survives
  * Behavior: 
     -Decrements its local "energy" Atomic Parameter by an Element Parameter "metabolic rate".  If this value is now less than or equal to 0, it deletes itself from the MFM.
     -If it sees a **Host** Element in its Event Window, it attemps to infect it.  It can only infect a **Host** with both "infected" and "immune" bits set to 0.  This infection is based on the "infection rate" Element Parameter of Virus (it may be 100% if **Host** is one cell away, 0% otherwise - as an example of a simple rule).
     -When a **Virus** successfully infects a **Host**, it will:
        - Set the "infected" Atomic Parameter of the **Host** to indicate the infection
        - Delete itself from the MFM 
      - If the **Virus** cannot infect any **Host** in its Event Window, it moves towards the closest **Host** or does a random movement (one cell) if none are visible

**Host**:
  * Gets infected by instances of **Virus**
  * Has a finite lifespan represented by an "Energy" Atomic Parameter, which starts at a "lifespan" Element Parameter
  * Behavior:
      -Decrement its energy value by an Element Parameter, "metabolic rate".  If its energy value is less than or equal to 0, it will delete itself from the MFM
      -If the "infection" bit of the **Host** instance is set to 1, the **Host** will:
          - Decrease its energy value by an amount specified by an Element Parameter "infection drain" of **Virus**
          - With probability defined by an "spread rate" Element Parameter of **Virus**, produce a new **Virus** instance in a random spot of distance 1 from itself
          - Increment an Atomic Parameter, "infected timer"  
          - If the value of the "infected timer" is greater than a "infection time" Element Parameter of **Virus**, **Host** sets its "infection" bit to 0 and a "immune" bit to 1 (it can never get infected again and stops producing **Virus**)
      -Create a new instance of **Host** (reproduce) with probability determined by Element Parameter "reproduction rate"
      -Finally, **Host** will do a random walk 

**Quarantiner**
  * Attempts to stop the spread of **Virus** by trapping infected instances of **Host** with bubbles of **Isolator** Elements that last for some period of time
  * Behavior:
      -Decrement an Atomic Parameter "energy" by an Element Parameter "metabolic rate"
      -If "energy" is less than or equal to 0, delete itself from MFM
      - Looks in all but the farthest cells in its Event Window for an instance of **Host** with an "infection" bit set to 1.  If one is found in any of these cells:
        - **Quarantiner** creates new instances of **Isolator** in all cells of the Event Window that are farthest from itself
        - Deletes itself from the MFM
      - Create a new instance of **Quarantiner** (reproduce) with probability determined by Element Parameter "reproduction rate"
      - If no infected **Host** is found, it will do a random walk
 
**Isolator**
  * Used to form isolation chambers to trap **Host** instances infected with **Virus** in one area for a configurable amount of events
  * Has an Element Parameter that specifies a "lifespan" (does not reproduce)
  * Behavior:
      - If its "lifespan" parameter is less than or equal 0, it deletes itself from the MFM
      - Otherwise, it decrements its lifespan parameter by 1   

-------------------------------------------------------------------------------

**9/09/2014**

Tried a couple of ideas out for the "Egg drop challenge".  First, I tried kind of a cheating method - enclosing the single tile with a wall.  Within, I made a miniature version of the fishsticks setup that Professor Ackley successfully used.  This system does not seem to work, probably because it is very sensitive to fluctuations in population due to the small enclosed space.  Best runs here were less than 5 kAEPS, just miserable.  I also tried using Anti-Forkbomb (Af), which spreads out across the grid.  The idea there was to make the "mud" that Ezra had used before with Data, but I can't really use Data for this because it does not reproduce; Anti-Forkbomb does.  It does indeed spread out and make some obstacles across the universe, but not apparently in sufficient amount to cause any real difference.  The best runs I could get with that setup were around 25 kAEPS.

-------------------------------------------------------------------------------

**9/07/2014**

Trying out another scheme for the "shark week challenge" that I thought up and I think has been discussed by others.  I'm calling it "the hatcheries".  The idea is to populate the world with some (appropriate number of) little areas enclosed by a Wall, such that there is a very small opening.  Then, I will put a Fish population in each.  Sharks will start outside of the hatcheries.  The thinking here is that fish will escape the hatcheries at a hopefully steady rate determined by the size of the opening on each.  This will hopefully regulate the supply of Fish being provided to the Sharks and therefore (again, HOPEFULLY) their population size.  Setup looks something like this:

{{:people:sharweek_hatcheries1.png?nolink&800}}

Each hatchery is seeded with a small amount of Fish to start.  There are Sharks spread out around the environment, with some Fish among them outside of the hatcheries to sustain them until the hatcheries start producing.  I tried varying the hatchery volume and opening size to try and see how they could hold a Fish population relative to each other.

This is a common scene of this hatchery ecosystem in action:

{{:people:sharkweek_hatchery1_action.png?nolink&800|}}

The hatcheries do seem to //sort of// work, in that they fill up and then gradually let a steady amount of Fish out of them.  The issue though, is that Sharks inevitably enter the hatcheries and decimate them.  I guess this goes back to that discussion of a "valve" the class was having - a way to only allow one type of Element into an area.

An upside to hatcheries though (despite their failure of being a safe and steady food provider) is that they seem to allow nice pockets of Fish to develop.  When Sharks decimate a hatchery, they usually die within; cold, lonely, and wondering where all the Fish went.  This leaves an empty hatchery, which usually gets repopulated by a lucky Fish that wanders into it without a Shark.  If you watch the simulation for a while, you'll see hatcheries come and go - but there are usually at least a couple that are fully stocked.  Thus, it appears that the Fish population is a little safer.  Also, the sharks dying after gorging themselves on a hatchery controls a potential population boom therein - the hatcheries are acting as a kind of //honeypot//.

As a control experiment, I also ran a simulation using the hatchery setup and initial populations as above, but then closed the entrances of all hatcheries with Walls.  The purpose of this was to see if it was simply the segmentation of the world by the hatcheries, rather than the dynamic and function of the hatcheries, that seemed to make a difference.  The control experiment sustained Shark populations for the following times in kAEPS: {1.739, 1.768}.  In contrast, the actual hatchery version ran for around 15 kAEPS - still not great though.  I do submit that a possible reason for the difference between the control and hatchery versions of this experiment is that there are more fish available to the Sharks in the hatchery version.

--------------------------------------------------------------------------------

**9/06/2014**

Just had a kind of morbid idea for a research topic while I was grocery shopping today (yes, Wal-mart).  I was looking around and thinking about how it seemed like the "dumbest looking" people (yup, I was being a judgmental bastard) had the most kids.  That got me thinking.  Is it possible that providing an ecosystem with ample resources, as our current civilization has done, actually leads to a weaker gene pool?  That is, by making it easier to survive, does the population actually become less survivable and less robust?  That's kind of what I saw at Wal-mart today.  I was wondering if the number of smart people on Earth (I mean 'intelligent', not 'educated') was proportionally higher in times of greater struggle to survive.  It would appear that in the modern world, the less-intelligent are perhaps more likely to have more offspring.  I think such a topic is outside of the reach of a 12-week project, and probably a little out of scope of the class - it's more a question about real biological systems rather than artificial ones.

--------------------------------------------------------------------------------

**9/01/14**    (01-Sep-2014 01:43:44PM-0600)

Further exploring the shark week double challenge.  I'm trying a recursive version of the segmenting (dotted cross) from yesterday, now with a grid of 16 cells instead of 4.  Looks something like this:

{{:people:sharkweek_eightsgrid.png?nolink&800|}}

{{:people:sharkweek_eightsgrid_init.png?nolink&800|}}

This setup has too many Sharks and WAY too many Fish.  Here's a better one:

{{:people:sharweek_eighthsgrid_init2.png?nolink&800|}}

I was starting to wonder if the grid segmentation was only helping by enforcing a segmentation of the Shark and Fish initial populations as shown above.  So I tried this setup as a control experiment:

{{:people:sharkweek_eighths_nowalls.png?nolink&800|}}

This experiment ran for a while, but eventually all the Sharks perished at around 12 kAEPS.  Sadly, the 16-cell grid doesn't seem to help - I could only get it to run for {5, 2} kAEPS compared to 12 kAEPS without the Walls present.

--------------------------------------------------------------------------------

**8/31/14**    (31-Aug-2014 10:38:23PM-0600)

Messing with some ideas for the "shark week double challenge".  As far as I can tell, the only element
that will be useful is Wall.  None of the other elements really seem to interact with the Shark or Fish
at all, except to destroy them (as in the case of the several varieties of Bomb).  So, I've been cooking up
some possible Wall designs to prevent the simplistic endgame that we discussed in class; a large wave of Sharks meeting a large wave of Fish, allowing the Sharks to kill all Fish and finish the ecosystem.  So, my plan here is to try to use Wall to turn the grid into a place where this is unlikely.  Think coral reef.  I came up with this idea first:

{{:people:sharkweek_square_spiral.png?nolink&800|}}

My idea here was to try and prevent sharks and fish from forming large groups by turning the open grid world into a kind of maze.  This strategy does NOT work.  It actually makes Shark waves more effective with fewer numbers of them. Sharks can form a wave in the narrow passages of the maze and wind their way outward or inward, decimating the fish in their path.  It was an idea, anyway.

The next thing I tried was also a maze, but this time a circular one.  I didn't really expect it to behave differently, but figured "eh, what the hell".  It suffers from the same issue as the square spiral.

{{:people:sharkweek_circular_spiral.png?nolink&800|}}
{{:people:sharkweek_circularspiral_initial.png?nolink&800|}} 

Considering what went wrong with these two implementations compared to my original intent, I had the thought of trying to segment the grid into smaller areas.  This was partly based on what we said in class about the original Wa-tor and how small, localized, chaotic interactions were better for the ecosystem as a whole.  I think this kind of implementation has potential.  It reduces the movement of Sharks and Fish along the boundaries, but does not completely divide the world (i.e. there are spaces in the Walls).  The effect of this seems to be to prevent waves of Sharks from forming.  It also seems to help small amount of Fish escape Shark herds (by wandering around the other side of a Wall, for instance) to breed and re-populate.

{{:people:sharkweek_dottedcross.png?nolink&800|}}

I intend to try some other designs as well using Walls.  I had this idea in class (related to coral reefs) about making little circular enclosed areas, with one small exit.  Then Sharks and some Fish would be placed outside these 'bubbles', and fish placed into the bubbles.  I don't know if this will work or not, but the thinking was that the fish would multiply within the bubble, and then slowly trickle out of it, controlling both the Shark and Fish population through the trickle rate (which is in turn controlled by the size of the bubble openings).

--------------------------------------------------------------------------------

**8/28/14**

Posting some of my research ideas for this class.

1.) Disease propagation and effectiveness:
   - Would probably involve adding a 'virus' object/lifeform to the MFM
   - This virus would infect a host, and spread to other hosts via host-to-host contact
   - These interactions could be controlled by parameters like probability of infection from contact, incubation period, and the time to kill or the host (or other adverse affects to the host like energy levels)
   - Effects studied could include disease spread and effectiveness, and methods of combating the virus

2.) Can betrayal within a species/group that's starving benefit the group as a whole?
   - Born out of an observation that the sharks in wa-tor often exhaust their food supply when their numbers overwhelm the fish, and the need for a "thinning of the herd" when this happens
   - The species being tested on could have a probability of attacking their own that is related to their hunger/energy level; the hungrier they are, the more likely they are to attack their own kind when encountered
   - Effects studied could include what benefit (if any) such behavior can have for the group and/or individual organisms, and the 'right' relationship between aggressiveness and resource scarcity/need

These are the main two I'm considering.  I've had a few other ones, feel free to steal these:

3.) Some kind of study into the effect an aging population has on a society (think "baby-boomers").  The implementation could involve something where old members of a species are weaker and require care from younger members to survive.  Studied effects could include the aging rate vs amount of care required overall, and the benefit/cost relationship of caring for the elderly versus abandoning them (tisk, tisk).  You could also flip this around and make it so the young members of a species require care/attention, like children, until they reach adulthood.

4.) This one is "out there" and probably way outside the scope of the course.  I had this idea about seeing if you could get the organisms in an alife simulation to communicate in some way, by //synthesizing// some kind of language.  I guess it would involve the organisms trying to communicate with rudimentary symbols, and maybe try and see if they develop some kind of common language (no matter how simple) if there are benefits to be had and they are accordingly motivated to do so.  This one sounds pretty interesting, but REALLY hard to implement and get any results out of.

--------------------------------------------------------------------------------

**8/24/14:**  Finally got a good setup for the 'Shark Week' challenge.  I actually got my simulation to live up to 90 kAEPS, with no sign of stopping.  My parameters were:

Birth Age (Fi): 13
Birth Age (Sh): 73
Energy_per_fish(Sh): 3

I also found the starting geographical distribution and amount of fishes and sharks to be important.  I would fill the grid completely with fish, then use the paintbrush to draw a wavy line of sharks around the whole grid.  I usually had the starting number of fishes to sharks be around 2:1 or 3:1.  My saved MFM simulation is on my CS webpage, cs.unm.edu/~jvick3.  If you load it, remember to change the relevant parameters (birth ages and energy per fish) or the population will die rather quickly :)

--------------------------------------------------------------------------------------------------------------

**8/21/14:**  Looked around on the 'interwebs for some ideas about alife topics.  Browsed some topics from the ISAL (International Society for Artificial Life).  Currently I'm leaning towards something related to viruses and disease; perhaps digging down into what kind of properties make an effective vs ineffective pathogen in terms of survivability and proliferation.  I've also had a few other ones, some more odd than others.  I think a study into populations that have large segments of 'elderly' organisms that require care and help from younger ones could be interesting.  I also think something relating to language/communication synthesis in a society of artifical beings could be cool.