Skip to content

Global Configuration

LeonBein edited this page Nov 29, 2019 · 6 revisions

The Global Configuration file contains all global information for one simulation run. Thus, exactly one GC is used for one simulation run. The information inside the GC can include resource assignment strategies, a global simulation seed, simulation time zone, timetables for resources and resource definitions themselves.

General structure of file

The GC is encoded in xml format. Its root element is a <globalConfiguration> tag. The configuration elements are child elements of this root. The root contains an id attribute to uniquely identify the GC.

Resource assignment strategies

Resource assignment strategies determine which work items are prioritized when multiple one compete for the same resources. When multiple strategies are defined, Scylla tries to resolve resource conflicts with the first, then, if it fails, with the second and so on. Resource assignment strategies are defined inside a <resourceAssignmentOrder> tag that is a child of the root. The names of the used strategies are put into the body of this tag, separated by commas.

Without plugins, Scylla supports two strategies:

  • Priority Strategy, defined in class EventOrderPriority. This strategy dependends on assignment priorities defined in task configurations of the respective Simulation Configurations. Tasks with the higher priority are prioritized, tasks with no priority are assumed to have the lowest priority. For this strategy the name to put into the global configuration is priority.
  • Simulation Time Strategy, defined in class EventOrderSimulationTime. This strategy prioritizes Tasks by the time their enablement Event occured. For this strategy the name to put into the global configuration is simulationTime.

Per default, if no strategy is defined, the simulation time strategy is used.

Addition strategies can be defined by creating a plugin for the entry point EventOrderType. Note that the plugin getName() method determines which name to put into the resource assignment order tag of the GC file.

Simulation Seed

The simulation seed of the gc is used as general seed for the desmoJ experiment. If not overriden, it is also used as seed for the Simulation Configurations i.e. that all random elements in the respective model of the sc are determined by this seed. This includes for example event arrival rates and task durations. In the GC file, the seed is defined as body of a <randomSeed> tag.

Zone offset

The zone offset allows to set the time zone that the simulation runs in. This influences mainly the format of the outputs that are generated.

The offset can be defined inside the gc with a <zoneOffset> tag. The body of this tag is the time zone to use, formatted as +hh:mm or -hh:mm which define the hours and minutes offset from GMT.

Resource timetables

Timetables describe the availability of resources. Each timetable consists of one or more items that describe the start and end time for each of an interval of days.

Inside the GC file, all timetables are defined as <timetable> tags inside one <timetables> tag under the root node. Each timetable tag has an id attribute for it to be uniquely identified. Each timetable tag has one or more <timetableItem/> tags as children.

Each timetableItem tag defines the attributes from, to, beginTime and endTime. All four are strings. From and to are the weekdays for this item coded by ther java DayOfWeek enum names. beginTime and endTime are the beginning and end time on all those days defined in ISO-8601 hh:mm:ss format or similar (should be parseable by java LocalTime.parse).

Resources

Resource data defines which resources exists, how often they exist, what they cost and optionally which timetables they use and which named instances exist (which can differ from their resource type a bit).

Inside the gc root, there is a <resourceData> tag. This tag contains a number of <dynamicResource> tags which each define one resource type. Each dynamicResource has an unique attribute id to identify it, as well as attributes defaultQuantity, defaultCost and defaultTimeUnit. All are of type string, but defaultQuantity should be parseable as integer, defaultCost as float/double and defaultTimeUnit as java TimeUnit. A name attribute can be specified, if the display name should differ from the id. A defaultTimetableId attribute should be specified if the resource should follow a timetable. This attribute must match the id of one of the defined timetable ids (see timetables above).

The dynamicResource tags can contain a number of <instance/> tags. These represent named instances that might deviate from their resource type. These instances must contain a name attribute. Additionally they can define their own cost and timetableId attributes to override those set for their resource type. If these attributes are not set, the respective defaultCost and defaultTimetableId are used.