Diffusion when multiple subnetworks and collections are present

[bdemchak]

When a diffusion is performed on a subnetwork in a collection, the columns are created at the collection level and the Results Panel is displayed. This is appropriate. Verify that when a different subnetwork in the same collection is selected, using the slider and other Results Panel controls operates on the newly selected subnetwork and not the original subnetwork. Additionally, when a subnetwork in another collection is selected, the Results Panel must reference columns in that collection, not the previously selected collection.

[keiono]

I think diffusion results should be a part of local table, not a collection because collection can share all nodes, but topology is always associated with a network. This will cause a problems when user loads multiple networks into a single collection.

[bdemchak]

Probably reasonable. That means that the diffusion controls should apply to local attributes and not global ones. Can you show Eric how to do this from a Cytoscape API perspective? This will also hit the service code ... when it extracts a subnetwork, it must capture the local attributes instead of the global ones.

[ericsage]

We changed the function call we were using to get the default node table to one that gets the local table for the network. This means that all columns are now written locally to the subnetworks, and we verified that the diffusion panel can read these local tables.

[bdemchak]

Did you also verify that the Python code receiving the local attributes treats them properly when selecting a subnetwork from a collection?

[keiono]

This is fixed by creating local column in the table, i.e., diffusion result is always associated with a network, not a collection.

[bdemchak]

Not quite. First, the diffusion_input is created as a shared column. It should be created as a local column. Next, if I change views to a collection that doesn't have any diffusion columns, shouldn't the Diffusion Output Range Column clear to indicate that no column is available for selection? And shouldn't the other controls be disabled? Likewise, when focus moves to a view that contains diffusion columns, the list and controls should be filled/enabled ... and the list should be positioned on the last diffusion column that was selected for it. Correct??

[keiono]

1. Change input data column to local, too
2. Add listener to the combobox and react to current network changed event(?)

[bdemchak]

Still broken. If I use galFiltered and create two different diffusions, then create separate networks from the diffusions and attempt to diffuse on the second new network, I get an error box:

The diffusion does seem successful, as it creates a new column and the Results Output dropdown does contain the old and new columns. However, selecting any of the Range Columns does not update the network with new selections. This is the behavior on both of the new networks and the original network.

More or less the same thing happens if I start with galFiltered and create two subnetworks, then Diffuse on nodes in the subnetwork.

[keiono]

Fixed in v1.2.3.

[bdemchak]

There is still a failure (v1.2.5) when moving between networks. It's possible to get the results panel and controls for the wrong network. Here's what I did.

1) Diffuse on galFiltered 2) Use the Rank slider to select the top 33 nodes 3) Hit the Create button (with size-rank style) 4) Make the new network current, and play with the Rank slider 5) Make the original network current ... the new network's controls (and limitations) are incorrectly applied to the original network.

See below. The original network has 331 nodes, but the Diffusion Output pane allows only up to node rank 33.

[keiono]

@bdemchak Is this really a 1.2.5 issue? I've tested with the latest version, but I could not reproduce it.

[bdemchak]

Unclear. When I restart Cytoscape (with 1.2.5 installed), I can't reproduce it either. This may have been an artifact of installing 1.2.3 and then 1.2.5 and then trying this sequence. Could there have been junk left over when 1.2.3 was replaced by 1.2.5?