Clustering, when there's a row mismatch between gtr and cdt, results in a missing tree

[Robert Leach]

USE CASE: WHAT DO YOU WANT TO DO?

Cluster a .cdt file whose row clustering does not match existing .gtr file.

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

1. Open small_133x133.cdt
2. Cluster it with default clustering options

CURRENT BEHAVIOR

First, when the user opens the small_133x133.cdt file, the data is shown as unclustered instead of clustered:

When the user selects to cluster the data, the data should be run through the clustering algorithm regardless of whether the starting data is from a cdt file or not. (It doesn't appear as though that's what's happening, since no progress bar appears - though it could have happened quickly - I don't know.)

Appropriately, an error pops up:

but instead of clustering and generating an appropriate .gtr file, the malformed .gtr file is re-generated and then causes the above error every time you open the cdt. The user is unable to cluster the rows (even though the rows appear clustered in the matrix) and see the tree:

EXPECTED BEHAVIOR

When a problem occurs, throw out the .gtr file and re-cluster or regenerate a .gtr file, since the user intentionally initiated the clustering algorithm. Choosing to cluster should always run the data through the clustering algorithm and not rely on previously generated data.

DEVELOPERS ONLY SECTION

SUGGESTED CHANGE (Pseudocode optional)

Always run the clustering algorithm when the user initiates it.

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

unknown

LEVEL OF EFFORT - developers only

medium

COMMENTS

This issue is minor since the input cdt file that causes the problem, was generated by an older version of TreeView that evidently had a bug, which presumably is now fixed. However, the concept of always running the algorithm is a good idea since it promotes confidence in the tool.

[Christopher Keil]

@hepcat72 I believe this has been solved with the PR for #256. Please verify and close this issue, since it's been merged into master.

[Robert Leach]

Seems to work as far as the tree clustering is concerned, but I saw a weird side-effect. I'm not sure if it's the result of the PR or if it pre-existed (i.e. would have happened anyway if the tree had been properly generated in the first place). The resulting row tree did not show a blue background highlight until I hovered over it.

I was not able to reproduce this behavior upon subsequent attempts, however I also noticed that sometimes when the mouse hovers off treeview, the blue highlight background of the tree remains. It should not.

I suspect that this is probably an entirely separate issue, but it could be related to new code. Not sure. Can you see what I'm talking about on your end? Try moving your cursor off the window in different ways to see if you can get the blue background to remain... That seems more reproducible than the clustering thing I witnessed and they're likely related.

[Robert Leach]

OK, never mind. I see the issue also exists in my whizzing trees jar. At least, the highlight remaining - so I assume the cluster "side-effect" is also present and that it just got revealed when you fixed the other issue.

Setting to closed.

[Robert Leach]

Tested & confirmed 2/2/2016

[Christopher Keil]

I was just about to open an issue. Do you want to? The issue is a NullPointerException in RowTreeView right upon loading the new file.

Following line of code:

g.fillRect(0,(int) scaleEq.transform((double) map.getFirstVisibleLabel()), [..]

I suspect that

getFirstVisibleLabel()

returns null for some reason.

[Robert Leach]

I cannot seem to reproduce that error. How did you encounter it? What did you do when it occurred?

[Robert Leach]

Removing milestone: Clustering (automated comment)