Table of contents
Click the links to jump to the relevant section below:
- How is hierarchy decided?
- Common situations with an "incorrectly ordered" population tree
The Population Tree in Cytobank builds itself automatically as you gate.
The statistics of the Population Tree update dynamically as changes are made to gates and populations.
The Population Tree is available as a tab at the bottom of the Gating Interface:
If you want to export the statistics present to the right of the Population Tree, contact Cytobank Support for instructions how.
For a different interactive visualization of your Population Tree, check out the Population Sunburst!
Cytobank does not store a linked list of gates pointing to each other in order to define a gating hierarchy. Instead, the population tree builds itself based on relationships between populations using the information present in the Population Manager, which defines sets of gates that are termed "populations". Learn more about how gates and populations work. The linked article also outlines how the population tree compares gate sets in order to determine a hierarchy.
Sometimes the population tree may appear to have an incorrect ordering. While visually problematic, there is an underlying valid logic to this ordering. The common situations are outlined below:
- Ambiguous parent: There are multiple possible parent populations for a single child population. The child population is assigned to a parent that is a technically correct possibility, though not the desired parent according to the user. See details below.
- Unwanted hierarchy: Parent-child relationships are detected among populations and organized by the population tree into a hierarchy, but the user considers these populations as siblings without hierarchy. See details below.
In order to understand the ambiguous parent scenario, the set logic that builds the population tree must first be understood. With this understanding, consider the following population manager scenario and resulting population tree:
Both populations P and J are equally close proper subsets of population Z. However, Cytobank has to choose a single parent for population Z. Population P is chosen because sibling populations are ordered alphabetically, thus P appears after J and becomes the parent of Z. In order to make population J the parent of population Z, the name of population J would have to be changed to be alphabetically after population P. For example, "population X". With this change, the population tree would put population X as the parent to population Z. The exception to alphabetical ordering among sibling populations is when the populations have different numbers of children. Populations with more children are ordered lower in the tree.
The unwanted hierarchy scenario generally manifests during boolean gating workflows where different combinations of a number of gates are desired. The image directly above serves to illustrate this scenario well. If every combination of gate A and gate B are needed, then that means you will need three sets: (A), (B), (A,B). As a scientist you may think of these combinations as siblings of each other off of a certain parent, but Cytobank will detect proper subset relationships among these combinations and will place them as such. It is a visual issue only, but unfortunately cannot be arbitrarily adjusted.
To make visual adjustments to the population tree in order to manually change the ordering, you must export it as SVG.