`getIGHreadType()` fails with “NA in coercion to boolean” on 10x 5′ Cell Ranger BAM after successful `getIGHmapping()`

[denvercal1234GitHub]

Hello there,

Thank you for the tool.

I am running sciCSR on human 10x Genomics 5′ scRNA-seq B-cell data using Cell Ranger possorted_genome_bam.bam files. getIGHmapping() appears to complete successfully for each BAM, but getIGHreadType(out1$read_count) fails consistently with:

NA in coercion to boolean

This happens for all three BAMs I tested.

Data context

• Human 10x Genomics 5′ scRNA-seq BAMs from Cell Ranger.
• BAM files are indexed.
• BAM reference names include chr14.
• BAM tags are present. On a sample of 1000 alignments:

Run168_4:  CB 940, UB 994, CR 1000, UR 1000
Run168_8:  CB 817, UB 997, CR 1000, UR 1000
Run170_11: CB 941, UB 949, CR 1000, UR 1000

Minimal code

library(sciCSR)

utils::data("human_definitions", package = "sciCSR", envir = .GlobalEnv)
human_definitions <- get("human_definitions", envir = .GlobalEnv)

bam <- "path/to/possorted_genome_bam.bam"

out1 <- sciCSR::getIGHmapping(bam, human_definitions)

dim(out1$read_count)
colnames(out1$read_count)
sum(is.na(out1$read_count))

out2 <- sciCSR::getIGHreadType(out1$read_count)

Observed behavior

getIGHmapping() prints:

Fetching reads mapped to VDJ genes ...
Fetching reads mapped to C gene coding regions ...
Fetching reads mapped to C gene 5' regions ...

and returns a read_count data frame.

For one BAM:

class: data.frame
n_rows: 546063
n_cols: 19
columns:
CB; UB; IGHM_C; IGHM_I; IGHG3_C; IGHG3_I; IGHG1_C; IGHG1_I;
IGHA1_C; IGHA1_I; IGHG2_C; IGHG2_I; IGHG4_C; IGHG4_I;
IGHE_C; IGHE_I; IGHA2_C; IGHA2_I; VDJ

n_total_NA: 0

However:

sciCSR::getIGHreadType(out1$read_count)

fails with:

NA in coercion to boolean

Molecule-level summary of out1$read_count

For one BAM:

n_molecules: 546063
n_multi_C: 11389
prop_multi_C: 0.02085657
n_multi_feature: 21345
prop_multi_feature: 0.0390889
n_C_and_VDJ: 6057
prop_C_and_VDJ: 0.01109213

Breakdown:

n_positive_C  n_positive_I  has_VDJ  n
0             0             TRUE     363309
1             0             FALSE    153566
2             0             FALSE    10145
0             1             FALSE    7843
1             0             TRUE     5270
1             1             FALSE    4079
3             0             FALSE    688
1             1             TRUE     403
2             0             TRUE     337
0             2             FALSE    139
2             1             FALSE    128
1             2             FALSE    35
2             1             TRUE     35
4             0             FALSE    24
0             1             TRUE     20
0             3             FALSE    10
2             2             FALSE    10
3             0             TRUE     10
3             1             FALSE    10
3             1             TRUE     2

Question

Would you mind giving me some advice as to whether this may be an expected edge case in getIGHreadType() when a molecule has multiple C-region or C + VDJ signals? If so, is there a recommended filtering strategy before getIGHreadType(), or should getIGHreadType() internally handle these rows and assign them to -C rather than erroring?

I want to avoid modifying the read_count object incorrectly before sciCSR.

Thank you for your help.

Note that the BAM files appear to have the expected Cell Ranger tags and chromosome naming:

Reference contains chr14: TRUE
CB/UB tags present: TRUE
CR/UR tags present: TRUE

[denvercal1234GitHub]

BTW, I also isolated the first one-row input that fails with sciCSR::getIGHreadType(). It is:

CB: AATCCGTCACGTTCGA-1
UB: TGTCAAGTTCGC
IGHA2_C: 1
VDJ: 1
all other IGH columns: 0

This appears to be a simple productive IGHA2 molecule and should presumably classify as IGHA2_P. However, getIGHreadType() on this one-row data frame fails with:

NA in coercion to boolean

Tiny subset tests also fail:
first_10: error
first_100: error
vdj_only_100: error
c_only_100: error

Filtering multi-C and/or multi-I molecules did not fix the error.

I implemented a local scalar-safe reimplementation of the sciCSR 0.3.5 getIGHreadType logic as a temporary workaround. On the same BAMs, it produced:

Run168_4: 546063 read_count rows, 171151 annotated molecules, 8332 cells with IGH counts, 24 IGH features
Run168_8: 140078 read_count rows, 20379 annotated molecules, 1438 cells with IGH counts, 24 IGH features
Run170_11: 528226 read_count rows, 79380 annotated molecules, 4292 cells with IGH counts, 24 IGH features

summariseIGHreads() then completed fine.

[josef0731]

Hi, Thank you for trying the package and spotting the issue - will need to investigate further. This is most probably a class/type issue with some columns of the getIGHmapping function output and/or manipulation done within getIGHreadType. Can you provide a short snippet (just the 'head') of your read_count output from getIGHmapping? (I.e. the input you passed to getIGHreadType? Also the following two lines may be useful as well: ``` str(read_count) #read_count being the getIGHmapping read_count output sapply(read_count, class) ``` There might be a package versioning difference that causes it, so a sessionInfo() would also be useful in terms of identifying potentially offending dependency packages. Many thanks! Will look into this shortly. Best wishes Joseph Joseph Ng

…

On Wed, 17 Jun 2026, 02:15 Quang Nguyen, ***@***.***> wrote: *denvercal1234GitHub* left a comment (Fraternalilab/sciCSR#16) <#16 (comment)> BTW, I further isolated the first failing row by calling getIGHreadType() one row at a time. The first row that fails is: CB: AATCCGTCACGTTCGA-1 UB: TGTCAAGTTCGC IGHA2_C: 1 VDJ: 1 all other IGH columns: 0 This appears to be a simple productive IGHA2 molecule and should presumably classify as IGHA2_P. However, calling getIGHreadType() on this one-row data frame still fails with “NA in coercion to boolean”. Tiny subset tests also fail: first_10: error first_100: error vdj_only_100: error c_only_100: error Filtering multi-C or multi-I molecules did not fix the error. This suggests the issue is not caused by ambiguous multi-isotype molecules, but may be an edge case or R 4.6 compatibility issue in getIGHreadType(). — Reply to this email directly, view it on GitHub <#16?email_source=notifications&email_token=AFPBID6T2LQYAJ3OFBKYC2D5AHWLLA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZSGUYDEMZSGEY2M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-4725023211>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFPBIDYGDK75XXX33SVV7C35AHWLLAVCNFSNUABFKJSXA33TNF2G64TZHM2DSMRXHA3TEMRTHNEXG43VMU5TINRXHA4TSOJUGM22C5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AFPBID4YXJHUQQL5ZENNKYL5AHWLLA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZSGUYDEMZSGEY2M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/AFPBIDY2V35HCN4SWSZLSCD5AHWLLA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZSGUYDEMZSGEY2M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[josef0731]

@denvercal1234GitHub Just to say that I think I have identified and patched the issue - was a strange error with a couple of lines in getIGHreadType() that for some reason didn't come up in previous versions of R.
You may want to reinstall from this branch on github and see if this addressed the problem?

remotes::install_github("FraternaliLab/sciCSR", ref = "16-getIGHreadType")

[denvercal1234GitHub]

Hi Joseph,

Apologies for the delay. That is great to hear. I will rerun it after my travels and will let you know. Thank you again for taking a look into it.

[denvercal1234GitHub]

Dear @josef0731,

Thanks for patching the getIGHreadType() issue. I reinstalled sciCSR from that branch and reran my workflow. The patched official sciCSR::getIGHreadType() now ran successfully, but there is likely some bug somewhere that I hope to get your input.

Questions

1. Is this degree of csr_pot == 1 saturation expected for lymph-node B cells?
2. Should csr_pot be interpreted as a coarse/capped CSR-state score rather than a finely continuous variable?
3. Does passing paired-BCR/Immcantation-derived constant-region annotation as c_gene_anno_name make csr_pot more likely to saturate?
4. In data with both paired scBCR-seq constant-region calls and BAM-derived productive/sterile IGH counts, what is your recommended getCSRpotential() usage?
5. Would you recommend a sensitivity run without c_gene_anno_name, or is c_gene_anno_name required/recommended when available?
6. Is the D -> M output-isotype behavior expected?
7. If this saturation is expected, what downstream interpretation do you recommend: binary/max-vs-lower categories, continuous csr_pot, or just sciCSR transition/dynamics outputs instead?
8. For getSHM(), is the min-max scaling intended for downstream biological interpretation, or should I preserve raw 1 - V identity separately when needing an absolute SHM fraction?

Thank you again for your help.

Analysis context

I am applying sciCSR to human 10x Genomics 5′ scRNA-seq with paired BCR-seq.

Upstream BCR annotations were generated using Cell Ranger VDJ filtered contigs followed by Immcantation/IgBLAST/Change-O/SHazaM/SCOPer. I then ran sciCSR on the 10x GEX BAMs using:

getIGHmapping()
getIGHreadType()
summariseIGHreads()
repairBarcode()
mergeIgHCountsToSeurat()
getCSRpotential()
getSHM()

My getCSRpotential() call was:

obj <- sciCSR::getCSRpotential(
  SeuratObj = seu_s_for_scicsr,
  c_gene_anno_name = "sciCSR_input__IGH_c_gene_from_immcantation",
  reference_based = "human",
  isotype_column_to_add = "sciCSR_output__isotype"
)

where sciCSR_input__IGH_c_gene_from_immcantation is a normalized constant-region annotation from paired BCR-seq / Immcantation, with values such as IGHM, IGHD, IGHG1, IGHA1, etc. The object also contains the IGHC assay generated from the BAM-derived productive/sterile IGH workflow.

csr_pot distribution after patched run

After the patched official run, csr_pot is highly ceiling-enriched:

n_cells = 3696
n_nonmissing_csr_pot = 3696
min = 0
q01 = 0.1394
q05 = 0.2441
q25 = 0.5514
median = 1
mean = 0.8137
q75 = 1
q95 = 1
q99 = 1
max = 1
n_exact_0 = 1
n_exact_1 = 2505
pct_exact_0 = 0.00027
pct_exact_1 = 0.6778
n_unique_values = 1192

By paired-BCR/Immcantation input isotype:

BCR isotype   n      median   mean     pct_exact_1
M             2259   1        0.7400   0.5538
D              234   1        0.8041   0.6709
G1             271   1        0.9548   0.9004
A1             170   1        0.9533   0.9235
G2             106   1        0.9813   0.9528
G3              25   1        0.9700   0.9600
A2              21   1        1.0000   1.0000
G4               5   1        0.8462   0.8000
Missing_BCR    605   1        0.9474   0.9025

By sciCSR output isotype:

sciCSR isotype   n      median   mean     pct_exact_1
M                3005   1        0.7796   0.6210
G1                350   1        0.9575   0.9086
A1                178   1        0.9554   0.9270
G2                112   1        0.9823   0.9554
G3                 25   1        0.9700   0.9600
A2                 21   1        1.0000   1.0000
G4                  5   1        0.8462   0.8000

The part I am unsure about is that many IgM/IgD-like cells also have csr_pot == 1. For example, 55.4% of BCR/Immcantation IgM cells, 67.1% of BCR/Immcantation IgD cells, and 62.1% of sciCSR-output IgM cells have csr_pot == 1.

BCR input isotype vs sciCSR output isotype

The BCR input vs sciCSR output isotype cross-tabulation is mostly concordant, except many BCR IgD cells are output as IgM:

BCR input isotype   sciCSR output isotype   n_cells
M                   M                       2259
NA                  M                        514
G1                  G1                       271
D                   M                        232
A1                  A1                       170
G2                  G2                       106
NA                  G1                        77
G3                  G3                        25
A2                  A2                        21
NA                  A1                         8
NA                  G2                         6
G4                  G4                         5
D                   G1                         2

Is the D -> M behavior expected in this workflow?

Output completeness and barcode/IGH-count QC

Output completeness looked good:

n_cells = 3696
n_csr_pot = 3696
prop_csr_pot = 1
n_sciCSR_output_isotype = 3696
prop_sciCSR_output_isotype = 1
n_input_c_gene = 3091
prop_input_c_gene = 0.8363
n_input_v_identity = 3102
prop_input_v_identity = 0.8393
status = ok

Barcode repair / Seurat overlap also looked good:

n_igh_counts_cells_before_filter = 14359
n_seurat_b_cells = 3696
n_igh_counts_cells_in_seurat = 3517
n_seurat_b_cells_with_igh_counts = 3517
prop_seurat_b_cells_with_igh_counts = 0.9516

So the BAM-to-Seurat matching appears successful.

SHM note

One secondary note: in my installed version, getSHM() appears to compute 1 - v_identity and then min-max normalize it:

shm <- 1 - v_identity[, v_identity_anno_name]
shm <- (shm - min(shm, na.rm = TRUE)) / abs(diff(range(shm, na.rm = TRUE)))

For biological summaries, I therefore saved a separate raw SHM fraction as 1 - input V identity.

[josef0731]

Hello, Apologies for the delayed response! Is this degree of csr_pot == 1 saturation expected for lymph-node B cells? - csr_pot is a quantification simply from the perspective of expression of sterile/productive IgH transcripts (see original sciCSR paper). I don't think we expect a homogeneous picture for the lymph node - some B cells would have progressed further in their CSR history, express more sterile/productive transcripts beyond IgM and should have a higher csr_pot. The important point here is whether CSR has "begun" and/or progressed far enough so that the productive/sterile transcription patterns look different enough compared to a naive B cells - this is what csr_pot is aiming to capture. Should csr_pot be interpreted as a coarse/capped CSR-state score rather than a finely continuous variable? - the way csr_pot was defined implies that this is more a rough/coarse CSR state score - essentially it only reflects how far a B cell has deviated from a naive cell, in terms of expressing sterile/productive transcripts beyond IgM. Does passing paired-BCR/Immcantation-derived constant-region annotation as c_gene_anno_name make csr_pot more likely to saturate? - Depends. If you have c_gene_anno_name supplied, the function will take this as the assignment of what productive transcript(s) are being expressed. This is normally recommended since in standard GEX library the amount of productive transcripts is likely underestimated. Pushing csr_pot higher would imply that in your c_gene_anno labels your BCR library captures more non-IgM BCRs systematically - I don't know if this is likely the case? Equally I don't think we identified any biases in terms of identifying productive IgM vs other isotypes from BAM alignments, so I am not sure if there is a generic and valid trend for this. In data with both paired scBCR-seq constant-region calls and BAM-derived productive/sterile IGH counts, what is your recommended getCSRpotential() usage? Would you recommend a sensitivity run - I hope the above answers this - I recommend you to supply c_gene_anno_name pointing to the C gene annotation obtained from BCR libraries. Is the D -> M output-isotype behavior expected? Yes - apologies if this is not sufficiently explained in the paper or in vignettes/documentation. The productive/sterile transcript quantification pipeline does not consider IgD because it is unclear biologically the involvement of IgD in CSR. The textbook understanding (as far as I can tell) is that IgD expression for naive/unswitched cells is essentially a splicing-like mechanism to decides whether a transcript would be IgM or IgD. Specifically the definition of IgD sterile transcripts is not explicitly (experimentally) described in the literature. In sciCSR we therefore did not consider IgD in modelling CSR states. In other words if you have naive/unswitched cells in your data which would otherwise be IgM+IgD+, they would be labelled as IgM only. If this saturation is expected, what downstream interpretation do you recommend: binary/max-vs-lower categories, continuous csr_pot, or just sciCSR transition/dynamics outputs instead? - csr_pot was defined with the sole purpose as a pseudotime like measure of B cells. If all you wish to answer is the csr potential of different cell types/states, you can just use this as a pseudotime metric and compare the distributions of this metric across different cell states. From the perspective of fitting cellrank-like models for transition dynamics this csr_pot can be used as a substitute to pseudotime-type measures offered by other means. You are right that if there is little difference between cell states (before of "saturation"), the distinguishing power of this csr_pot is limited - I think this should bring extra caution when interpreting any resulting models. For getSHM(), is the min-max scaling intended for downstream biological interpretation, or should I preserve raw 1 - V identity separately when needing an absolute SHM fraction? - the min-max scaling is to mimick the behaviour of other pseudotime-like measures which normally have a [0,1] range. If all you want is to compare SHM levels across cell types/states the raw 1-Videntity numbers may be more intuitive to understand. Hope these answers help and that I haven't missed out anything! Joseph Ng

…

On Wed, 24 Jun 2026, 23:59 Quang Nguyen, ***@***.***> wrote: *denvercal1234GitHub* left a comment (Fraternalilab/sciCSR#16) <#16 (comment)> Dear @josef0731 <https://github.com/josef0731>, Thanks for patching the getIGHreadType() issue. I reinstalled sciCSR from that branch and reran my workflow. The patched official sciCSR::getIGHreadType() now ran successfully, but there is likely some bug somewhere that I hope to get your input. Questions 1. Is this degree of csr_pot == 1 saturation expected for lymph-node B cells? 2. Should csr_pot be interpreted as a coarse/capped CSR-state score rather than a finely continuous variable? 3. Does passing paired-BCR/Immcantation-derived constant-region annotation as c_gene_anno_name make csr_pot more likely to saturate? 4. In data with both paired scBCR-seq constant-region calls and BAM-derived productive/sterile IGH counts, what is your recommended getCSRpotential() usage? 5. Would you recommend a sensitivity run without c_gene_anno_name, or is c_gene_anno_name required/recommended when available? 6. Is the D -> M output-isotype behavior expected? 7. If this saturation is expected, what downstream interpretation do you recommend: binary/max-vs-lower categories, continuous csr_pot, or just sciCSR transition/dynamics outputs instead? 8. For getSHM(), is the min-max scaling intended for downstream biological interpretation, or should I preserve raw 1 - V identity separately when needing an absolute SHM fraction? Thank you again for your help. Analysis context I am applying sciCSR to human 10x Genomics 5′ scRNA-seq with paired BCR-seq. Upstream BCR annotations were generated using Cell Ranger VDJ filtered contigs followed by Immcantation/IgBLAST/Change-O/SHazaM/SCOPer. I then ran sciCSR on the 10x GEX BAMs using: getIGHmapping() getIGHreadType() summariseIGHreads() repairBarcode() mergeIgHCountsToSeurat() getCSRpotential() getSHM() My getCSRpotential() call was: obj <- sciCSR::getCSRpotential( SeuratObj = seu_s_for_scicsr, c_gene_anno_name = "sciCSR_input__IGH_c_gene_from_immcantation", reference_based = "human", isotype_column_to_add = "sciCSR_output__isotype" ) where sciCSR_input__IGH_c_gene_from_immcantation is a normalized constant-region annotation from paired BCR-seq / Immcantation, with values such as IGHM, IGHD, IGHG1, IGHA1, etc. The object also contains the IGHC assay generated from the BAM-derived productive/sterile IGH workflow. csr_pot distribution after patched run After the patched official run, csr_pot is highly ceiling-enriched: n_cells = 3696 n_nonmissing_csr_pot = 3696 min = 0 q01 = 0.1394 q05 = 0.2441 q25 = 0.5514 median = 1 mean = 0.8137 q75 = 1 q95 = 1 q99 = 1 max = 1 n_exact_0 = 1 n_exact_1 = 2505 pct_exact_0 = 0.00027 pct_exact_1 = 0.6778 n_unique_values = 1192 By paired-BCR/Immcantation input isotype: BCR isotype n median mean pct_exact_1 M 2259 1 0.7400 0.5538 D 234 1 0.8041 0.6709 G1 271 1 0.9548 0.9004 A1 170 1 0.9533 0.9235 G2 106 1 0.9813 0.9528 G3 25 1 0.9700 0.9600 A2 21 1 1.0000 1.0000 G4 5 1 0.8462 0.8000 Missing_BCR 605 1 0.9474 0.9025 By sciCSR output isotype: sciCSR isotype n median mean pct_exact_1 M 3005 1 0.7796 0.6210 G1 350 1 0.9575 0.9086 A1 178 1 0.9554 0.9270 G2 112 1 0.9823 0.9554 G3 25 1 0.9700 0.9600 A2 21 1 1.0000 1.0000 G4 5 1 0.8462 0.8000 *The part I am unsure about is that many IgM/IgD-like cells also have csr_pot == 1. For example, 55.4% of BCR/Immcantation IgM cells, 67.1% of BCR/Immcantation IgD cells, and 62.1% of sciCSR-output IgM cells have csr_pot == 1.* BCR input isotype vs sciCSR output isotype The BCR input vs sciCSR output isotype cross-tabulation is mostly concordant, except many BCR IgD cells are output as IgM: BCR input isotype sciCSR output isotype n_cells M M 2259 NA M 514 G1 G1 271 D M 232 A1 A1 170 G2 G2 106 NA G1 77 G3 G3 25 A2 A2 21 NA A1 8 NA G2 6 G4 G4 5 D G1 2 *Is the D -> M behavior expected in this workflow?* Output completeness and barcode/IGH-count QC Output completeness looked good: n_cells = 3696 n_csr_pot = 3696 prop_csr_pot = 1 n_sciCSR_output_isotype = 3696 prop_sciCSR_output_isotype = 1 n_input_c_gene = 3091 prop_input_c_gene = 0.8363 n_input_v_identity = 3102 prop_input_v_identity = 0.8393 status = ok Barcode repair / Seurat overlap also looked good: n_igh_counts_cells_before_filter = 14359 n_seurat_b_cells = 3696 n_igh_counts_cells_in_seurat = 3517 n_seurat_b_cells_with_igh_counts = 3517 prop_seurat_b_cells_with_igh_counts = 0.9516 So the BAM-to-Seurat matching appears successful. SHM note One secondary note: in my installed version, getSHM() appears to compute 1 - v_identity and then min-max normalize it: shm <- 1 - v_identity[, v_identity_anno_name]shm <- (shm - min(shm, na.rm = TRUE)) / abs(diff(range(shm, na.rm = TRUE))) For biological summaries, I therefore saved a separate raw SHM fraction as 1 - input V identity. — Reply to this email directly, view it on GitHub <#16?email_source=notifications&email_token=AFPBID77VR24HLSDWHSAJC35BRMOBA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZZGQZTINBTHEZ2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4794344393>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFPBIDZ2EHOKI6575JDKWSL5BRMOBAVCNFSNUABFKJSXA33TNF2G64TZHM2DSMRXHA3TEMRTHNEXG43VMU5TINRXHA4TSOJUGM22C5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AFPBIDZPB6G3SYFUUKKXRIL5BRMOBA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZZGQZTINBTHEZ2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AFPBIDYXIP752DAS3TEHYRT5BRMOBA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZZGQZTINBTHEZ2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>