AnyLogic automatically writes all essential statistics about the model execution in the log files. While the model runs, all information about agents, their parameters, movement, event occurrences, message arrivals, statechart, and flowchart activities, resource usage, etc. is written into the model execution log. See the detailed description of all standard AnyLogic logs here.
To make the model write information into the log, you have just to turn logging on.
To command the model to write information to the log
- In the Projects view, click the model’s Database item.
- In the Properties view, expand the Log section, and select the option Log model execution.
AnyLogic enables the user to see the logs in a common table form, using the built-in database table editor.
To view the log
- Stop the model execution and close the model window. It may take some time to dump the information and refresh the model tree in the Projects view.
- In the Projects view, expand the Database branch.
- Expand the Log item’s branch in the tree. You will see the list of logs in the Log branch.
- Double-click the log to view its data. The log contents will be shown in the table form in the database table editor. AnyLogic logs are shown in read-only mode. You cannot modify the log data.
If the simulation takes significantly more time with the logging being turned on, you can disable data collection for some logs that you do not need.
To disable data collection for a log
- After you simulated your model at least once and got the logs collected, expand the Database branch in the Projects view.
- Expand the Log item’s branch in the tree. You will see the list of logs in the Log branch.
- In the Projects tree, select the log you do not need, and select the I do not need this type of log checkbox in the properties.
Log name | Description |
---|---|
agent_messages_log | Log on all messages sent by agents. |
agent_movement_log | Log on agent movement. Each entry corresponds to a single movement process (only if it was initiated by the MoveTo block, or by any moveTo() function). Train movement initiated by the TrainMoveTo block and pedestrian movement is also logged. In the current product version movement of cars initiated by CarMoveTo block is not logged. Each record contains agent’s type, agent’s name, movement speed (in meters per second), start and stop time of movement. |
agent_movement_stats_log | Log containing cumulative movement statistics for each agent that has moved. The movement is logged if it was initiated by the MoveTo block, or by any moveTo() function. Train movement initiated by the TrainMoveTo block and pedestrian movement is also logged. In the current product version movement of cars initiated by CarMoveTo block is not logged. Each record contains agent’s type, agent’s name, total distance covered (in meters), total time spent on covering the distance and the average speed (in meters per second). |
agent_parameters_log | Stores initial values of parameters of all agents in the model. |
agent_statechart_states_log | Log on agent’s transitions within its statechart. The table stores agent’s type, its name, the name of the statechart, the state of the agent at certain time as well as the dates at which the agent entered and exited certain states of the statechart. |
agent_statechart_stats_log | Log on agent’s transitions statistics. The table stores agent’s type, its name, the name of the statechart, the state of the agent, the average and the total time (in seconds) that the agent spent in this or that state, and the number of entries made to a particular state. |
agent_type_statechart_stats_log | The log contains statistics on agent residence in certain states of its statechart, aggregated for all agents of the same type. The table stores agent’s type, the name of the statechart, the name of the state, the average, the total, the min and the max time (in seconds) that agents spent in the state, and the number of times agents entered this state (the n_entries column). |
agents_log | [For advanced users] The table stores the creation time (and optional destroy time) of all agents. |
datasets_log |
Data from all data sets and charts collected during the model execution. The data is logged only for the Data sets with the property Log to database selected.
Data sets and charts have limitations on the number of stored samples (defined with the parameter Keep / Display up to ... samples), so having set strict limitations, you may get the data set tails only.
|
events_log | The log contains information about all occurrences of events and dynamic events in the model. |
flowchart_entries_log | Stores information on the time moments when agents and resources entered flowchart blocks. |
flowchart_process_states_log | The statistics showing the time agents spent in different states of flowchart blocks: waiting time (activity_type: WAIT), processing time (activity_type: WORK), and so on. |
flowchart_stats_time_in_state_log | The aggregated statistics on time that agents spent in flowchart blocks. Inside some blocks agent can be busy with several alternative activities. For instance, in Service block agent can wait, or it can be serviced. In the log, you will see two records for each Service, one for waiting time (activity_type: WAIT) and another for processing time (activity_type: WORK). Each record contains aggregated statistics on all agents that passed through the block: minimum, maximum, and total time in seconds, and the total number of processed agents so far. From the following log, you can see, e.g. that the delay time of the block delayAuditKey is fixed (180 seconds), the mean waiting time for the printBill operation is 36,32 seconds, 25 bills have been processed at fixBillingErrors block so far, and so on. |
fluid_rates_log | Log on fluid rates within the flowchart. The table stores block’s type, its name, port, the total amount of fluid passed through the port, the minimum, maximum, and average rate of the fluid. |
fluid_storages_log | Stores block types, the minimum, the maximum and the average amount of fluid (in cubic meters) that the each block type contained. |
fluid_units_log | Stores block types, the fluid amount and rate measurement units used in this or that block type. |
fluid_utilization_log | Stores block types, names of the blocks and the block utilization ratio. |
histograms_log | Data from histogram data elements collected during the model execution. The data is logged only for the Histogram Data with the property Log to database selected. |
library_block_parameters_log | Stores initial values of parameters of all flowchart blocks in the model. |
library_blocks_log | [For advanced users] The table stores time moments when the flowchart blocks were created. |
resource_pool_task_stats_log | Stores the type of resource units for a certain resource pool, the name of the resource pool, the carried out task, the mean and total time (in seconds) spent on the task, and the total number of completed tasks. |
resource_pool_utilization_log | Log on resource pool utilization. The table stores the name of the resource pool, the utilization ratio and the quantity of resource units involved. |
resource_unit_states_log | Stores information on states of the resource units. |
resource_unit_task_stats_log | Log contains statistics on tasks of the resource units. The table contains type of resource units for a certain resource pool, the name of the resource pool, the resource unit ID, the carried out task, the mean and total time (in seconds) spent on the task, and the total number of completed tasks. |
resource_unit_utilization_log | Log on resource unit utilization. The table stores the type of the resource unit, the name of the resource pool, the population the unit is a part of, unit’s index and ID within this population, and the utilization ratio of this resource unit. |
statechart_transitions_log |
Stores information on statechart transitions trigger moments. You can log the information only for selected statecharts. To enable logging for a statechart, set the option Log to database for its statechart entry point. |
statistics_log | Data from all statistics elements, collected during the model execution. The data is logged only for the Statistics with the property Log to database selected. |
trace_log | Stores all text outputs the user did by calling the traceToDB() function. |
Each predefined log requires some particular raw data to be collected. In the Projects tree, you can see them in the Raw data branch of the database’s Log. The more logs you need, the more related raw data will be collected.
Each log is in fact AnyLogic database view. If you want to create a similar log, you can create a copy of the predefined AnyLogic log, and modify its SQL query.
To create your own log based on a predefined log
- Click the log in the Projects tree to open its properties.
- In the Properties, click the link Create an editable copy of this view.
- In the Projects view you will see a new database view created. It will be put in the Database branch, but not in the Log branch (where only AnyLogic predefined and non-editable views are placed).
- The SQL query of this view is editable, so you can open the new view properties and customize its query as you need in the View definition field.
The log is stored in the model folder, in the sub-folder database storing all the data for the model’s built-in database.
In some cases you may want to delete the log. For instance, you are distributing your model by copying the model folder, and want to optimize the folder size. You should not delete the files in the file manager, because this will delete all the input and output data from the model database. To delete just the model execution logs, please follow this way:
To delete all model execution logs
- In the Projects view, right-click the Database branch, and choose Delete log from the context menu.
You can delete the logs programmatically at the model runtime using the deleteExistingLogObjects(java.sql.Connection connection) function.
The function is defined in the model database's ModelDatabase class. It deletes all the model log data (if any logs were turned on) from the model database. You should pass the database connection as its argument. Below we provide the code sample, which deletes the model execution logs. Since the function may throw java.sql.SQLException exception, you have to handle it with the try — catch operator:
try
{
getEngine().getModelDatabase().deleteExistingLogObjects(getDatabaseConnection());
}
catch (SQLException e)
{
error("Error occurred while deleting the model execution logs: " + e);
};
When the model is exported to AnyLogic Cloud or the standalone Java application, the log is deleted automatically.
-
How can we improve this article?
-