The options above embody the default setup when using mcxassemble. There are many more options which mostly provide subtly different ways of doing input/output, set warning levels, or regulate how repeated entries and vectors should be treated. The full list of options is shown below. Read enables easy matrix creation from an intermediate raw matrix format that can easily be constructed from a one-pass-parse of cooccurrence data. The basic setup is as follows. When done, write out required header and domain information to a separate file. The domain information can be built during the parsing stage. for more information. The domain information in the header file will be used to pre-construct a skeleton matrix and to validate the entries in the raw data file as they fill the skeleton matrix. . Simply put, no header specification, no domain specification, and no matrix introduction syntax is used. The file just contains a listing of vectors. An example fragment is the following: The listing of vectors need not be sorted, and neither does a vector itself need to be sorted – the mcl generic matrix format is actually not different in this respect. Furthermore, duplicate entries and duplicate vectors are allowed. This is in fact again allowed in the generic format, except that where applications expect generic format warnings will be issued and duplicate entries will be disregarded. do have to match the domains specified in the header file. The leading index that specifies the column index has to be present in the column domain, all subsequent indices that specify column entries have to be present in the row domain. Such a matrix is used to relabel the nodes as found in the raw data. A situation that might occur when parsing some external format (and producing raw matrix format), is that ID’s (indices) are handed out on the fly during the parse. Afterwards, one may want to relabel the IDs such that they correspond with an alphabetic listing of the quantity that is represented by the node domain, or by some other sort criterion. A map file is then typically generated by the parser, as that is the utility in charge of the IDs. A small example of a map file for a graph containing five nodes is the following: (mclheader mcltype matrix dimensions 5×5 ) (mclmatrix begin 0 4 $ # mno 1 2 $ # ghi 2 1 $ # def 3 3 $ # jkl 4 0 $ # abc ) This corresponds to a relabeling such that the associated strings will be ordered alphabetically. Note that comments can be used to link string identifiers with indices. This map file says e.g. that the string identifier ‘mno’ is represented by index 0 in the raw data, and by index 4 in the matrix output by Explicitly specify the header file and the data file (rather than constructing the file names from a base name and suffixes). and its siblings are used to explicitly specify the map file to be used, rather than combining a base name with a fixed suffix. Options for writing matrices other than the default symmetrized result. The primary result matrix is the matrix constructed from reading in the raw data and adding entries to the skeleton matrix as specified with the to read both the header information and the raw data from the same file, where the syntax should be fully conforming to generic mcl matrix format. The first applies its transformation spec to the values as found in the raw data. The second applies its transformation spec to the primary matrix. The third applies its transformation step to the symmetrified matrix. Refer to Merge options, dictating the behaviour when repeated entries are found. A distinction is made between entries that are repeated within the same column listing, and entries that are repeated between different column listings. An entry can be a repeat of both kinds simultaneously as well. Additionally, the final result is by default symmetrized by combining with the mirror image (in matrix terminology, the 0 1:120 2:60 3:20 4:70 $ # first (transformed) vector 0 1:60 2:80 4:40 $ # second vector 0 1:120 2:80 3:20 4:70 $ # entry wise maximum Source.