Input script

In this book, input scripts for running the various programs are set in a typewriter typeface. Unless a script is marked as a continuation of the previous script, you should start the program anew or type reset to clear your previous configuration. 

The SPECE8 input script below describes the analysis of a hypothetical ground-water, assuming equilibrium with ferric hydroxide and a soil gas in which fco2 = 10-2. In the script, we decouple a number of redox pairs so that we can constrain the amounts of several elements in two or more redox states. 

The exchange capacity (the total number of sites, and therefore the maximum amount of adsorbed Ca) in moles (0.01) is given in the input script. The script shown in Table 7.5 is taken from the User s Guide, substituting our new file name for the modified surface data. Because we want to use a number of different Ca concentrations, we must modify the script and run it repeatedly. 

Table 11.1. Input script for program react, to model the dissolution of albite.

LAMMPS [225] is a classical MD program implementing potentials for soft materials (biomolecules, polymers), solid-state materials (metals, semiconductors), and coarse-grained or mesoscopic systems. The code is designed to be easy to modify or extend with new functionalities. The comprehensive manual compensates for the somewhat clumsy input script syntax. Most of its model potentials have been parallelized and run on systems with multiple CPUs and GPUs, granting very good speedups, especially for the most compUcated pair potential styles, like the Gay-Beme and other CG potentials. 

The calculation setup screens list a good selection of the options that are most widely used. However, it is not a complete list. The user also chooses which queue to use on the remote machine and can set queue resource limits. All of this is turned into a script with queue commands and the job input file. The user can edit this script manually before it is run. Once the job is submitted, the inputs are transferred to the server machine, the job is run and the results can be sent back to the local machine. The server can be configured to work with an NQS queue system. The system administrator and users have a reasonable amount of control in configuring how the jobs are run and where files are stored. The administrator should look carefully at this configuration and must consider where results will be sent in the case of a failed job or network outage. 

The ASCII input file includes elements of a scripting language. Thus, the input can contain variables, loops, and procedures. This is one of the aspects of the program that makes it possible to do very complex calculations. The documentation describes the input options, but does not discuss when and why they should be used. The user must have a solid understanding of ah initio theory in order to correctly utilize many of the functions in this program. It is very powerful, but not for beginners. 

There is a screen to set up the calculation that has menus for the most widely used functions. Many users will still need to know many of the keywords, which can be typed in. There was no default comment statement, so the input file created would not be valid if the user forgot to include a comment. A calculation can be started from the graphic interface, which will be run interactively by default. The script that launches the calculation was not too dilficult to modify for use with a job-queueing system. 

Examples of test data sets available (e.g., test scripts or automated test tools that would be suitable for version purchased) Boundary/stress/unexpected input tests Structural/functional testing (documentation of walkthroughs, etc.)... 

I chose to use this software for reasons that extend beyond familiarity and prejudice the programs are interactive and take simple commands as input. As such, I can include within the text of this book scripts that in a few lines show the precise steps taken to calculate each result. Readers can, of course, reproduce the calculations by using any of a number of other modeling programs, such as those listed in Appendix 1. Following the steps shown in the text, they should be able to construct input in the format recognized by the chosen program. 

Test plans, procedures, scripts/specifications, input, and output data, and test reports are... 

For each step of the test script, the item tested, the input to that step, and the expected... 

Figure 6.1. DynaFit start windows. After loading script file, the program automatically inputs data file and plots raw data in the graphic window. Start the analysis (File->Run ) upon receiving Ready to run instruction in the status window.

Standardized directory structures for source code, documentation hies, hnal executables, conhguration hies, and model inputs/outputs allow tracking the software development process and also help in easily integrating multiple, independently developed modules. Standardized directory structures allow easy detection of con-hicts in the names of functions, scripts, or conhguration hies. 

The NONMEM control hie for parameter estimation is provided in Appendix 12.5. The UNIX script provided in Appendix 12.6 creates a set of estimation hies that are identical, except for the name of the input datable. One set of NONMEM... 

Rule scripts operate on substances defined in a data file in either SMILES (simplified molecular input line entry specification) or CMP (compound) format. The conventional SMILES notation as developed by Weininger [28] provides a basic description of molecules in terms of two-dimensional chemical graphs. The CMP file format developed with the OASIS system [29] provides separate logical records for information about connectivity, three-dimensional structure, electronic structure from quantum-chemical molecular-orbital computations, as well as physicochemical and experimental toxicological data. 

Below a Matlab script implementing the tensor-product QMOM for a simple bivariate case described in this section is reported. The required inputs are the number of nodes for the first (Nl) and for the second (N2) internal coordinates. Since in the formulation described above the moments used for the calculation of the quadrature approximation are defined by the method itself, no exponent matrix is needed. The moments used are passed though a matrix variable m, whose elements are defined by two indices. The first one indicates the order of the moments with respect to the first internal coordinates (index 1 for moment 0, index 2 for moment order 1, etc.), whereas the second one is for the order of the moments with respect to the second internal coordinate. The final matrix is very similar to that reported in Table 3.8. The script returns the quadrature approximation in the usual form the weights are stored in the weight vector w of size N = Mi M2, whereas the nodes are stored in a matrix with two rows (corresponding to the first and second internal coordinate) and M = M1M2 columns (corresponding to the different nodes). 

With SDB and GFF files for each genome in hand, we are now ready to generate the input files for Mercator. The easiest way to do this is with the makeMercatorlnput script (Mercator distribution). We simply supply the names of the assemblies as arguments to this script. The makeMercatorlnput script will look in the current directory for each genome s SDB and GFF file. See Note 4 for information regarding custom jobs with or without makeMercatorlnput. 

With the input for MAVID generated, all that is left is to run MAVID on the sequences for each orthologous segment set. Each segment set is stored in a separate subdirectory. This is a good step at which to parallelize, but if that is not an option, the mavidAlignDirs script (Mercator distribution) can be used. See Note 9 for details on the nucleotide-level alignment step. 

Generating input for Mercator. For custom jobs (e.g., to parallelize some tasks), you may wish to generate the input for Mercator without using the makeMercatorlnput script. In such cases, consult the README file in the Mercator distribution for exact specifications of the various input files that are required. Some routines of makeMercatorlnput are customizable via command-line options. Use the —help option to get full usage information. 

Note that the script deduces from the input -mer lists (e.g., 7mer scores. txt) whether gaps should be used or not. Also, mRNA analyses are conducted according to Note 6. 

Before running a QRNA search, the BLAST output file must be converted to a QRNA input file. To do this, drag and drop the blastn2qrnadepth.pl Perl file from the scripts directory followed by the BLAST output file (see Note 10) into the terminal window. These Perl scripts will create three new files in the scripts directory. The file with .q extension will serve as the input file for QRNA. 

To run QRNA, drag and drop the icon of the QRNA Unix executable (located in the src directory) into the terminal window. Next, assign values for the window (-w) and slide (-x) parameters (see Note 11) and a name for the output file (-o). Finally, drag and drop the QRNA input file located in the scripts directory. Be aware that, depending on the size of the input file and the window and slide values, QRNA analysis may take many hours to be completed. 

---