PianaApi
index
../../../../piana/code/PianaApi/PianaApi.py

 File       : PianaApi.py
 Author     : R. Aragues
 Creation   : 17.03.2005
 Contents   : class that acts as an interface to all piana commands
 Called from: piana.py and web interface to PIANA
 
=======================================================================================================
 
If you simply want to use PIANA as a library for protein-protein interaction networks, this class
provides you with methods that execute a number of useful commands.
 
For example, you would something like this :
 
# 1. get from user strings describing the database, the host, mysql user and mysql password
 
piana_dbname= "pianaDB_limited"
piana_dbhost= "localhost"
piana_dbuser= None
piana_dbpass= None
piana_dbport= None
 
# 2. create the piana api object
piana_api = PianaApi(piana_dbname=piana_dbname, piana_dbhost= piana_dbhost, piana_dbuser=piana_dbuser, piana_dbpass= piana_dbpass)
 
# 3. create a network from a list of proteins
 
#  3.1 get from user the file name, type of code used, depth desired, tax id, hub threshold, source dbs to use and methods to use
file_name = "dummy_file.txt"
this_file_id_type = "geneName"  # any type of identifier accepted by PIANA (do python piana.py --help for info on how to know
                                     # types of identifiers accepted by your PIANA database
this_file_depth = 2
this_file_hub_threshold = 0
list_source_dbs= ["dip", "string"]
inverse_dbs= "no"
list_source_methods= ["y2h", "coip"]
inverse_methods= "no"
 
# 3.2 make the call to piana_api to add proteins in a file to the network
#    --> this will search for interactions in the database for those proteins
#        and create a network
 
piana_api.add_file_proteins_to_piana_graph(file_object= file(file_name,"r"),
                                           id_type= this_file_id_type,
                                           tax_id_value= this_file_tax_id,
                                           depth = this_file_depth,
                                           hub_threshold= this_file_hub_threshold,
                                           use_self_ints=use_self_ints,
                                           list_source_dbs= list_source_dbs,
                                           inverse_dbs= inverse_dbs,
                                           list_source_methods= list_source_methods,
                                           inverse_methods= inverse_methods )
 
# You could now continue calling commands from piana_api.*

 
Modules
       
Bio
GOApi
MySQLdb
PianaGlobals
copy
getopt
numarray
os
piana_configuration_parameters
random
re
readline
sys
time
types
utilities

 
Classes
       
__builtin__.object
PianaApi

 
class PianaApi(__builtin__.object)
    class that acts as an interface to all piana commands
 
  Methods defined here:
__init__(self, piana_dbname=None, piana_dbhost=None, piana_dbuser=None, piana_dbpass=None, piana_dbport=None, use_secondary_db='no', network_name='name', memory_mode='memory')
Creates your PIANA API object that you will then use to work with PIANA.
 
"piana_dbname", "piana_dbhost", "piana_dbuser", "piana_dbpass" and "piana_dbport"are the parameters that are going to be used to create a
connection to the MySQL PIANA database
 
"use_secondary_db" must be set to 'yes' if you want PIANA to look for interactions in a secondary database in case it 
does not find any in the primary database (the one that you have set with the above parameters).
     -> a detailed description of use_secondary_db can be read on piana/code/execs/conf_files/general_template.piana_conf
     -> if you set this parameter to 'yes', the behaviour described above will be applied to all proteins that you add
        to your network
        -> even if you set this parameter to 'no', you can still use the secondary PIANA database for specific proteins using
        argument force_secondary_db in PianaApi methods add_protein_to_piana_graph and add_proteins_file_to_piana_graph
     -> the secondary PIANA database that will be used is the one specified on piana/code/utilities/piana_configuration_parameters.py
 
 "memory_mode" is the flag that tells how to manage memory. It can be:
              "memory" Edge objects and Edge Attributes will be stored in memory. It takes more memory, but it is faster. So, memory usage will be high
              "speed" Edge Objects will not be stored in memory: they will be generated on the flight when are needed. So, speed will be decreased but memory usage will decrease considerably
add_file_interactions_to_piana_graph(self, file_object, id_type)
Adds interactions from a file to current piana_graph
 (adds only those interactions described in the file. This command doesn't search for interactions in the database for these proteins.)
 (this is not inserting the interactions into the piana database: it is just adding it to the current network)
 
"file_object" is a file object describing one interaction per line
 
    --> The interactions file follows the format (set unknown values to None):
 
    protein_a<TAB>protein_b<TAB>source_database<TAB>detection_method<TAB>confidence_score
 
    for example, a line could be:
 
    HOG1    MOT1   None    y2h   None
 
 
    This format is described in detail in file piana/code/dbParsers/piana_text_intParser/README.piana_interaction_data_format
 
 
"id_type" is the type of code used for protein protein_code
add_file_proteins_to_piana_graph(self, file_object, id_type, tax_id_value, depth, hub_threshold, use_self_ints='yes', list_source_dbs='all', inverse_dbs='no', list_source_methods='all', inverse_methods='no', force_secondary_db='no')
Adds proteins and their interactions to current piana_graph. Proteins to add are in file "file_object"
 
"file_object" is a file object pointing to a file that contains one protein per line
 
"id_type" is the type of code used for protein protein_code
 
"tax_id_value" sets the species of the proteins that are being added (can be used for eliminating ambiguities between codes across species)
   --> valid species names are 0 (do not take into account the species) and those taxonomy ids provided by ncbi taxonomy
 
"depth" fixes the depth at which interactions will be added (eg. depth 2 will add parters of partners of protein protein_code)
 
"use_self_ints" is used to avoid adding self interactions in the network
              -> 'yes' adds all interactions
              -> 'no' doesn't add interactions between a protein and itself
 
 
"hub_threshold" sets the maximum number of interactions a protein can have for it to be added to the piana_graph
   -> 0 is equivalent to not applying any hub threshold
 
"list_source_dbs" sets the interaction databases that will be used to get interactions when building the piana_graph
   -> can be a list of dbs (eg ["dip", "string"]) or "all" (all source dbs used)
 
"inverse_dbs" can be:
               no (databases in list_source_dbs will be used to build the network)
               yes (all databases except those in list_source_dbs will be used to build the network)
 
"list_source_methods" sets the methods that will be used to get interactions when building the piana_graph
   -> can be a list of methods (eg ["y2h", "tap"]) or "all" (all methods used)
 
"inverse_methods" can be:
               no (methods in list_source_methods will be used to build the network)
               yes (all methods except those in list_source_methods will be used to build the network)
 
"force_secondary_db" can be:
        no (use standard piana database to retrieve interactions for this protein)
        yes (use the secondary piana database described in piana/code/utilities/piana_configuration_parameters.py)
add_interaction_to_piana_graph(self, protein_a, protein_b, id_type, source_db=None, method=None, confidence=1)
Adds one interaction between protein_a and protein_b to current piana_graph
 (adds only this interaction. This command doesn't search for interactions in the database for these proteins.)
 (this is not inserting the interaction into the piana database: it is just adding it to the current network)
 
"source_db" is the database from which  you have obtained the interaction
    --> set it to None if this is not relevant for your analysis
    --> set it to 'user' if you want to label it as 'added by user' (will appear in yellow)
    
"method" is the method you have used to detect the interaction
    --> set it to None if this is not relevant for your analysis
    
"confidence" is not currently being used... set it to 1
 
"id_type" is the type of code used for protein protein_codes protein_a and protein_b (it has to be the same for both)
add_protein_to_piana_graph(self, protein_code, id_type, tax_id_value, depth, hub_threshold, use_self_ints='yes', list_source_dbs='all', inverse_dbs='no', list_source_methods='all', inverse_methods='no', force_secondary_db='no')
Adds one protein and its interactions to current piana_graph.
 
 
"protein_code" is a string with the protein code (must be of type id_type)
 
"id_type" is the type of code used for protein protein_code
 
"tax_id_value" sets the species of the protein that is being added (can be used for eliminating ambiguities between codes across species)
   --> valid tax ids are 0 (do not take into account the species) and those taxonomy ids provided by ncbi taxonomy
 
"depth" fixes the depth at which interactions will be added (eg. depth 2 will add parters of partners of protein protein_code)
 
"use_self_ints" is used to avoid adding self interactions in the network
              -> 'yes' adds all interactions
              -> 'no' doesn't add interactions between a protein and itself
 
"hub_threshold" sets the maximum number of interactions a protein can have for it to be added to the piana_graph
   -> 0 is equivalent to not applying any hub threshold
 
"list_source_dbs" sets the interaction databases that will be used to get interactions when building the piana_graph
   -> can be a list of dbs (eg ["dip", "string"]) or "all" (all source dbs used)
 
"inverse_dbs" can be:
               no (databases in list_source_dbs will be used to build the network)
               yes (all databases except those in list_source_dbs will be used to build the network)
 
"list_source_methods" sets the methods that will be used to get interactions when building the piana_graph
   -> can be a list of methods (eg ["y2h", "tap"]) or "all" (all methods used)
 
"inverse_methods" can be:
        no (methods in list_source_methods will be used to build the network)
        yes (all methods except those in list_source_methods will be used to build the network)
 
"force_secondary_db" can be:
        no (use standard piana database to retrieve interactions for this protein)
        yes (use the secondary piana database described in piana/code/utilities/piana_configuration_parameters.py)
create_database_method_piana_graph(self, tax_id_value=0, use_self_ints='yes', list_source_dbs='all', inverse_dbs='no', list_source_methods='all', inverse_methods='no')
Replaces current piana_graph with the interaction piana_graph for a given list of databases and methods
(ie. adds all interactions that appear in databases list_source_dbs that are of a method that appear in list_source_methods)
 
"tax_id_value" is the species for which the piana_graph will be built
   --> valid tax ids are 0 (do not take into account the species) and those taxonomy ids provided by ncbi taxonomy
 
 
"use_self_ints" is used to avoid adding self interactions in the network
              -> 'yes' adds all interactions
              -> 'no' doesn't add interactions between a protein and itself
              
"list_source_dbs" sets the interaction databases that will be used to get interactions when building the piana_graph
   -> can be a list of dbs (eg ["dip", "string"]) or "all" (all source dbs used)
 
"inverse_dbs" can be:
               no (databases in list_source_dbs will be used to build the network)
               yes (all databases except those in list_source_dbs will be used to build the network)
 
"list_source_methods" sets the methods that will be used to get interactions when building the piana_graph
   -> can be a list of methods (eg ["y2h", "tap"]) or "all" (all methods used)
 
"inverse_methods" can be:
               no (methods in list_source_methods will be used to build the network)
               yes (all methods except those in list_source_methods will be used to build the network)
 
Note: no depth argument is needed, since we are adding all interactions that respect a certain criteria
create_go_clustered_network(self, output_target=None, term_type=None, score_threshold=None, sim_mode=None, level_threshold=None, distance_threshold=None, rep_term=None, print_id=None)
Creates a network of GO (Gene Ontology) terms from the piana graph
Then, clusters the Go network using parameters provided
Finally,  prints the clustered go network 
 
"output_target" is the file object where the clustered network in DOT format will be printed
 
 
- "term_type" sets the kind of GO terms that will be used for the clustering.
  -> term-type can be "molecular_function", "biological_process" or "cellular_component"
 
- "score_threshold" is the lowest score obtained by the similarity function allowed for continuing the clustering
  -> can be any real number from 0 to 100 (0 will group all proteins, 100 will not group any proteins). To obtain a relevant clustered network
     use score thresholds between 0.1 and 1
 
- "sim_mode" sets how to calculate distances between two clusters
   - "random" takes a random element from each cluster and evaluates similarity between them
   - "min" takes the minimal distance between elements of each cluster
   - "max" takes the maximal distance between elements of each cluster
   - "average" takes the average distance between all elements of each cluster
 
- "level_threshold" is the lowest level of the go term in the cluster allowed for continuing the clustering
   -> GO is a hierarchy organized from a initial root level (ie. 0) that increasingly makes more specific the terms. 
      Therefore, the higher the level used the less clustering will be performed. To obtain a relevant clustered network 
      use level thresholds between 1 and 3. It all depends on how general you want to be in the interpretation of the network.
 
- "distance_threshold" is the maximum distance allowed between two proteins in order to be clustered
   -> can be any integer between 1 and ...
 
- "rep_term" sets which of the GO terms of the cluster will be used for printing output
   -> can be min (term of minimal depth in the hierarchy) or max (maximal depth)
 
- "print_id" sets which id will be used for identifying the clusters in the printed output
   -> can be "no" (default id: go term name) or "yes" (a more complex id)
create_species_piana_graph(self, species_name=None, tax_id=None, hub_threshold=0, use_self_ints='yes', list_source_dbs='all', inverse_dbs='no', list_source_methods='all', inverse_methods='no')
Replaces current piana_graph with the protein-protein interaction piana_graph for a given species (using all proteins)
 
The user can fix the species using a tax id or a species name (don't use both at the same time):
    "taxonomy_id" is the tax id for which the piana_graph will be built (set it to None if not using it)
       -> has to be a valid tax id (eg. 9606; ...)
 
    "species_name" is the species for which the piana_graph will be built (set it to None if not using it)
       -> has to be the name of a species (e.g "human", "yeast", ...)
 
  --> in case both species_name_value and taxonomy_value are set to something different from None, taxonomy_value is used
 
"hub_threshold" sets the maximum number of interactions a protein can have for it to be added to the piana_graph
   -> 0 is equivalent to not applying any hub threshold
 
 
"use_self_ints" is used to avoid adding self interactions in the network
              -> 'yes' adds all interactions
              -> 'no' doesn't add interactions between a protein and itself
              
"list_source_dbs" sets the interaction databases that will be used to get interactions when building the piana_graph
   -> can be a list of dbs (eg ["dip", "string"]) or "all" (all source dbs used)
 
"inverse_dbs" can be:
               no (databases in list_source_dbs will be used to build the network)
               yes (all databases except those in list_source_dbs will be used to build the network)
 
"list_source_methods" sets the methods that will be used to get interactions when building the piana_graph
   -> can be a list of methods (eg ["y2h", "tap"]) or "all" (all methods used)
 
"inverse_methods" can be:
               no (methods in list_source_methods will be used to build the network)
               yes (all methods except those in list_source_methods will be used to build the network)
 
 
Note: no depth argument is needed, since we are adding all interactions for all proteins of a given species
do_imotif_clustering(self, similarity_mode, minimum_score, imotif_mode, num_ints_thres, common_ints_thres, global_map, results_prefix, results_dir, use_self_ints, list_source_dbs, inverse_dbs, list_source_methods, inverse_methods, hub_threshold, input_id_type, input_tax_id)
perform imotif clustering
 
a detailed description of this arguments can be read on piana/code/execs/conf_files/general_template.piana_conf
expand_piana_graph_interactions(self, expansion_type, expansion_mode, expansion_threshold, hub_threshold, exp_output_mode, output_file_object, id_type, alternative_id_types, output_tax_id, use_self_ints='yes', list_source_dbs='all', inverse_dbs='no', list_source_methods='all', inverse_methods='no')
Expands interactions in the current piana_graph by propagating interactions to nodes "expansion_mode" from all nodes that
have a common characteristic "expansion_type"
 
"expansion_type" defines the characteristic that is used to propagate interactions between nodes
    -> valid expansion-type values are those defined in PianaGlobals.expansion_types (currently can be cog, scop (ie. scop family), interpro or ec)
    -> if two proteins share expansion-type, interactions are interpropagated
 
"expansion_mode" defines to which nodes we will propagate the interactions to
     -> valid expansion-nodes values are: all (all proteins in piana_graph are expanded) or root (only root proteins are expanded)
     -> if you are looking for new interactions (predictions) for your input proteins, use root
     -> if you want to expand all the proteins in the piana_graph (partners of root proteins as well) use all
     -> root proteins are the source proteins used to build the piana_graph
 
"expansion_threshold" is used to avoid propagating interactions when there are too many nodes that share the expansion type
     -> valid values are: 0 (no thresholds applied) and positive integers
 
"hub_threshold" sets the maximum number of interactions a protein can have for it to be added to the piana_graph
   -> 0 is equivalent to not applying any hub threshold
 
 
"use_self_ints" is used to avoid adding self interactions in the network
              -> 'yes' adds all interactions
              -> 'no' doesn't add interactions between a protein and itself
              
"list_source_dbs" sets the interaction databases that will be used to get interactions when building the piana_graph
   -> can be a list of dbs (eg ["dip", "string"]) or "all" (all source dbs used)
 
"inverse_dbs" can be:
               no (databases in list_source_dbs will be used to build the network)
               yes (all databases except those in list_source_dbs will be used to build the network)
 
"list_source_methods" sets the methods that will be used to get interactions when building the piana_graph
   -> can be a list of methods (eg ["y2h", "tap"]) or "all" (all methods used)
 
"inverse_methods" can be:
               no (methods in list_source_methods will be used to build the network)
               yes (all methods except those in list_source_methods will be used to build the network)
 
 
"exp_output_mode" sets whether new interactions are added to the piana_graph or printed to an output file
 
   -> valid exp-output-mode values are: add (add predictions to piana_graph) and print (print to output-target)
      -> 'add' will add to the piana_graph the predictions found by expansion
      -> 'print' will print to output-target (or to default results file) the list of predictions found by expansion
   -> for example, if you wanted to get predictions for root nodes using double cog expansion
      you would first use command expand-interactions with expansion-nodes=all and mode=add
      and then, another command expand-interactions with expansion-nodes=root and mode=print
      doing this "double expansion" you will be predicting interactions based on a previous expansion
 
   - if exp-output-mode is add, the following arguments can be ignored: leave them to blank:
   - if exp-output-mode is "print" then :
 
      -> "output_file_object" is the file object where the interactions will be printed
 
 
      -> "output_tax_id" restricts the species of proteins in the interactions that will be printed
           --> valid tax ids are 0 (do not take into account the species) and those taxonomy ids provided by ncbi taxonomy
           
      -> "id_type" is the type of code that should be used for printing proteins identifiers
           -> valid protein-type values are those defined in PianaGlobals.valid_protein_ids
 
      -> the results will follow the following format (one interaction per line):
 
         protein1<TAB>protein2<TAB>expansion_type<TAB>source_interactionPiana<TAB>source_proteinPiana
get_external_databases_in_pianaDB(self, database_type)
returns the names of external databases that have been integrated into the PIANA databases associated to this PianaApi
 
"database_type" specifies which type of external databases will be returned
    -> valid values for database_type are:
         - "all"
         - "protein sequences"
         - "protein attributes"
         - "protein-protein interactions"
         - "identifiers cross-references"
get_one_tax_id_from_species_name(self, species_name=None)
returns the tax id associated to "species_name"
 
If there are more than one tax id associated, raises an error (to avoid ambiguities)
 
If there is no tax id associated to it, raises an error (to avoid using a name that doesn't exist)
get_random_protein_dic(self, tax_id_value, dic_size, id_type, alternative_id_types=[], force_ints='yes', use_self_ints='yes', list_source_dbs='all', inverse_dbs='no', list_source_methods='all', inverse_methods='no', file_over_expressed=None, file_infra_expressed=None, expression_id_type=None, dic_special_proteins_file=None)
returns a dic with random proteins (of size "dic_size") from species "tax_id_value"
 
     {  protein1:{'expression':expression_value, 'labels':[label1, label2, ...]},
        protein2: ....
     }
 
the type of identifier used for the proteins will be id_type (or alternative_id_types)
 
if "force_ints" is yes, it only returns proteins if they have known interactions.
    --> if set to "yes", then you must set all parameters associated to interactions
 
 
expression_values will be inserted only if the following expression arguments are set:
 
   "file_over_expressed" and "file_infra_expressed" are names of files that contain proteins that are either over expressed or infra expressed
   "expression_id_type" is the type of protein code used in files file_over_expressed and file_infra_expressed
 
 
labels will be inserted only if argument dic_special_proteins_file is set
 
"dic_special_proteins_file" is a dictionary used to highligth special proteins in your results files
                            follows structure:   { label1: (id_type1, path_to_file1),
                                                   label2: (id_type2, path_to_file2),
                                                   ...............
                                                 }
load_piana_graph(self, file_object)
loads a previously saved piana_graph into the current piana_graph (ie replaces current piana_graph by the one in file_object)
 
file_object must have been opened using binary read (ie file_object= file(file_name, "rb") )
print_all_proteins_information(self, id_type, output_file_object, output_mode='compact', format_mode='txt', alternative_id_types=[], tax_id_value=0, list_keywords=[], file_over_expressed=None, file_infra_expressed=None, expression_id_type=None, dic_special_proteins_file=None)
Prints information about all the proteins in the current piana_graph
 
"id_type" is the type of code that should be used for printing proteins identifiers
     -> valid protein-type values are those defined in the PIANA reference card (see README.piana_tutorial)
 
"output_file_object" is the file object (sys.stdout to print to screen) where interactions will be printed
 
"output_mode" can be:
   - 'compact': all relevant information in one line
   - 'extended': all information in text paragraphs
    
"format_mode" sets the type of format that will be used for output
       - 'txt' will print flat text
       - 'html' will print html 
 
"alternative_id_types" can be used to set a list of alternative types in case no id_type code is found
   --> user must provide a list of valid easy-to-remember type names
   alternative_id_types can for example look like this: ["gi", "uniacc", "md5"]
   I suggest always placing md5 at the end of alternative types, so you never get a None in the output
   
"tax_id_value" determines which species must be the proteins that will be printed
   --> valid tax ids are 0 (do not take into account the species) and those taxonomy ids provided by ncbi taxonomy
   
 
"list_keywords" sets a list of keywords that will be used to highlight important proteins in the network
   -> currently, it doesn't do anything
   
"file_over_expressed" and "file_infra_expressed" are names of files that contain proteins that are either over expressed or infra expressed
 
"expression_id_type" is the type of protein code used in files file_over_expressed and file_infra_expressed
 
"dic_special_proteins_file" is a dictionary used to highligth special proteins in your results files
                            follows structure:   { label1: (id_type1, path_to_file1),
                                                   label2: (id_type2, path_to_file2),
                                                   ...............
                                                 }
print_all_proteins_with_network_class(self, id_type, output_file_object, alternative_id_types=[], tax_id_value=0, file_over_expressed=None, file_infra_expressed=None, expression_id_type=None, dic_special_proteins_file={})
Prints all proteins in current piana_graph, indicating whether they are a root protein, a linker or a partner
 -> a root is a protein that was given as input by the user
 -> a linker is a protein that connects two or more root proteins
 -> a partner is a protein that is connected to just one root protein
 
"id_type" is the type of code that should be used for printing proteins identifiers
     -> valid protein-type values are those defined in the PIANA reference card (see README.piana_tutorial)
 
"output_file_object" is the file object (sys.stdout to print to screen) where interactions will be printed
    
"alternative_id_types" can be used to set a list of alternative types in case no id_type code is found
   --> user must provide a list of valid easy-to-remember type names
   alternative_id_types can for example look like this: ["gi", "uniacc", "md5"]
   I suggest always placing md5 at the end of alternative types, so you never get a None in the output
       
"tax_id_value" determines which species must be the proteins that will be printed
   --> valid tax ids are 0 (do not take into account the species) and those taxonomy ids provided by ncbi taxonomy
 
"file_over_expressed" and "file_infra_expressed" are names of files that contain proteins that are either over expressed or infra expressed
 
"expression_id_type" is the type of protein code used in files file_over_expressed and file_infra_expressed
 
"dic_special_proteins_file" is a dictionary used to highligth special proteins in your results files
                            follows structure:   { label1: (id_type1, path_to_file1),
                                                   label2: (id_type2, path_to_file2),
                                                   ...............
                                                 }
print_connecting_proteins_information(self, id_type, output_file_object, output_mode='compact', format_mode='txt', alternative_id_types=[], tax_id_value=0, list_keywords=[], file_over_expressed=None, file_infra_expressed=None, expression_id_type=None, dic_special_proteins_file=None)
Prints information about linkers in the current piana_graph
 -> a linker is a protein that connects two or more root proteins
 
"id_type" is the type of code that should be used for printing proteins identifiers
     -> valid protein-type values are those defined in the PIANA reference card (see README.piana_tutorial)
 
"output_file_object" is the file object (sys.stdout to print to screen) where interactions will be printed
 
 
"output_mode" can be:
   - 'compact': all relevant information in one line
   - 'extended': all information in text paragraphs
    
"format_mode" sets the type of format that will be used for output
       - 'txt' will print flat text
       - 'html' will print html 
    
    
"alternative_id_types" can be used to set a list of alternative types in case no id_type code is found
   --> user must provide a list of valid easy-to-remember type names
   alternative_id_types can for example look like this: ["gi", "uniacc", "md5"]
   I suggest always placing md5 at the end of alternative types, so you never get a None in the output
       
"tax_id_value" determines which species must be the proteins that will be printed
   --> valid tax ids are 0 (do not take into account the species) and those taxonomy ids provided by ncbi taxonomy
 
"list_keywords" sets a list of keywords that will be used to highlight important proteins in the network
   -> currently, it doesn't do anything
   
"file_over_expressed" and "file_infra_expressed" are names of files that contain proteins that are either over expressed or infra expressed
 
"expression_id_type" is the type of protein code used in files file_over_expressed and file_infra_expressed
 
"dic_special_proteins_file" is a dictionary used to highligth special proteins in your results files
                            follows structure:   { label1: (id_type1, path_to_file1),
                                                   label2: (id_type2, path_to_file2),
                                                   ...............
                                                 }
print_file_proteins_information(self, input_file_object, input_id_type, output_file_object, output_id_type, output_mode, format_mode='txt', list_keywords=[], alternative_id_types=[], tax_id_value=0, file_over_expressed=None, file_infra_expressed=None, expression_id_type=None, dic_special_proteins_file=None)
Prints information for all proteins in file "input_file_object"
 --> only works in compact mode to prevent the creation of enormous text files
 
"input_file_object" is the file object with the protein codes for which you want to obtain the information
 
"input_id_type" is the type of code that should be used for printing proteins identifiers
     -> valid protein-type values are those defined in the PIANA reference card (see README.piana_tutorial)
 
"output_file_object" is the file object where the protein information will be written
 
"output_id_type" is the type of code that will be used to identify proteins in the output file
     -> valid protein-type values are those defined in the PIANA reference card (see README.piana_tutorial)
 
"tax_id_value" sets the species of the protein that will be printed (can be used for eliminating ambiguities between codes across species)
   --> valid tax ids are 0 (do not take into account the species) and those taxonomy ids provided by ncbi taxonomy
   
"output_mode" can be:
   - 'extended' (multiple lines per protein to be shown directly to the screen)
   - 'compact' (one line per protein to be shown directly on the screen)
    
"format_mode" sets the type of format that will be used for output
       - 'txt' will print flat text
       - 'html' will print html 
 
"list_keywords" sets a list of keywords that will be used to highlight important proteins in the network
   -> currently, it doesn't do anything
   
"file_over_expressed" and "file_infra_expressed" are names of files that contain proteins that are either over expressed or infra expressed
 
"expression_id_type" is the type of protein code used in files file_over_expressed and file_infra_expressed
 
"dic_special_proteins_file" is a dictionary used to highligth special proteins in your results files
                            follows structure:   { label1: (id_type1, path_to_file1),
                                                   label2: (id_type2, path_to_file2),
                                                   ...............
                                                 }
print_interactions(self, id_type, output_file_object, output_format, print_mode, format_mode, alternative_id_types, tax_id_value, use_self_ints='yes', list_keywords=[], intersection_dbs=None, file_over_expressed=None, file_infra_expressed=None, expression_id_type=None, dic_special_proteins_file=None, network_attributes_prefix=None)
Prints interactions from current piana_graph in the format chosen by the user.
 
"id_type"  is the type of code that should be used for printing proteins identifiers
     -> valid protein-type values are those defined in the PIANA reference card (see README.piana_tutorial)
     
"output_file_object" is the file object (sys.stdout to print to screen) where interactions will be printed
 
"output_format" is the format that will be followed for the output
   -'table': prints interactions in table format
   -'network': prints interactions in a format that can be visualized as a network
 
"format_mode" sets the type of format that will be used for output
 
   -> valid formats for output_format 'table' are:
       - 'txt' will print flat text
       - 'html' will print html 
 
          --> format_mode 'txt' for table will print a table in the format indicated 
              in the description of command print-table-* in the template for piana 
              configuration files: piana/code/execs/conf_files/general_template.piana_conf
 
          --> format_mode 'html' produces an HTML table with the interactions and information 
              associated to them
       
   -> valid formats for output_format 'network' are:
       - 'dot': uses DOT format as defined in www.graphviz.org
       - 'sif': uses SIF format as defined in www.cytoscape.org
 
          --> format_dot will produce an output that can be then given to visualization programs
              for example, neato from GraphViz, would work by:
               $> cat output_in_dot_format | neato -Tgif -o network.gif
 
          --> format_mode 'sif' will produce an output that can be imported from cytoscape
       
 
 
"print_mode" sets which proteins will be printed
   -> "all" will print all interactions in the piana_graph
   -> "all_root" will print all interactions in the piana_graph where at least one partner is a root protein
   -> "only_root" will print only interactions between root proteins
   -> "connecting" will print only interactions between root proteins and those proteins that connect more than one root protein
 
"alternative_id_types" can be used to set a list of alternative types in case no id_type code is found
 --> user must provide a list of valid easy-to-remember type names
     alternative_id_types can for example look like this: ["gi", "uniacc", "md5"]
       -> The list of values that this list can contain can be obtained by doing python piana.py or
          looking to the PIANA reference card (see README.piana_tutorial)
 
     I suggest always placing md5 at the end of alternative types, so you never get a None in the output
 
 
"tax_id_value" determines which species must be the proteins that will be printed
   --> valid tax ids are 0 (do not take into account the species) and those taxonomy ids provided by ncbi taxonomy
 
"use_self_ints" determines if self interactions of proteins will be printed out
    --> valid values are 'yes' (i.e. print all interactions) and 'no' (i.e. do not print self interactions)
    (a self interaction is an interaction of a protein with itsel, as seen in homodimers)
 
"list_keywords" sets a list of keywords that will be used to highlight important proteins in the network
   -> currently, it highlights in red the proteins in the DOT file that contain at least one keyword in the function, description or name
   -> currently, it is not used when printing the interactions in a table
   -> If you are interested in highlighting proteins related to cancer, list_keywords could be: ['cancer', 'onco', 'carcinoma', 'tumor']
   
"intersection_dbs" sets intersection mode, which only prints out interactions that appear in all dbs of the list being passed
    -> it can be None (no intersection mode applied) or a list of database names
    -> valid database names are those indicated in the PIANA reference card (see README.piana_tutorial)
    
"file_over_expressed" and "file_infra_expressed" are names of files that contain proteins that are either over expressed or infra expressed
 
"expression_id_type" is the type of protein code used in files file_over_expressed and file_infra_expressed
 
"dic_special_proteins_file" is a dictionary used to highligth special proteins in your results files
                            follows structure:   { label1: (id_type1, path_to_file1),
                                                   label2: (id_type2, path_to_file2),
                                                   ...............
                                                 }
 
"network_attributes_prefix" is used to create files with information about the nodes and edges
    -> these files can then be used from cytoscape to visualize certain characteristics of the network, nodes and edges
print_list_proteins_information(self, protein_list, input_id_type, output_file_object, output_id_type, alternative_id_types=[], output_mode='compact', format_mode='txt', list_keywords=[], tax_id_value=0, file_over_expressed=None, file_infra_expressed=None, expression_id_type=None, dic_special_proteins_file=None)
Prints information for all proteins in list "protein_list" (does not take into account the network, only these proteins)
 --> only works in compact mode to prevent the creation of enormous text files
 
"protein_list" is the list of proteins for which you want to retrieve the information
 
"input_id_type" is the type of code of proteins in the protein list
     -> valid protein-type values are those defined in the PIANA reference card (see README.piana_tutorial)
 
"output_file_object" is the file object where the protein information will be written
 
"output_id_type" is the type of code that will be used to identify proteins in the output file
     -> valid protein-type values are those defined in the PIANA reference card (see README.piana_tutorial)
 
"tax_id_value" determines which species must be the proteins that will be printed
   --> valid tax ids are 0 (do not take into account the species) and those taxonomy ids provided by ncbi taxonomy
   
"alternative_id_types" can be used to set a list of alternative types in case no id_type code is found
   --> user must provide a list of valid easy-to-remember type names
   alternative_id_types can for example look like this: ["gi", "uniacc", "md5"]
   I suggest always placing md5 at the end of alternative types, so you never get a None in the output
   
"output_mode" can be:
   - 'extended' (multiple lines per protein to be shown directly to the screen)
   - 'compact' (one line per protein to be shown directly on the screen)
    
"format_mode" sets the type of format that will be used for output
       - 'txt' will print flat text
       - 'html' will print html 
 
"list_keywords" sets a list of keywords that will be used to highlight important proteins in the network
   -> currently, it doesn't do anything
   
"file_over_expressed" and "file_infra_expressed" are names of files that contain proteins that are either over expressed or infra expressed
 
"expression_id_type" is the type of protein code used in files file_over_expressed and file_infra_expressed
  
"dic_special_proteins_file" is a dictionary used to highligth special proteins in your results files
                            follows structure:   { label1: (id_type1, path_to_file1),
                                                   label2: (id_type2, path_to_file2),
                                                   ...............
                                                 }
print_matched_gos(self, force_expression, output_file_object, format_mode, output_id_type, tax_id, term_type, level_threshold, go_dbname, go_dbhost, go_dbuser, go_dbpass, file_over_expressed=None, file_infra_expressed=None, expression_id_type=None, dic_special_proteins_file=None)
Prints out the GO terms frequency for GO terms associated to proteins that appear in the current piana_graph
 
   --> this can be used to know which GO terms are 'involved' in the current network. For example, if you build a network for 
       proteins known to be involved in cancer, then you can check which GO terms are related to the proteins in the cancer network
 
"force_expression" can be 'yes' or 'no' and is used to know which proteins of the network will be used to match pathways
     'no': all proteins in the current network are used to match pathways
     'yes': only those proteins that are over/under expressed are used to match pathways
 
"output_file_object" is the file where the results will be printed
 
"output_id_type" is the easy-to-remember type name that will be used to print out results
  -> Valid output_id_type are those listed in the PIANA reference card (see README.piana_tutorial)
 
"format_mode" sets the type of format that will be used for output
       - 'txt' will print flat text
       - 'html' will print html 
 
"tax_id_value" sets which will be the species for the proteins translated
   --> valid tax ids are 0 (do not take into account the species) and those taxonomy ids provided by ncbi taxonomy
 
 
"term_type" sets the kind of GO terms that will be used for the clustering.
  -> term-type can be "molecular_function", "biological_process" or "cellular_component"
 
"level_threshold" is the lowest level of the go terms that will be retrieved for calculating the frequency
     -> all GO terms associated to each protein will be retrieved, then parents of those GO terms until reaching level_threshold will also be retrieved
 
     -> GO is a hierarchy organized from a initial root level (ie. 0) that increasingly makes more specific the terms. 
        Therefore, the higher the level used the more specific the GO terms will be. To obtain a relevant GO terms
        use level thresholds between 3 and 5. It all depends on how general you want to be in the interpretation of the network.
 
 "go_dbname", "go_dbhost", "go_dbuser" and "go_dbpass" are the mysql parameters for your external GO database
     -> attention! this database is different from your standard pianaDB. This is a different database that has to be created
        by following the instructions on README.populate_piana_db section "parse GO"
 
"file_over_expressed" and "file_infra_expressed" are names of files that contain proteins that are either over expressed or infra expressed
 
"expression_id_type" is the type of protein code used in files file_over_expressed and file_infra_expressed
 
"dic_special_proteins_file" is a dictionary used to highligth special proteins in your results files
                            follows structure:   { label1: (id_type1, path_to_file1),
                                                   label2: (id_type2, path_to_file2),
                                                   ...............
                                                 }
print_matched_pathways(self, pathways_dir, force_expression, output_file_object, results_dir, files_prefix, output_id_type, alternative_id_types, format_mode, pathway_id_type, tax_id, file_over_expressed=None, file_infra_expressed=None, expression_id_type=None, dic_special_proteins_file=None)
Prints out for each pathway in pathways_dir, the number of proteins in the pathway (and percentage) that appear in the current piana_graph
 
   --> this can be used to know which pathways are being 'affected' by the current network. For example, if you build a network for 
       proteins known to be involved in cancer, then you can check which pathways might be affected by the proteins in the cancer network
 
"pathways_dir" is the directory that contains pathway files
         -> a pathway file is a file that contains proteins that are known to be involved in a given pathway
         -> the pathway filename must be indicative of the pathway: that name will be used for the output
         -> all proteins in all pathway files must be in the same type of protein identifier.
            If you have pathways that use different identifiers, you must call this method as many times as id types you have
 
"force_expression" can be 'yes' or 'no' and is used to know which proteins of the network will be used to match pathways
     'no': all proteins in the current network are used to match pathways
     'yes': only those proteins that are over/under expressed are used to match pathways
 
"output_file_object" is the file where the results will be printed
 
"output_id_type" is the type of code that will be used to print proteins
     -> valid protein-type values are those defined in the PIANA reference card (see README.piana_tutorial)
 
"alternative_id_types" can be used to set a list of alternative types in case no id_type code is found
 --> user must provide a list of valid easy-to-remember type names
     alternative_id_types can for example look like this: ["gi", "uniacc", "md5"]
     I suggest always placing md5 at the end of alternative types, so you never get a None in the output
 
"pathway_id_type" is the easy-to-remember type name that has been used in the pathways files
  -> Valid pathway_type are those listed in the PIANA reference card (see README.piana_tutorial)
 
"format_mode" sets the type of format that will be used for output
       - 'txt' will print flat text
       - 'html' will print html 
 
"tax_id_value" sets which will be the species for the proteins translated
   --> valid tax ids are 0 (do not take into account the species) and those taxonomy ids provided by ncbi taxonomy
 
"file_over_expressed" and "file_infra_expressed" are names of files that contain proteins that are either over expressed or infra expressed
 
"expression_id_type" is the type of protein code used in files file_over_expressed and file_infra_expressed
 
"dic_special_proteins_file" is a dictionary used to highligth special proteins in your results files
                            follows structure:   { label1: (id_type1, path_to_file1),
                                                   label2: (id_type2, path_to_file2),
                                                   ...............
                                                 }
print_proteins_at_distance_x(self, query_protein, distance, input_id_type, output_id_type, alternative_id_types, output_file_object, format_mode, info, tax_id_value=0)
Prints to "output_file_object" proteins from the network that are at distance "distance" from the protein "query protein"
 
"query_protein" is the query protein: proteins returned will be at distance "distance" from this protein
 
"distance" is the distance at which the proteins will be searched
 
"input_id_type" is the type of code used for protein query_protein
     -> valid protein-type values are those defined in the PIANA reference card (see README.piana_tutorial)
 
"output_id_type" is the type of code that will be used to print proteins
     -> valid protein-type values are those defined in the PIANA reference card (see README.piana_tutorial)
 
"alternative_id_types" can be used to set a list of alternative types in case no id_type code is found
 --> user must provide a list of valid easy-to-remember type names
     alternative_id_types can for example look like this: ["gi", "uniacc", "md5"]
     I suggest always placing md5 at the end of alternative types, so you never get a None in the output
     
"output_file_object" is the file object (sys.stdout to print to screen) where proteins at distance X will be printed 
 
"format_mode" sets the type of format that will be used for output
       - 'txt' will print flat text
       - 'html' will print html 
 
"info" sets whether domain information associated to the proteins will be printed or not
   - 'all' will show all domain information
   - 'scop' will show SCOP domain information
   - 'cath' will show CATH domain information
   - 'no' shows no domain information
 
 
"tax_id_value" sets the species of the protein that will be printed (can be used for eliminating ambiguities between codes across species)
   --> valid tax ids are 0 (do not take into account the species) and those taxonomy ids provided by ncbi taxonomy
print_root_proteins_information(self, id_type, output_file_object, output_mode='compact', format_mode='txt', alternative_id_types=[], tax_id_value=0, list_keywords=[], file_over_expressed=None, file_infra_expressed=None, expression_id_type=None, dic_special_proteins_file=None)
Prints information about root proteins in the current piana_graph
 -> a root protein is a protein that was given by the user as input (ie. protein of interest)
 
"id_type" is the type of code that should be used for printing proteins identifiers
     -> valid protein-type values are those defined in the PIANA reference card (see README.piana_tutorial)
 
"output_file_object" is the file object (sys.stdout to print to screen) where interactions will be printed
 
 
"output_mode" can be:
   - 'compact': all relevant information in one line
   - 'extended': all information in text paragraphs
    
"format_mode" sets the type of format that will be used for output
       - 'txt' will print flat text
       - 'html' will print html 
    
    
"alternative_id_types" can be used to set a list of alternative types in case no id_type code is found
   --> user must provide a list of valid easy-to-remember type names
   alternative_id_types can for example look like this: ["gi", "uniacc", "md5"]
   I suggest always placing md5 at the end of alternative types, so you never get a None in the output
   
"tax_id_value" determines which species must be the proteins that will be printed
   --> valid tax ids are 0 (do not take into account the species) and those taxonomy ids provided by ncbi taxonomy
 
"list_keywords" sets a list of keywords that will be used to highlight important proteins in the network
   -> currently, it doesn't do anything
   
"file_over_expressed" and "file_infra_expressed" are names of files that contain proteins that are either over expressed or infra expressed
 
"expression_id_type" is the type of protein code used in files file_over_expressed and file_infra_expressed
 
"dic_special_proteins_file" is a dictionary used to highligth special proteins in your results files
                            follows structure:   { label1: (id_type1, path_to_file1),
                                                   label2: (id_type2, path_to_file2),
                                                   ...............
                                                 }
print_shortest_route(self, protein_a_name, protein_b_name, input_id_type, output_id_type, alternative_id_types, output_file_object, format_mode, tax_id_value=0)
Prints to "output_file_object" the route from "protein_a_name" to "protein_b_name"
 
 
"input_id_type" is the type of code used for protein query_protein
     -> valid protein-type values are those defined in the PIANA reference card (see README.piana_tutorial)
 
"output_id_type" is the type of code that will be used to print proteins
     -> valid protein-type values are those defined in the PIANA reference card (see README.piana_tutorial)
 
"alternative_id_types" can be used to set a list of alternative types in case no id_type code is found
 --> user must provide a list of valid easy-to-remember type names
     alternative_id_types can for example look like this: ["gi", "uniacc", "md5"]
     I suggest always placing md5 at the end of alternative types, so you never get a None in the output
     
"output_file_object"is the file object (sys.stdout to print to screen) where the route will be printed
 
 
"format_mode" sets the type of format that will be used for output (Attention! Currently not working. Output is always TXT!)
       - 'txt' will print flat text
       - 'html' will print html 
 
"tax_id_value" sets the species of the protein that will be printed (can be used for eliminating ambiguities between codes across species)
   --> valid tax ids are 0 (do not take into account the species) and those taxonomy ids provided by ncbi taxonomy
print_spot_protein_correspondence(self, spots_file_object, molecular_error_bounds, isoelectric_error_bounds, output_file_object, output_id_type, alternative_id_types, format_mode)
Finds correspondences between proteins in the piana_graph and spots in a 2D electrophoresis gel
  --> It does it by comparing molecular weights and isoeletric points of the spots with the mw and ip of protein sequences
  --> prints to "output_file_object" (a file object) the spots matches for each error allowed, using protein codes indicated by "id_type"
  --> (one spot can be assigned to several proteinPianas and viceversa (this is just a matching by mw and ip...)
       
"spots_file_object": a file object with spots from a Gel, and their Molecular Weight and Isoelectric Point
 
       text file with spots must follows format (one spot per line):
 
            spot_id<TAB>Molecular Weight<TAB>Isoelectric Point
 
       Attention!!! - Numbers must be in american style: 234234.45 and not 234234,45
                    - No headers or footers allowed
 
 
"mw_error_bounds" and "ip_error_bounds" are lists of error bounds (they must have the same number of elements)
 
    the error bounds describe the percentage of error admitted when matching a spot mw or ip to the theoretical mw or ip of a protein
    for example:
 
            mw_error_bounds   = [0.0, 0.0025, 0.005, 0.01]
            ip_error_bounds   = [0.0, 0.0025, 0.005, 0.01]
 
 
"output_id_type" is the easy-to-remember type name that will be used for printing the proteins that match the 2D gel
  -> Valid id_type are those listed in the PIANA reference card (see README.piana_tutorial)
 
"alternative_id_types" can be used to set a list of alternative types in case no id_type code is found
  -> the user must provide a list of valid easy-to-remember type names
    alternative_id_types can for example look like this: ["gi", "uniacc", "md5"]
     
    I suggest always placing md5 at the end of alternative types, so you never get a None in the output
    
"format_mode" sets the type of format that will be used for output
       - 'txt' will print flat text
       - 'html' will print html
protein_code_2_protein_code(self, input_file_object, input_id_type, output_file_object, output_id_type, alternative_id_types, format_mode, tax_id_value=0)
Translates protein codes of a certain type into another type
 
"input_file_object" is the file object with the protein codes to translate (one protein code per line)
 
"input_id_type" is the type of code used to identify proteins in input_file_object
     -> valid protein-type values are those defined in the PIANA reference card (see README.piana_tutorial)
 
"output_file_object" is the file object where the translated codes will be written
 
"output_id_type" is the target type of code
     -> valid protein-type values are those defined in the PIANA reference card (see README.piana_tutorial)
    
"format_mode" sets the type of format that will be used for output
       - 'txt' will print flat text
       - 'html' will print html
 
"tax_id_value" sets which will be the species for the proteins translated
   --> valid tax ids are 0 (do not take into account the species) and those taxonomy ids provided by ncbi taxonomy
reset_piana_graph(self)
start a new piana_graph
save_piana_graph(self, file_object)
saves current piana_graph in file file_object
 
file_object must have been created using binary write (ir file_object = file(file_name, "wb")
write_reference_card(self, file_object)
Writes the PIANA reference card to file object.
 
It will (obviously) print the reference card with data from the PIANA database that is being used by this PianaApi object
 
 
ATTENTION: this method can only be called from piana.py
           Why? because I have hardcoded the path to general_template.piana_conf, and it is hardcoded as ./conf_files/general_template.piana_conf
                and calling this method from any other directory will crash, as it will not find the template.

Data and other attributes defined here:
__dict__ = <dictproxy object>
dictionary for instance variables (if defined)
__weakref__ = <attribute '__weakref__' of 'PianaApi' objects>
list of weak references to the object (if defined)
info_values = {'all': None, 'cath': None, 'no': None, 'scop': None}
max_min_values = {'max': None, 'min': None}
valid_exp_output_modes = {'add': None, 'print': None}
valid_expansion_modes = {'all': None, 'root': None}
valid_expansion_types = {'cog': ['cog', 'expansionsamecog'], 'ec': ['ec', 'expansionsameec'], 'interpro': ['interpro', 'expansionsameinterpro'], 'scop': ['scop', 'expansionsamescop']}
valid_format_modes = {'dot': None, 'html': None, 'sif': None, 'txt': None}
valid_methods = {'3dstruct': ['3dstruct', 'three dimensional structure', '3d structure', 'xcryst', 'x-ray crystallograph', 'x-ray crystallography', 'x-ray: x-ray crystallography', 'x-ray crystallography', 'xscat', 'x-ray scattering', 'pdb_int', 'coming from pdb', 'x-ray diffraction', 'co-crystal structure'], 'adenylate': ['adenylate', 'adenylate cyclase'], 'adhesion': ['adhesion', 'interaction adhesion', 'interaction adhesion assay'], 'affinchrom': ['affinchrom', 'affinity chromatogra', 'affinity chromatography technology', 'affinity chromatography', 'affinity chromatography technologies', 'affinity technology', 'affinity chrom', 'affinity techniques', 'affinity technologies', 'chromatography', 'chromatography technologies', 'reverse phase chrom', 'affinity capture-luminescence', 'affinity capture-rna', 'affinity capture-western', 'pulldown', 'pull down', 'gst pull down', 'his pull down', 'tandaffin', ...], 'alanine': ['alanine', 'alanine scanning'], 'antibodyarray': ['antibodyarray', 'antibody array'], 'arraytec': ['arraytec', 'peptide array', 'protein array', 'Epistatic MiniArray Profile', 'array technologies', 'microarray'], 'atomic': ['atomic', 'atomic force microsc', 'atomic force microscopy'], 'betagalactcompl': ['betagalactcompl', 'galactosidase', 'beta galactosidase', 'beta galactosidase complementation'], 'betalactcompl': ['betalactcompl', 'beta lactamase complementation'], ...}
valid_output_formats = {'network': None, 'table': None}
valid_output_modes = {'compact': None, 'extended': None}
valid_print_modes = {'all': None, 'all_root': None, 'connecting': None, 'only_root': None}
valid_sim_modes = {'average': None, 'max': None, 'min': None, 'random': None}
valid_term_types = {'biological_process': None, 'cellular_component': None, 'molecular_function': None}
yes_no_values = {'no': None, 'yes': None}

 
Data
        root_nodes = {}
verbose = 0
verbose_add_edge_detailed = 0
verbose_add_edge_shallow = 0
verbose_build = 0
verbose_build_shallow = 0
verbose_build_very_shallow = 0
verbose_command_sequence = 1
verbose_detailed = 0
verbose_expansion_detailed = 0
verbose_expansion_minimal = 0
verbose_expansion_shallow = 0
verbose_expression = 0
verbose_get_all_links = 0
verbose_get_edge = 0
verbose_get_node = 0
verbose_has_edge = 0
verbose_insert_interaction = 0
verbose_join = 0
verbose_output_graph = 0
verbose_patches = 0
verbose_pathway = 0
verbose_process = 0
verbose_propagate = 0
verbose_propagate_print = 0
verbose_prots_imotifs = 0
verbose_prots_imotifs_iteration = 0
verbose_prots_imotifs_shallow = 1
verbose_shallow = 0
verbose_species = 1
verbose_spots = 0