read.flowSet or read.FCS no longer working after updating from R 3.6.3 to R 4.0.2 on BD Accuri C6 data

[FMKerckhof]

Describe the bug

I have a dataset of about 1900 FCS files from the BD Accuri C6, which used to load just fine into a flowSet when running R 3.6.3. After updating to R 4.0.2 I get a fatal R error, even when loading just one of these files.

This behavior is consistent on both Linux (Ubuntu 18.04.5 LTS) and Windows (Win10).

To Reproduce

It's not very easy to provide a reproducible example, since I need to share the raw FCS files to do so. I created a download link using BelNet (sharing platform for Belgian universities) that has a temporary validity (until 31/8) - for 11 of the files.

Your code here.

library("flowCore")
file_location <- "your/path/to/the/files"
# flowFrame example 
fftest <- read.FCS(paste0(file_location,"/A01 T1.D10.3.B_FRESH_SG_20x.fcs"))
# CRASH on R 4.0.2, runds fine on R 3.6.3
# flowSet examples
fstest <- read.flowSet(path=file_location,pattern="*.fcs",emptyValue = FALSE,as.is = TRUE,ignore.text.offset = TRUE)
# CRASH on R 4.0.2, runds fine on R 3.6.3

sessionInfo() under R 4.0.2 (on Win)

R version 4.0.2 (2020-06-22)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 18362)

Matrix products: default

locale:
[1] LC_COLLATE=Dutch_Belgium.1252  LC_CTYPE=Dutch_Belgium.1252    LC_MONETARY=Dutch_Belgium.1252
[4] LC_NUMERIC=C                   LC_TIME=Dutch_Belgium.1252    

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] flowCore_2.0.1

loaded via a namespace (and not attached):
 [1] Rcpp_1.0.5          compiler_4.0.2      cytolib_2.0.3       prettyunits_1.1.1   remotes_2.2.0       tools_4.0.2        
 [7] testthat_2.3.2      digest_0.6.25       packrat_0.5.0       pkgbuild_1.1.0      pkgload_1.1.0       evaluate_0.14      
[13] memoise_1.1.0       rlang_0.4.7         cli_2.0.2           rstudioapi_0.11     yaml_2.2.1          parallel_4.0.2     
[19] xfun_0.16           withr_2.2.0         knitr_1.29          desc_1.2.0          fs_1.5.0            devtools_2.3.1     
[25] stats4_4.0.2        rprojroot_1.3-2     glue_1.4.1          Biobase_2.48.0      R6_2.4.1            processx_3.4.3     
[31] fansi_0.4.1         rmarkdown_2.3       sessioninfo_1.1.1   RProtoBufLib_2.0.0  callr_3.4.3         magrittr_1.5       
[37] matrixStats_0.56.0  backports_1.1.8     ps_1.3.4            ellipsis_0.3.1      htmltools_0.5.0     usethis_1.6.1      
[43] BiocGenerics_0.34.0 assertthat_0.2.1    RcppParallel_5.0.2  crayon_1.3.4       

sessionInfo() under R 4.0.2 (on Linux)

R version 4.0.2 (2020-06-22)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.5 LTS

Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.7.1
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.7.1

locale:
 [1] LC_CTYPE=en_IE.UTF-8       LC_NUMERIC=C               LC_TIME=en_IE.UTF-8        LC_COLLATE=en_IE.UTF-8    
 [5] LC_MONETARY=en_IE.UTF-8    LC_MESSAGES=en_IE.UTF-8    LC_PAPER=en_IE.UTF-8       LC_NAME=C                 
 [9] LC_ADDRESS=C               LC_TELEPHONE=C             LC_MEASUREMENT=en_IE.UTF-8 LC_IDENTIFICATION=C       

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] flowCore_2.0.1

loaded via a namespace (and not attached):
 [1] Rcpp_1.0.5          matrixStats_0.56.0  RProtoBufLib_2.0.0  digest_0.6.25       stats4_4.0.2       
 [6] evaluate_0.14       RcppParallel_5.0.2  rlang_0.4.7         rmarkdown_2.3       tools_4.0.2        
[11] Biobase_2.48.0      xfun_0.16           yaml_2.2.1          parallel_4.0.2      compiler_4.0.2     
[16] BiocGenerics_0.34.0 cytolib_2.0.3       htmltools_0.5.0     knitr_1.29 

sessionInfo() under R 3.6.3 (on Win)

R version 3.6.3 (2020-02-29)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 18362)

Matrix products: default

locale:
[1] LC_COLLATE=Dutch_Belgium.1252  LC_CTYPE=Dutch_Belgium.1252    LC_MONETARY=Dutch_Belgium.1252
[4] LC_NUMERIC=C                   LC_TIME=Dutch_Belgium.1252    

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] flowCore_1.52.1

loaded via a namespace (and not attached):
 [1] Rcpp_1.0.5          compiler_3.6.3      BiocManager_1.30.10 remotes_2.2.0       prettyunits_1.1.1   tools_3.6.3        
 [7] testthat_2.3.2      digest_0.6.25       packrat_0.5.0       pkgbuild_1.1.0      pkgload_1.1.0       evaluate_0.14      
[13] memoise_1.1.0       rlang_0.4.7         cli_2.0.2           rstudioapi_0.11     yaml_2.2.1          parallel_3.6.3     
[19] xfun_0.16           withr_2.2.0         knitr_1.29          fs_1.5.0            desc_1.2.0          devtools_2.3.1     
[25] stats4_3.6.3        rprojroot_1.3-2     glue_1.4.1          Biobase_2.46.0      R6_2.4.1            processx_3.4.3     
[31] fansi_0.4.1         rmarkdown_2.3       sessioninfo_1.1.1   callr_3.4.3         magrittr_1.5        usethis_1.6.1      
[37] backports_1.1.8     ps_1.3.4            matrixStats_0.56.0  ellipsis_0.3.1      htmltools_0.5.0     BiocGenerics_0.32.0
[43] assertthat_0.2.1    crayon_1.3.4       

Are there major changes between flowCore 1.52.1 for R 3.6.1 and flowCore 2.0.1 which would cause this very undesirable behavior (complete seizing up of R session, crashing into fatal error)?

[jacobpwagner]

Thanks for the example files, @FMKerckhof. Many of the files you provided actually parse correctly, but the difference between the ones that do and the ones that don't is how they write out the spillover matrix under the SPILLOVER keyword.

Here is the relevant section from one of the files that does not work:

$SPILLOVER/8,3,4,5,6,9,10,11,12,1,000,0,000,0,000,0,000,0,000,0,000,0,000,0,000,0,000,1,000,0,000,0,000,0,000,0,000,0,000,0,000,0,000,0,000,1,000,0,000,0,000,0,000,0,000,0,000,0,000,0,000,0,000,1,000,0,000,0,000,0,000,0,000,0,000,0,000,0,000,0,000,1,000,0,000,0,000,0,000,0,000,0,000,0,000,0,000,0,000,1,000,0,000,0,000,0,000,0,000,0,000,0,000,0,000,0,000,1,000,0,000,0,000,0,000,0,000,0,000,0,000,0,000,0,000,1,000/#BDACCURICAPTUREDDATE/1556534999760/$TIMESTEP/0.1/$PROJ/20190429_133741/$BTIM/12:50:15:29/$ETIM/12:51:01:84/#ATIM/46/#ACQUISITIONTIMEMILLI/46581/$VOL/50043/$BEGINSTEXT/58/$ENDSTEXT/2572/$BEGINDATA/2573/$ENDDATA/1461541/$BEGINANALYSIS/0/$ENDANALYSIS/0/#SPACERS/000/

While this is the relevant section from one that does work:

$SPILLOVER/8,FL1-A,FL2-A,FL3-A,FL4-A,FL1-H,FL2-H,FL3-H,FL4-H,1.0000,0.0000,0.0000,0.0000,0.0000,0.0000,0.0000,0.0000,0.0000,1.0000,0.0000,0.0000,0.0000,0.0000,0.0000,0.0000,0.0000,0.0000,1.0000,0.0000,0.0000,0.0000,0.0000,0.0000,0.0000,0.0000,0.0000,1.0000,0.0000,0.0000,0.0000,0.0000,0.0000,0.0000,0.0000,0.0000,1.0000,0.0000,0.0000,0.0000,0.0000,0.0000,0.0000,0.0000,0.0000,1.0000,0.0000,0.0000,0.0000,0.0000,0.0000,0.0000,0.0000,0.0000,1.0000,0.0000,0.0000,0.0000,0.0000,0.0000,0.0000,0.0000,0.0000,1.0000/#BDACCURICAPTUREDDATE/1556433871668/$TIMESTEP/0.1/$PROJ/20190613_171144/$BTIM/13:44:48.16/$ETIM/13:45:34.81/#ATIM/46/#ACQUISITIONTIMEMILLI/46832/$TR/FL1-H,1000/#SECONDARYTHRESHOLD/FL1-H,1000/$VOL/50213/#P1MaxUsefulDataChannel/786431/#P2MaxUsefulDataChannel/8191/#P3MaxUsefulDataChannel/57343/#P4MaxUsefulDataChannel/10239/#P5MaxUsefulDataChannel/5119/#P6MaxUsefulDataChannel/511/#P7MaxUsefulDataChannel/127999/#P8MaxUsefulDataChannel/8191/#P9MaxUsefulDataChannel/81919/#P10MaxUsefulDataChannel/23551/#P11MaxUsefulDataChannel/6143/#P12MaxUsefulDataChannel/1087/#P13MaxUsefulDataChe U6`+bh|0|.4Max(U=1s R=taChannel/611/$BEGINSTEXT/58/$ENDSTEXT/4429/$BEGINDATA/4430/$ENDDATA/3399093/$BEGINANALYSIS/0/$ENDANALYSIS/0/#SPACERS/000/

The difference here is that, while both define the non-standard #SPACERS keyword, the first (problematic) file actually utilizes that defined spacer within the spillover matrix definition. I'm guessing this is so BD's software can use it for sparse storage.

The parsing of the spillover matrix was switched to wrapping a C++ level parser by this commit. That parser works correctly for properly defined SPILLOVER keywords, but my guess is that the R-level logic was silently handling conversion of the spacer from "000" to 0.0:

> as.numeric("000")
[1] 0

while this needs to be done more explicitly in the C++ parser. I'll work on a fix to tolerate this, or at least provide a more graceful error.

[jacobpwagner]

Actually there are just many ways that the problematic SPILLOVER matrices in these files are incorrectly written. I will still see what should be done to more gracefully handle them, but the files themselves are essentially invalid.

Even if you revert before that commit so those problematic files will parse, you can see that the spillover matrices brought in are not carrying the channels as they should (because the PnN values are missing from SPILLOVER in the fcs).

> spillmat <- spillover(fr)$`$SPILLOVER`
> spillmat
      3 4 5 6 9 10 11 12
 [1,] 1 0 0 0 0  0  0  0
 [2,] 0 0 0 0 0  0  0  0
 [3,] 0 0 1 0 0  0  0  0
 [4,] 0 0 0 0 0  0  0  0
 [5,] 0 0 0 0 1  0  0  0
 [6,] 0 0 0 0 0  0  0  0
 [7,] 0 0 0 0 0  0  1  0
 [8,] 0 0 0 0 0  0  0  0
 [9,] 0 0 0 0 0  0  0  0
[10,] 1 0 0 0 0  0  0  0
[11,] 0 0 0 0 0  0  0  0
[12,] 0 0 1 0 0  0  0  0
[13,] 0 0 0 0 0  0  0  0
[14,] 0 0 0 0 1  0  0  0
[15,] 0 0 0 0 0  0  0  0
[16,] 0 0 0 0 0  0  1  0
> compensate(fr, spillmat)
Error: test_pre.fcs
The following parameters in the spillover matrix
 are not present in the flowFrame:
3, 4, 5, 6, 9, 10, 11, 12
> colnames(fr)
 [1] "FSC-A" "SSC-A" "FL1-A" "FL2-A" "FL3-A" "FL4-A" "FSC-H" "SSC-H" "FL1-H"
[10] "FL2-H" "FL3-H" "FL4-H" "Width" "Time" 
> markernames(fr)
[1] "FL1-A" "FL2-A" "FL3-A" "FL4-A" "FL1-H" "FL2-H" "FL3-H" "FL4-H" "Width"

[FMKerckhof]

Thank you for the clear and swift reply, @jacobpwagner , much appreciated!

The errors are puzzling. All FCS files have been generated on the same machine using the same software (Accuri C6 csampler software). Do you think locale settings on the acquisition machine could affect this (e.g. "," as decimal separator)?

We did a re-analysis of fixated samples on the updated version of the system (BD Accuri C6+, we own both a C6 and C6+), where no issues occur on loading the flowSet, so it appears BD resolved the issue in later versions of the acquisition software.

The files have been uploaded to the flowRepository (not public yet) without issues, but indeed appear to be missing the correct parameters in the spillover matrix.

As a side-note: For microbial FCM data (which this is) we rarely use more than two colors (although we'd love to use more, see WS15 in https://doi.org/10.1002/cyto.a.23777). For these samples only SYBR-green I was used as a general nucleic acid stain, where we do not need compensation (hence we didn't notice the issue ourselves). Still, we record all parameters for use with our own microbial fingerprinting method, Phenoflow, which also relies on flowCore and others (and I'd like to take this as an opportunity to say thanks to you and the other RGLab members for making flowCore happen).

To "make a case" for the fixes: many microbial cytometrists have a lot of historical data on the BD Accuri C6: it was a very affordable 2-laser instrument that found its way into many labs. Currently it is gradually being replaced by instruments like the BC CytoFlex (or Thermo Attune NXT in our case), but we have 1000s of FCS files of this device in our lab alone. The Accuri machines have many limitations but they are incredibly compact, which allow us to take them "in the field". The samples I shared with you were collected "on farm" and quite often we hook the C6 up to a OnCyt autosampler, which stains and automatically injects a sample from different lines every 15 min (which we can leave running for weeks, accumulating a ton of FCS files). An example of such an application in a water tower you can see here. As you can imagine, in this way we can create huge datasets which we'd love to keep on processing.

p.s.: for now, I solved the issue by temporary loading the files to a flowSet in R 3.6.3, and exporting the flowSet using saveRDS for use in R 4.0.2

[jacobpwagner]

Ah, yeah. You're probably right that it is using the comma as a decimal separator because of the locale. Then it's clearly an identity matrix rather than the nonsense it appears to be in the example pasted in my last message. Sorry, I somehow missed that yesterday.

Thanks for the background. Having spent more time in mammalian biology, I love hearing about other applications of flow cytometry and it helps inform the work we do by knowing the user base. In particular it's also nice to hear about field work nowadays as outside time has been pretty limited... And it's understandable that you'd want to be able to keep working with the mountain of data you've generated so I'll see what I can do.

I'll try to handle or at least catch this locale issue in the relevant cytolib code or at least guard against this allocation fault which is probably the result of the incorrect dimensions yielded by splitting the comma-decimal representations to multiple entries.

[jacobpwagner]

@FMKerckhof , https://github.com/RGLab/cytolib/commit/e2f3d9cf7f154f88168b31e70f34b8656923684c should fix this. The logic will be unchanged for samples with properly-defined spillover matrices, but it will now also handle cases like yours that use a different decimal separator, albeit with a warning:

> library(flowCore)
> library(flowWorkspace)
As part of improvements to flowWorkspace, some behavior of
GatingSet objects has changed. For details, please read the section
titled "The cytoframe and cytoset classes" in the package vignette:

  vignette("flowWorkspace-Introduction", "flowWorkspace")
> fr <- read.FCS("test_pre.fcs")
SPILLOVER keyword value is of improper size for number of spillover channels!
SPILLOVER size discrepancy was resolved by assuming non-standard decimal delimiter.
> fr
flowFrame object 'test_pre.fcs'
with 26053 cells and 14 observables:
            name        desc     range  minRange  maxRange
$P1        FSC-A       FSC-A  16777216         0  16777215
$P2        SSC-A       SSC-A  16777216         0  16777215
$P3        FL1-A       FL1-A  16777216         0  16777215
$P4        FL2-A       FL2-A  16777216         0  16777215
$P5        FL3-A       FL3-A  16777216         0  16777215
...          ...         ...       ...       ...       ...
$P10       FL2-H       FL2-H  16777216         0  16777215
$P11       FL3-H       FL3-H  16777216         0  16777215
$P12       FL4-H       FL4-H  16777216         0  16777215
$P13       Width       Width  16777216         0  16777215
$P14        Time        Time  16777216         0  16777215
159 keywords are stored in the 'description' slot
> spillover(fr)
$SPILL
NULL

$spillover
NULL

$`$SPILLOVER`
     3 4 5 6 9 10 11 12
[1,] 1 0 0 0 0  0  0  0
[2,] 0 1 0 0 0  0  0  0
[3,] 0 0 1 0 0  0  0  0
[4,] 0 0 0 1 0  0  0  0
[5,] 0 0 0 0 1  0  0  0
[6,] 0 0 0 0 0  1  0  0
[7,] 0 0 0 0 0  0  1  0
[8,] 0 0 0 0 0  0  0  1

Notice that it now is getting the dimensions on the simple identity spillover matrix correct. In the case of a spillover matrix with truly improper number of entries (I just made a dummy broken example), it will still error out, but with a more helpful message and no bad allocation from bad vector access:

> fr <- read.FCS("test_broken.fcs")
SPILLOVER keyword value is of improper size for number of spillover channels!
Error in string_to_spill(txt) : 
  SPILLOVER size discrepancy could not be resolved!

load_cytoframe_from_fcs converges on the same logic for handling the spillover string. So all of that will apply for load_cytoframe_from_fcs as well.

I'll move the changes over to Bioconductor, so they should be available from the Bioconductor devel branch within in a few days, but if you don't want to wait, you can install from GitHub. Just keep in mind that you will need to re-install cytolib and all packages that depend on it (e.g. flowCore, flowWorkspace, and CytoML).

[FMKerckhof]

Hi @jacobpwagner , thank you very much for this. I will wait until it is on Bioconductor before I roll out to our production servers (to streamline updating), but if users need it more urgently we can look into the GitHub solution.

[jacobpwagner]

@FMKerckhof , the updates should be available from Bioconductor now.

[rprops]

Hi @jacobpwagner I tried both the latest dev (v2.1.2) and also the current Bioconductor version (v2.0.1) and I'm still getting crashes when loading the data with read.flowSet.

R version 4.0.2 (2020-06-22) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 10 x64 (build 17134)

Matrix products: default

locale: [1] LC_COLLATE=Dutch_Belgium.1252 LC_CTYPE=Dutch_Belgium.1252
[3] LC_MONETARY=Dutch_Belgium.1252 LC_NUMERIC=C
[5] LC_TIME=Dutch_Belgium.1252

attached base packages: [1] stats graphics grDevices utils datasets methods
[7] base

loaded via a namespace (and not attached): [1] compiler_4.0.2 tools_4.0.2 yaml_2.2.1

[jacobpwagner]

@rprops, can you give me the output of packageVersion("cytolib")? The fix was at the cytolib level and I didn't bump the dependency, so chances are re-installing flowCore didn't prompt an update of cytolib.

[rprops]

@jacobpwagner Hi Jacob, see below:

> packageVersion("cytolib")
[1] ‘2.0.3’

[jacobpwagner]

Yeah, your cytolib installation is too old to have the fixing commit. The commit was put in before 2.1.16 and should be present in the development branch from Bioconductor or from GitHub, so please try re-installing cytolib and flowCore from one of those two sources.

[rprops]

@jacobpwagner issue still remains: R Session Aborted.

R version 4.0.2 (2020-06-22)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 17134)

Matrix products: default

locale:
[1] LC_COLLATE=Dutch_Belgium.1252  LC_CTYPE=Dutch_Belgium.1252   
[3] LC_MONETARY=Dutch_Belgium.1252 LC_NUMERIC=C                  
[5] LC_TIME=Dutch_Belgium.1252    

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] flowCore_2.1.2

loaded via a namespace (and not attached):
 [1] Rcpp_1.0.5          matrixStats_0.57.0  RProtoBufLib_2.0.0 
 [4] digest_0.6.25       cellranger_1.1.0    stats4_4.0.2       
 [7] evaluate_0.14       RcppParallel_5.0.2  rlang_0.4.7        
[10] readxl_1.3.1        S4Vectors_0.26.1    rmarkdown_2.4      
[13] tools_4.0.2         Biobase_2.48.0      xfun_0.18          
[16] yaml_2.2.1          parallel_4.0.2      compiler_4.0.2     
[19] BiocGenerics_0.34.0 cytolib_2.1.19      htmltools_0.5.0    
[22] knitr_1.30         

[jacobpwagner]

A couple of questions: 1) Is this with the same files from @FMKerckhof 's original post? If not, can you provide me the files somehow? 2) How did you re-install flowCore after re-installing cytolib? If it did not see an updated SHA1 hash (because you had just updated flowCore), it might have just skipped re-installing from source. To be on the safe side, if you could just purge the flowCore installation directory before re-installing or at least use devtools::install_github("RGLab/flowCore", force = TRUE) to skip the SHA check, that would help ensure you are getting a fresh installation of flowCore utilizing the updated cytolib.

Point number 2 is important because flowCore needs to be recompiled against the updated compensation.hpp header in cytolib.

[FMKerckhof]

Hi @jacobpwagner, as you tagged me: this is not the same data but it is generated using a comparable instrument/software/regionale setting (not the same instrument though). It got me thinking about this issue, so I suggested to Ruben to see if it fixed the issue and otherwise flag it to you. Additional thought: if installed through BioConductor (even dev branch) will flowCore be compiled on Win? AFAIK R on Win mainly uses binaries, unless Rtools is installed.

[jacobpwagner]

True, for Bioconductor. As Ruben's cytolib version moved to 2.1.19, I assumed he was working with the GitHub branches rather than Bioconductor, in which case flowCore would be built from source and need to be rebuilt.

However, your point about the Bioconductor binaries is a good one and I think it may just be a matter of timing. Bioconductor will only re-compile binaries when it sees a version bump to the package. The last version bump to flowCore came only two days after the fix for this issue, so depending on when each was respectively merged to the Bioconductor repositories, it's possible that the current flowCore binary available there was built before this fix was merged over.

Let me add a version bump to flowCore on Bioconductor to trigger a rebuild there and test it in a few days when the new binary is available. In the meantime, if Ruben is using the GitHub branches to build from source using Rtools (which appears to be the case given the cytolib version), then forcing a clean rebuild of flowCore should bring in the fix.

But if it really still fails with these new files, then I can take a look to see if there is another issue to be dealt with.

[rprops]

@jacobpwagner devtools::install_github("RGLab/flowCore", force = TRUE) did the trick. Thanks a bunch for the rapid response! It is enormously appreciated!

R version 4.0.2 (2020-06-22)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 17134)

Matrix products: default

locale:
[1] LC_COLLATE=Dutch_Belgium.1252 
[2] LC_CTYPE=Dutch_Belgium.1252   
[3] LC_MONETARY=Dutch_Belgium.1252
[4] LC_NUMERIC=C                  
[5] LC_TIME=Dutch_Belgium.1252    

attached base packages:
[1] stats     graphics  grDevices utils     datasets 
[6] methods   base     

other attached packages:
[1] flowCore_2.1.3

loaded via a namespace (and not attached):
 [1] compiler_4.0.2      RProtoBufLib_2.0.0 
 [3] cytolib_2.1.19      parallel_4.0.2     
 [5] tools_4.0.2         yaml_2.2.1         
 [7] Rcpp_1.0.5          Biobase_2.48.0     
 [9] S4Vectors_0.26.1    BiocGenerics_0.34.0
[11] matrixStats_0.57.0  RcppParallel_5.0.2 
[13] stats4_4.0.2    

[jacobpwagner]

Going ahead and closing this now, as the problem seems to be solved and the fix should be in Bioconductor in a few days. Feel free to re-open it if you run in to any more problems, however.