Additional testing:

Add http://lorainelab-quickload.scidas.org/hotpollen/ as a new data source.
Open the S_lycopersicum_Sep_2019 genome
Navigate to SL4.0ch02:48,738,056-48,738,176

Add the following scaled coverage graphs:
are 28 only, rep 1, scaled coverage
are 28 only, rep 2, scaled coverage
are 28 only, rep 3, scaled coverage
are 28 to 34, rep 1, scaled coverage
are 28 to 34, rep 2, scaled coverage
are 28 to 34, rep 3, scaled coverage

Click Load Data
Create Mean graphs for the two groups of 3
Hide the original 6 scaled coverage graphs
Create Diff graph from the means
Navigate to SL4.0ch02:48,737,813-48,738,983
Click Load Data 3 times

This appears to break the Diff graph as it should now show incorrect data.

If all data including mean and diff graphs are loaded at SL4.0ch02:48,737,813-48,738,983 they appear correctly (see img1.png). It is only when the view is zoomed in initially, the data loaded, and then zoomed out that the diff graph appears to become corrupted (see img2.png). From examining the y-coord in the corrupted diff track, it appears that the data are a copy of the bronze colored mean track (see img3.png). IGB also appears to have trouble rendering the track, which is why it appears on both the positive and negative axis in img2.png.

From this initial testing I can make a few guesses as to what might be happening. When IGB creates tracks based on multi-graph operators it first needs to load the data before calculating the multi-graph operator track. From the user's perspective they may need to click the Load Data button multiple times. In this example, there are two multi-graph operator tracks, so IGB needs to follow the correct order of operations to successfully create the diff of the means track. When I clicked load data it appeared that only one of the mean tracks was created successfully while the other was in limbo (see img4.png). Clicking load data again caused the corrupt diff track to appear.

In addition, once the corrupt diff track has appeared the track is broken from that point forward. Removing and reloading the track does not appear to fix the issue, only restarting IGB can correct the track. My guess would be that something is incorrectly being included in a data model for that track in IGB and is causing any attempt to further load data in the diff track to fail. However, nothing is appearing in the IGB logs.

While this is somewhat of an edge case I think it is worth further investigation as it could be very confusing for a user.

Tested on Mac 11.6.3 on IGB 9.1.8 release.

I think the next steps for this issue would be for someone to follow the steps outlined above to replicate the issue.

If the issue does appear to be repeatable, then I would suggest we create a new ticket to attempt to resolve the issue.

Followed above testing instructions on IGB 9.1.10 with the build date/time : 01-24-2022 15:26:44 and the latest commit id : 6015d4c2488ec0abab95bd36b2ff1d94b3c3f9be and Operating System - Windows 11.

The issue does appear repeatable.

Dr. Freese is creating a new ticket to resolve the issue.

Thank you Omkar Marne and Nowlan Freese. Moving to Done, with the expectation that Nowlan Freese will create a new issue to address this.

I think it is indeed an important issue to address because there is now way for a user to understand the sequence of events that need to be performed in order to achieve the correct result. Also, this issue may have been noticed prior to this. It would be worthwhile to search Jira for prior observations of this same problem.

I have created IGBF-3084 to further investigate this issue.