The current GATK version is 3.6-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!

Powered by Vanilla. Made with Bootstrap.
Register now for the upcoming GATK Best Practices workshop, Nov 7-8 at the Broad in Cambridge, MA. Open to all comers! More info and signup at

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

vschillvschill Posts: 5Member

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.




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.
Could you please help me ?!


Best Answer


  • Geraldine_VdAuweraGeraldine_VdAuwera Posts: 10,567Administrator, Dev admin

    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

  • vschillvschill Posts: 5Member
    edited July 2013

    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 :







    Is that correctly written? Would you have some explanation for this error message?
    Thanks in advance,


  • vschillvschill Posts: 5Member

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


  • KStammKStamm 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?

  • Geraldine_VdAuweraGeraldine_VdAuwera Posts: 10,567Administrator, Dev admin

    Where did you originally get your reference from? If it's a standard one you needn't worry about re-downloading it, it won't mess up your previous work.

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

    Geraldine Van der Auwera, PhD

  • KStammKStamm 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.

  • Geraldine_VdAuweraGeraldine_VdAuwera Posts: 10,567Administrator, Dev admin

    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

  • KStammKStamm 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
  • Geraldine_VdAuweraGeraldine_VdAuwera Posts: 10,567Administrator, Dev admin

    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

  • KStammKStamm 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.

  • Geraldine_VdAuweraGeraldine_VdAuwera Posts: 10,567Administrator, Dev admin

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

    Geraldine Van der Auwera, PhD

  • JulsJuls Graz, AustriaPosts: 7Member


    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 ------------------------------------------------------------------------------------------
    ERROR A USER ERROR has occurred (version 2.6-4-g3e5ff60):
    ERROR The invalid arguments or inputs must be corrected before the GATK can proceed
    ERROR Please do not post this error to the GATK forum
    ERROR See the documentation (rerun with -h) for this tool to view allowable command-line arguments.
    ERROR Visit our website and forum for extensive documentation and answers to
    ERROR commonly asked questions
    ERROR MESSAGE: Bad input: We encountered a non-standard non-IUPAC base in the provided reference: '0'
    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

  • Geraldine_VdAuweraGeraldine_VdAuwera Posts: 10,567Administrator, Dev admin

    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

  • ersenkavakersenkavak TurkeyPosts: 1Member

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

  • jkominekjkominek 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.

  • lawallawal 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!!!

  • fabiodpfabiodp Padova, ItalyPosts: 3Member

    Hi All,
    Is there any update about this issue?
    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.

  • Geraldine_VdAuweraGeraldine_VdAuwera Posts: 10,567Administrator, Dev admin
    @fabiodp did you try any of the solutions other people have proposed above?

    Geraldine Van der Auwera, PhD

  • fabiodpfabiodp Padova, ItalyPosts: 3Member

    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?

  • SheilaSheila Broad InstitutePosts: 4,105Member, Broadie, Moderator, Dev admin


    Can you confirm this happens with the latest version?


Sign In or Register to comment.