<< Click to Display Table of Contents >> Navigation:  Examples  > Patterns > Aging cohorts

Some things separate naturally into cohorts, such as students moving through school or batches in a manufacturing process. Other situations, such as models of populations, involve objects arriving continuously, but are most usefully considered in cohorts of similar age. Models of these situations are often highly aggregated, calculating totals for the population, or highly disaggregated, representing each individual member of the population.  

 

Cohort entities represent a middle ground. Each cohort entity in the model represents a subset of the population in the aggregate. But each subset consists entirely of members of similar age. Simulating a tens or hundreds of cohorts instead of thousands or millions of individuals gives the advantages of model clarity and simplification that come from aggregation, while allowing exploration of decisions involving only older members, for example, in a manner that is computationally accurate and simple to manage. Creating cohort entities, then letting them exit the computation once their membership has vanished, means there is no computational nor cognitive overhead spent sifting through which cohorts are still relevant at any particular time.

 

Cohort entities are explained below, or, through a series of four cohort population models in this video:

 

 

Using Cohorts

 

The aging cohorts pattern involves two entity types: a population entity type and a cohort entity type.

 

The population is the answer to the question, "Cohorts of what?" Examples:

 

 

There are many cases where you might tracking cohorts only in one population, in which case the population entity will be singular.

 

The population entity type requires a create cohort action and a trigger to invoke that action whenever a new cohort comes into existence. Optionally, the population entity type can also include an attribute reference to the head (youngest) cohort. This is useful in cases where members of the population are being continually created and your model needs to assign them to the cohort currently being formed. Both the population examples above and the automobile fleet below give examples of this.

 

The cohort entity type is where you calculate anything you wish to track about each cohort. For an epidemiology model, each cohort will have a size (number of people) and a prevalence (number of sick people). For a transportation model, each cohort of cars will have a total fuel consumption, total passenger miles per year, average maintenance costs. In addition to whatever interests you about your cohorts, no elements are strictly required by the cohort entity type. There are two things that are nearly always useful:

1. The cohort entity type will usually have a subcollection, partitioned by population, so the model can calculate statistics of each population across cohorts. It will also generally have a stock that records the time of creation for the cohort, so the age of the cohort can be computed and used by other variables.

2. It will usually have a delete action that removes the cohort from the simulation when it is no longer active.

 

The elements above are not described in great detail here because it is easier to see them in context: the CohortPattern example provided with Ventity is a minimal example, including these elements and nothing else, and serves as a good starting point. For more developed examples, see the cohort population models described in the video above, or an example involving fleets of cars, discussed next.

 

Car Fleet Example

 

The CohortFleet7 model, which simulates the evolution of fleets of automobiles, is an example. The model defines two main entity types. A fleet is an entity representing all the cars having a common owner, such as a large rental car company. Thus each fleet is a subpopulation of cars.  A cohort is a group of cars acquired by the owner during a time span of, in this case, 10 years. Each 10 years, a new cohort entity is created, and new cars are added to the count of the newest cohort only. The plot below shows the number of cars in each cohort. Two cohorts are initialized to include all cars purchased before the time period of the simulation. A new cohort is established by a create action, and grows as new cars are purchased over time. Ten years later, another new cohort is established, and the first stops accepting newly-acquired cars, which now accrue to the second cohort. Each cohort loses cars over time.

 

 

To organize this in Ventity, all that's required is for the create action that creates a new cohort to also reset the fleet's attribute to know that the new cohort is the "head" or "lead" cohort, that is, the current cohort, which therefore should be the one to accrue new cars. This is accomplished easily with surrogates in the create action.

 

 

This definition of Parent•Head cohort basically means, assign the new cohort an ID (newCohort•CohortID) then change the fleet's value of "Head cohort" from whatever it was to the new cohort's ID. It is the fleet's "Head cohort" property that is being changed because the fleet is the parent (owner) of the action, "Start New Cohort", so the "parent" reference refers to the fleet.