Description Usage Arguments Details Value See Also Examples
Trace values of thermalhydraulic regime (temperature, pressure, consumption) in the bunched pipeline along the flow direction using norms of heat flux values prescribed by Minenergo Order 325.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23  m325tracefw(
sender = c(0, 1),
acceptor = c(1, 2),
temperature = c(70, NA_real_),
pressure = c(pipenostics::mpa_kgf(6), NA_real_),
consumption = c(20, NA_real_),
d = rep_len(100, 2),
len = rep_len(72.446, 2),
year = rep_len(1986, 2),
insulation = rep_len(0, 2),
laying = rep_len("tunnel", 2),
beta = rep_len(FALSE, 2),
exp5k = rep_len(TRUE, 2),
roughness = rep_len(0.001, 2),
inlet = c(0.5, 1),
outlet = c(1, 1),
elev_tol = 0.1,
method = "romeo",
verbose = TRUE,
csv = FALSE,
file = "m325tracefw.csv",
maxcores = 2
)

sender 
identifier of the node which heat carrier flows out.
Type: any type that can be painlessly coerced to character by

acceptor 
identifier of the node which heat carrier flows in. According to topology
of test bench considered this identifier should be unique for every row.
Type: any type that can be painlessly coerced to character by

temperature 
snapshot of thermalhydraulic regime state: temperature of heat carrier
(water) sensormeasured on the root node, [°C].
Type: 
pressure 
snapshot of thermalhydraulic regime state: sensormeasured
absolute pressure
of heat carrier (water) inside the pipe (i.e. acceptor's incoming edge),
[MPa].
Type: 
consumption 
snapshot of thermalhydraulic regime state:
sensormeasured amount of heat carrier (water) on root node that is
transferred by pipe (i.e. acceptor's incoming edge) during a period,
[ton/hour].
Type: 
d 
internal diameter of pipe (i.e.diameter of acceptor's incoming edge),
[mm].
Type: 
len 
pipe length (i.e. length of acceptor's incoming edge), [m].
Type: 
year 
year when the pipe (i.e. acceptor's incoming edge) is put in operation
after laying or total overhaul.
Type: 
insulation 
identifier of insulation that covers the exterior of pipe (i.e. acceptor's incoming edge):
Type: 
laying 
type of pipe laying depicting the position of pipe in space. Only five types of pipe laying are considered:
Type: 
beta 
logical indicator: should they consider additional heat losses of fittings
located on this pipe (i.e. acceptor's incoming edge)?
Type: 
exp5k 
logical indicator for regime of pipe (i.e. acceptor's incoming edge): if

roughness 
roughness of internal wall of pipe (i.e. acceptor's incoming edge),
[m].
Type: 
inlet 
elevation of pipe inlet, [m].
Type: 
outlet 
elevation of pipe outlet, [m].
Type: 
elev_tol 
maximum allowed discrepancy between adjacent outlet and inlet elevations of
two subsequent pipes in the traced path, [m].
Type: 
method 
method of determining Darcy friction factor:
Type: 
verbose 
logical indicator: should they watch tracing process on console?
Type: 
csv 
logical indicator: should they incrementally dump results to csvfile
while tracing?
Type: 
file 
name of csvfile which they dump results to.
Type: 
maxcores 
maximum cores of CPU to use in parallel processing.
Type: 
The calculated (values of) regime may be considered as representation of district heating process in conditions of hypothetically perfect technical state of pipe walls and insulation.
They consider the topology of district heating network much similar to
m325testbench
:
Tracing starts from sensorequipped root node and goes forward, i.e along
the flow direction. Function m325traceline
serves under the
hood for tracing identified linear segments from root node to every
terminal node. Hence they only need root node to be equipped with sensors.
Sensors at other nodes are redundant in forward tracing, since the tracing
algorithm by no means consider them for tracing.
Moreover in the forward tracing algorithm they assume the flow of heat carrier is distributed proportionally to the crosssectional area of the outgoing pipeline. Actually, a lot of reasons may cause significant deviations from this assumption. As a result, the sequence of paired backward/forward tracing may be divergent for regime parameters.
Though some input arguments are natively vectorized their individual values
all relate to common part of district heating network, i.e. associated with
common object. It is due to isomorphism between vector representation and
directed graph of this network. For more details of isomorphic topology
description see m325testbench
.
They are welcome to couple the algorithm with functionality of data.table.
data.frame
containing results of tracing in
long format
(narrow format)
mostly like it returned by function m325tracebw
:
node
identifier of the node for which regime parameters is calculated.
Values in this vector are identical to those in argument acceptor
.
Type: assert_character
.
trace
identifiers of nodes from which regime parameters are
traced for the given node. Identifier sensor
is used when
values of regime parameters for the node are sensor readings.
Type: assert_character
.
backward
identifier of tracing direction. It constantly equals to FALSE
.
Type: assert_logical
.
aggregation
aggregation method associated with values of calculated temperature or
pressure in data.frame
's row for the node. For forward tracing
the only option is identity
.
Type: assert_character
.
temperature
snapshot of thermalhydraulic regime state: traced temperature of heat
carrier (water) that is associated with the node, [°C]
Type: assert_double
.
pressure
snapshot of thermalhydraulic regime state: traced pressure of heat
carrier (water) that is associated with the node, [MPa]
Type: assert_double
.
consumption
snapshot of thermalhydraulic regime state: traced pressure of heat
carrier (water) that is associated with the node, [ton/hour]
Type: assert_double
.
job
value of trace step counter. For forward tracing value of job
counts the number of traced paths from root node.
Type: assert_integer
.
Other Regime tracing:
m325tracebw()
,
m325traceline()
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50  # Minimum two nodes should be in district heating network graph:
m325tracefw(verbose = FALSE)
# node trace backward aggregation temperature pressure consumption job
# 1 1 sensor FALSE identity 70.00000 0.5883990 20 0
# 2 2 1 FALSE identity 69.71603 0.5813153 20 1
# Example with the test bench:
nx < pipenostics::m325testbench
# avoid using numeric identifiers for nodes:
nx$sender < paste0("N", nx$sender)
nx$acceptor < paste0("N", nx$acceptor)
# Alter units:
nx$d < 1e3 * nx$d # convert [m] to [mm]
# Perform backward tracing to get regime on root node:
bw_report < do.call("m325tracebw", c(as.list(nx), verbose = FALSE))
# Put the traced values to the root node of the test bench:
root_node_idx < 12
root_node < paste0("N", root_node_idx)
regime_param < c("temperature", "pressure", "consumption")
nx[root_node_idx, regime_param] <
subset(bw_report,
node == root_node & aggregation == "median",
regime_param)
rm(root_node, root_node_idx)
# Trace the test bench forward for the first time:
fw_report < do.call("m325tracefw",
c(as.list(nx), verbose = FALSE, elev_tol = .5))
# Let's compare traced regime at terminal nodes back to test bench:
report < subset(
rbind(bw_report, fw_report),
node %in% subset(nx, !(acceptor %in% sender))$acceptor &
aggregation == "identity"
)
regime_delta < colMeans(
subset(report, backward, regime_param) 
subset(report, !backward, regime_param)
)
print(regime_delta)
# temperature pressure consumption
# 4.640201e01 5.208802e03 5.465713e16
stopifnot(sqrt(regime_delta %*% regime_delta) < 0.5)

Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.