Issue reproducing FlowJo gating (exactly) in flowWorkspace

[phauchamps]

Hi Mike and Team,

I am currently struggling with reproducing the manual gating as performed in FlowJo, into an R script, which I need to automate the calculation of concordance metrics between manual gating in FlowJo, and automated gating in R. For this, I am using flowWorkspace, which can read a .wsp workspace file -as generated/saved by FlowJo. It seems to technically work, but I still obtain discrepancies between the application of the gating in R (with flowWorkspace gating objects), and the same process in FlowJo. The event labels (in or out specific gated populations) I obtain are not exactly the same, with sometimes very different percentage of events for the gating of rarer populations, and I suspect the main differences are due to math formula/code variations in the scale transformations (FlowJo vs. flowCore in C++).

In particular, the transfo type and parameters I am currently investigating are the following (from FlowJo .wsp file):

<transforms:biex transforms:length="256"  transforms:maxRange="262144"  transforms:neg="0"  transforms:width="-100"  transforms:pos="4.418539922" >
           <data-type:parameter data-type:name="Comp-Alexa Fluor 700-A" />
</transforms:biex>

Have you noticed/heard of such issues before and would you have advice to improve the matching between both implementations?

Thanks a lot,

Philippe

[mikejiang]

when you parse a wsp into a gatingset, it is expected to see minor difference between xml stats and opencyto stats, e.g.

> gh_pop_compare_stats(gh)
    openCyto.freq   xml.freq openCyto.count xml.count            node
 1:    1.00000000 1.00000000         119531    119531            root
 2:    0.76733232 0.76733232          91720     91720      not debris
 3:    0.94877889 0.94889882          87022     87033        singlets
 4:    0.62608306 0.62892236          54483     54737            CD3+
 5:    0.62463521 0.62266840          34032     34083             CD4
 6:    0.03299835 0.03297832           1123      1124     CD4/38- DR+

however, if you observe the significant difference, there might be parsing issue with this particular workspace, which we will need an example to troubleshoot

[phauchamps]

Hi Mike,

With the new insight coming from your answer, I did a bit of further investigation on my side.

Actually I was using flowWorkspace to apply a gating hierarchy defined in FlowJo, to a new fcs file, which in this case was supposed to correspond - in terms of data points - to the original data file that was imported in flowJo.

I found out that the main discrepancies I had found were due to a mismatch of compensation matrix between flowJo and my R code (flowJo was not using the acquired compensation matrix for this particular sample, but a copy which had been manually updated). So nothing to do with flowWorkspace code :-)

On top of that, I found a couple of other sources of more minor discrepancies, which I thought I could provide here for information:

• FlowJo polygon gates have a resolution parameter (set silently in the workspace) that is set by default to 256. With that set-up, minor discrepancies in the 'in-events' set are observed. Increasing this parameter manually in the .wsp file lead to better match with flowWorkspace, as confirmed by FlowJo tech support (gate resolution is a calculation time optimization). However, note that this setting update cannot be done from FlowJo GUI.
• In my code, I was calling CytoML::flowjo_to_gatingset() with execute = FALSE (as the gating needs to be applied on new data), but without explicitly specifying extend_val and extend_to parameters. Because of this, my singlet gate, that was defined with negative coordinate vertices did not match the gating in FlowJo. I solved this by setting extend_val = -Inf in my code.
• Finally there was an issue with the reproduction of the time gate threshold that was present in my FlowJo gating, and I found out this was a side effect of the [following]: https://docs.flowjo.com/flowjo/experiment-based-platforms/kinetics/how-flowjo-handles-time/ Due to this change, the scale factor that FlowJo uses for the time channel is no more equal to $TIMESTEP (0.01 is most cases), but to a slightly different number, that is provided in the .wsp file in the transformation attached to the time channel. This ‘gain’ parameter, as soon as it is correctly calculated and provided, allows flowWorkspace to correctly apply gating in the time channel dimension. However, for some reasons I was not able to isolate, it sometimes happens (but not always) that FlowJo does not correctly output this ‘gain’. I did not find any impact of this issue in FlowJo itself, but it creates a mismatch when using flowWorkspace. I was able to work-around this by applying the inverse mismatch (calculating myself what the gain parameter should be) on the time channel data, prior to calling flowWorkspace. I raised an issue to FlowJo tech support, not sure they would bother looking at this further.

In very short, you can now close this issue, as soon as you have read this comment :-)