greenwoodlab / funtoonorm Goto Github PK

The travis checking have to be unactivated since the new version is very different from the previous one.

We recently ran a data set consisting of all women through funtooNorm and it incorrectly told us they were all males. This is because the gender-inference code based on chromosome Y methylation levels is set up backwards.

In Wang et al (2021), we see that the gender-inference should be based on this approach:

"The Y chromosome: the identified sex-associated CpG sites of males are highly methylated with beta values greater than 0.6 whereas females exhibited low methylation signals"

Wang Y, Hannon E, Grant OA, Gorrie-Stone TJ, Kumari M, Mill J, Zhai X, McDonald-Maier KD, Schalkwyk LC. DNA methylation-based sex classifier to predict sex and identify sex chromosome aneuploidy. BMC Genomics. 2021 Jun 28;22(1):484. DOI: https://doi.org/10.1186/s12864-021-07675-2

However, the funtooNorm code is identifying as males those with median chromosome Y beta values less than 0.6 (Note also that 'sex' needs to be coded as 0 and 1 or 0=FALSE=female; 1=TRUE = male):

              ###### this part deal with chrY
              if(is.null(sex)){
                  mens=matrixStats::colMedians(calcBeta(object@signal$AchrY,
                                                    object@signal$BchrY))<0.6                    <= FIX: >=0.6
                  message("we found ",sum(mens)," men and ",sum(!mens),
                          " women in your data set base on Y probes only")
                  }else{
                      mens=sex
                      message("There is ",sum(mens)," men and ",
                              sum(!mens)," women")
                      }
              # no correction for women
              object@predmat$AchrY=object@signal$AchrY
              object@predmat$BchrY=object@signal$BchrY
              if(1<sum(mens)){                                                                   <= FIX: 1<=sum(mens)
                  object@predmat$AchrY[,mens]=
                      quantileNormalization(object@signal$AchrY[,mens])
                  object@predmat$BchrY[,mens]=
                      quantileNormalization(object@signal$BchrY[,mens])
                  }

I recently used funtooNorm to normalize raw 450K .idat files through the pipeline described in the vignette. Eventually I noticed the relationship between M-values and beta-values (as extracted using getNormBeta and getNormM from the sample normalized sampleSet) have an inverse relationship! i.e. low M-values correspond to high beta-values and vice versa.

I think perhaps the problem is that the function getNormBeta() uses a helper function, calcBeta(), which is defined as such:

calcBeta <- function (A, B, offset = 100) 
{
    return((2^B - 1)/(2^A + 2^B - 2 + offset))
}

Is that the unmethylated signal in the numerator? Isn't the beta-value supposed to have the methylated signal in the numerator? At least according to Du et al 2010?

I think A and B are not inverted in the use of this function since the calls for the two high-level functions are:

From getNormM:

getLogSigA(object$predmat) - getLogSigB(object$predmat)

From getNormBeta:

calcBeta(getLogSigA(object$predmat), getLogSigB(object$predmat), 
        offset)

We'd like to apply 'funtooNorm' to some EPIC data, but the current stable version from Bioconductor (version 1.6.0) fails with this error message:

Error in minfi::getGreen(myRGChannelSet)[TypeI.Green$AddressA, ]:
    subscript out of bounds.

A similar error discussed at https://support.bioconductor.org/p/97229/, where trying to analyze EPIC data led to this error:

mySampleSet <- fromRGChannelSet(RGSet_combined)
Error in minfi::getRed(myRGChannelSet)[controlTable$Address, ] : 
  subscript out of bounds

There Kasper Hansen suggests that:

The authors of funtooNorm should modify their code to work with subsetted
objects. This is something we now fully support in minfi and they can look
in minfi to see examples of how to write it.

One advantage of working with subsetted objects is to allow things like
this.

Is this fixed in the development version (version 1.7.0)? Or, if not, any suggestions on how to extend/adjust funtooNorm so that it can process EPIC data?

Thank you,
Dan Weeks

Noob was an important preprocessing step in funnorm -- not implemented here?