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):
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_timeis 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.