Pregunta:
¿Por qué los archivos BAM creados por diferentes herramientas tienen diferentes tamaños de archivo?
medbe
2017-06-03 04:38:14 UTC
view on stackexchange narkive permalink

Tengo un BAM creado por Picard. Quiero filtrar alineaciones por banderas con samtools view . Sin embargo, noté que incluso si no aplico filtros, el BAM de salida es diferente de mi BAM de entrada. ¿Los BAM producidos por diferentes herramientas también son diferentes en tamaño? ¿Cómo puedo comprobar si dos BAM son iguales?

Hola medbe, gracias por hacer tu pregunta, que encaja bien con este sitio de bioinformática. Para mejorar las respuestas que obtendrá, puede ser útil editar su pregunta y crear una pequeña historia en torno a ella. ¿Qué te llevó a querer filtrar alineaciones por banderas? ¿Por qué importa que los archivos BAM tengan un formato diferente?
¿Podría explicar exactamente en qué se diferencia la salida de samtools / picard? ¿Es solo el tamaño del archivo o le faltan datos de los campos opcionales de la sección de alineación?
Dos respuestas:
Matt Bashton
2017-06-03 17:14:12 UTC
view on stackexchange narkive permalink

Vale la pena tener en cuenta que al generar BAM comprimido, como lo hacen la mayoría de las herramientas por defecto, es posible que estén usando diferentes niveles de compresión y / o diferentes bibliotecas, o versiones de dichas bibliotecas para hacer (des) compresión que dan como resultado diferentes tamaños de archivo. Además, el BAM ordenado por coordenadas comprimirá más que el BAM sin clasificar. La versión actual de Picard usa HTSJDK que a su vez usa java.util.zip.Deflater / Inflater, las versiones actuales de samtools deben usar la biblioteca HTSlib que a su vez depende de la biblioteca zlib estándar. Puede ver el efecto de diferentes implementaciones de zlib en el tamaño del archivo y el tiempo de ejecución en la evaluación comparativa realizada por el equipo de samtools.

Sin embargo, en su caso, la mejor manera de ver si Si existe alguna diferencia entre los archivos BAM es descartar el efecto de diferentes niveles de compresión o bibliotecas utilizadas para la compresión y guardar ambos archivos BAM como sin comprimir. Tanto samtools como Picard tienen opciones para deshabilitar o cambiar los niveles de compresión, dado que el estándar de compresión BAM BGZF se implementa sobre el formato gzip, ha heredado la capacidad, al igual que con gzip, de cambiar el nivel de compresión de 0 a 9.

samtools view -bu le permitirá producir una salida BAM sin comprimir (que también es útil para conectar con otros programas, ya que ahorra tiempo perdido comprimiendo descomprimiendo lo que es esencialmente un flujo). También tenga en cuenta que samtools sort tiene una configuración -l INT donde INT se puede establecer entre 0 (compresión desactivada, como con -u ) 1 ( para una compresión más rápida, pero un tamaño de archivo aumentado) o -9 (para una compresión máxima, con un mayor tiempo de ejecución). Algunos de los efectos de un mayor tiempo de ejecución para configuraciones de compresión más altas pueden mejorarse usando el argumento - @ que le permite establecer el número de subprocesos adicionales usados ​​para la compresión BAM, por defecto samtools no usará ninguno.

Las herramientas Picard tienen una configuración general COMPRESSION_LEVEL que es aplicable a la mayoría de sus herramientas estableciendo esto en 0, COMPRESSION_LEVEL = 0 debería deshabilitar la compresión.

Por lo tanto, volver a ejecutar cualquier herramienta de Picard que usó en la primera instancia con COMPRESSION_LEVEL = 0 le permitirá verificar que el archivo no sea modificado por samtools view -bu . La suposición aquí es que si ambos archivos tienen exactamente el mismo contenido, deberían tener el mismo tamaño sin comprimir, por supuesto, si tienen diferencias triviales con respecto al formato de espacios en blanco, las cosas aún pueden diferir.

gringer
2017-06-03 05:20:02 UTC
view on stackexchange narkive permalink

Es poco probable que dos herramientas de mapeo diferentes den exactamente la misma alineación, puntuaciones y cadenas de coincidencia para la misma secuencia mapeada a la misma referencia. Para algunas alineaciones de secuencia / referencia, es imposible determinar cuál es la "mejor" alineación, y pequeñas diferencias en el código pueden tener grandes efectos en la alineación elegida.

Sin embargo, incluso si la ubicación real del mapeo y la coincidencia string son exactamente iguales (por ejemplo, cuando se usa una herramienta como Picard para filtrar archivos BAM / SAM), diferentes herramientas incorporarán diferentes metadatos con cada mapeo. Esto está permitido en la especificación de formato de archivo SAM mediante la adición de campos opcionales más allá de la undécima columna. Hay algunas etiquetas opcionales estándar que se pueden usar en estos campos, y también se pueden usar etiquetas no estándar personalizadas adicionales. Es muy probable que Picard esté agregando metadatos adicionales a las alineaciones en el archivo BAM / SAM.

Hay una complicación adicional en que la alineación (y metadatos) SAM subyacente podría ser idéntico, pero el archivo BAM aún puede tener diferentes tamaños de archivo. Una razón de esto es que se pueden cambiar los métodos de compresión de archivos BAM. Por ejemplo, las herramientas de alineación pueden elegir un método de compresión rápido, mientras que las herramientas de filtrado pueden elegir un método que resulte en una mejor compresión.

Verificar la similitud de alineación es más difícil que simplemente comparar archivos a nivel binario y su La aplicación particular (o contexto, o historia) cambiará cuál es el mejor método de comparación. Sería útil saber por qué desea comparar archivos BAM para poder responder mejor a su pregunta.



Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 3.0 bajo la que se distribuye.
Loading...