mismatch位置(MD tag)- sam/bam格式解读进阶

本文介绍如何使用MD标签计算序列比对中的错配数量,并深入解析MD字段在无需参考序列的情况下实现SNP和Indel调用的过程。通过具体的例子展示了MD字段的含义及其与CIGAR字符串的匹配方式。

这算是第二讲了,前面一讲是:Edit Distance编辑距离(NM tag)- sam/bam格式解读进阶

MD是mismatch位置的字符串的表示形式,貌似在call SNP和indel的时候会用到。

当然我这里要说的只是利用它来计算mismatch的个数

MD = line.get_tag('MD')
pat = "[0-9]+[ATGC]+"
MD_list = re.findall(pat,MD)
for i in MD_list:
        for j in i:
                if j == 'A' or j == 'T' or j == 'G' or j == 'C':
                        total_mismatch_MD += 1

几行代码简单搞定~~~

 

额,那这篇文章是不是太水了

好吧,那就再深入一点

先看一篇文章:SAM/BAM MD tag

The MD field aims to achieve SNP/indel calling without looking at the reference. For example, a string "10A5^AC6" means from the leftmost reference base in the alignment, there are 10 matches followed by an A on the reference which is different from the aligned read base; the next 5 reference bases are matches followed by a 2bp deletion from the reference; the deleted sequence is AC; the last 6 bases are matches. The MD field ought to match the CIGAR string.

转载于:https://www.cnblogs.com/leezx/p/6074826.html

<think>我们面对的是代码覆盖率测试中出现的gcda文件合并错误(Merge mismatch for summaries)。这个问题通常是由于不同版本的gcda文件(覆盖率数据文件)混合导致的。这些文件可能来自不同的构建版本或源代码版本。以下是解决步骤: 1. **清理现有的gcda文件**:删除所有现有的gcda文件,这样在重新运行测试时会生成新的gcda文件,避免新旧文件混合。 2. **确保完全重新编译**:在清理后,进行完整的重新编译,确保所有的目标文件都是基于当前源代码生成的。 3. **运行测试**:在重新编译后,再次运行测试以生成新的gcda文件。 4. **生成覆盖率报告**:使用lcov等工具生成覆盖率报告。 具体操作命令如下: ### 步骤1:清理gcda文件 在构建目录(这里是`build/test-obj/`)中,删除所有gcda文件: ```bash find build/test-obj/ -name "*.gcda" -exec rm -f {} \; ``` ### 步骤2:重新编译 进入构建目录,执行`make clean`(如果有)然后重新编译。如果没有`make clean`,也可以删除整个构建目录并重新构建。 ```bash cd build # 如果有make clean make clean # 然后重新编译 make -j$(nproc) ``` ### 步骤3:运行测试 运行测试程序,生成新的gcda文件。 ```bash # 假设测试程序在build/test-obj/目录下,或者通过ctest运行 ctest -j$(nproc) # 或者直接运行测试程序 ./test-obj/your_test_executable ``` ### 步骤4:生成覆盖率报告 使用lcov收集覆盖率数据并生成报告: ```bash lcov --capture --directory build/test-obj/ --output-file coverage.info genhtml coverage.info --output-directory coverage_report ``` ### 预防措施 - 在切换Git分支时,确保清理构建目录和gcda文件- 避免在同一个构建目录中编译不同分支的代码。 如果问题仍然存在,可能需要检查是否在构建过程中有多个编译器版本混用,或者是否在构建过程中有部分文件没有被重新编译。 §§相关问题§§ 1. 如何在使用CMake的项目中自动化清理gcda文件? 2. 在持续集成(CI)环境中如何避免覆盖率数据的合并错误? 3. 除了删除gcda文件,还有哪些方法可以解决覆盖率数据合并错误? 4. 如何配置lcov忽略特定的目录或文件? 5. 当使用多线程编译时,如何确保gcda文件的正确生成?</think>### 解决覆盖率数据合并错误的完整方案 #### 🛠️ 分步解决方案: 1. **立即清理冲突文件**: ```bash # 删除所有冲突的 gcda 文件 find build/test-obj/ -name "*.gcda" -exec rm -f {} \; # 清理构建缓存 make clean ``` 2. **强制完全重新构建**: ```bash # 删除整个构建目录 rm -rf build/ # 重新创建并配置构建环境 mkdir build && cd build cmake -DCMAKE_BUILD_TYPE=Coverage .. # 确保启用覆盖率 ``` 3. **单线程编译与测试**: ```bash # 避免并行编译问题 make -j1 # 单线程运行测试 ctest -j1 # 或 ./your_test_executable ``` 4. **重新生成覆盖率报告**: ```bash # 收集覆盖率数据 lcov --capture --directory . --output-file coverage.info # 生成HTML报告 genhtml coverage.info --output-directory coverage_report ``` #### ⚠️ 关键注意事项: 1. **环境一致性检查**: ```bash # 验证编译器版本 gcc --version # 检查代码提交状态 git status ``` 2. **构建系统配置**: 在 CMakeLists.txt 中确保包含: ```cmake set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} --coverage") set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} --coverage") ``` 3. **自动化预防脚本**: 创建 `.git/hooks/pre-commit` 包含: ```bash #!/bin/bash find . -name "*.gcda" -exec rm -f {} \; ``` #### 🔍 根本原因解决方案: | 问题类型 | 解决方案 | 验证命令 | |---------|---------|---------| | 源代码修改未完全编译 | 强制完全重建 | `make clean && make` | | 多版本代码混合 | 清理git工作区 | `git clean -xdf` | | 并行编译冲突 | 单线程编译 | `make -j1` | | 容器环境不一致 | 重建Docker镜像 | `docker build --no-cache .` |
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值