Domanda:
Perché questo comando makeblastdb non funziona?
TW93
2017-09-21 17:53:10 UTC
view on stackexchange narkive permalink

Sto cercando di creare database locali per il pacchetto ncbi-blast + (versione 2.60). Lo sto facendo per 4 geni del recettore delle cellule T. 3 dei 4 (TRAV, TRAJ, TRBV) hanno funzionato bene, ma ho problemi con TRBJ. Dico questo perché dovrebbero avere lo stesso formato e se uno funziona il resto funziona.

Prendono il formato seguente: 

  >K02545 | TRBJ1-1 * 01 | Homo sapiens | F | J-REGION | 749..796 | 48 nt | 3 | | | | 15 AA | 15 + 0 = 15 | | | NTEAFFGQGTRLTVV

Ho usato il seguente comando (come ho detto, andava bene per il resto, stranamente): 

  makeblastdb -in TRBJ_AA.fa -parse_seqids -dbtype prot

e ricevo il seguente messaggio di errore: 

  Errore opzioni BLAST: TRBJ_AA.fa non corrisponde al tipo di formato di input, input predefinito il tipoèFASTA

Un problema che ho verificato è che la lunghezza delle sequenze è troppo breve, ma credo che 11 sia la lunghezza minima richiesta (per gli input, non so se è la stessa per i database), ma qualcuno sarebbe in grado di confermare che questo mi sembra il candidato più probabile?

Sono felice di utilizzare qualche altra metrica, ma speravo di mantenere BLAST per coerenza per il momento.

Grazie.

edit: So che è troppo tardi, ma per riferimento sono su Ubuntu 16.04.2 LTS x86_64 per tutti i passaggi.

Su quale sistema operativo lo stai eseguendo e su quale sistema operativo è stato creato il file di input? Inoltre, [modifica] la tua domanda e mostraci il file che stai utilizzando.
Una risposta:
terdon
2017-09-21 19:18:49 UTC
view on stackexchange narkive permalink

Sembra un bug in makeblastdb . Rimozione del finale | | | dalla descrizione della sequenza lo fa funzionare: 

  >K02545 | TRBJ1-1 * 01 | Homo sapiens | F | J-REGION | 749..796 | 48 nt | 3 | | | | 15 AA | 15 + 0 = 15

Così come rimuove tutto dopo il primo spazio: 

  >K02545 | TRBJ1-1 * 01 | Homo sapiens | F | J-REGION | 749..796 | 48

Non c'è nulla nella definizione FASTA che spieghi questo e, ancor più stranamente, la presenza del | | | da solo non è sufficiente per attivare il problema. Ci ho giocato un po 'e sembra che non gli piaccia la combinazione di + o - insieme a | | , ma non riesco a vedere uno schema chiaro:

Questi falliscono: 

  > | | | 15- | | | > | | | 15+ | | | > | | | 15-1 | | | > | | | 15 + 1 | | |

Questi funzionano: 

  > | | 15+ | | > | | | 151 | | |

Quindi sì, suona come un bug. Ti suggerisco di segnalarlo agli sviluppatori NCBI. Nel frattempo, una semplice soluzione sarebbe quella di mantenere il primo campo separato da spazi della tua intestazione fasta. Passa il tuo file fasta attraverso questo: 

  awk '{print $ 1}' fasta.fa > new.fa

Questo stamperà il primo campo di ciascuno e, supponendo che tu non abbia spazi nella sequenza, dovrebbe risolverlo efficacemente per te.

Non sono convinto che si tratti di un bug di per sé: gli header FASTA possono utilizzare qualsiasi combinazione di [questi identificatori specifici] (https://www.ncbi.nlm.nih.gov/books/NBK21097/table/A632/? report = objectonly). Lo sta analizzando in qualche modo (supponendo che stia cercando di capire quale dei possibili identificatori usare in base all'analisi di + e - come stringhe), ma deve essere confuso dall'aggiunta di tre colonne vuote.
@OrdiNeu ciò che è dopo> è lasciato all'utente il compito di decidere se NCBI decide di aggiungere questi identificatori o più è una sua decisione ma dovrebbe essere in grado di funzionare con altri identificatori
@OrdiNeu il formato FASTA stesso consente a tutto ciò che ti interessa di mettere lì. Gli identificatori a cui ti sei collegato sono proprio quelli che NCBI tende a usare nei * suoi * file FASTA, ma non hanno nulla a che fare con il formato FASTA. Se un programma prevede un formato specifico, il programma è difettoso. Il fatto che non ci sia uno schema chiaro e che il problema si verifichi sia con che senza il flag `-parse_seqids` è un'ulteriore indicazione di un bug.
Stranamente ho scoperto sul mio sistema che se "funziona" dipende anche dalle righe della sequenza. Ad esempio, prendi l'intestazione `> | | | 151 | | | `e la sequenza` ATGAAGAG` fallisce, con `ATGAAGAG \ nATG` funziona (in entrambi i casi si esegue` makeblastdb -dbtype nucl -in my_fasta.fa`)
@Chris_Rands curioso e curioso. Ma questo rende ancora più probabile che si tratti di un bug.
@terdon Sì, puoi replicare ciò che ho descritto?
@terdon Questo è ehm ... interessante! Le 3 colonne vuote possono essere trovate nelle altre intestazioni di sequenza IMGT, che sono state analizzate con successo, mentre i numeri con +/- si trovano solo nel file del problema che pone la colpa saldamente alla loro porta. Inoltre, non funziona ancora quando si omette il flag -parseseq_id. Lo segnalerò. Grazie per aver mantenuto la mia sanità mentale.
@Chris_Rands sì e no. Quello che dici funziona, un po 'funziona sul mio sistema ma si lamenta di "Errore di creazione del database BLAST: Defline manca di un ID appropriato intorno alla riga 1". Cambiando la definizione in `> a | | | 151 | | | `, tuttavia, riproduce perfettamente ciò che descrivi: la sequenza` ATGAAGAG` fallisce ma la sequenza `ATGAAGAG \ nATG` funziona. Strano.
@TW93 sei il benvenuto. So come ti senti. Mi sarei interrogato anche sulla mia sanità mentale se l'avessi incontrato in natura.


ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...