Closed kdahlquist closed 6 years ago
I gave some issues a 0.5 priority so that you have a menu of tasks to work on if you need a break from the priority 0 tasks. I don't mean them to be distracting, but they are either the next things we need to work on or relatively minor (I hope).
I updated the tasks.
From the previous meeting we've been working on the test file audit and familiarizing ourselves with the corresponding issues. I focused on the test file audit while @cazinge can talk about addressing the bug in output.m. I have a couple questions moving forward on the test audit that I will ask at the meeting.
We weren't able to get to it in the meeting, but am I able to go to the One Card Office and request access for Dahlquist's lab and the UH lab?
Sorry, @jtorre39, forgot to answer this. The permission for my lab should already be there, so you could get it coded at the OneCard office at any time. @bengfitzpatrick needs to chime in about the UH lab because he controls that.
Just to update, I've gotten OneCard access and can confirm that I have access to the lab in LSB.
For this week, I've been continuing work on the test file audit #361 and getting things squared away with that. I also completed registration for SCURR as well.
We've finished the poster for review and for this week I spent a long time finishing LSETest and removing its need for an input sheet. In the process I seemed to have discovered a bug related to compressmissingdata. GRNmap read in an input sheet and incorrectly made the compressed matrix which will be shown in the pictures below which are both incorrect.
The data cells in column 4 are incorrectly being appended to column 4 instead of column 3. This pushes the data cells that should be in column 4 to column 5. This bug might possibly be related to the inputsheet since it is a bit old or some oversight we did not catch. I will attach a link to the input sheet.
I see the difference in behavior although from my vantage point I don't yet have a full sense for what is going on here. I do agree that this would be a new issue. Write this up as a new issue, then at the meeting, assess whether this might block the data analysis team.
Copied the information I wrote here into a new issue. #380
Updating on this ticket due to having resolved these tickets without running the ENTIRE test suite to fully resolve, but #289, #185, and #375 have been tested for and resolved by my latest commit. The problem with these tickets pertained to information being copied over into rows that were one off, and similarly for the threshold b problem, the data was being carried over from a previous spreadsheet. I've written tests that check for the issue, but they're solely testing for the size of the tables rather than the values (which for threshold_b was the main issue), so for next week I'll be addressing that and finishing up more comprehensive tests for the L_Curve script.
Ran full test suite with Eddie's code to double check everything's passing. Everything's all good!
Double checking the input sheets for issue #361 has been taking a while. I've found at least one that had extra rows that no longer conformed to the current input sheet standards. In the meanwhile I updated the readme.md to describe each of the folders in the directory level under test_files.
Closing this and creating new list for Spring 2018 semester.
SCCUR abstract:
Issues on the verge of closure:
Next up:
Last on the list, if there is time:
At your work session today, before doing any "work" sit down and look at each of these issues and write out your plan of attack for these.