最近因为疫情的原因一直呆在家里，然后突然一个师兄找我要了个bed文件，然后我就从服务器上down下来给了他。但很快师兄就反馈说这个bed文件加载不到IGV里面去。一直出现这个报错。

image

然后我心里想，不应该啊，我之前明明从服务器上down到我的台式机上，然后成功用IGV加载了的，虽然里面的数据可能不太一样了，但应该都是一样的bed。为啥到他电脑就不行了，于是我强行启动我笔记本的IGV，结果也出现了报错。面对这种报错，我的第一反应是可能是IGV的版本不对，于是我重新下了最新的IGV，发现还是一样的错误。

然后我就懵逼了，只能去上网搜，网上只有有限几个类似的报错

• BED Parsing errors are more cryptic than they should be
• Error parsing line at byte position when uploading bed file

其中只有第二个是成功解决了的，他里面说

I figured out what was wrong. In one of the bed line, the address was written in scientific form. That's why IGV is throwing out an error.

对于 scientific form，我还是不太懂……所以我只能祭出最后一招，逐行逐行地去看bed文件（开玩笑的：））。我按顺序大块大块地部分复制了我原来那个bed文件，形成新的bed，载入IGV中，终于被我发现了有问题的那一行

Chr5    4e+05   400206  peak_19737  .   .

然后终于跟之前对起来了，原来是科学计数法惹的祸。因为R会对一些大数字运用科学计数法，从而导致了40000变成了4e+05。而之前我一直没报错是因为我之前的bed文件很幸运地没有大的整数。

至于怎么解决这个问题，上网搜下就行。比如说你可以在输出bed的时候，设置下格式

write.table(format(merge_peak,scientific=FALSE),
            file = "result/processed_result/merge_peak.bed",
            quote = F,sep = "\t",
            row.names = F,col.names = F,
            )

也可以一开始就options下，比如说下面的意思就是在200个位以内不要使用科学计数法

options(scipen = 200)

最好还是用第二种方法，因为我发现第一种方法好像输出的不是一个正常的tab分割的文件

# 第一种输出的格式会变成这样
Chr1          30             875
Chr1        1392            1953
Chr1        2164            3625
Chr1        8268            8966
Chr1       13654           14698
Chr1       16512           16931
Chr1       20391           21655
Chr1       22671           23272
Chr1       33104           33997