Scripts can be written to automate a large number of runs on a circuit, saving the output in a sequence of rawfiles. Typically this may be done in the background, using WRspice in batch mode. This section addresses some of the subtleties of using scripts in batch mode.
Any script, or circuit file containing a script, can be sourced by WRspice when started in batch mode (-b option given). However, the batch mode behavior will not be evident unless 1) the sourced file (and any inclusions) contains a circuit description, and 2) no analysis command is run on the circuit from a .control block in the same file (plus inclusions). That is, after executing the .control lines, if WRspice finds that an analysis has already been run, such as from a tran command in the .control block, WRspice will simply exit rather than run the circuit again in batch mode. Here, by ``batch mode'', we mean the usual plots, prints, and other data output that would occur for a pure circuit file. When the circuit was run from the .control block, all of this output is absent, and .plot, .print and similar lines are ignored as in interactive mode.
If the input file contains a circuit description, recall that an .exec block in the same (logical) file will be executed before the circuit is parsed, and therefor can be used to set shell variables which can affect the circuit. For example:
* RC Test
R1 1 0 1k
c1 1 0 $cval
i1 0 1 pulse 0 1m 10p 10p
.plot tran v(1)
.tran 10n 1u
.exec
set cval="1n"
.endc
The circuit will run in batch mode, with the capacitance value provided from the .exec script. This example is trivial, but conceptually the .exec script can be far more elaborate, configuring the circuit according to an external data file, for example.
Often, it is more convenient to provide our own analysis control in the input file. For example, add a trivial .control block to the example above.
* RC Test
R1 1 0 1k
c1 1 0 $cval
i1 0 1 pulse 0 1m 10p 10p
.plot tran v(1)
.tran 10n 1u
.exec
set cval="1n"
.endc
.control
run
.endc
When run with the -b option, there is no ``batch mode'' output. Further, if the -r option was used to generate a plot data file, the file would not be created. The presence of an analysis command (``run'') in the .control block inhibits the ``batch mode'' behavior. The analysis was run, but we forgot to save any data. One must add an explicit write command to save vectors to a file for later review. One could also add print and plot commands. Since there is no graphics, the plot command reverts to the asciiplot as used in batch mode output, so is not of much value. Note that the plot command and .plot control line have similar but different syntax, one should avoid confusing the two.
Again, our example is trivial, but the .control block can implement complex procedures and run sequences, provide post-simulation data manipulation, and perform other tasks.
At the start of every analysis command execution, the circuit is reset, meaning that the input is re-parsed. This will not happen with the first analysis command found in a .control block, as the circuit is already effectively in the reset state. However, on subsequent analysis commands, the .exec block will be re-executed, and the circuit will be re-parsed. Chances are, if we are running more than one simulation, we would like to change the parameter value. Consider the example:
* RC Test
R1 1 0 1k
c1 1 0 $cval
i1 0 1 pulse 0 1m 10p 10p
.tran 10n 1u
.exec
if $?cval = 0
set cval="1n"
endif
.endc
.control
run
write out1n.csdf
set cval="2n"
run
write out2n.csdf
.endc
We are now running two transient analyses, with different capacitance values. The first change is within the .exec block. The set command will be applied only if the cval variable is unset, i.e., it will be set once only, when the file is first read. Instead, ahead of the second run command in the .control block, we use the set command to provide a new value for cval. This will update the circuit as the circuit is re-parsed in the second run command. Without the change to the .exec block, the evaluation of the .exec block in the second run command would override our new cval value.