ParseLog
ParseLog[objects,field]⟹data
parses useful information for the objects from the specified log field field using sensible default parameters, such as total times spent in each status.
Details
- ParseLog takes a log field as input and returns useful information about the time periods that the target was in a particular status.
- For example, a StatusLog logs the times at which a target changes status. ParseLog takes this log and returns the total amount of time that the target spent in each status.
- The function consists of a core overload (Additional Definitions) that takes the log contents directly (no interaction with the database) and a fully specified set of parameters to be used to parse the log.
- There is also a friendly overload (Basic Definitions) that takes a list of objects, the field name to parse, and determines a sensible set of default parameters for that log field type. Manual parsing parameters can still be passed through using options.
- The number of options that can be specified is indicative of the diversity of log fields - you may be able to get the function to return a result, but it may not mean much for your particular result. Check that the output is what you intend.
- Log fields broadly fall into two categories - single status and multi-status. A single status field is one where each new line in the log implicitly supersedes the previous line, such as an instrument status log. A multi-status log is one where this is not the case, for example a contents log. A line removing B from the target does not have any effect on a line referring to A.
- ParseLog splits up multi-status logs based on the supplied identifier column, into a series of single-status sub-logs for each identifier. The results from each sub-log are then combined prior to output.
- An additional consideration for multi-status logs is whether to 'double count' periods of overlap. Primary use case is operator ProtocolLogs where an operator can be in two protocols at once, when interrupted. However, the operator is only actively working on the most recent protocol. Counting overlap returns the total time between entering and exiting a protocol, and not counting overlap returns the total time a protocol is actively being worked on.
- Counting overlap has little relevance to most multi-status log fields, such as a ContentsLog.
- Logs can also be considered closed or open. A closed log is one where the final entry in the log should be considered the end, otherwise analysis will continue to Now.
- For example, if a protocol is Processing, that status should be considered to extend to Now. However, if a protocol is completed, it may be more sensible to consider the log closed at the final entry, otherwise there will be a long period of Completed status. This is accurate, but not necessarily desirable.
- Closed log looks at DateRetired, DateDiscarded and DateCompleted to determine if a log is better regarded as closed.
- Inactive Statuses describe statuses where the following time period should not be associated with the party making the change. This is most relevant when analyzing multi-status fields, or a field that is not the status field.
- For example, if analyzing the parties who have used an instrument, this involves analyzing the "Responsible Party" of the StatusLog. However, if a party set the instrument to Available, the following time period in the log should not be associated with that party. Available should therefore be included in the InactiveStatuses.
- For multi-status logs such as a contents log, InactiveStatuses functions similarly. Time periods will only be counted when each object is active (in the case of a contents log, when the object is "In").
- The additional options allow you to describe the log that is being parsed. DateColumn and StatusColumn are fixed for a certain log type. FieldColumn and IdentifierColumn may be change to manipulate output.
- ParseLog does not perform any log validation, so if the log field contains incorrect or atypical entries, the results may not be representative.
- Log fields currently supported with automatic parameters are: StatusLog, QualificationResultsLog, RestrictedLog, MassLog, CountLog, VolumeLog, LocationLog, ConnectionLog, WiringConnectionsLog, ContentsLog, ProtocolLog.
- Additional Definitions
-
ParseLog[log,dateColumn,statusColumn,identifierColumn,fieldOfInterest,singleStatusQ,closedLogQ,inactiveStatuses] data parses useful information from a directly supplied 'log', with all required parameters manually specified. -
InvalidField `2` does not contain the field `1`. InvalidLogField Field `1` for `2` does not match the pattern of a compatible log field. ParseLogCountOverlapConflict Counting overlap conflicts with selecting the same status column as the identifier column. Please set CounterOverlap->False or set different values for StatusColumn and IdentifierColumn.
Input
Output
General Options
Messages
Examples
Basic Examples (3)
Additional Examples (15)
Parse a connection log and return a list of connectors used:
Parse a connection log and return a list of objects connected:
Parse a connection log and return a list of objects connected with their ports:
Parse a connection log by connected object:
Parse a connection log by connected object and return the times as date ranges:
Parse a connection log by connected object and return the times as patterns:
Parse a connection log by connected object and return the times as percentages over the log time period:
Parse a connection log by connector:
Parse a connection log by connector and connected object:
Parse a qualification results log:
Specify to output patterns that match the times for each status:
Specify to output percentage of times in each status:
Specify to output the datetime ranges in each status:
Options (13)
ClosedLog (1)
IdentifierIndex (1)
Last modified on Wed 18 May 2022 12:28:40