A hierarchy of hexagonal tilings

This model has been included to illustrate a number of techniques used to create complex structures in which model components can interact. It allows an area to be represented as a series of hexagonal tilings, with increasing levels of detail. Each hexagon in one level corresponds to a group of 7 hexagons in the next level down. The arrangement is based on that used in the HOOFS model (S. P. Oom et al, 2004) It would be straightforward to implement this layout with a series of nested submodels, each representing one layer of the tiling. In this case, each submodel would have dimensions of 7, corresponding to the 7 hexagons at a lower level that fill a single hexagon at a higher level. However, since several variables are needed in each level to keep the hexagon's position and vertex coordinates, it is more elegant to have all the hexagons at all levels represented by instances of a single submodel, with an association to represent the parent-child relation between them.   This example has hexagons at six levels, the top level consisting of just one hexagon, the bottom of 7^5 or 16807 hexagons. The hexagon submodel has 19608 members, that being the total number of hexagons at all levels. The parent-child association connects hexagons with other hexagons. If it were to be enumerated by checking every pair for a parent-child relationship it would have to do nearly 400 million checks, which would be too slow. Therefore a technique called one-sided enumeration is used.   To do this, each hexagon calculates the id of its parent. This is straightforward as the children of all parents are in the same order as the parents themselves. The role arrow from the parent instance (higher) is then marked 'allow base instance lookup', and the existence condition in the association submodel starts 'index(1) is...' which allows the association to be set up by directly looking up the parent instance from each child instance.   Now child instances must get some information from their parents. Firstly they must get their level, which is one greater than that of their parents. This is used to access information from the corresponding instance of the submodel 'level info', for, e.g., the offsets of their centres from the parent's. So the parent's level is fed into the association model and taken out by the child, which adds 1 to get its own level.   Because the association is exclusive for the child, there is only one parent level value for each child. This makes the model simpler, but creates a problem when setting the level of the top level hexagon. The problem is that the base model values are set for each association model, so it will only get a value at all if it has the child role in some association. This is solved by adding a dummy instance of the association, connecting the top level hexagom with itself. In this case, the equation for the 'my parent' variable has a clause that sets it to 1 for instance 1, when it would otherwise be 0. The 'dummy' variable in the association model is true for the instance resulting from this clause (linking hexagon 1 with itself) and this variable is used to make sure that in this instance the information being passed to the child hexagon is that needed by the top-level hexagon, rather than trying (and failing) to get it from the parent hexagon.   Also note the dashed influence arrows going from the hexagon submodel to the parent/child association. These are created by selecting 'use in same time step' in the influence properties. The purpose of this feature is to indicate how the model should be built in the case of an apparent circular set of influences. The circularity occurs because each hexagon instance's level (and other properties) is set from the association, while the level values for the associations are set from the hexagons. Making a dashed influence to the association means that the value in the association can be set without waiting for all the values in the hexagon submodels to be calculated. This makes it work properly because also, * Since the child hexagon is an exclusive role, values in the child that come from the association are set at the same point in the program as values in the association itself (see discussion on dummy instances above) * The association model instances are in the order of the indices of the base models. Thus, the first association gets the right value because of the special clause for the dummy instance, and the first hexagon (which is the child in the dummy association) gets level 1 from the dummy. The second to eighth hexagons get level 2 because when they are evaluated the right level has already been set for their parent, hexagon 1, and the association picks it up without waiting for the child values to be calculated, and so on, till they all have the right level.   Finally, there is a conditional submodel 'for display' which exists within the hexagon submodel and exists only for those of a particular level. This is where the hexagon vertices are calculated, and the condition ensures only the vertices of a particular level are done, simply so the polygon display tool can be used to show the polygons at one level. This is currently the bottom level, level 6, but the model can be changed to display hexagons at higher levels.