Clustering rows only generates error/exception

Issue #539 resolved
Robert Leach created an issue

USE CASE: WHAT DO YOU WANT TO DO?

Cluster rows only without error

STEPS TO REPRODUCE AN ISSUE (OR TRIGGER A NEW FEATURE)

  1. Open an older version cdt file (with GENE#X and ARRY#X GID and AID formats)
  2. command-c to cluster
  3. Change columns to "Leave unchanged"
  4. Click cluster

cluster_rows_only_settings.png

CURRENT BEHAVIOR

The following error is generated:

rows_only_error.png

This exception is generated:

Identifier ARRY127X from tree file not found in CDT.  Here's how many keys there were in the hash created from the CDT: 0
Root node is null or leaf in paint() in InvertedTreeDrawer!
Root node is null or leaf in paint() in InvertedTreeDrawer!
Identifier ARRY127X from tree file not found in CDT.
 - edu.stanford.genetics.treeview.plugin.dendroview.TreeDrawer.setData(TreeDrawer.java:291)
 - edu.stanford.genetics.treeview.plugin.dendroview.TreePainter.setData(TreePainter.java:1)
 - Controllers.DendroController.bindTrees(DendroController.java:1234)
 - Controllers.DendroController.bindComponentFunctions(DendroController.java:782)
 - Controllers.DendroController.setNewMatrix(DendroController.java:184)
 - Controllers.TVController.finishLoading(TVController.java:342)
 - edu.stanford.genetics.treeview.model.ModelLoader.done(ModelLoader.java:146)
 - javax.swing.SwingWorker$5.run(SwingWorker.java:737)
 - javax.swing.SwingWorker$DoSubmitAccumulativeRunnable.run(SwingWorker.java:832)
 - sun.swing.AccumulativeRunnable.run(AccumulativeRunnable.java:112)
 - javax.swing.SwingWorker$DoSubmitAccumulativeRunnable.actionPerformed(SwingWorker.java:842)
 - javax.swing.Timer.fireActionPerformed(Timer.java:313)
 - javax.swing.Timer$DoPostEvent.run(Timer.java:245)
 - java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
 - java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744)
 - java.awt.EventQueue.access$400(EventQueue.java:97)
 - java.awt.EventQueue$3.run(EventQueue.java:697)
 - java.awt.EventQueue$3.run(EventQueue.java:691)
 - java.security.AccessController.doPrivileged(Native Method)
 - java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
 - java.awt.EventQueue.dispatchEvent(EventQueue.java:714)
 - java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
 - java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
 - java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
 - java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
 - java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
 - java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

And the resulting clustering looks OK:

rows_only_result.png

Oddly enough, if you cluster columns only (leaving rows unchanged), you do not get this error.

EXPECTED BEHAVIOR

Clustering rows only using an older ID type should not cause an error, the same way clustering columns only using old IDs does not generate an error.

DEVELOPERS ONLY SECTION

SUGGESTED CHANGE (Pseudocode optional)

I would start by looking at the order of the column headers in the CDT file to see if a certain order is expected, and loosen that restriction. I already looked at the code where the exception is thrown and it turns out that the hash of the IDs from the CDT file is empty. So I would put a breakpoint above the exception in there and run the columns only clustering to see if the 2 clustering options (cols only and rows only) use the same code.

FILES AFFECTED (where the changes will be implemented) - developers only

TreeDrawer.java

LEVEL OF EFFORT - developers only

medium

COMMENTS

Related to issue #475

Comments (4)

  1. Robert Leach reporter

    OK, I have determined that when the cdt file is generated after clustering - if you cluster only rows - the AID row is being populated with the COMPLEX values and the AID values are being completely left out. So when that file is loaded, the id2node member hashtable inside the IntLabelInfo object gets populated with COMPLEX strings instead of AID strings, which doesn't match what's in the (old) .atr file's tree structure.

    So it looks like I have to trace the cdt file creation during/after clustering to find out why it's populating the AID row with the values from the COMPLEX row.

  2. Robert Leach reporter

    Resolved issue #539 - clustering rows only no longer yields an error complaining about a corrupt file when a cdt and atr file generated from an old version of treeview or any version of the cluster app is encountered.

    → <<cset 5a375c955a73>>

  3. Log in to comment