Selected topics on IDA usage

Previous (Selected topics)    | Back to Start    |    Next (Parametric Runs)

Selected topics on IDA usage

Creating input tables and binding variables

Select library ‘Utility’ by clicking on Utility.

Position the cursor on the TABLE object and drag to the system form.

Open the table object by double clicking on it and the diagram tab (Figure ) appears.

Figure 55. Table diagram

The table contains one variable with name "var1" and zero value.

To add another variable to the table, click on button Add and give it a name. A graph of the variable over the whole specified simulation interval is shown (default value zero).

There are three ways of defining the time series two of which will be explained here.

1. Editing the graph.

Double click on the graph, position the cursor on the graph at a specific time, click, hold and drag up or down, release. Continue this procedure until wanted shape of graph is achieved. Then right click and select done to finish.

Figure 56. Editing a diagram

2. Editing the table.

Click on the Data button and the Table editor (Figure ) is available. Fill the table with pairs, time and variable value, and finish by clicking on the OK button. The time series is then shown as a graph.

Figure 57. Table editor

3. Entering as text.

Switch to Text tab and type in the time and values of all variables as columns separated by blank characters (in the same format as in source files). It is also possible to copy data from and to Notepad or other text editors.

Figure 58. Table as text

To define a discontinuity in a time series the same time coordinate is entered twice, with a ‘before’ value and an ‘after’ value of the variable.

To bind this time series to variables in the system model proceed as follows (except the control signals that are described below).

Left double click on the component containing the variable to be connected.

If the variable appears with a ‘Bind to…’ button in General tab form then

            click on the ‘Bind to…’ button

else

            click on the Outline tab and find the variable in the list,

            right click on the variable and select ‘Binding…’.

The form for connecting a variable appears (Figure ).

Figure 59. Binding a variable to a table

Mark ‘connect to a variable of …’ and click on the system model name below. Then a list of objects (components etc.) of the system model appears in the window to the right. Find the table and click on it to exhibit the variables defined in it. Click on the right variable and on the ‘Connect’ button to complete the binding.

A different procedure is used for control signals (fan controls in tunnel sections, air supply/exhaust, and axial fan model; opening control in damper model; flow control in given flow model). This is because the control signals are designed for connecting with components from the control library.

The connection between a control signals and a table is established in the same way as connections between components, using connection lines. Tables contain an interface "int1" that references the variable "var1" and may be connected to control interfaces in models.

It is also possible to add a new interface to a table. To do this, connect a control signal with the table with connection line. In the Connect dialog (Figure ), type in the interface name and click Ok button

Figure 60. Connecting a control signal to a table

In the Define interface dialog (Figure ) select variable(s) that should be included in the new interface. The left pane lists the variables included in the model's interface (the control interfaces consists of one variables only). The right pane lists all variables in the table.

Figure 61. Define interface dialog

        To connect a variable in the model with an existing variable in the table, select the desired variables and click "Connect         selected".

        To connect a variable in the model with a new variable in the table, select the variable in the model and click "Connect to new"         and than select a name for new variable.

After connecting all variables in the interface, click Ok button. The interface is defined and connected.

Recording output time series

Select library ‘Utility’ by clicking on Utility.

Position the cursor on the OUTPUT-FILE object and drag to the system form.

At the top of the system form under heading ‘Results:’ an output file with name OUTTPUT-FILE now appears.

            By default there is always a predefined output file (with name RESULTS). If many time series are to be recorded on different             output files it might be convenient to rename the files. To do this right click on the file name and select ‘Rename …’ from the             list of options, write the new name and press OK.

To select variables to be recorded proceed as follows.

Left double click on the component containing the variable to be recorded.

If the variable appears in General tab form then

            double click on the pane with variable value

else

            click on the Outline tab and find the variable in the list, then

            double click on the variable.

The variable form appears (Figure ).

Figure 62. Form for variable

At the bottom of the form to the right of ‘Logged to’ select the output file.

            Instead of the variable name used in the model one may give another, which will be used when presenting the resulting time             series.

Close the form by clicking on the ‘Close’ button.

Adding a time series from file (source file)

Select library ‘Utility’ by clicking on Utility.

Position the cursor on the SOURCE-FILE object and drag to the system form.

Open the source file object by double clicking on it and the diagram tab (Figure ) appears.

Figure 63. Source file dialog

            The output files described above (and Climate files used in IDA Rail) can be used as source files. They have a format where             each row contains time, variable 1 value, variable 2 value, etc. to define time series for variable 1, 2 etc.. Extension .prn is             used to denote such files.

Click on the ‘Browse’ button and find source file.

Click on button 'Take the list of var….' and select appropriate variable by marking it, then press the OK button.

To bind this time series to a variable in the system model proceed as follows.

Left double click on the component containing the variable to be connected.

If the variable appears with a ‘Bind to…’ button in General tab form then

            click on the ‘Bind to…’ button

else

            click on the Outline tab and find the variable in the list,

            right click on the variable and select ‘Binding…’.

The form for connecting a variable appears (Figure ).

Mark ‘connect to a variable of …’ and click on the system model name below. Then a list of objects (components etc.) of the system model appears in the window to the right. Find the source file and click on it to exhibit the variables defined in it. Click on the right variable and on the ‘Connect’ button to complete the binding.

Creating schedules and binding variables

Schedules are used to define how something varies with time and especially convenient to use for describing processes occurring in a periodic (daily) manner. Examples of this are the presence of occupants, closing/opening of doors, operation time of fans and time tables of trains. To demonstrate how to use schedules we construct a time table for a train having the same schedule every day.

Select library ‘Utility’ by clicking on Utility.

Position the cursor on the Schedule object and drag to the system form.

Open the schedule object by double clicking on it. The form of Figure appears.

Figure 64. Schedule form

Right click on the right-most arrow and select ‘Open’, see Figure .

Figure 65. Schedule dialog

Click on the ‘Advanced’ button and write ‘Train intervals’ in the description pane, Figure .

Figure 66. Advanced Schedule dialog

You can do basic editing of a profile on the graph under the heading ‘Daily schedule’. Click on the ‘Edit profile’ button  for a more detailed editing. In the ‘Profile’ dialog, edit the profile either in diagram, see Figure (in the same way as a variable in a table, see section ) or in dialog, see Figure . Click ‘OK’ to accept the changes.

Figure 67. Edit profile in a diagram

            It is not clear what is "interval between trains" at the time when where in no traffic. IDA Tunnel expects in this case the time             remaining to the next train (this is significant only when starting a simulation at the time when there is no traffic). Therefore the             time interval in the example on the Figure decreases at nighttime from 5 hours at 1:00 to zero at 6:00.

Figure 68. Edit profile in a dialog

To define different timetables for different weekdays or seasons, define additional rules using buttons at the top of the advanced schedule dialog, see Figure .

            In the Rules list box, new rules can be added with the Add button, and existing rules deleted with the Delete button. The rule             furthest up applies in the first hand, and the one furthest down applies last. The rule selected in the list box can be moved up             and down with the Promote and Demote buttons, respectively.

For every rule, define the validity conditions (weekdays and/or start and end date) and the daily profile.

• When a simple schedule is changed via the Advanced button, the simple schedule appears as the only rule and is given the name Default. The rule output can be changed, but not its time of validity. The Default rule is always valid (the Valid days box is inactive when this rule is elected), and the rule also always remains as the last rule. This guarantees that the schedule’s value is always defined.
• Validity time for the selected rule is given in the lower right half of the dialog. In the Start date and End date fields the validity time for the rule can be limited to a portion of the year. If no start date is indicated the rule applies from the beginning of the year. If no end date is indicated the rule applies until the end of the year. The Calendar button is used to open the Calendar dialog, which aids selection of an existing date. In the Valid days box, the rule can be limited to apply only to certain days of the week (by crossing those days the rule is applicable). Clicking on  button, you can quickly choose one of the common sets of valid days.

When the schedule is ready, click either ‘OK’ to accept the changes in profile or ‘Save as…’ to keep both the old and the new version the schedule. You will be prompted for a new name for the changed schedule. (Note that if you click ‘OK’, you will be prompted to save the new version as a new object since it is not allowed to modify ‘Always on’ schedule.)

Working with database

IDA Tunnel Application uses a database to store typical examples of data objects

The following data types may be stored in database:

• Wall types
• Materials
• Time schedules
• Descriptions of climate files
• Locations for design day weather
• Cross-section profiles for 3D view of tunnel

To load an object from database,

            When setting a value for wall, material, time schedule, weather data, location, or cross-section profile, choose "Load from             database" from the list of available values (alternatively, click the button  at the right of the field or right click on the field and             select "Load from database" from menu);

            In the dialog, select the desired object, optionally change the name and press "Ok".

Figure 69. Loading object from database

To save an object to the database,

            Select the desired object, either in the "Resources" list on the "Global" tab, or in a field that shows a wall, material, time             schedule, weather data, location, or cross-section profile;

            Click the button  at the right of the field or right click on the field;

            Select the menu item "Write to database".

Figure 70. Saving an object to database

To open the database,

            Select the Database menu item from the Tools menu.

            To remove an object from database,

            Open the database;

            Select the desired object;

            Press "Delete" button on the keyboard (alternatively, right click the object and select "Delete" from menu).

Hot start

IDA offers an alternative way of starting a simulation, called Hot start, where the current values of variables are used as initial values. This is convenient in situations where one wants to continue a simulation for a longer time horizon or when one has stopped and saved a simulation before end time. Another occasion is when a simulation has terminated accidentally (crashed). In this case, one can retrieve automatically saved results from file and restart by using the hot start possibility. Converged results are saved regularly in a file, ida_lisp.hot, in the temporary directory where the simulation is done.

When a model is unstable and prone to crashing, there is usually some underlying physical cause that needs to be addressed. However, when it is unpractical to start such a debugging procedure, it may frequently be possible to simply restart the simulation from the last saved converged state as saved in the ida_lisp.hot file and chances are good that a new sequence of time steps will avoid the problematic point.

To hot start from current state (end state of a previous simulation),

            Select Hot start from the Tools menu.

            Give the end (To) time in the Hot start dialog and press button ‘Run’ to start the simulation.

In order not to overwrite the results of the previous simulation case one can save the new case under another name.

To retrieve results from file do

            Select Load results… from the Tools menu.

            Choose file ida_lisp.hot.

            Hot start according to the instruction above.

Note that file ida_lisp.hot is overwritten so be sure to retrieve it or copy it if needed before any other simulation case is started.

When Hot start is used, the time history of a logged variable is not appended to the old history in the prn file. If one doesn’t rename the hot start simulation the old history will be overwritten. By saving the hot start simulation with a different name one will have the complete history but in two prn files. These files can of course be combined to one file but this requires some manual editing.

Long term simulation

To compute the conditions in a tunnel system after a long time it is important that the temperature field in the surrounding bedrock can be estimated. This can of course be achieved by performing a simulation covering several years. However, large and complex systems will in general yield completely unrealistic execution times. Some other method is required to reduce execution times to realistic levels while preserving the accuracy within an acceptable tolerance.

IDA Tunnel has a procedure where the time scale for the heat transport in the surrounding bedrock is rescaled to yield a faster transport, e.g. temperature developments which in reality cover years, will in simulations be shortened to hours or days. A way of thinking about this is that the material properties of the rock are adjusted, so that a long term temperature field is established with only a small fraction of the amount of energy that normally would be required. Simultaneously, the boundary conditions, e.g. time dependent climate data and other driving functions, are adapted to the artificial time scale.

Limiting factors for the degree of scaling are periodic processes, e.g. climate data having day/night (24 hour period), seasonal variations (1 year period) and schedules of trains varying during day/night and week/weekend. The length of a long term simulation has to cover a fair number of the longest periods. Test simulations have shown that these limitations partly can be circumvented by averaging and thus shortening the longest periods. This is done by splitting the entire long term simulation into a sequence of simulations.

First a simulation is done covering the main phase (years) and where considerable time rescaling and averaging are used. This is followed by a winter and possibly summer season simulation, with more detailed information on climate and schedules and finally design day simulations, winter and/or summer day, where fully detailed information is used without time rescaling and averaging. Final temperatures from previous runs are used as initial values for subsequent simulations.

Preparing a long term simulation

The model of the tunnel system to be simulated is subject to some restrictions. The objects Local ambient climate data can not be used in the model; the whole model has to be exposed to the same climate from a yearly climate file. Tables defining time series should not be used in complete long term simulations since these are not handled by the time rescaling and averaging procedures. Use schedules instead. Control systems should also be used with care. If they rely on schedules, taking a yearly average of the schedule must be a meaningful operation.

With the tunnel system to be simulated (base system) opened in IDA Tunnel select ‘Longterm & Design day simulation…’ in the Tools menu at the top of the system form. A form according to Figure is displayed.

1. Climate data. The first two simulations, 1 ‘Long term with averaged schedules’ and 2 ‘Season’ , require that a Climate data file is selected. Click on the down arrow to the right and search the database to find a suitable climate file. A Location can also be chosen from the database, which possibly will be utilized in the design day simulations (see below).
2. Main long term simulation with averaged schedules and a yearly average of climate data. Averaging the schedule of a train, means that all the train departures are evenly distributed during the year. Similarly all other schedules, for example for passenger densities or heat loads, are averaged so that the same mean value is used all around the clock. The periodic behaviour remaining after averaging schedules and climate is caused only by train passages. Simulation experiments indicate that the length of the main long term simulation can be compressed as to have at least 800 train passages per route. This typically means that years can be compressed to hours. By default 30 years are compressed to 72 hours, i.e. a rescaling factor of 3660.
3. Season simulation. Here there are two possibilities. If ‘averaged schedules’ are checked then just as in step 1, averaged schedules are used but climate data are run through (traversed) faster according to the given rescaling factor. The default rescaling is 183, i.e. 183 days = 0.5 year in 1 day. The rescaling factor can be changed by opening the ‘Outline’ form and giving another value in the SEASON-RESCALE field. If ‘actual schedules’ is checked, then unaltered schedules are used and climate data is averaged so that the climate of the first day corresponds to a mean day of January, the second day to a mean day of February etc. Twelve days climate data represents in this way the climate for a whole year (rescaling factor = 30). The winter season simulation corresponds to 3 months (December to February on the northern hemisphere and June to August on the southern hemisphere) and the summer season simulation to 6 additional months (March to August on the northern hemisphere and September to February on the southern hemisphere).
4. Design day simulation. In design day simulations, the complete information regarding schedules and climate is used without time rescaling and averaging. Just like in any ‘normal’ simulation. There are two ways of choosing climate data. If ‘Design-day from climate file’ is checked climate data is taken from the file specified under 0. above. The days to simulate are selected by editing the date field to the right or by clicking on the calendar button and then in the calendar defining the last design day. The number of days is given in the field above. The default simulation time is 5 days (from Monday to Friday) in the middle of January/July. If ‘Design-day climate data for location’ is chosen then synthetic climate data from the location object with its variation over the day for an extreme summer or winter day is used. Synthetic climate data contains temperature and moisture conditions recommended by ASHRAE for building HVAC design. Note that the default dates set for the design simulations are not always updated; make sure that they are correct regarding location, northern or southern hemisphere.

Results selected for logging in the base case will be logged in all simulations. Logging to e.g. path reports and animation should therefore be used with care not to produce huge result files. Such results might not be meaningful in simulations with time rescaling but of interest in the design day simulations. How to change logging see below (Performing a long term simulation).

The specified long term data is saved together with the whole case by selecting ‘Save’ in the File menu at the top of the system form.

Figure 71. Long-term simulation form

Performing a long term simulation

The normal sequence of simulations in a long term simulation would be simulations 1, 2 and one of 3 and 4 or both (numbers from Long-term form Figure ). However any of the 4 simulations can be skipped. If the main long term simulation 1 is not performed the bedrock temperatures in the base case will be used as initial temperatures.

To start the simulations press the ‘Run’ button in the Long-term simulation form. The specified simulations will now be executed one after the other with the development of each simulation displayed on the screen.

One can interrupt and stop any simulation and resume at a later occasion. To terminate a simulation press the Stop button and after that the Abort button in the progress dialog. To continue the sequence of simulations when it has been interrupted, press the ‘Restart…’ button in the Long-term form and select the simulation, which was stopped. This restart option will restart the simulation from its start time. See also how to use the hot start possibility below.

If one wants to change the logging of results, e.g. include more logging in the design day simulations, do the following. Perform a long term simulation with the design day simulations not checked in the Long-term simulation form. Next include the wanted logging in the base system, check the design day simulation(s), leave previous simulations still checked, and restart from design day simulation.

Inspecting results

Each simulation is saved as a separate case file in the same way as a regular simulation and can be inspected as such. The simulations are opened by placing the cursor at the open symbol (hyperlink) to the right in the Long-term form and left-click. Note that, long-term (1) and season (2) cases are saved with rescaled time and averaged schedules. Base and design day cases are saved without rescaling, and may be used for subsequent runs. The rescale parameter, timeRescale, can be found in the Outline tab of the system form under fireDetails.

The simulation cases belonging to a long-term simulation are saved in a sub directory with a name equal to base case extended by .longterm and may be accessed as ordinary simulation cases.

Using hot start

Since the simulations can be quite time consuming, it might be worthwhile to use the hot start possibility for a terminated run (see Section) instead of the Restart procedure described above. In this case, the specific simulation is performed as a regular simulation and not from the Long-term simulation form. Open the simulation case by placing the cursor at the open symbol (hyperlink) to the right in the Long-term form and left-click. After completing such a simulation save the temperature field to file case.stf together with case.idm in directory basecase.longterm where case is the name of simulation case (see section ). After that one can return to the Long-term simulation form and start subsequent simulations by the Restart procedure.

Methods

Time rescaling

The process with the largest time constant is the temperature development in the bedrock. The time rescaling aims at speeding up this process, which is governed by a partial differential equation in space and time:

Introducing another time scale µ by  = α.t yields the equation

which is equivalent to dividing the heat capacity by the time rescale factor α. Larger rescale factor causes faster transients measured in time scale . The first main long term simulation, where by default, 30 years are compressed to 72 hours (3 days), uses a time rescale factor

α = 30.366/3 = 3660.

The default values for the season simulations correspond to rescale factors 183 and 30 respectively.

Filtering

The time variations of the temperature field in the bedrock close to the wall surface due to train traffic increase with larger time rescale factor (smaller heat capacity). This means that the final states in the first main long term simulation and the season simulations, which are used as initial states in subsequent simulations, would be very sensitive to how the train traffic situation happens to be at the very end of these simulations. To decrease the influence of this unwanted effect we filter the air temperature T_air exposed to the wall surface and get T_air2wall by using a time constant  (default 3600 sec)

This procedure will decrease the amplitude of the temperature variations in the bedrock. The time constant, parameter tauT, can be found in the Outline tab of the system form under fireDetails. Filtering is only applied in the long-term (1) and season (2) simulations.

Stochastic train traffic

Simulated train traffic usually implies perfect adherence to time tables. To disturb this deterministic behavior we have introduced the possibility of applying a stochastic delay to train departures. This can be used to describe randomly occurring delays in daily traffic as well as uncertainties in knowledge of future traffic relative headways. One can also think of it as a means of computing an average state of all possible relative headways in a single simulation, instead of performing a set of long term simulations with combinations of headways and from these computing an average. The stochastic delay is applied to every train departure. Two probability distributions are available in IDA Tunnel. There is the exponential distribution with probability density function

where λ is the mean value of the time delay and t is the delay. The used pseudo-random number generator limits the maximal delay to 10.4 times λ. Then we also have the uniform distribution according to density function

where b-a is the headway.

If the interval between two trains is too small due to stochastic delay, the later train will wait so that the headway will not be smaller than the value of minHeadway (default 60 sec). This parameter may be found under Outline tab of each route.

Comparing the two distributions one notes that the uniform distribution always generates delays within the headway, whereas with the exponential distribution we may get delays larger than the headway. This means that the exponential distribution may cause trains to be cancelled and not just delayed. This suggests that the uniform distribution might be more appropriate in connection with long term simulations while the exponential distribution is more suited to describe randomly occurring events in daily traffic.

To select type of distribution click on the ‘stoch. delay’ button to the right in the Route form (see Figure ) and check the wanted distribution. If exponential distribution is selected also give the mean value of the time delay.

Using a mean time delay of about half of the minimum headway (interval between trains) will normally remove most effects of train synchronization in cases with exponential distribution.

The using of delay often requires increasing of the maximal number of scheduled trains nRun.

Stochastic train traffic has an adverse effect on the accuracy of time rescaling, i.e. one can generally apply less severe time rescaling factors for stochastic runs. Default values as discussed above for time rescaling will in general be acceptable for stochastic runs. For non-stochastic runs, more aggressive time rescaling may often be applied.

Distribution of train heat and air fraction along the train length

By default, emissions of heat and air fractions are released at the front of the train.

With the parameter, “nLoc – Number and position of locomotives”, in the train form different types of distribution can be adjusted (Figure):

Figure 72. Adjusting the train heat distribution in the train form

In “undefined”, emissions of heat and air fractions are handled with everything released at the front of the train.

In “Distributed”, emissions of heat and air fractions are distributed evenly along the length of the train.

In the other alternatives where the user chooses the position and number of locomotives:

• * Specifies the position of a locomotive in train movement from left to right.
• QLoss and QDieselHeat are released at the locomotive’s positions. The remainder of Qtrain2air are distributed evenly along the length of the train (For more details about definition of this parameters please refer to the train heat model section of the theoretical guide).
• CO2 and vapour from passengers are distributed evenly along the length of the train. (For more details, please refer to the CO₂ content sub section of air quality section in the theoretical guide)
• Particles from brakes, rolling and locomotive defined in Outline->glob:
  • Particles from brakes and rolling defined in “k_b” and “k_r” are distributed evenly along the length of the train.
  • Particles from locomotive defined in “k_loc” are released at the locomotive’s positions.

                (For more details, please refer to the particle content sub section of air quality section in the theoretical guide)

• Emissions from diesel trains: HC, CO, NOx, PM, CO2 and vapour are released at the locomotive’s positions. 

                (For more details, please refer to the CO, NO2 and HC contents sub section of air quality section in the theoretical guide)

For emissions of heat and air fractions from a locomotive, the position of the locomotive is handled as a point, i.e. length of locomotives is not considered.

Ambient temperature gradient

IDA Tunnel by default assumes constant temperatures in the vertical direction, indicating an isothermal atmosphere (Check equation * in the theoretical guide). However, there is a vertical temperature gradient in the atmosphere. In tunnels with long lengths and significant differential portal altitudes, it might be necessary to consider this effect. In the global form (Figure), you can set the temperature gradient (the suggested value is -6.5ºC/km height according to ISO 2533). In that case, both the height and the temperature change in the atmosphere affect the calculated local pressure at the portals. Additionally, the atmospheric pressure can be provided in this form at the local reference defined by hRef if one wishes to use that in a constant ambient form.

 ​​​​​​​

Figure 73. Possible setting the ambient temperature gradient in general form

​​​​​​​

Selected topics on IDA usage

In this section, some general IDA operations that are commonly needed by the RTV user are explained. Other general IDA functions are treated in the on-line help (See the Help menu, Contents.) A pdf version of these texts is available on the User’s homepage: Help menu, IDA on the Web, RTV user support.

Diagram properties

To change a diagram open the Diagram Properties dialog,

1. Selects the diagram or the diagram’s legend.

2. Select Properties... from the Object menu or by right clicking from the shortcut menu

The Diagram Properties dialog consists of three tabs: General, Legend, and Variables.

Figure 7 .34. Diagram Properties dialog, general tab

Figure 7 .35. Diagram Properties dialog, Legend tab

Figure 7 .36. Diagram Properties dialog, Variables tab

The General tab controls the general properties of the diagram and legend:

Read-Only

Disables editing of the diagram data. If the diagram data are not intended for editing (e.g., are calculated), this item is not available.

X-Range

Controls the data range along the horizontal axis (usually the time). Auto means include all points.

The choice Use time slice is available for time series with Calendar time (not available in IDA RTV).

Y-Range

Controls the data range along the vertical axis. Auto means include all points.

Font

Select the font for text in diagram (only for bar charts)

Diagram type, Data (for time series only)

Normal Show all points

Integral Show the integral function of the time series. Note that the values of integral
functions have different ranges, measurement units, and descriptions. Therefore Y-range and the legends and scales for variables should also be changed to attain a correct integral diagram.

Duration Shows the duration diagram, i.e. samples sorted by size.

Diagram type, Weight schedule

The weight function is only available with Calendar applications (not IDA RTV).

Diagram type, Presentation

Select how to show the data is in the diagram.

The Legend tab controls the properties of the legend.

The Variables tab controls the properties of data series.

Select a row in the Data series box. The properties of that series will be displayed in the right side of the dialog box:

Description

Type the text in the legend or select Auto to use the description and the measurement unit of the variable.

Line color,
 Line style

Select the color and the thickness or pattern of the plot line

Adjustment

Select the scale and the offset of the plot line in order to fit in the selected Y-range. The displayed plot line will have a y-coordinate equal to scale * value + offset. Remember to mention the scale and offset in the legend (the Auto legend automatically includes this information).

Input time series from file (source file)

As an alternative to the definition of tables, one may access time series that have been stored as text files (usually containing larger amounts of data.) A common situation is when a variable has been logged in one simulation and then the resulting time series is used as a driving function for another run.

To create the object that contains the reference to a text file on disk, do the following:

Select library ‘Other’ by clicking on Other in the Side bar.

Position the cursor on the SOURCE-FILE object and drag to the system form.

Open the source file object by double clicking on it and the diagram tab (Figure 7 .37) appears.

Figure 7 .372 Source file dialog

Source files have a format where each row contains time, variable 1 value, variable 2 value, etc. to define time series for variable 1, 2, etc. Extension .prn is used to denote such files.

Click on the ‘Browse’ button to find the source file.

Click on button 'Take the list of var….' and select appropriate variable by marking it, then press the OK button.

To bind this time series to a variable in the system model proceed as follows.

Double click on the component containing the variable to be connected.

If the variable appears with a ‘Bind to…’ button in General tab form then

click on the ‘Bind to…’ button

else

click on the Outline tab and find the variable in the list,

right click on the variable and select ‘Binding…’.

The form for connecting a variable appears (Error: Reference source not found).

Mark ‘connect to a variable of …’ and click on the system model name below. Then a list of objects (components etc.) of the system model appears in the window to the right. Find the source file and click on it to exhibit the variables defined in it. Click on the right variable and on the ‘Connect’ button to complete the binding.

Building a custom form

The general tab for an RTV model is reserved for a user-defined form customized for a single case.

It may contain a description of the tunnel including pictures, and fields for access to the most important parameters and variables.

To add elements to a custom form, use the Insert menu.

To select which tab is shown first when opening a system, select that tab in the menu Options | RTV Options | Default view for RTV systems.

The fields in the custom view may become invalid in case of changes in the tunnel’s schema. To fix a field which has become invalid, click it with right mouse button and select Replace… from the pop-up menu.

Fan on/off

To insert, for example, a fan switch,

Select Insert | New Field …menu item;

In the Insert field dialog, select the tunnel section with required fan;

In the “show as” list, select “Fan at xxx on/off” and click “Ok”

Mark the place in the form where the field is to be inserted.

To edit the label, click the field with the right mouse button and select Properties from the pop-up menu.

Figure 7 .15. Insert fan switch dialog

Insert a new Element into a Document

To insert a new element into the edited document do the following:

Select the element from the Insert Menu: Object, Field, Text, Shape, or Button. A dialog will normally appear.

If a dialog is displayed, select the desired type of new object from the dialog and press the OK button (the dialogs for inserting objects and fields are more complicated, see Insert Component Dialog, Insert Field Dialog for details).

If the cursor in the document changes its form to  , choose a place and a size for the new object.

For the Text class one must also type in a string. The cursor (vertical line) shows where to begin. Press Enter to end typing. See Text elements for details.

These are typical steps. Sometimes they can be different.

2a) If there is no choice of type (i.e., objects of a single type may be inserted) step 2 is skipped.

3a) For lines (polyline, polygon, and arc) step 3 is completely different; see Editing a line.

Figure 7 .386. Insert Graphics dialog

 

A simple custom form

The example from \ida\samples\rtv\ test3.idm shown below is a simple example of a custom form. With the use of a form it’s easy in this example to perform simulations with fan on or off and check the resulting NO2 max. value without leaving the general tab.

Figure 7 .397. A sample form with graphics, fields and text

Selected topics on physical modelling

Traffic flow model

Congestion model

The traffic (for one lane) is described by the following variables:

• Vehicle flow  [pcu/h] where pcu is Passenger Car Unit (a conventional unit for measuring traffic flow consisting of vehicles of different type)
• Vehicle speed  [km/h]
• Density  [pcu/km]
• Average road length per vehicle  [m/pcu].

The dependence between variables are expressed by equations

For congested traffic, the vehicle speed is limited because of small distance between vehicles. Therefore we calculate the speed as a function of road length per vehicle  :

		when	Free traffic
	interpolated between  and	when	Medium traffic
		when	Congested traffic
	decreases linearly to zero	when	Traffic stop

A graph of this dependence (for three vehicle types) is shown in

. In Figure 8 .41 the same dependence is shown as flow-speed diagram, which is a more established way of describing traffic flow models.

Figure 8 .40 Vehicle speed [km/h] as function of road length per vehicle [m]

Figure 8 .41 The same dependence represented in flow [veh/h] and speed [km/h] coordinates

Unfortunately we cannot require the user to supply values for parameters used in this equation (except  ), because they are not intuitive and depend on many different factors. Instead we calculate them from the tables described below.

Table 1 gives the value free speed  (i.e., vehicle speed in non-congested traffic). The free speed depends on vehicle type, slope, and allowed speed limit. In a realistic traffic model the free speed may exceed the allowed limit.

In this and the following tables, the slopes and the speed limits should be listed in the increasing order. The uphill sections have positive slopes.

Table 2 gives the steady speed that limits the free speed on long uphill sections, depending on vehicle type and slope. If a vehicle at the beginning of an uphill section moves faster than the steady speed, it slows down to steady speed at 1000 m of the uphill section and than continue moving with steady speed.

Table 3 gives the road capacity  (maximal possible vehicle flow) as a function of number of lanes and speed limit. The capacity of the section after entrance is reduced proportionally to the vehicle flow from the entrance.

Table 4 gives the number of  (Passenger Car Units) per vehicle depending on vehicle type, slope, and slope length. Unlike other tables, this one is never extrapolated; the outmost rows and columns are used for slopes and length outside of the range given in the table.

Table 5 defines travel velocity at full capacity flow  depending on speed limit and slope. This is the speed at traffic conditions that corresponds to maximal possible vehicle flow. It does not depend on vehicle type (i.e. all vehicles are moving with the same speed). Therefore the value of  is reduced if  for some vehicle type is smaller then  .

Table 6 defines the coefficient  for interpolation of the speed between  and   .

The program uses the value of  at flow equal to 0, 43, 77, and 100% of full capacity, but only the value at 77% is calculated from table. The values at 0 and 43% are always 0 and the value at 100% is always 1.

The parameters used in the traffic equation are defined as:

 – calculated as an average road length per standing vehicle (that is given by the user for every vehicle type)

 – a point between  and  calculated from the condition that the curve  is smooth.

Tunnel connections

The traffic in every tunnel section is simulated using one or two (for bi-directional traffic) Way models. Adjacent Way models are connected so that every section receives from the previous one the traffic flow (for every vehicle type) and sends back the traffic density per lane.

The same information is sent also to and from other traffic models (Queue, Split, Merge).

The splitting branch is modelled using two models, Split and Queue. The Split model is a simple model that removes the given fraction of the traffic flow from the main stream and adds it to the exit stream. The beginning of the exit stream is modelled in the same way as the tunnel entry (Queue model).

The merging branch (Merge model) joins two traffic streams into one stream. Both ingoing sections use the value of traffic density from the outgoing section to calculate the traffic speed. The traffic flow from the branch stream reduces also the capacity of the outgoing stream. The smallest of the incoming traffic flows reduces the capacity of the outgoing stream.

Tunnel entry and exit

The traffic speed and flow at tunnel entries (Queue model) are calculated as functions of the density at the beginning of the tunnel. If the ingoing traffic flow exceeds the calculated one, the extra vehicles line up in the queue. If the ingoing traffic flow is smaller than the calculated one then the vehicles from the queue (if any) are used to raise the actual flow.

At the tunnel exit, the single required value is the traffic density directly after the tunnel. It is used to calculate the traffic speed at the end of the last tunnel section.

If the density is set to –1 (left blank in the Entry/Exit form), the Way model will use the traffic density in the last segment instead.

Multiple vehicle types

Vehicles of different types are modelled as traffic components. Vehicle speed and flow are calculated separately for every component. Vehicle density is first calculated for every component, but the flow equations use the total density.

In case of congested traffic all vehicles have the same speed. Therefore the vehicles with low speed constrain the speed of other vehicles. Clearly the traffic components with zero density cannot hinder other vehicles. Therefore the model assumes that only the components with density 1 veh/km or higher constrain the speed; for density between 0 and 1 veh/km the constrained speed is interpolated.

The concentration of traffic components may change dynamically. These changes are not delayed by the queue because the order in the queue is not modelled.

Multi-lane traffic

The model does not simulate every lane separately. All lanes have equal traffic conditions. Multi-lane traffic is modelled by defining the road capacity depending on the number of lanes (table 3 in vehicle flow model). The overtaking possibility is included in this dependency and not considered elsewhere.

Simplified traffic models

The congestion model is not the most appropriate for modelling a traffic situation with given vehicle flow or density. For this purpose IDA RTV defines two simplified traffic models: moving traffic and standing traffic.

In the moving traffic model the road capacity and possible speed are unlimited. The actual vehicle speed is equal to the given speed limit and vehicle flows are given at each entry.

The user can specify the default speed limit in the Global tab and the particular limits in section forms.

In the standing traffic model, all exits are closed so the tunnel fills completely by vehicles, except sections that are not available for traffic. Traffic lights are ignored, so they do not prevent the filling of the tunnel. Note that it takes some time to fill the tunnel. If the tunnel is not completely filled after the simulation, try to increase the simulation time.

The vehicle density is given by the parameter "Road length per standing vehicle".

The distribution of vehicles of different types is calculated from the traffic flows at entries and exit fractions in splitting branches.

2 A separate add-in for IDA RTV allows the user to build feedback control systems using component such as PI controllers, filters, state selectors etc. (See www.equa.se for more information).

Previous (Selected topics)    | Back to Start    |    Next (Parametric Runs)