The current GATK version is 3.5-0

#### Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

# ERROR MESSAGE: Bad input:We encountered a non-standard non-IUPAC base in the provided reference: '13

Posts: 5Member

Hi,
I'm currently working with bwa, samtools and GATK to make SNP calling on Medicago truncatula. I'm using my own reference sequence, with the 8 chromosoms in the same fasta file.

C1_lenght=155648

AAAGATAGAGA..

C2_lenght=125018

ATGGATC...
etc..
I have done alignments without problem, but for GATK : I do rmdup --> CreateSequenceDictionary.jar (picard) --> samtools sort --> Read Group (picard) --> samtools index and then :
Pre alignment with :

java -jar -Xmx4g /usr/local/bioinfo/src/GATK/GenomeAnalysisTK-2.4-9-g532efad/GenomeAnalysisTK.jar -nt 8 -T RealignerTargetCreator -R REF.fa -o RTC.intervals -I INPUT_muq30_RMDUP_RG.bam

Here there is no problem, but when I want to make the realignement :

java -jar -Xmx4g /usr/local/bioinfo/src/GATK/GenomeAnalysisTK-2.4-9-g532efad/GenomeAnalysisTK.jar -T IndelRealigner -R REF.fa -I INPUT_muq30_RMDUP_RG.bam -targetIntervals RTC.intervals -o INPUT_muq30_RMDUP_RG_REAL.bam

And I got this error message :
ERROR MESSAGE: Bad input:We encountered a non-standard non-IUPAC base in the provided reference: '13'

I didn't find any explanation in google for this error.

vschilling

Tagged:

Have you seen the FAQ article about inputs?

This could be an encoding issue, if you're sure that there are no non-IUPAC bases in your reference.

Geraldine Van der Auwera, PhD

• Posts: 5Member
edited July 2013

*Hi,
I have seen the FAQ article about inputs. I'm sure that there are no non-IUPAC bases in my reference. My last message was not well transcripted, my reference fasta file is like this :

'>C1_lenght155648

AAAGATAGAGAATCGCTAGCTC

CGCTAGCTCGCATATAGAGATAG
......

'>C2_lenght28648

ATTTCGCTCCCGATAAGATACTC

CGCTCGCGCTCGAAAGCTCGA
......

Is that correctly written? Would you have some explanation for this error message?

Vincent

Post edited by vschill on
• Posts: 5Member

Hi,
thanks for answer. I have opened my fasta file into gedit and saved it with UTF-8 format. I'm going to check it.

Vschilling

• Posts: 31Member
edited August 2013

Same problem has just cropped up for me today. Running the "BaseRecalibrator" from git/gatk-04-18-g2fd787a/GenomeAnalysisTK.jar gave the error "ERROR MESSAGE: Bad input:We encountered a non-standard non-IUPAC base in the provided reference: '10"

It's strange because I have used this pipeline on previous samples successfully. In fact it's the same reference fasta I've used for alignment and other BaseRecalibration many times in the past. The task even appears to complete, running right past Chr10 and through ChrX then MT before reporting the error. Then no output is produced and I only noticed when downstream processes reported missing input files.

If the error message would have told me what the problem was, or which line or offset, or even what the non-IUPAC code was, I could search for it. It's not impossible for my reference fasta to have become corrupted somehow; in fact that's the only explanation I can come up with given it has worked in the past. Now I'm searching through chr10 manually looking for anything out of place but that's not fruitful.

Now I'm looking for FASTA validator tools I could run on the reference; but it's very strange for bwa to have succeeded.

----- edit update:

I found the GATK now has a tool called QCRef to actually QC a reference file. Running that on my suspect fasta yeilds the same results. It processes happily through all chromosomes, then at the end it reported

  ##### ERROR MESSAGE: Bad input: We encountered a non-standard non-IUPAC base in the provided reference: '10'


Now I'm at a loss. I guess my fasta has become corrupted and have no way of knowing where in the file the error was found, where in the chromosome, what the error was or how it got there. I don't want to download a new one at risk of any updates invalidating all previous work before this occurred (all previous alignments and variant calls would have to be rerun on the updated reference). What other information can I get about this error?

Post edited by KStamm on

If you want to troubleshoot this problem you can start by checking the encoding of your reference file.

Geraldine Van der Auwera, PhD

• Posts: 31Member
edited August 2013

I use the GATK/bundle/1.2/human_g1k_v37.fasta which I suppose would be stable and redownloadable. I'll do that and md5sum to check for divergence.

Line endings are \n only.

Ive been using this file for a long time. The last batch of samples ran with this same reference and GATK version in July. That's what is really concerning me. It's therefore either a random data corruption or perhaps an updated system library my administrator didn't tell me about. I have come to expect each new version of GATK to have some new file format expectations and errors but that's why I stick to aging versions until a showstopping bug forces me to upgrade. (that put me up to nightly gatk-04-18-g2fd787a). So I know this version of GATK/reference had worked in the past.

It's worth a try to redownload and checksum. If it turns out to be the problem, then we've got some more serious problems.

----edit UPDATE

I don't see bundle version 1.2 still up on the FTP, but bundle 2.6 has a file of name human_g1k_v37.fasta I will compare to my local copy. The MD5 does not match mine, but perhaps I have renamed a chromosome. Now running a diff to find what is changed.

Post edited by KStamm on

OK -- I believe we have always used the same human_g1k_v37.fasta so the bundle copy should be exactly the same. Good luck!

Geraldine Van der Auwera, PhD

• Posts: 31Member
edited August 2013

After checking the two reference fastas for any differences I think I've found the problem. The GATK bundle human_g1k_v37.fasta has a blank line (extra \n) between chrs MT and GL000207 (at line number 51594898). Some tool had complained about this invalid line (wish I remembered which tool!) so I removed the empty line.

A fasta.index was rebuilt but the fasta.fai was ignored and became outdated. Now I guess the error here is the single character being removed would cause the .fai to be offset. Now when the BaseRecalibrator task tries to grasp a small portion of the GL000207 chromosome it would get something that bridges an otherwise valid single \n. Hence the error message about character '10'.

I'm running this step on the clean version to check that this was truly the problem and to rule out other system changes.

Post edited by KStamm on

Hmm, interesting. Thanks for reporting back with this info, it might be useful to other users. Please do confirm whether this does indeed solve the problem.

FYI I think the Fasta format specification does allow blank lines as long as records are formatted correctly; it sounds like it's whatever the tool that complained that's not able to cope with them. If you ever find which tool that was it might be useful to tell the developers that.

Geraldine Van der Auwera, PhD

• Posts: 31Member

Yup everything seems to be working now.

The problem was a fasta index being outdated after I manually edited the genome reference to remove a single empty line between chromosomes, causing a cascade of off-by-one errors. It wasn't noticed by most tools because it occurred only in the auxiliary GL* chromosomes. The tool that refused to operate across the empty newline was Ensembl's Variant Effect Predictor, a perl script that calculates the coding-sequence impacts of a VCF with respect to a reference FASTA.

Therefore I introduced the problem after the previous batch of samples had finished their GATK processing and only now have new samples shown the error in the reference's index.

The good news is tracking down the problem has resolved my fears of unknown software updates or random data corruption or even erroneous sample processing; everything should be okay now and work doesn't have to be redone.

Glad to hear it! And thank you for summarizing the issue & resolution.

Geraldine Van der Auwera, PhD

• Graz, AustriaPosts: 4Member

Hi,

I get a similar error when running the following command:

java7 -jar /path2gatk/GenomeAnalysisTK-2.6-4-g3e5ff60//GenomeAnalysisTK.jar -T HaplotypeCaller -R reference.fasta -I file.bam -o output.vcf -nct 25 --minPruning 5 -dcov 200 -gt_mode DISCOVERY -out_mode EMIT_VARIANTS_ONLY -stand_emit_conf 10 -stand_call_conf 30

##### ERROR ------------------------------------------------------------------------------------------

The reference file has the correct encoding. I have exported the file from the CLC workbench - there shouldn't be any non-IUPAC chars in there. I've also run the local realignment without any trouble with this reference - this just showed up when running the HaplotypeCaller. And the error pops up randomly (not always at the same scaffold as shown by the progressmeter)

I am lost here. I hope you can help me!
Thank you

The randomness of the error is likely due to the fact that the error only occurs when the positions involved are actually used by the program, and certain processing steps don't necessary act on all positions.

I expect that the issue was introduced by CLC workbench. Is it a custom reference?

Geraldine Van der Auwera, PhD

• TurkeyPosts: 1Member

I had the same problem and reindexing the reference fasta file resolved the issue.

• BelgiumPosts: 1Member

I just had the same problem, so I want to thank everybody on the topic for suggestions. I wanted to add that sometimes reindexing alone isn't enough to make the error go away. You might also need to "normalize" your reference FASTA file (using "picard NormalizeFasta") before reindexing, even if your reference file looks perfectly ordinary.

• United KingdomPosts: 7Member

@All, just to contribute to the post. I got this error message

Bad input: We encountered a non-standard non-IUPAC base in the provided reference: '10'

While going through this page, i found an idea where the problem may be coming from. I realized that after creating the .fa.fai, .dict and so on, I later changed the header of my fasta file to a name completely different from the .fa.fai. This actually created the problem. So what i did was to rename it to the one that matches other extensions earlier created from the fasta file and guess what...BINGO!!!