cytoscape / RCy3

New version of RCy3, redesigned and collaboratively maintained by Cytoscape developer community
MIT License
50 stars 20 forks source link

createNetworkFromDataFrames scrambles shared.name and name #81

Closed K-C-Martin closed 4 years ago

K-C-Martin commented 4 years ago

My first attempt at a bug report: please advise if I'm doing it 'wrong' or could be better.

I've been using createNetworkFromDataFrames to generate a network from a 230-row node df and a 286-row edge df, and have been finding that the results are somewhat scrambled... edges are assigned to the wrong nodes.

Oddly, repeated runs change which edges are assigned to a given pair of nodes, with a pattern that seems to repeat (and every so often there is a block of 5-6 runs that give correctly assigned edges to all nodes).

I've simplified my dataframes by replacing my original node names with simple ids, stripping interaction type and other attributes, and included duplicates of the id, source, and target columns as attributes:

test edges.txt test nodes.txt

I can reproduce the error with the following code:

library(RCy3) cytoscapePing() nodes <- read.csv('test nodes.txt', stringsAsFactors = F) edges <- read.csv('test edges.txt', stringsAsFactors = F) createNetworkFromDataFrames(nodes, edges)

Example output (script run with freshly-opened Cytoscape and RStudio), selecting the only edge between two nodes labeled 'nid1' and 'nid193':

Edge linking nodes 'nid1' and 'nid193' (taken from Cytoscape edge table): SUID = 405 shared name = nid1 (interacts with) nid193 name = nid66 (interacts with) nid128 source = nid66 target = nid128 cpsource (attribute) = nid66 cptarget (attribute) = nid128

getEdgeInfo(405) gives the following output: source = 62 (matches nid1 SUID in Cytoscape node table) target = 254 (matches nid193 SUID in Cytoscape node table) shared name = "nid1 (interacts with) nid193" name = "nid66 (interacts with) nid128"

Session info as follows:

R version 3.6.1 (2019-07-05) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 10 x64 (build 18362)

Matrix products: default

attached base packages: [1] stats graphics grDevices utils datasets methods base

other attached packages: [1] RCy3_2.4.6

loaded via a namespace (and not attached): [1] XML_3.98-1.20 R.methodsS3_1.7.1 R6_2.4.0 stats4_3.6.1 magrittr_1.5
[6] graph_1.62.0 httr_1.4.1 curl_4.2 R.oo_1.23.0 R.utils_2.9.0
[11] RJSONIO_1.3-1.3 tools_3.6.1 igraph_1.2.4.1 parallel_3.6.1 compiler_3.6.1
[16] pkgconfig_2.0.3 BiocGenerics_0.30.0

K-C-Martin commented 4 years ago

I've tried to get around the problem by going via igraph instead, and have the same issue - the following code (using the same 'test edges.txt' attached above) gives the correct network when the commented-out line isn't included, but the incorrect network (i.e. edge 'shared name' and 'name' do not match) when the line is included:

library(igraph) library(RCy3) edges <- read.csv('test edges.txt', stringsAsFactors = F) edgelist <- as.matrix(edges[, c('source', 'target')]) newgraph <- graph_from_edgelist(edgelist)

edge_attr(newgraph, 'cpsource') <- edges$cpsource

createNetworkFromIgraph(newgraph)

K-C-Martin commented 4 years ago

As a follow-on the the above comment, and the mention of a 'pattern' when a network is repeatedly generated, the following loop produces a pattern of 8 incorrect / 6 correct networks (NB: the loop runs after the 'edge_attr' line has been applied... I would expect the same igraph to produce the same network each time, but it doesn't):

library(igraph) library(RCy3) edges <- read.csv('test edges.txt', stringsAsFactors = F) edgelist <- as.matrix(edges[, c('source', 'target')]) newgraph <- graph_from_edgelist(edgelist) edge_attr(newgraph, 'cpsource') <- edges$cpsource

num_runs <- 50

correct_runs <- data.frame(correct = vector(mode = 'logical', length = num_runs), shared_name = vector(mode = 'character', length = num_runs), stringsAsFactors = F)

for (r in c(1:num_runs)) {

createNetworkFromIgraph(newgraph)

check_edge <- getEdgeInfo("nid1 (interacts with) nid193")$nid1 (interacts with) nid193$shared name

correct_runs$correct[r] <- (check_edge == "nid1 (interacts with) nid193")

correct_runs$shared_name[r] <- check_edge

closeSession(F)

}

OUTPUT (the 'correct_runs' df) - note 8 incorrect / 6 correct pattern: correct shared_name 1 FALSE nid163 (interacts with) nid48 2 FALSE nid147 (interacts with) nid12 3 FALSE nid118 (interacts with) nid223 4 FALSE nid112 (interacts with) nid124 5 FALSE nid76 (interacts with) nid133 6 FALSE nid41 (interacts with) nid150 7 FALSE nid5 (interacts with) nid158 8 TRUE nid1 (interacts with) nid193 9 TRUE nid1 (interacts with) nid193 10 TRUE nid1 (interacts with) nid193 11 TRUE nid1 (interacts with) nid193 12 TRUE nid1 (interacts with) nid193 13 TRUE nid1 (interacts with) nid193 14 FALSE nid187 (interacts with) nid91 15 FALSE nid158 (interacts with) nid41 16 FALSE nid148 (interacts with) nid20 17 FALSE nid126 (interacts with) nid124 18 FALSE nid196 (interacts with) nid120 19 FALSE nid84 (interacts with) nid188 20 FALSE nid49 (interacts with) nid164 21 FALSE nid13 (interacts with) nid147 22 TRUE nid1 (interacts with) nid193 23 TRUE nid1 (interacts with) nid193 24 TRUE nid1 (interacts with) nid193 25 TRUE nid1 (interacts with) nid193 26 TRUE nid1 (interacts with) nid193 27 TRUE nid1 (interacts with) nid193 28 FALSE nid188 (interacts with) nid99 29 FALSE nid171 (interacts with) nid63 30 FALSE nid153 (interacts with) nid28 31 FALSE nid134 (interacts with) nid228 32 FALSE nid161 (interacts with) nid128 33 FALSE nid92 (interacts with) nid139 34 FALSE nid56 (interacts with) nid150 35 FALSE nid21 (interacts with) nid114 36 TRUE nid1 (interacts with) nid193 37 TRUE nid1 (interacts with) nid193 38 TRUE nid1 (interacts with) nid193 39 TRUE nid1 (interacts with) nid193 40 TRUE nid1 (interacts with) nid193 41 TRUE nid1 (interacts with) nid193 42 FALSE nid192 (interacts with) nid107 43 FALSE nid177 (interacts with) nid71 44 FALSE nid143 (interacts with) nid36 45 FALSE nid142 (interacts with) nid162 46 FALSE nid190 (interacts with) nid136 47 FALSE nid100 (interacts with) nid221 48 FALSE nid64 (interacts with) nid126 49 FALSE nid29 (interacts with) nid119 50 TRUE nid1 (interacts with) nid193

AlexanderPico commented 4 years ago

Thanks for the thorough bug report. I've never seen this bug before!

As a quick workaround for you, I noticed that excluding your extra "cp..." columns appears to cleat up the issues. Try your tests with just createNetworkFromDataFrames(edges=edges[1:2]). My local testing shows that this reproducibly gives the correct result.

I will keep this issue open while I track down why your "cp..." columns confuse my simple functions :)

K-C-Martin commented 4 years ago

Thank you for responding so quickly! I'm glad that you can also reproduce it - I'd worried it was something unique to my setup.

Unfortunately edge attributes are something I need to be able to set, so the workaround of excluding them doesn't help me.

It doesn't seem like the problem has to do with either my naming the attribute columns, or the fact that the attributes have the same values as the nodes - the following gives the same issues:

library(igraph) library(RCy3)

edges <- read.csv('test edges.txt', stringsAsFactors = F)

names(edges) <- c("source", "target", "attr1", "attr2")

edges$attr1 <- 'test' edges$attr2 <- 'test'

edgelist <- as.matrix(edges[, c('source', 'target')]) newgraph <- graph_from_edgelist(edgelist)

edge_attr(newgraph, 'attr1') <- edges$attr1

createNetworkFromIgraph(newgraph)

AlexanderPico commented 4 years ago

Right. I can confirm the same issue with alternate names and with changed values, e.g., removing the "nid" prefix for all attribute values. Still looking...

AlexanderPico commented 4 years ago

I'm afraid this one has me stumped. I can't reproduce it when I step through the function code line-by-line. And it only sometimes reproduces when running the command. The difference between those two approaches... is not apparent to me.

For the purposes of your research, I would separate the steps of network creation and attribute loading, e.g.,

library(RCy3)
library(magrittr)
library(dplyr)

createNetworkFromDataFrames(edges=edges[,1:2])
edges <- edges %>%
    mutate(key=paste(cpsource, "(interacts with)", cptarget))
loadTableData(edges[,3:5],data.key.column = 'key', table = 'edge')

Let me know if this ever produces anomalous results for you. I'll continue to ponder this one, but won't likely have a solution in the next few days...

K-C-Martin commented 4 years ago

This works! Thank you Alexander!

I've rewritten my script to use loadTableData, and my node and edge attributes are pulling through reliably now (I've run it enough times that that tricksy 6-correct-8-incorrect pattern of outputs wouldn't fool me).

Thank you again - much appreciated!

K-C-Martin commented 4 years ago

The above solution does work, but needs a little tweaking in the case of a network having multiple edges between nodes (i.e. same source node, interaction type, and target node, but different attributes)... otherwise one set of attributes get assigned to each set of 'multiple' edges.

A workaround is to create the network using edges, then get the SUID assigned to the edges and match them up with the attributes, and then load the attributes using the SUID as the key (pardon the crude code):

createNetworkFromDataFrames(edges=edges[, c('source', 'interaction', 'target')])

# create key to match edge attributes with edge SUID
edges <- edges %>%
  mutate(key=paste(source, paste0('(', interaction, ')'), target))

# get SUID for edges and match with edge attributes
cy_edges <- getTableColumns(table = 'edge')
cy_edges <- cy_edges[order(cy_edges$name), ]
edges <- edges[order(edges$key), ]
edges$cpSUID <- cy_edges$SUID

# add edge attributes
loadTableData(subset(edges, select = -c(source, interaction, target)), 
              data.key.column = 'cpSUID', table.key.column = 'SUID',
              table = 'edge')

# add node attributes
loadTableData(nodes, data.key.column = 'id', table = 'node')
AlexanderPico commented 4 years ago

Right. That is literally the approach underlying what createNetworkFromDataFrame does... when it works :)

K-C-Martin commented 4 years ago

Mysterious! The above does work reliably from what I can tell (running it for 50 iterations on a loop like I did before, to check for a pattern like that sneaky 'right for 6, then wrong for 8' thing), but I'm looking forward to the cause of the original problem being identified at some point: I don't like 'mysterious' when it comes to code output!

sisterdot commented 4 years ago

thanks for developing RCy3! its a VERY useful package- for network visualization and for prepping "cys" files for collaborators.

also stumbled across the issue that the edge annotation of my "cys" files were inconsistent (comparing source, target, name, shared name columns) when using the createNetworkFromDataFrames function

R version 3.6.1 (2019-07-05)
Platform: x86_64-conda_cos6-linux-gnu (64-bit)
Running under: Debian GNU/Linux 9 (stretch)

other attached packages:
[1] RCy3_2.6.0

cytoscape                 3.7.2                hf1b8bbb_0    bioconda

got the wrong edge annotation also with the example list in ?createNetworkFromDataFrames so no extra edge annotation when trying to go through the code of createNetworkFromDataFrames step by step the edge table obtained using getTableColumns(table = 'edge') was as expected until after the

loadTableData(edges,data.key.column = 'data.key.column',
                          table = 'edge', table.key.column = 'SUID',
                           network = network.suid, base.url = base.url)

i am starting cytoscape on a server using Xvfb, before interacting with it with Rcy3.

for me the "problem" was solved by always using a "clean" cytoscape for each network (killing and restarting Xvfb). not sure why.

still- added a check of the edges annotation obtained from "getTableColumns(table = 'edge')" after the createNetworkFromDataFrames step, just to be on the safe side :-)

thanks!

AlexanderPico commented 4 years ago

Glad you found a solution. This one still has me stumped. I can run the ?createNetworkFromDataFrames example all day long and I get the exact same (correct) network everytime.

It's been hard for me to diagnose this one without a reproducible case...

sisterdot commented 4 years ago

this error is like a skinner box honestly :-o

with my cytoscape freshly started with Xvfb and running:

library(RCy3)
library(dplyr)

nodes <- data.frame(id=c("node 0","node 1","node 2","node 3"),
                    group=c("A","A","B","B"), # categorical strings
                    score=as.integer(c(20,10,15,5))) # integers
edges <- data.frame(source=c("node 0","node 0","node 0","node 2"),
                    target=c("node 1","node 2","node 3","node 3"),
                    interaction=c("inhibits","interacts",
                        "activates","interacts"),  # optional
                    weight=c(5.1,3.0,5.2,9.9))

sink("test1.txt")
for(i in 1:100){
    print(i)
    print(createNetworkFromDataFrames(nodes,edges))
    edgeCheck<-getTableColumns(table = "edge") %>% filter(!`shared name` == name)
     if(nrow(edgeCheck)){print(edgeCheck)}
}
sink()

i seem to "reproducibly" get 2 edge misassignment in a 100

[1] 26
Loading data...
Applying default style...
Applying preferred layout...
networkSUID 
        752 
  SUID               shared name shared interaction source target
1  768 node 0 (activates) node 3          activates node 0 node 1
2  769 node 2 (interacts) node 3          interacts node 0 node 2
3  766  node 0 (inhibits) node 1           inhibits node 0 node 3
4  767 node 0 (interacts) node 2          interacts node 2 node 3
  data.key.column weight                      name selected interaction
1             768    5.1  node 0 (inhibits) node 1    FALSE    inhibits
2             769    3.0 node 0 (interacts) node 2    FALSE   interacts
3             766    5.2 node 0 (activates) node 3    FALSE   activates
4             767    9.9 node 2 (interacts) node 3    FALSE   interacts

[1] 90
Loading data...
Applying default style...
Applying preferred layout...
networkSUID 
       2544 
  SUID               shared name shared interaction source target
1 2560 node 0 (activates) node 3          activates node 0 node 1
2 2561 node 2 (interacts) node 3          interacts node 0 node 2
3 2558  node 0 (inhibits) node 1           inhibits node 0 node 3
4 2559 node 0 (interacts) node 2          interacts node 2 node 3
  data.key.column weight                      name selected interaction
1            2560    5.1  node 0 (inhibits) node 1    FALSE    inhibits
2            2561    3.0 node 0 (interacts) node 2    FALSE   interacts
3            2558    5.2 node 0 (activates) node 3    FALSE   activates
4            2559    9.9 node 2 (interacts) node 3    FALSE   interacts

restarting cytoscape and running

sink("test2.txt")
for(i in 1:100){
    closeSession(FALSE)
    openSession()
    print(i)
    print(createNetworkFromDataFrames(nodes,edges))
    edgeCheck<-getTableColumns(table = "edge") %>% filter(!`shared name` == name)
     if(nrow(edgeCheck)){print(edgeCheck)}
}
sink()

i "sometimes" get the error

Exception in thread "AWT-EventQueue-0" java.lang.IllegalStateException: org.cytoscape.filter.internal.filters.composite.CompositeSeparator[,0,0,0x0,invalid,layout=java.awt.FlowLayout,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.synth.SynthBorder@a6913a7,flags=9,maximumSize=,minimumSize=,preferredSize=] is not attached to a horizontal group
    at javax.swing.GroupLayout.checkComponents(GroupLayout.java:1086)
    at javax.swing.GroupLayout.prepare(GroupLayout.java:1040)
    at javax.swing.GroupLayout.preferredLayoutSize(GroupLayout.java:878)
    at java.awt.Container.preferredSize(Container.java:1799)
    at java.awt.Container.getPreferredSize(Container.java:1783)
    at javax.swing.JComponent.getPreferredSize(JComponent.java:1664)
    at javax.swing.ViewportLayout.preferredLayoutSize(ViewportLayout.java:96)
    at java.awt.Container.preferredSize(Container.java:1799)
    at java.awt.Container.getPreferredSize(Container.java:1783)

and than i get only edge misassignments

[1] 45
Loading data...
Applying default style...
Applying preferred layout...
networkSUID 
      66023 
   SUID               shared name shared interaction                      name
1 66039 node 0 (activates) node 3          activates node 0 (interacts) node 2
2 66038 node 0 (interacts) node 2          interacts node 0 (activates) node 3
  selected interaction source target data.key.column weight
1    FALSE   interacts node 0 node 2           66039    3.0
2    FALSE   activates node 0 node 3           66038    5.2
[1] 46
Loading data...
Applying default style...
Applying preferred layout...
networkSUID 
      67490 
   SUID               shared name shared interaction                      name
1 67505 node 0 (interacts) node 2          interacts  node 0 (inhibits) node 1
2 67504  node 0 (inhibits) node 1           inhibits node 0 (interacts) node 2
3 67507 node 2 (interacts) node 3          interacts node 0 (activates) node 3
4 67506 node 0 (activates) node 3          activates node 2 (interacts) node 3
  selected interaction source target data.key.column weight
1    FALSE    inhibits node 0 node 1           67505    5.1
2    FALSE   interacts node 0 node 2           67504    3.0
3    FALSE   activates node 0 node 3           67507    5.2
4    FALSE   interacts node 2 node 3           67506    9.9
[1] 47
Loading data...
Applying default style...
Applying preferred layout...
networkSUID 
      68957 
   SUID               shared name shared interaction                      name
1 68973 node 0 (activates) node 3          activates node 0 (interacts) node 2
2 68972 node 0 (interacts) node 2          interacts node 0 (activates) node 3
  selected interaction source target data.key.column weight
1    FALSE   interacts node 0 node 2           68973    3.0
2    FALSE   activates node 0 node 3           68972    5.2
[1] 48
Loading data...
Applying default style...
Applying preferred layout...
networkSUID 
      70424 
   SUID               shared name shared interaction                      name
1 70439 node 0 (interacts) node 2          interacts  node 0 (inhibits) node 1
2 70438  node 0 (inhibits) node 1           inhibits node 0 (interacts) node 2
3 70441 node 2 (interacts) node 3          interacts node 0 (activates) node 3
4 70440 node 0 (activates) node 3          activates node 2 (interacts) node 3
  selected interaction source target data.key.column weight
1    FALSE    inhibits node 0 node 1           70439    5.1
2    FALSE   interacts node 0 node 2           70438    3.0
3    FALSE   activates node 0 node 3           70441    5.2
4    FALSE   interacts node 2 node 3           70440    9.9
[1] 49
Loading data...
Applying default style...
Applying preferred layout...
networkSUID 
      71891 
   SUID               shared name shared interaction                      name
1 71907 node 0 (activates) node 3          activates node 0 (interacts) node 2
2 71906 node 0 (interacts) node 2          interacts node 0 (activates) node 3
  selected interaction source target data.key.column weight
1    FALSE   interacts node 0 node 2           71907    3.0
2    FALSE   activates node 0 node 3           71906    5.2
[1] 50
Loading data...
Applying default style...
Applying preferred layout...
networkSUID 
      73358 
   SUID               shared name shared interaction                      name
1 73373 node 0 (interacts) node 2          interacts  node 0 (inhibits) node 1
2 73372  node 0 (inhibits) node 1           inhibits node 0 (interacts) node 2
3 73375 node 2 (interacts) node 3          interacts node 0 (activates) node 3
4 73374 node 0 (activates) node 3          activates node 2 (interacts) node 3
  selected interaction source target data.key.column weight
1    FALSE    inhibits node 0 node 1           73373    5.1
2    FALSE   interacts node 0 node 2           73372    3.0
3    FALSE   activates node 0 node 3           73375    5.2
4    FALSE   interacts node 2 node 3           73374    9.9
[1] 51
Loading data...
Applying default style...
Applying preferred layout...
networkSUID 
      74825 
   SUID               shared name shared interaction                      name
1 74841 node 0 (activates) node 3          activates node 0 (interacts) node 2
2 74840 node 0 (interacts) node 2          interacts node 0 (activates) node 3
  selected interaction source target data.key.column weight
1    FALSE   interacts node 0 node 2           74841    3.0
2    FALSE   activates node 0 node 3           74840    5.2
[1] 52
Loading data...
Applying default style...
Applying preferred layout...
networkSUID 
      76292 
   SUID               shared name shared interaction                      name
1 76307 node 0 (interacts) node 2          interacts  node 0 (inhibits) node 1
2 76306  node 0 (inhibits) node 1           inhibits node 0 (interacts) node 2
3 76309 node 2 (interacts) node 3          interacts node 0 (activates) node 3
4 76308 node 0 (activates) node 3          activates node 2 (interacts) node 3
  selected interaction source target data.key.column weight
1    FALSE    inhibits node 0 node 1           76307    5.1
2    FALSE   interacts node 0 node 2           76306    3.0
3    FALSE   activates node 0 node 3           76309    5.2
4    FALSE   interacts node 2 node 3           76308    9.9
[1] 53
Loading data...
Applying default style...
Applying preferred layout...
networkSUID 
      77759 
   SUID               shared name shared interaction                      name
1 77775 node 0 (activates) node 3          activates node 0 (interacts) node 2
2 77774 node 0 (interacts) node 2          interacts node 0 (activates) node 3
  selected interaction source target data.key.column weight
1    FALSE   interacts node 0 node 2           77775    3.0
2    FALSE   activates node 0 node 3           77774    5.2
[1] 54
Loading data...
Applying default style...
Applying preferred layout...
networkSUID 
      79226 
   SUID               shared name shared interaction                      name
1 79241 node 0 (interacts) node 2          interacts  node 0 (inhibits) node 1
2 79240  node 0 (inhibits) node 1           inhibits node 0 (interacts) node 2
3 79243 node 2 (interacts) node 3          interacts node 0 (activates) node 3
4 79242 node 0 (activates) node 3          activates node 2 (interacts) node 3
  selected interaction source target data.key.column weight
1    FALSE    inhibits node 0 node 1           79241    5.1
2    FALSE   interacts node 0 node 2           79240    3.0
3    FALSE   activates node 0 node 3           79243    5.2
4    FALSE   interacts node 2 node 3           79242    9.9

thats why i thought its more about cytoscape and cyrest than RCy3?

or is it because its friday?!?!?!

AlexanderPico commented 4 years ago

A Skinner Box is fairly predictable... I think you mean the box with Schrödinger's cat :)

Thanks for these test cases, I will try them out as well. I'll pass this "up the chain" to CyREST and other Cytoscape folks if I can isolate it.

sisterdot commented 4 years ago

great thanks! and thanks again for RCy3- it makes life so much easier!

ps. i meant the random pigeon box- although food dropped in at random the pigeons started linking the food to some behavioral pattern that accidentally coincided :-) https://io9.gizmodo.com/how-pigeons-get-to-be-superstitious-5746904

AlexanderPico commented 4 years ago

Oh, we are in the box? Ha, yes, perfect!

m-grimes commented 4 years ago

Alex

I am seeing a similar problem in both Cy 3.7.2 and 3.8.0. The cy "shared interaction" does not match "interaction" in the Cytoscape table. This is a problem because I use "interaction" to map edge color, width, etc. I'm trying to prepare a figure for the ISCB meeting and this is quite an impediment! Like others note above this problem is stochastic. I can plot a network several times and sometimes all the edges are misaligned, sometimes only some of them.

In the Styles tab, mapping for colors is set to "interaction" so the network window displays edge colors as if they were incorrectly mapped. Perhaps if I could set mapping to "shared interaction" - which is correct and matches "shared name" this could be a workaround but toggling them back and forth only removes all my color mapping.

Thanks for your attention to this,

Mark

Screenshot 2020-06-25 10 46 35
AlexanderPico commented 4 years ago

This was logged as a Cytoscape bug recently and should be fixed in the 3.8.1 release. That is probably a month or two away, however, so whatever workarounds you devise are the best current option. Perhaps using a custom column, e.g., "my interaction" or "type", instead of the inconsistently mananged special columns like "interaction" and "shared interaction"?

m-grimes commented 4 years ago

Good to know, thanks. This works for the edge problem discussed in my comment above:

setEdgeColorMapping( 'shared interaction', edgeTypes, edgecolors, 'd', default.color="#FFFFFF")

Something similar might work if node 'id', 'name', and 'shared name' don't match.

Mark

kfuku52 commented 3 years ago

I confirmed a similar problem with my dataset in Cytoscape v.3.8.2 and RCy3 2.10.0 (both latest). The use of loadTableData() worked like a charm.

pillepalle123 commented 3 years ago

Hi, I have exactly the same issue using Cytoscape 3.8.2 and RCy3 2.10.2 The "name" column matches the attributes (source, target, etc.) as they should, but the "shared name" column is sometimes random and not identical to the "name" column. Did I understand correctly that the issue couldn't have been located yet? I am using createNetworkFromIgraph for the transfer to Cytoscape

What I noticed: The columns "name" "shared name" "interaction" and "shared interaction" are written right at the start. Writing the attribute columns (source, target, etc) takes a little longer. So I have some time to check the columns. When I look at the "name" and "shared name" columns BEFORE the attributes are updated/added in Cytoscape, they match each other (are correct). Once the attribute columns are added/updated, the "shared name" column switches to the scrambled/wrong naming.

Is there any chance that I can fix this? Help would be really appreciated. thanx

m-grimes commented 3 years ago

The GItHUb version of RCy3 2.11 has a fix, but it won't be on Bioconductor for another month or so (Alex can confirm).

Meanwhile if you don't want to use the GitHub version you can just use a checking function as follows as a workaround.

createNetworkFromDataFrames.check <- function(nodes, edges, 

title="Checked", collection="Checked interactions") { for (i in 1:10){ createNetworkFromDataFrames(nodes, edges, title, collection) edgeTable <- getTableColumns("edge", c("name", "shared name")) if(!identical(edgeTable[,1], edgeTable[,2])) { print(paste('Network', i, "is bad.")) deleteNetwork()} else { print (paste("Network", i, "passes edge test.")) break } }}

If you get 10 failures just try again! Usually it works after just a few tries.

Mark

Mark Grimes Division of Biological Sciences University of Montana

On 19 Mar 2021, at 6:42, pillepalle123 wrote:

Hi, I have exactly the same issue using Cytoscape 3.8.2 and RCy3 2.10.2 The "name" column matches the attributes (source, target, etc.) as they should, but the "shared name" column is sometimes random and not identical to the "name" column. Did I understand correctly that the issue couldn't have been located yet? I am using createNetworkFromIgraph for the transfer to Cytoscape

What I noticed: The columns "name" "shared name" "interaction" and "shared interaction" are written right at the start. Writing the attribute columns (source, target, etc) takes a little longer. So I have some time to check the columns. When I look at the "name" and "shared name" columns BEFORE the attributes are updated/added in Cytoscape, they match each other (are correct). Once the attribute columns are added/updated, the "shared name" column switches to the scrambled/wrong naming.

Is there any chance that I can fix this? Help would be really appreciated. thanx

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/cytoscape/RCy3/issues/81#issuecomment-802806725

pillepalle123 commented 3 years ago

that's amazing. Thanks a lot! I installed the github version RCy3 2.11.5 and it seems to work now. Took me quite a while to figure out what was going on there. thx!

AlexanderPico commented 3 years ago

Terrific. And this fix is available as the "dev" version from Bioconductor: https://bioconductor.org/packages/devel/bioc/html/RCy3.html

The next Bioconductor "official" release will be in late April.