Feature Specifications

Specifications for Facsimile library features are detailed here. The status of each feature will be maintained by the Launchpad Blueprint tracking system.

Measurements

Please check the status of the corresponding blueprint on Launchpad before editing it. If the status is Approved, then contact the nominated assignee before making changes.

Please feel free to enter comments on this specification below.

1. Summary

Provide a simple and elegant API for storing and presenting measurements.

All measurement data is stored internally in SI-standard units. Whilst arbitrary from the user's perspective, these units simplify the implementation of mechanics formulae and other calculations internally.

2. Rationale

Simulation models need to deal with a variety of different types of measurement in any number of different units. For example, it is frequently necessary to have measurements of time in a simulation. However, time can be measured in units such as milliseconds, seconds, minutes, hours, days, weeks, etc.

It is important that Facsimile does not force a user to work in any specific unit of time or any other type of measurement, whether it be a distance, mass, angle, temperature, velocity, etc. If a particular project needs to measure distances in inches, then Facsimile should work with this requirement, not fight it. If it is appropriate to allow users to set measurement preferences, then it should be possible for user A to see masses measured in pounds, whilst user B can see the same masses measured in kilograms.

Furthermore, simulations should be able to communicate information about measurements in a consistent fashion. This allows data, including 3D object data, to be transferred from one simulation to another without the user having to rescale from one set of units to another.

3. Use cases

  • A developer is writing a VRML file importer. VRML data standards require that distance data is stored in meters, time data in seconds and angle data in radians. The developer identifies these as the default units for the VRML data during processing. However, not all VRML images adhere to this standard - particularly in regard to distance units - and so the exact units can be selected by a user, resulting in an accurate, equivalent representation within Facsimile.
  • Two Facsimile simulation models have been developed independently by two different consulting firms, but the two models need to communicate with each other. The first consulting firm prefers to enter distance data in millimeters, time date in seconds and velocities in kilometers per hour. The second firm prefers inches, minutes and feet per minute. The two models interact perfectly, being able to share such data without any need for explicit measurement unit conversions.
  • A client contracts a simulation consultant to model a facility in feet and inches. Mid-way through the project, they are taken over by a firm that insists that all engineering drawings use millimeters. The Facsimile simulation adapts to the change effortlessly, with no re-scaling of data required.

4. Scope

The scope of this specification is limited to the storage and retrieval of measurement data within and between Facsimile models.

The mechanisms required to handle the input and output of the data, such as the processing of a data input file, are necessarily bespoke and are not covered by this specification; this specification is intended to facilitate the development of such mechanisms.

5. Design

TBD

6. Implementation

TBD

7. Unresolved issues

TBD

PRN generator

Please check the status of the corresponding blueprint on Launchpad before editing it. If the status is Approved, then contact the nominated assignee before making changes.

Please feel free to enter comments on this specification below.

Simulation Engine

Please check the status of the corresponding blueprint on Launchpad before editing it. If the status is Approved, then contact the nominated assignee before making changes.

Please feel free to enter comments on this specification below.

1. Summary

To be done...

2. Rationale

To be done...

3. Use cases

To be done...

4. Scope

To be done...

5. Design

To be done...

6. Implementation

To be done...

7. Unresolved issues

To be done...