The (obsolete) four data blocks can be stored in two, three, or four input files (obsolete).
First we will describe the option using four files (obsolete): (Note, that the name of all files can be choosen arbitrarily (inlcuding the extension type).)
The inital system data contains the file names of the three other blocks. The following parameter identifier are used for that reason (obsolete):
device_file: /name/of/the/device/file
conncetion_file: ~/name/of/the/connection/file
loop_control_file: ~/tilde/can/be/used/as/alias/for/the/homedir
A filename without a perceding '/' is taken as a filename relative to the initial system data file. If one of these filename identifier is omitted within the initial system data file, the initial system data file itself is assumed to be the desired file. Hence, it is possible to copy the data of any file to the inital system data file and delete the parameter identifier (or comment it out using '//').
Additionally some overall system parameter can be specified:
rng_seed_with_time: true
rng_seed_value.rng_seed_value: 1
rng_seed_with_time is set to false the generators are seeded by the given value.
Here is an (obsolete) example for a file that keeps inital simulation system data: (Note: The following files are just used for demonstration. They do NOT build an useful system to be simulated!! (Actually, it's a communication system using an encoder but no decoder!) More proper examples should be available with the libraries you are going to use for your simulations, e.g. the library simtheticlib provides some examples within the directory 'simtheticlib/parameter/'.
/* 'example_1.par': Example parameter file to specifiy the inital data of an EventDrivenSystem.
Note: This parameter file and those that are included are just used for demonstration.
They do NOT build an useful system to be simulated!!
(Actually, it's a communication system using an encoder but no decoder!)
More proper examples should be available with the libraries you are going to use
for your simulations, e.g. the library SimtheticLib provides some examples within
the directory 'simtheticlib/parameter/'.
This example init parameter file specifies the name of the device file, the connection file,
and the loop variable file. It is also possible to delete one or more of these specifications
and copy the information stored in the corresponding files into this file.
*/
COM: Specifiy the system (yet there is only free_connection_standard possible)
system: free_connection_standard
COM: Specifiy some system parameters
rng_seed_with_time: true // seed the random generator (RG) by system time
rng_seed_value: 1 // if not seed by system time take this value to seed (RG)
COM: Pre-load some libraries (otherwise you have to specify the library for each block)
pre_loaded_libraries: simthetic
COM: Paths to search libraries within, if a library is given by a relative path.
//library_paths: ~/usr/lib
COM: Stores the device depended data (filename can be given relative to this file):
device_file: example_1.dev // (you can also put the contents of the file into this file)
COM: Stores the connection between the devices (filename can be given relative to this file):
connection_file: example_1.con // same as above
COM: Stores the information of the loop variables (filename can be given relative to this file):
loop_control_file: example_1.loo // same as above
COM: File to store output data. Note that the data is append if the
COM: file already exists. Hence, if a device
COM: will write some information to a file (see for example the monitor device),
COM: you can use the same file to store both the output information the system
COM: and the output information of that device.
COM: (Filename can *NOT* be given relative to this file but relative to the directory simthetic has been called.)
output_file: testout1.err
The contents of the device_file looks as follows:
/* Example device file 'example_1.dev'
A device file specifies the parameter of devices. The parameter
of each device block are within '[blockX]' and '[end]', where X
is the device (or block) number that starts from zero. Note that
it is nor possible to overleap a device number. The parameter
library can be omitted if the library is one of the pre-loaded libraries
in the inital system parameter file (see example_1.par). If the name of library is
given as a relative pathname (i.e. without perceeding '/') the library is searched
in the library paths specified in the inital system parameter file (see example_1.par).
*/
=======
[block0]
//The tag library can be omitted if the library is already set by 'pre_loaded_library:' (see example.par):
//library: simthetic
type: bit_generator
bitseq_len: 1018
all_zero_sequence? no
all_one_sequence? no
[end]
=======
[block1]
//library: simthetic
type: encoder
interleaver_token: intl
input_length: 1018
OPTIONS: convolutional punct_convolutional turbo_conv_conv punct_turbo_conv_conv adachi_turbo
turbo_conv_diffmod turbo_conv_dapsk
coding_type: convolutional
COM: Used for convolutional, punct_convolutional and adachi_turbo:
polynomials: 171 133
COM: Used for turbo_conv_diffmod, turbo_conv_conv and adachi_turbo:
inner_polynomials: 1 // 7 5 // 171 133 //
outer_polynomials: 171 133
inner_recursive_polynomial: 3 // 0 // 5
iterations: 0
COM: Used for punct_convolutional and punct_turbo_conv_conv:
inner_rate_numerator: 1
inner_rate_denumerator: 4
outer_rate_numerator: 2
outer_rate_denumerator: 3
COM: Used for turbo_conv_diffmod:
bits_per_symbol: 3
mapping_mode: GRAY
[end]
=======
[block2]
//library: simthetic
type: monitor
COM: monitor
display_results? yes
write_gnuplot_file? yes
error_position_info? yes
input_length: 1018
append_file? no
output_file: ./parameteroutputfile.err
write_protection? no
min_bits: 2000
max_bits: 500000
min_bit_errors: 1000
early_stopping_feature? no
snr: SNR_loop
[end]
Here you see the contents of a connection_file that connects the interface of the three device blocks. (Device block 2 has two input interfaces) WATCH OUT: This is the new file format (version=2.0) for a connection file. Simthetic used to offer an old file format which was difficult to understand, but now we always recommend this new file format. As a side effect, it is not possible to merge the connection file and the other parameters into one file, since the file formats are now very different. But the example file also describes the format:
// Example connection_file 'example_1.con' // // // This example parameter file specifies connections between devices (or more precisley between // interfaces) in a StreamDrivenSimulationSystem. // The line '(n,i) (m,j)' connects the i-th output interface of the device with the ID 'n' with // the j-th input interface of the device with the ID 'm'. // // Specifiy the connection file version, i.e. 2.0: // <connection_file_version=2.0> // Bit Generator (ID: 0, Outpt-Intf: 0) -> Encoder (ID: 1, Inpt-Intf: 0) (0,0) (1,0) // Bit Generator (ID: 0, Outpt-Intf: 0) -> Monitor (ID: 2, Inpt-Intf: 0) (0,0) (2,0) // Encoder (ID: 1, Outpt-Intf: 0) -> Monitor (ID: 2, Inpt-Intf: 1) (1,0) (2,1)
Finally we present an example for a loop_control_file. The loop controls are used as runtime control of a simulation, e.g. the loop control with the name 'SNR_loop' in the example below, is used to control the SNR simulation range of the simulation run. To get an overview of the general, very flexible loop control mechanism of Simthetic, see Runtime control of a Simthetic simulation.
/* 'example_1.loo': Example loop control file.
This example loop control file specifies the loop controls used
in an EventDrivenSystem (see LoopControl). Loop controls are
used to control the process flow of a simulation run.
E.g. a LinearLoopControl<double> with start value 5 and end value
19 could represent an SNR-range from 5dB to 19dB in a simulation
system that simulates a digital transmission chain. This loop
control is specified by the argument 'type: linear_double'.
To have an influence on the SNR of the simulated transmission
system, the LinearLoopControl must be connected with a
ControlInterface of the Channel device that wraps the function
setSNR(double newValue). Therefore, the loop control must
specifies a name which is referred to by the channel. Then, each
time the function nextIteration() of this loop control is called,
the function setSNR() of the channel is called with the current
value of the linear loop control.
It is also possible to use nested loops. The loop control with
the smallest number, here loop_control0, represents the innermost
loop; the loop control with the highest number, here
loop_control1, represents the outermost loop. */
/* The innermost loop: Here, a so called counter loop is used. The
number of loops to be performed are given by number_of_loops. This
loop variable can be connected to any device function, that takes no
argument, e.g. the function refresh() of the WSSUSChannel class can be
connected with, to dice for each SNR value (see the loop control
below) a given number (by number_of_loops:) of new channel
represantives. Since in this example we are using an AWGN channel, no
device is connected with this loop control and hence we can set the
number_of_loops: to zero. In that case we could also delete that loop
control from this file. */
[loop_control0]
name: refresh_loop
type: counter
number_of_loops: 0
[end]
/* Second loop: Here the outermost loop. See the description above
for further explanation. */
[loop_control1]
name: SNR_loop
type: linear_double
start_value: 0
end_value: 5
increment: 1
[end]
However, as already mentioned, you can put all the information in the inital system data file.
1.4.1