Tech Note

Title:               Simulation Result Extraction
Date:              April 9, 2003
Written by:     Peter C. Bosch
Number:        TN-005
Version:         0.1 – Proposed Works-In-Progress

Problem Statement – The MAI Scheduler Team needs a summary of the times and identities of resource acquisitions and releases that were encountered in the running of a batch. This summary will be used in conjunction with other batches’ extracted resource requirements to create a profile of resource usage either by resource instance or resource type. Future implementations may include the manipulation of start times and combination of disparate datasets from given batches to pursue optimization of the resource profile.

A simulation, after running, has accrued information on the timing of the start and finish of the simulation, as well as the times of execution of certain key events in the simulation. These events include resource requests and releases, batch starts and finishes, and perhaps others. Some events are paired, such as resource acquisitions and releases (and these pairs must be easily correlated), and others, such as reactant ingress and product egress, are not necessarily paired events. Models are constructed such that each of these events is a true event, with add and remove capability, exposed by the model or a child element of the model.

For many purposes, this data provides a sufficient overview of the results of the simulation.

Data Collection

We are proposing, as a general solution to this problem, a mechanism that attaches to a model and registers for relevant events, logs their firing, and can correlate certain events with each other. After completion of the model, the logger can export the recorded data as an XML document.

This requires several mechanisms –

1.)    Summarizers, whose purpose it is to attach to a model and coordinate the creation and attachment of loggers, maintain a log of event entries, and present the final summary XML document.

2.)    EventListeners, whose purpose it is to register and unregister for specific types of events on the model and its children, receive the events as they fire and log the events.

3.)    DocumentGenerators, whose purpose it is to generate an XML (or other) document from the log.

An initial implementation will entail a summarizer, two event listeners, and a document generator. The summarizer will be equipped with two EventListeners. The first event listener will listen for, and record, all resource acquisitions and releases. The second event listener will listen for and record the starts and finishes of each batch. The document generator will create a document similar to that shown in figure 1, below.

<?xml version="1.0" encoding="utf-8"?>

<Batch xmlns="http://tempuri.org/~vs9A.xsd">

    <Name>ValidationBatch</Name>

    <Guid>409361A8-1EE8-43e5-A8D0-12DEB114F9FE</Guid>

    <Product>Sulbactum</Product>

    <StartTime>1/1/0001 12:00:00 AM</StartTime>

    <FinishTime>4/10/2003 1:02:39 AM</FinishTime>

    <ResourceTypeDefinition>

        <Name>Vessel</Name>

        <Guid />

        <ParentResourceType />

        <!-- Parent type -->

    </ResourceTypeDefinition>

    <ResourceManager>

        <Name>Unit 1 Equipment Pool</Name>

        <Guid>EEF436B3-F290-45df-982E-CB9EAF159603</Guid>

    </ResourceManager>

    <Resource>

        <Name>Vat-1</Name>

        <Guid>3EDB4E5C-3364-44f9-AAC6-86E56639C82C</Guid>

        <ResourceType>Vessel</ResourceType>

    </Resource>

    <ResourceAcquisition>

        <Acquired>

            <Time>4/10/2003 12:32:00 AM</Time>

            <ResourceGuid>3EDB4E5C-3364-44f9-AAC6-86E56639C82C</ResourceGuid>

            <FromMgrGuid>EEF436B3-F290-45df-982E-CB9EAF159603</FromMgrGuid>

            <QtyAcquired>1.0</QtyAcquired>

            <QtyRemaining>0.0</QtyRemaining>

        </Acquired>

        <Released>

            <Time>4/10/2003 12:32:00 AM</Time>

        </Released>

    </ResourceAcquisition>

</Batch>

Figure 1: Proposed XML Document Format For Resource Acquisition Summary

The above report would be acquired by creating a Summarizer, adding two EventListeners and a DocumentGenerator to it, and running a model, and afterwards requesting the Summary from the Summarizer, optionally resetting the summarizer before running the model again.

Document structure would be determined by the DocumentGenerator, with node structure determined by the EventListener. The EventListener would be responsible for the protocol it needed to follow to perform all relevant event registrations.

Note that the larger requirement here is to be able to export data relevant to a model’s execution, after the execution is complete. While it is beyond the scope of this particular need, it is a reasonable piece of infrastructure for a modeling framework, will likely encounter further use in this project, and will certainly encounter further use by the VR_Sim framework. We can approach this as a broader design challenge, or as the point-solution-with-hooks-for-growth that is proposed here. It is a project management call, which approach we take. If we take the point-solution approach it may require 2½ days’ work (½ day design, 1 ½ days development, .1½ days testing), while if we approach it as a broader, more abstract effort, it could take 4-8 days.

Note that adding a third listener that tracks the times and quantities of materials charged, and another that tracks the times and quantities of materials discharged, might also be useful in meeting what are likely to be other aspects of this requirement.

Data Aggregation

We expect that once one or more of these documents are generated, that there will be a need to combine multiple copies of documents for the same or different batches and report on the time course of resource utilization by resource and by each level of the resource type hierarchy. This will be done by the Scheduler, but a reasonable approach to this challenge would be to create for each item-of-concern (e.g. resource, material) a SortedList of milestones (sorted on time of occurrence) each of which represents a change in level of a quantity-of-concern of that item, and adding a milestone to the appropriate item-of-concern’s SortedList for each acquisition, each release, each charge and each discharge event. Different documents could be time-shifted as they were being used to generate such milestones, in order to represent the staggering of batch executions.

After this aggregation, there will be a SortedList for each item or category, and a SortedList would contain milestones each of which represented a change in quantity of that item, or members of that category. Read in sequence, they would depict the time course of utilization of that resource or resource category.

Estimation of this effort will follow the identification of further requirements and probably other further discussion.