The current GATK version is 3.7-0
Examples: Monday, today, last week, Mar 26, 3/26/04

#### Howdy, Stranger!

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

You can opt in to receive email notifications, for example when your questions get answered or when there are new announcements, by following the instructions given here.

#### ☞ Did you remember to?

1. Search using the upper-right search box, e.g. using the error message.
3. Include tool and Java versions.
4. Tell us whether you are following GATK Best Practices.
5. Include relevant details, e.g. platform, DNA- or RNA-Seq, WES (+capture kit) or WGS (PCR-free or PCR+), paired- or single-end, read length, expected average coverage, somatic data, etc.
6. For tool errors, include the error stacktrace as well as the exact command.
7. For format issues, include the result of running ValidateSamFile for BAMs or ValidateVariants for VCFs.
8. For weird results, include an illustrative example, e.g. attach IGV screenshots according to Article#5484.
9. For a seeming variant that is uncalled, include results of following Article#1235.

#### ☞ Formatting tip!

Wrap blocks of code, error messages and BAM/VCF snippets--especially content with hashes (#)--with lines with three backticks (  ) each to make a code block as demonstrated here.

GATK 3.7 is here! Be sure to read the Version Highlights and optionally the full Release Notes.

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

Member Posts: 5

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

• Member Posts: 5
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

• Member Posts: 5

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

• Member Posts: 31
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?

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

Geraldine Van der Auwera, PhD

• Member Posts: 31
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.

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

• Member Posts: 31
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

• Member Posts: 31

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, AustriaMember Posts: 18

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

• TurkeyMember Posts: 1

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

• BelgiumMember Posts: 1

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 KingdomMember Posts: 7

@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!!!

Hi All,
I had the same problem in running HaplotypeCaller from GATK 3.4-46 on exome sequencing data with a standard version of hg37 as reference. The strange thing is that in my lab we always use this fasta file for many other studies and analyses with GATK tools and we never find this error before. I checked it for blank lines or spaces but none were found, I also checked the date of fasta file and relative indexes and all the indexes are younger than the reference and no modifications were done.
Moreover, I tried to run the HaplotypeCaller on the same dataset twice and it stacked in different point but with this same error:

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

Thanks for any help.

@fabiodp did you try any of the solutions other people have proposed above?

Geraldine Van der Auwera, PhD

@Geraldine_VdAuwera
I searched the reference for blank spaces or empty lines but non were found. And the indexes were ok with the reference.
Now the thing is strange because I had a couple of samples that I am analyzing with HaplotypeCaller. The error appeared when I run simultaneously the analysis for all the samples. After that, I tried to launch one sample after the other only when the analysis is completed: no error issue for any sample. This make me think that there could be a problem in interrogating the same file (the reference) at the same time by different HaplotypeCaller process... I know this might sound strange, this is the only explanation it kept to my mind. Could it be possible?
Thanks

@fabiodp
Hi,

Thanks,
Sheila

• HomeMember Posts: 65

Hello,

I am suddenly seeing this exact same issue using RealignerTargetCreator on v3.6-0-gf185a75. We've run this on previous versions w/ the exactly same FASTA/FAI inputs (and even the same FASTQ input data) before. We have the exact same error on 2 different genomes (different FASTAs) in the last day. The exact error is "Bad input: We encountered a non-standard non-IUPAC base in the provided reference: '10'". Based on these posts I'm going to check the FASTA for \r and double newlines. If there is anything else I should check please let me know. I'll remake the FAI after this if anything changes. Should I be doing anything else?

Is this a known issue w/ 3.6, or did some parsing change?

• germanyMember Posts: 1

Hi,
I used GATKs RealignerTargetCreator and got the same error message:

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

The reference sequence was 'created' with snapgene.

Solution: I am working in a UNIX environment and I converted the reference file to have unix line breaks:
mac2unix ref.fa
And just to make sure, I used the following as well
dos2unix ref.fa

Then I created new dictionary and index file and GATKs RealignerTargetCreator worked without no errors.
So the problem seemed to be the line breaks.

• HomeMember Posts: 65

FWIW - that doesnt explain ours. our FASTA only contains \n, and did not have carriage returns. it also did not have blank newlines (which was suggested elsewhere as a possible issue).

@bbimber
Hi,

There was an issue with the nightly build system that should be fixed now. Please try again with the latest nightly build, and the issue should go away.

-Sheila

• HomeMember Posts: 65

I've been making the JAR by cloning from github master, 3.6 tag and building locally. Does this change that answer at all?