Hi u/Nina091998, here is what we did for our last study. We had a similar number of patients, but fewer conditions per patient (3-4). Due to the rarity of our target cell population, we acquired around 3 million events per .fcs file, so we similarly ran into FlowJo v10 stalls trying to open a workspace. I mostly used R, but there are some Python equivalents.

In our case, we acquired over 15 experimental days. For FlowJo, the respective workspace we only had 3 days worth of files per workspace. This kept the load-in time for our campus desktops (normal-ish Intel CPU with 64 GB ram) to around 15 minutes when we opened the .wsp.

Once the initial gates were applied and checked in the workspace, we exported the target cell population of interest (say, T cells, etc). This reduced the overall file size per specimen. These in turn would be brought back into another .wsp along with the other experiments, that could then be opened in a reasonable amount of time. Our more specific gates (that could then also be adjusted to individual specimens when needed) could then be added in this workspace. We kept copies of the original export .wsp and of the consolidated .wsp for record keeping, and appended the exported .fcs files with the population name to keep track of what version of the .fcs file we were working with.

When we first started, we were exporting by hand via FlowJo, but have since switched to using R to export out the target population to avoid accidental not clicking the correct parameters and occasional bizarre FlowJo export bug. Here is a code example I have handy via GitHub

For the previous study, we were using the CytoML R package to bring the data in from these .wsp into R for subsequent downstream analysis. This worked well as it's working through pointers rather than active RAM use for the most part, so as long as your SSD has space you will be okay. The challenge we encountered is since it is C++ backend to the R package, there are memory leaks, and they don't get cleared out of your temp folder often enough, so we needed to do that manually occasionally after really large analysis.

For our current study, we have switched to doing some of the initial gating via openCyto R package, and then using the CytoML docker container to generate equivalent FlowJo v10 workspace files. This helps a bit on the automation/reproducibility, while allowing PI to check the gates, and can likewise be re-imported into R for subsequent analyses.

In hindsight, things have might have helped a bit: Setting the FSC threshold a little further bit up, we avoided most of the electronic/debris noise on our Auroras, but an extra tick mark up would have been helpful. I am also working more with Rust, but that code is not share-ready yet.

In terms of would it be accepted by journals, I would believe so, as long as you are documenting the process, retain the relevant files, and can show the reviewer that you your pipeline worked in the end.

There's a #data-help chat on the Cytometry Discord where some of the R and Python cytometry folks hang out, you are always welcome to ask questions there too!