Between the creation of the Pythia object and the 
init call for it, you may use several alternative 
methods to modify some of the default values. The same variable 
can be changed several times. If so, it is the last read value 
that counts. The two special 
";?>Tune:ee and 
";?>Tune:pp modes and the 
";?>Print:quiet flag 
are expanded to change several settings in one go, but these obey 
the same ordering rules. 
 
 
a) Inside your main program you can directly set values with 
 
    pythia.readString(string) 
 
where both the variable name and the value are contained inside 
the character string, separated by blanks and/or a =, e.g. 
 
    pythia.readString("TimeShower:pTmin = 1.0"); 
 
The match of the name to the database is case-insensitive. Names 
that do not match an existing variable are ignored. A warning is 
printed, however. Strings beginning with a non-alphanumeric character, 
like # or !, are assumed to be comments and are not processed at all. 
Values below the minimum or above the maximum are set at 
the respective border. In extreme cases, where it is necessary to 
go outside the allowed range, "FORCE=" can replace 
the normal "=" separator to force the requested value, 
at own responsibility. For bool values, the following 
notation may be used interchangeably: 
true = on = yes = ok = 1, while everything else gives 
false (including but not limited to 
false, off, no and 0).
 
 
 
b) The Pythia readString(string) method 
actually does not do changes itself, but sends on the string either 
to the Settings class or to ParticleData. 
The former holds if the string begins with a letter, the latter 
if it begins with a digit. (The exception is if an input list has been 
begun by an open brace { but no matching close brace } was present; 
then all subsequent non-empty input is directed to Settings 
until the close brace is found.) If desired, it is possible to communicate 
directly with the corresponding Settings method: 
 
    pythia.settings.readString("TimeShower:pTmin = 1.0"); 
 
In this case, changes intended for ParticleData 
would not be understood. 
 
 
c) Underlying the settings.readString(string) method are 
the settings-type-sensitive commands in the Settings, that 
are split by names containing flag, mode, 
parm or word. Thus, the example now reads 
 
    pythia.settings.parm("TimeShower:pTmin", 1.0); 
 
Such a form could be convenient e.g. if a parameter is calculated 
at the beginning of the main program, and thus is available as a 
variable rather than as a character string. 
Note that Boolean values must here be given as true or 
false i.e. there is less flexibility than with the 
previous methods. 
 
 
At the same level, there are several different methods available. 
These are included in the full description below, but normally the user 
should have no need for them. 
 
 
d) A simpler and more useful way is to collect all your changes 
in a separate file, with one line per change, e.g. 
 
    TimeShower:pTmin = 1.0 
 
Each line is read in as a string and processed with the methods already 
introduced. 
 
The file can be read by the 
 
    pythia.readFile(fileName); 
 
method (or an istream instead of a fileName). 
The file can freely mix commands to the Settings and 
ParticleData classes, and so is preferable. Lines with 
settings are handled by calls to the 
pythia.settings.readString(string) method. 
 
 
A file can make use of two extra features that are not available with the 
readString(...) method. One is the possibility to provide 
information for several distinct ";?>subruns. 
The other is the possibility to comment out a section of lines in the file. 
The first line of the commented section should then begin by /* 
and the last begin by */. This is reminiscent of the convention 
used in C++ and other languages, but is not as powerful, in that it is not 
possible to comment in or out parts of lines. It is only the first two 
non-blank characters of a line that are checked for a match, and a line 
beginning with */ is counted as part of the commented section. 
To avoid mistakes it is best to keep /* and */ 
on lines of their own, optionally followed by comments, but not by commands.