Tips on using Pipes and things to watch
Pipes transfer values from one attribute to another by regularly sampling and computing a transfer amount according to the load rate. Hence if the source or destination of a pipe are specified using matched cells, a significant overhead will be incurred since Planimate has to search for the cell to use every update iteration of the pipe.
Hence matched cell references should be avoided for pipe source, destination or any of the other configuration attributes of a pipe, otherwise performance will greatly suffer.
This is particularly important for the "run control" attribute of a pipe. Ideally this should be pointed to an attribute or a specific table cell (a table cell specified by attributes which are flagged constant during run), otherwise excessive unblocking messages for this attribute (since it has the capacity to block/release the pipe) will severely impact on model performance.
Round off errors
Pipes move values from one place to another by generating events at regular intervals and subtracting/adding to the source/target according to a specified hourly rate.
Numbers in PL are represented using C double precision values (64 bit).These have a precision of about 14 decimal digits. This precision limit becomes a problem when the pipe is transferring in small amounts to end points which contain a large value.
For example a pipe may be set up to transfer at a rate of 1750 units per hour, at a sampling resolution of 10 seconds to a target already containing 2 billion units.
1750 / 3600 * 10 = 4.86111111111111
(the number recurs but in memory would stop after 14 digits or so)
When the pipe dumps the first quantity into the target it does:
2,000,000,000 . 000 000 000 000 00 + 4 . 861 111 111 111 11
but due to the 14 digit limit, the result will lose the smaller fractions of the value being added because its a large value and runs out of precision
Over time these errors accumulate, leading to noticeable misbalance in the system and comparisons against expected limits failing.
Ways to alleviate this problem include:
- keep sources and targets as small as possible (eg:have a separate accumulator for your "entire" stockpile)
- dont sample more often than necessary
(the more frequently it samples, the smaller the values moved)
- dont code/expect exact quantities with pipes, allow a margin of error either way
An additional and significant improvement can be gained using the pipe option "Adjust Update Interval To Reduce Errors". Given that the hourly rate for the pipe is known, PL adjusts the transfer amount per sample to a value which takes less precision to represent. To compensate for this, the update interval is adjusted slightly, in order to keep the hourly rate the same.
So basically it trades off accuracy in the amount transferred per sample against the accuracy of the sampling interval. This all assumes that a "real world" model does not get troubled by the sampling interval not being exact.
EXAMPLE - In the case above, the amount per sample becomes 4.859375 (looks strange because truncation is done in base-2 math) and the sampling interval becomes 9.996428571429 (expect up to 0.1% variation from what is specified). Over time, far less error accumulates because the amount per sample is a precisely represented number.
Important - the precision limits are still there and will still manifest themselves when the ratio of bin level to transfer amount per sample is high. Initial testing suggests a ratio of 100 million to 1 should be OK, with this option selected.
Pipe Table Row Mode
A mode is supported for pipes which is useful when material blending needs to be tracked. This is only supported for pipes with a zero delay (version 5.00s) which transfer directly between source and target.
In this mode pipes still transfer between source and target values (with limiting etc operating the same). The values are now cells in tables. Most likely they will be cells in the same column but different rows of the same table (but this is not forced).
Every time a transfer occurs, other columns in the source table will also be transferred, proportional to the amount of the source that was transferred.
For example, the source value can be total tonnes and the other columns can be a breakdown of this total into its components. As the source "flows" to the target value, the components will also proportially accumulate in columns in the target row.
No column/tuple matching is performed: columns must match if 2 different tables are used for source and target.
To use this feature:
- ensure the pipe Total Time is 0 (otherwise it doesn't work)
- select the "Pipe Table Row Mode" option for the pipe
- set up the source and target references as table cells
(preferably to the same column but different rows in the same table) - The pipe context menu will include new menu items to select
"Additional Data Column Start" and "Additional Data Column End"
so the modeller can specify the range of columns that the pipe
will transfer in addition to the source/target.
They default to column 2, assuming the primary source/targets are
in column one.
If this column range overlaps either the source or target columns
then those columns get skipped to avoid "double transferring".
The cells referenced can be changed on-the-fly but the modeller needs to plan this extremely carefully.
idkbase note 311