| |
- Method resolution order:
- PianaGraph
- Graph.Graph
- __builtin__.object
Methods defined here:
- __getnewargs__(self)
- __getstate__(self)
- __init__(self, graphID=None, piana_access_object=None, piana_secondary_access_object=None, memory_mode='memory')
- __setstate__(self, dict)
- add_interaction(self, protein_a=None, protein_b=None, id_type=None, tax_id_value=0, source_db=None, method=None, confidence=None)
- Adds an interaction to the current PianaGraph object
"protein_a" is the protein code of one side of the interaction
"protein_b" is the protein code of the other side of the interaction
"id_type" is the type of protein code being used for protein_a and protein_b
--> valid types of protein code are listed in the PIANA reference card (read README.piana_tutorial)
"tax_id_value" sets the species of the interactions 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
"source_db", "method" and "confidence" not being used: that data is obtained directly from the database instead
- build_graph(self, user_graph_builder, complete_taxID=None)
- # ------------------------------------------
# Overwritte some methods
# ------------------------------------------
- get_distance_groups(self, protein_ext_code=None, input_id_type=None, output_id_type=None, alternative_id_types=[], user_protein_names={}, tax_id_value=0)
- gets proteins that are at a certain distance from a given protein protein_ext_code
returns a dictionary that follows the structure:
{ 1:[list of protein ext codes at distance 1 from protein_ext_code],
2:[list of protein ext codes at distance 2 from protein_ext_code],
3:[list of protein ext codes at distance 3 from protein_ext_code],
4:[list of protein ext codes at distance 4 from protein_ext_code]
}
"protein_ext_code" is the protein for which we want to find proteins at a certain distance
"input_id_type" is the easy-to-remember identifier type used for protein_ext_code
--> valid values are those listed in the PIANA reference card (read README.piana_tutorial)
"output_id_type" is the easy-to-remember identifier type that you want to use for results
--> valid values are those listed in the PIANA reference card (read 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 pairs 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" sets the species of the proteins being returned (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
- get_list_unified_names(self, list_proteinPianas, output_id_type, alternative_id_types, key_list=0)
- returns a list with the unified names for proteinPianas in list_proteinPianas
- get_network_proteins(self, output_id_type, alternative_id_types=None, tax_id_value=0, user_protein_names={})
- returns a list with the proteins in the network, using output_id_type to identify the proteins.
"output_id_type" is the easy-to-remember type name that will be used for printing the protein
-> valid id_type are those listed in the PIANA reference card (read 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 pairs 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" sets the species of the proteins being 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
"user_protein_names" can be used to fix a set of protein names that have preference over other names when a protein has several names
(eg. if proteinPiana has gene names CXCL1 and MGSA, and this dictionary has CXCL1, it is guaranteed that CXCL1 will be used for output)
--> user_protein_names is a dictionary that follows the structure: { protein_name:None, protein_name:None, ...}
- get_nodes_isoelectric_points(self)
- returns a dictionary (hashed by nodeID (ie proteinPiana)) of isoelectric points:
{nodeID1:isoelectricPoint1, nodeID2:isoelectricPoint2 , ...}
- get_nodes_molecular_weights(self)
- returns a dictionary (hashed by nodeID (ie proteinPiana)) of molecular weights:
{ nodeID1:molecularWeight1, nodeID2:molecularWeight2 , ...}
- get_proteins_expression(self, list_proteins=[], id_type=None, alternative_id_types=[], tax_id_value=0, file_over_expressed=None, file_infra_expressed=None, expression_id_type=None)
- given a list [protein1, protein2, ...] (of type "id_type") this method returns a dic
{protein1:'over_expressed', protein2:'over_and_under_expressed', protein3:...}
Attention! If expression is None, the protein will not appear in the dictionary
protein ext_codes in list_proteins do not need to be network proteins, neither unified
- get_proteins_special_labels(self, list_proteins=[], id_type=None, alternative_id_types=[], tax_id_value=0, file_over_expressed=None, file_infra_expressed=None, expression_id_type=None, dic_special_proteins_file={})
- given a list [protein1, protein2, ...] (of type "id_type") this method returns a dictionary
{ protein1:{'expression':expression_value, 'labels':[label1, label2, ...]},
protein2: ....
}
"list_proteins" is a list of external codes that has been obtained by calling to another PianaGraph method
-> you cannot set any list of proteins here. This list must be the result of some operation over a group
of unified names
"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),
...............
}
if the following parameters are set, then the expression info will be inserted in the results. Otherwise, expression info will be None
"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
Attention! A name unification must have been made previously for the proteinPianas of ext_codes in list_proteins, using the
same id_type you are using now (either via a call to get_list_unified_names or other network
operations that call _fill_dic_protein_naming)
- get_unified_edge(self, edge_key)
- Get the edge node and edge attribute for this edge_key
- get_unified_name(self, proteinPiana, id_type, alternative_id_types)
- returns the name (of code type "id_type") that is assigned to "proteinPiana" as the unified name
, another_dic_prot_naming=None
if another_dic_prot_naming is not None, uses this dictionary instead of self.dic_protein_naming
- match_gos(self, force_expression, output_file_object, format_mode, output_id_type, tax_id_value, term_type, level_threshold, go_cursor, 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
"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 (read 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" is the tax_id of the proteins we are working on (proteins in pathway files must be of this tax_id)
- set to 0 if you don't mind of the species, or to the tax id in case you do
"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_cursor" is a mysql connection to your external GO database
-> look at PianaApi.print_matched_gos to learn how to create a mysql connection from python
"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),
...............
}
- match_pathways(self, pathways_dir, force_expression, output_file_object, results_dir, files_prefix, format_mode, pathway_id_type, tax_id_value, output_id_type, alternative_id_types, user_protein_names={}, 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 (read 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 (read 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" is the tax_id of the proteins we are working on (proteins in pathway files must be of this tax_id)
- set to 0 if you don't mind of the species, or to the tax id in case you do
"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),
...............
}
"user_protein_names" can be used to fix a set of protein names that have preference over other names when a protein has several names
(eg. if proteinPiana has gene names CXCL1 and MGSA, and this dictionary has CXCL1, it is guaranteed that CXCL1 will be used for output)
--> user_protein_names is a dictionary that follows the structure: { protein_name:None, protein_name:None, ...}
- match_spots_to_proteins(self, spots_file_object=None, mw_error_bounds=None, ip_error_bounds=None, match_mode='all')
- matches spots in a spot file with proteins in the network
"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
returns a dictionary (with error levels as keys) with a list of tuples [spot_id, proteinPiana]
{ error_level1: [ [spot_id1, proteinPiana1], [spot_id2, proteinPiana2], ...],
error_level2: [ [spot_id1, proteinPiana1], [spot_id2, proteinPiana2], ...],
......................
}
(one spot can be assigned to several proteinPianas and viceversa (this is just a matching by mw and ip...)
"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]
"match_mode" can be (default is "all")
- "all" : matching performed by comparing molecular weight and isoelectric point
- "mw" : matching performed by comparing only molecular weight
- "ip" : matching performed by comparing only isoelectric point
- output_all_proteins_information(self, id_type, output_target, output_mode='compact', format_mode='txt', filter_mode='all', alternative_id_types=[], tax_id_value=0, list_keywords=[], user_protein_names={}, file_over_expressed=None, file_infra_expressed=None, expression_id_type=None, dic_special_proteins_file=None)
- writes information about all proteins in the network in file "output_target"
The description of the arguments in this method is the same as in method output_protein_information()
- output_connecting_proteins_information(self, id_type, output_target, output_mode='compact', format_mode='txt', filter_mode='all', alternative_id_types=[], tax_id_value=0, list_keywords=[], user_protein_names={}, file_over_expressed=None, file_infra_expressed=None, expression_id_type=None, dic_special_proteins_file=None)
- writes information to file object "output_target" about linker proteins in the network
The description of the arguments in this method is the same as in method output_protein_information()
- output_interactions(self, id_type=None, output_target=None, output_format=None, format_mode='txt', intersection_dbs=None, filter_mode='all', print_mode='all', alternative_id_types=[], tax_id_value=0, use_self_ints='yes', list_keywords=[], file_over_expressed=None, file_infra_expressed=None, expression_id_type=None, dic_special_proteins_file=None, user_protein_names={}, network_attributes_prefix=None)
- writes a (table or network in dot format) in file "output_target" describing graph information in the following formats:
dot format: follows the standard dot language for describing networks
table format:follows the format described in method print_table_interaction
"id_type" is the easy-to-remember type name that will be used for printing the proteins in the network.
--> Valid id_type are those listed in the PIANA reference card (read README.piana_tutorial)
"output_target" is a file object (set to sys.stdout if you want the output printed to your screen)
"output_format" is the format that will be followed for the output
-"table": prints interactions in table format
-"network": prints interactions in a network
"format_mode" sets the type of format that will be used for output
- 'txt' will print flat text (only valid for output_format 'table')
- 'html' will print html (only valid for output_format 'table')
- 'dot' will print a DOT file (only valid for output_format 'network')
"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 in PianaGlobals.interaction_databases
"filter_mode" not being used at the minute... will be used for hidden, unhidden, all
"print_mode" sets which proteins will be printed
-> "all" will print all interactions in the network
-> "all_root" will print all interactions in the network 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 pairs 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" sets the species of the interactions 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
"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']
"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),
...............
}
"user_protein_names" can be used to fix a set of protein names that have preference over other names when a protein has several names
(eg. if proteinPiana has gene names CXCL1 and MGSA, and this dictionary has CXCL1, it is guaranteed that CXCL1 will be used for output)
--> user_protein_names is a dictionary that follows the structure: { protein_name:None, protein_name:None, ...}
"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
- output_list_proteins_information(self, list_proteins, input_id_type, output_id_type, output_target, output_mode='compact', format_mode='txt', filter_mode='all', alternative_id_types=[], list_keywords=[], tax_id_value=0, key_list=-1, file_over_expressed=None, file_infra_expressed=None, expression_id_type=None, dic_special_proteins_file=None)
- writes information to file object output_target about all proteins in list "list_proteins" (of type "input_id_type")
This method is used to print information about proteins that are not in a network!!!! (ie. it won't print information about interactions of the proteins)
The description of the rest of the arguments of this method is the same as in method output_protein_information()
- output_nodes_isoelectric_points(self)
- output_nodes_molecular_weights(self)
- output_protein_information(self, proteinPiana_value, id_type, alternative_id_types=None, output_target=<open file '<stdout>', mode 'w'>, output_mode='compact', format_mode='txt', filter_mode='all', list_keywords=[], tax_id_value=0, user_protein_names={}, list_connects_nodes=None, list_proteinPianas=None, key_list=-1, file_over_expressed=None, file_infra_expressed=None, expression_id_type=None, dic_special_proteins_file=None)
- writes information about protein "proteinPiana_value" to "output_target", following format "output_mode"
"output_target" is a file object (sys.stdout to print to screen)
"id_type" is the easy-to-remember type name that will be used for printing the protein
-> valid id_type are those listed in the PIANA reference card (read README.piana_tutorial)
"filter_mode" not working at the minute: it will be used for hidden, unhidden, all
"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
"list_connects_nodes" is a list of root nodes that are connected through protein 'proteinPiana_value'. It comes from
one of the dictionary rows of get_connecting_nodes_dic(). If it is set to None, the method considers that the user does not
want to know information about connected root nodes
"alternative_id_types" can be used to set a list of alternative types in case no id_type code is found
--> user must provide pairs 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" sets the species of the proteins being 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
"user_protein_names" can be used to fix a set of protein names that have preference over other names when a protein has several names
(eg. if proteinPiana has gene names CXCL1 and MGSA, and this dictionary has CXCL1, it is guaranteed that CXCL1 will be used for output)
--> user_protein_names is a dictionary that follows the structure: { protein_name:None, protein_name:None, ...}
"list_keywords" sets a list of keywords that will be used to highlight important proteins in the network
-> when printing protein information, it prints in the protein information line user_keyword=word_found user_keyword=word_found ...
-> 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']
"list_proteinPianas" is normally None, but can be set to a list of proteinPianas for those cases in which we are not printing proteins of the network
but just proteins that the user asked information about. In case list_proteins is not None, then the names are unified for the proteins in the list
instead of doing it for proteins of the network. Look at PianaApi.print_list_proteins to better understand how this works
"key_list" is a unique key for this list of proteins, used to know when the unification of names has to be performed again
-> if you are making calls for different lists of proteins, just set the key to consecutive numbers so this method can
differentiate between the lists
-> a user key_list cannot be -1, because -1 is used as default to indicate that no key was used
"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),
...............
}
- output_proteins_with_network_class(self, id_type, output_target, alternative_id_types=[], tax_id_value=0, user_protein_names={}, file_over_expressed=None, file_infra_expressed=None, expression_id_type=None, dic_special_proteins_file={})
- writes to file object "output_target" all the proteins in the network with a label indicating whether they are root, linker or partner
The description of the arguments in this method is the same as in method output_protein_information()
- output_root_proteins_information(self, id_type, output_target, output_mode='compact', format_mode='txt', filter_mode='all', alternative_id_types=[], tax_id_value=0, list_keywords=[], user_protein_names={}, file_over_expressed=None, file_infra_expressed=None, expression_id_type=None, dic_special_proteins_file=None)
- writes information about root proteins in the network in file "output_target"
The description of the arguments in this method is the same as in method output_protein_information()
- output_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)
- 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 (read 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 (read 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!!!! mode 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_distance_group(self, distance_group, input_id_type, output_target, info, format_mode='txt', user_protein_names={}, tax_id_value=0)
- prints a distance group to output_target
"distance_group" is a list of protein codes of type input_id_type
"output_target" is a file object (sys.stdout to print to screen)
"info" determines which information will be printed next to the proteins in the distance group
(info will be preceded by a header stating the type of info being printed)
- blank: nothing
- all: all info available
- scop: scop codes
- cath: cath codes
"format_mode" sets the type of format that will be used for output
- 'txt' will print flat text
- 'html' will print html
"input_id_type" is the easy-to-remember identifier type used for protein_ext_code
--> valid values are those listed in the PIANA reference card (read README.piana_tutorial)
"tax_id_value" sets the species of the proteins that will be printed (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
- print_spots_matches(self, spots_matches=None, output_target=None, format_mode='txt', id_type=None, mw_error_bound=None, ip_error_bound=None, alternative_id_types=[], user_protein_names={})
- prints to "output_target" (a file object) the spots maches for each level, using protein codes indicated by "id_type"
"format_mode" sets the type of format that will be used for output
- 'txt' will print flat text
- 'html' will print html
"id_type" is the easy-to-remember type name that will be used for printing the proteins in the network.
Valid id_type are those listed in the PIANA reference card (read 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 pairs 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
"user_protein_names" can be used to fix a set of protein names that have preference over other names when a protein has several names
(eg. if proteinPiana has gene names CXCL1 and MGSA, and this dictionary has CXCL1, it is guaranteed that CXCL1 will be used for output)
--> user_protein_names is a dictionary that follows the structure: { protein_name:None, protein_name:None, ...}
spots_matches were obtained with method PianaGraph.match_spots_to_proteins
spots_matches follow structure:
{ error_level1: { spot_id: proteinPiana,
spot_id: proteinPiana,
......................},
error_level2: { spot_id: proteinPiana,
spot_id: proteinPiana,
....................},
.....................................
}
- print_table_interaction(self, output_target=None, format_mode='txt', root_connectivity=None, extcode_start=None, num_neigh_start=None, node_type_start=None, expression_start=None, special_labels_string_start=None, list_protein_user_keywords_start=None, extcode_end=None, num_neigh_end=None, node_type_end=None, expression_end=None, special_labels_string_end=None, list_protein_user_keywords_end=None, same_loc=None, same_species=None, list_interaction_dbs=None, list_interaction_methods=None, list_interaction_pubmeds=None, fill_interaction_table_strings=0)
- Prints one interaction between "extcode_start" and "extcode_end" in a table to "output_target"
-> html table if "format_mode" is 'html' or tabulated text if "format_mode" is 'txt'
"output_target" is a file object with writing rights
"list_interaction_dbs" is a list of the database names where this interaction appears
"list_interaction_pubmeds" is a list of the pubmed IDs where this interaction appears
in format_mode 'html', the table is simplified to fit to the screen.
Static methods defined here:
- print_image_interaction(output_target=None, format_mode=None, edge_object=None, piana_access=None, extcode_start=None, extcode_end=None, list_interaction_dbs=None, list_interaction_methods=None, network_attributes_prefix=None)
- prints to "output_target" one interaction between "extcode_start" and "extcode_end" in format defined by "format_mode"
"output_target" is a file object with write rights
"format_mode" sets the format used for printing the network interaction (right now, the only valid format is 'dot')
"edge_object" is the GraphEdge object of this interaction
"list_interaction_dbs" are the database names where this interaction appears
files written by this method can be used to create an image of the network using neato from package Graphviz:
$> cat "output_of_this_method" | neato -Tgif -o output_file.gif
"network_attributes_prefix" is the directory + file prefix that will be used to create the files that describe the information for this node
-> these files can then be used by cytoscape to visualize specific properties of the node
Methods inherited from Graph.Graph:
- __str__(self)
- add_edge(self, edge_object)
- Adds an edge to the graph. Argument is a GraphEdge object.
Attention! The nodes have to be added to the graph before adding the edge!!!!
-> add_edge does not add the nodes!
adds the edge to the graph after checking its existance. Therefore, it can be used wihtout checking if it was in the network
- add_node(self, node_object)
- Adds a node to the graph.
"node_object" must be previously created from GraphNode
- add_root_node(self, node_id)
- Adds a root node id to the set of root nodes
- clean_nodes(self)
- Looks for and removes nodes with no edges.
This is applied to the UNFILTERED graph - filtering has no effect so
a node which has no edges when filtered will NOT be removed.
- connected(self)
- Returns 1 if graph is fully connected, 0 otherwise.
Uses fortran subroutine.
- create_edge(self, node_id1=None, node_id2=None, attribute_object=None)
- Returns a tuple [edge object, new], where new= 1 means edge didn't exist in the graph before
If edge already existed, in edge returned attribute_object is merged with attribute of existing edge
"node_id1" and "node_id2" are node identifiers
Attention!!! The edge is not added to the graph! That must be done by the user if he wants to do so...
- edge_exists(self, identifier1=None, identifier2=None)
- Returns a 1 if edge already exists. 0 otherwise
if identifier1 and identifier2 are not None, both identifiers are node_id
if identifier2 is None, then identifier1 is an edge_id
- expand(self, expansion=None, behaviour='fresh', expansion_mode='all', exp_output_mode='add', output_target=None, id_type=None, alternative_id_types=None, expansion_threshold=0, hub_threshold=0, class_name='all')
- Expands node and edges of the graph based on behaviour defined by an object Expansion
-> expand is used to "propagate" edges of one node to another node in case they share a certain characteristic
- if node A has interactions a, b and c
- if node B has interactions d, e and f
- if node A and node B share characteristic X (defined by object expansion)
- if we perform a expand on both nodes, the new network will be:
- A will have interactions a, b, c, d, e and f
- B will have interactions a, b, c, d, e and f
"expansion" is an expansion object, created using a subclass of Expansion (and specific to the database you're working with)
"expansion_mode" determines if all nodes are expanded or only those that were used as root to create the network
- expansion_mode == "all" creates expanded edges for all nodes in the graph
- expansion_mode == "root" creates expanded edeges only for root nodes
"expansion_threshold" sets the threshold determining whether to expand a node or not
- if a node shares a certain characteristic with lots of other nodes, it might not be a relevant characteristic
for these cases, we introduce a threshold that determines that if there are more than "expansion_threshold" nodes sharing the characteristic
with the node, then edges from those nodes will not be propagated to the node.
- if 0, no thresholds will be applied
"hub_threshold" sets the threshold for how many edges can a node have in order to be added to the network
- if a node has more than "hub_threshold" edges, these edges will not be added to the network.
- if 0, no threshold is applied
"output_mode" determines if expansions performed will be added to the current graph or printed to stdout
- output_mode == "add" adds expansions to graph
- output_mode == "print" will print expansions to stdout
"id_type" is a code type used in database, and is the code type that will be used for printing out propagated edges (in exp_output_mode "print")
"alternative_id_types" are the alternative code types in case nothing is found for "id_type" (identifier will be preceded by "type:xxxx")
"class_name" is used in output_mode print to choose the class of nodes we want to print out
- "all" will print all classes of nodes
- other classes are defined by the subclass of Graph you are using (eg. in PianaGraph, class_name is the protein taxonomy id)
- expansions will only be printed out if both nodes in the edge are of class "class_name"
- filter(self, filters, behaviour='fresh')
- Hides node and edges in the graph based on filters.
Behaviour can either be "fresh" or "inc".
"fresh" (the default) unhides all nodes/edges previously hidden before applying
the new filters.
"inc" incrementally applies the new filters on the current visible graph.
not working at the minute!
- find_routes(self, node1_id, node2_id)
- When passed two node objects, finds routes between them.
Make sure nodes are retreived from the graph by extracting them with
g.get_node(node_nodeID,get_mode="error") for example.
THIS IS BROKEN AT THE MINUTE - IT'S NOT RETURNING ALL THE PATHS
- find_shortest_route(self, start_node_id, end_node_id)
- Uses Dijkstra's algorithm to find the shortest route between start_node_id and end_node_id
returns a tuple ( distance, route)
- get_all_distances(self)
- Uses Dijkstra's algorithm to find every pairwise distance in the
graph. This is more efficient than calling get_distances() for
each node.
NOT IMPLEMENTED YET!!!
- get_ave_degree(self)
- Returns the average degree of the graph.
This variable may be directly accessed as Graph.ave_degree but
interface through this method is preferable as it ensures that the
value is current.
- get_clus_coef(self)
- Returns the clustering coefficient of the graph. This is an
intelligent interface - if the graph has been modified since the
last calculation of the clustering coefficient (via a call to
Graph.calc_clus_coef()), its value will be re-calculated before
being returned.
- get_connecting_nodes_dic(self, distance=None)
- Returns a dictionary of node_ids that connect root_nodes of the graph
format is: {connecting_node_id:[list of root nodes that connects], connecting_node_id:[], ...}
These are the nodes that belong to the path between two root nodes, at a maximun distance "distance"
Note: it doesn't return nodes that are only connected to one root node. The minimum number of root nodes is 2.
- get_distances(self, query_node_id)
- Implements Dijkstra's algorithm for finding the distance to all
nodes of the graph from one query node. This is _much_ more efficient
than calling find_route() for all node combinations.
Returns a dictionary of distances, the keys being the node ids and the contents the distance at which that node can be found
- get_edge(self, identifier1, identifier2=None, attribute_object=None, get_mode='new')
- Returns an edge object.
"identifier1" and "identifier2" can be edgeIDs, edge objects GraphEdge, nodeIDs or nodes objects GraphNode.
If the edge described in the arguments already exists in the graph, returns that edge object.
Otherwise the behaviour is defined by parameter get_mode (see below)
get_mode can be "new" or "error" (default is "new")
- "new" - returns a new edge if it doesn't exist
- "error" - raises error if it doesn't exist
Both get_modes return a reference to the edge when it already existed
Attention: get_edge does not add the edge to the Graph!!!!!
- get_edge_attribute_parameters(self, edgeID)
- Returns the tuple that contains the values needed to construct the edge attribute object
- get_edge_ids_list(self)
- Returns a list with edge ids of the graph
- get_edge_object_list(self)
- Returns a list with edge objects of the graph
Avoid to use it because Edge Object are generated on the flight!
- get_graph_id(self)
- get_hidden_edges(self)
- Returns a list of hidden edges of the graph.
- get_hidden_nodes(self)
- Returns a list of hidden node objects in the graph.
- get_memory_mode(self)
- get_node(self, identifier, attribute=None, get_mode='new')
- Returns a node object.
"identifier" can be a nodeID or a GraphNode object.
Attention: get_node doesn't add the node to the graph!!!
If the node nodeID already exists in the graph, returns that node.
Otherwise the behaviour is defined by parameter get_mode (see below)
get_mode can be "new" or "error" (default is "new")
- "new" returns a new node in case node.nodeID doesn't exist
- "error" returns an error in case node.nodeID doesn't exist
- get_node_clus_coef(self, node_id)
- Returns the clustering coefficient for an specific node
- get_node_ids_list(self)
- Returns a list with node ids of current graph
- get_node_ids_list_deep_copy(self)
- Returns a new list (a deep copy, not just a reference to node_ids) with node ids of current graph
- get_node_node_links(self)
- returns a list of node_id pairs that have an edge between them
returned list looks like this: [ [node1, node2], [node1, node3], [node2,node4], ...]
- get_node_object_list(self)
- Returns a list with node objects of the graph
- get_node_root_connectivity(self, node)
- returns the number of root nodes that node "node" connects
- get_nodes_connectivities(self, distance=1)
- returns a dictionary of connectivities of all nodes in the graph
the dictionary returned follows format:
{node_id 1: list of node ids at distance 1 of node id 1,
node_id 2: list of node ids at distance 1 of node id 2,
............................. }
"distance" is currently not being used
- get_root_node_ids(self)
- Returns a set of root node ids of the graph.
- get_root_node_ids_deep_copy(self)
- Returns a list of root nodes (a deep copy, not just a reference to node objects) of the graph.
- get_root_node_ids_set(self)
- get_unhidden_edges(self)
- Returns a list of unhidden edges of the graph.
- get_unhidden_nodes(self)
- Returns a list of unhidden nodes objects in the graph.
- has_root_node_id(self, node_id)
- Returns 1 if the graph contains a root with node_id equal to "node_id". If not, returns None
- hide_edge(self, edge_id)
- Adds a hidden edge to the set of hidden edges
This does not check in edge_id exists in the graph, so, be careful
- hide_node(self, node_id)
- Adds a hidden node to the set of hidden nodes
This does not check if node_id exists in the graph, so, be careful
- is_hidden(self, node_id=None, edge_id=None)
- Returns True or False if node/edge is hidden
- join_graphs(self, graph_object)
- adds to current graph the nodes and edges from graph passed as argument "graph_object"
- load_graph_from_text_file(self, file_name)
- loads graph data described in a text file into the current graph object
input file must follow format:
node--node
node--node
where node are identifiers of nodes and each line is a link between those identifiers
- nodes_connected(self, node1, node2)
- Returns 1 is node1 is connected to node2 (at any network depth), 0 otherwise.
- old_connected(self)
- Returns 1 if graph is fully connected, 0 otherwise.
Not very efficient! Use connected() instead!
If you want to use it, you'll have to:
- add the import line: import LinearAlgebra
- uncomment the following lines
if self.laplacian is None:
_build_laplacian()
try:
ev = LinearAlgebra.eigenvalues(self.laplacian)
eigenvalues = []
k_node = len(get_unhidden_nodes())
for i in range(k_node):
eigenvalues.append(ev[i])
eigenvalues.sort()
# print eigenvalues
# secont smallest eigenvalue gives info about connectivity
# check smallest is zero first though
if not ( abs(eigenvalues[0]) < 0.000001 ):
raise Exception("Internal error: Eigenvalue problem")
if eigenvalues[1] > 0.0:
return 1
else:
return 0
except:
# having problems here - need to sort this out
return 1
- output_dot_file(self, filter_mode='all', output_target=None, use_alternative_id='no')
- Generates .dot file output that can be fed directly into the
GraphViz program neato. This produces very nice network images...
"output_target" is a file object where the dot file will be written
filter_mode can be:
- "all": prints all edges of the graph
- "hidden": prints hidden edges of the graph
- "unhidden": prints unhidden edges of the graph
"use_alternative_id" can be
- "yes" --> uses alternative id for printing graph
- "no" --> uses internal id for printing graph
use_alternative_id is used to codify in the node which is the label to be used for that node. This is useful when
we want to label the node with something different than the node id.
to produce a GIF file from the .dot file returned by this method, do the following:
cat output_of_this_method | neato -Tgif -o output_network.gif
- output_edges_table(self, filter_mode='all', output_target=None)
- prints pairs of interacting nodes to output_target
"output_target" is a file object (sys.stdout to print to screen)
filter_mode can be:
- "all": prints all edges of the graph
- "hidden": prints hidden edges of the graph
- "unhidden": prints unhidden edges of the graph
The output will look like this:
node1 id<TAB>node2 id
node3 id<TAB>node4 id
..............
- print_edges(self, filter_mode='all')
- prints edges in the graph
filter_mode can be:
- "all": prints all edges of the graph
- "hidden": prints hidden edges of the graph
- "unhidden": prints unhidden edges of the graph
- print_nodes(self, filter_mode='all')
- Prints nodes in Graph
filter_mode can be:
- "all": prints all nodes of the graph
- "hidden": prints hidden nodes of the graph
- "unhidden": prints unhidden nodes of the graph
- print_route(self, distance, route)
- prints the route codified in "route" (which is just a list of node objects)
- replace_filters(self, new_filters)
- Replaces current set of filters on the graph with some new
filters. Saves the old filters for restoration through
restore_filters()
not working at the minute!
- restore_filters(self)
- Restores an old set of filters replaced by replace_filters.
not working at the minute!
- rm_edge(self, edge_id)
- Removes a edge from the graph.
"edge_object" is a GraphEdge object of the graph
Attention!!! This method only deletes the edge. Affected nodes are not deleted, even though they are not implied in other edges
- rm_node(self, node_object)
- Removes a node from the graph.
"node_object" is a GraphNode object of the graph
- set_graph_id(self, new_graph_id)
- unfilter(self)
- Un-hides all nodes and edges of the graph.
not working at the minute!
- unhide_edge(self, edge_id)
- Unhides an edge of the set of hidden edges
- unhide_node(self, node_id)
- Unhiddes node to the set of hidden nodes
If the node is not hidden, print error message to stderr
Static methods inherited from Graph.Graph:
- build_cluster_graph(node_list=None, old_edges_dictionary=None, old_node_2_new_node_dictionary=None, new_node_to_old_node_list_dictionary=None, newGraph=None)
- Method that builds a new cluster_graph from:
"node_list": a list of new nodes to be added to the new cluster_graph
"old_edge_dictionary": a dictionary that in each position there is a list of nodes that had edge with this node
"old_node_2_new_node_dictionary": a dictionary that references old nodes_id to new_node_id e.g: old_node_2_new_node[old_node_id]=new_node_id
"node_to_old_node_list_dictionary": a dictionary that references new nodes_id to a list of old nodes_id that contents inside
eg: node_to_old_node_list_dictionary[new_node_id]=[old_node_id1,old_node_id2...]
- build_expanded_graph(node_list=None, old_edges_dictionary=None, old_node2new_node_dic=None, new_node2old_node_dic=None, newGraph=None)
- Method that builds a new cluster_graph from:
"node_list": a list of new nodes to be added to the new cluster_graph
"old_edge_dictionary": a dictionary that in each position there is a list of nodes that had edge with this node
"old_node2new_node_dic": a dictionary that references old nodes_id to new_node_id
e.g:old_node_2_new_node[old_node_id]=[new_node_id,new_node_id2...]
"new_node2old_node_dic": a dictionary that references new nodes_id to a list of old nodes_id that contents inside
eg: node_to_old_node_list_dictionary[new_node_id]=[old_node_id1,old_node_id2...]
Data and other attributes inherited from Graph.Graph:
- __dict__ = <dictproxy object>
- dictionary for instance variables (if defined)
- __weakref__ = <attribute '__weakref__' of 'Graph' objects>
- list of weak references to the object (if defined)
|