Get & Annotation of isomiR (isoform of miRNA) profile from RNA-seq I should get and analyse isomiR (isoform of miRNA) profile from RNA-seq with FASTA format. The best tool for this is "DeAnnIso". But here is a problem with this tool, it only allows you to upload FASTA format files  with a maximum size of 50MB. However, the size of my FASTA file is more than 1000MB. I tried to compress the file in different ways and uploading, but it doesn't work.
Does anybody know any way to solving this problem?

Or Does anybody know any other easy way to get isomiR profile from RNA-seq with FASTA format?

A sample of RNA-seq like this: 

&gt;RR42357.95441.1 I-D00105:274:H7MDXX:1:112:8124:865 length=51
TGGAATTCTCGGGTGCCAAGGAACTCCAGTCACCTTGTAATCTCGTATGCC
&gt;RR42357.95442.1 I-D00105:274:H7MDXX:1:112:8133:866 length=51
AAAGTGCTACTACTTTTGAGTCTTGGAATTCTCGGGTGCCAAGGAACTCCA
&gt;RR42357.95443.1 I-D00105:274:H7MDXX:1:112:8144:8637 length=51


Thank you very very much!
The obvious answer is to break up the file size and upload each separately,
First I'd check the file size,

wc infile.fa


Output


  XXXXX      YYYY     ZZZZZ infile.fa


The number you want is XXXX - the number of lines in the file.

You'd then decide how many files you wanted to break it up into ... in your case divide XXXXX by 3. Then .. for example

sed -n '1,5000000p' infile.fa &gt; outfile.fa
sed -n '5000001,2000000p' infile.fa &gt; outfile2.fa
sed -n '2000001,4000000p' infile.fa &gt; outfile3.fa




I'm not certain this would be cool however. An miRNA expert could answer this question very quickly. I think is you should check your data for sequence duplication. Simply piping the fasta file through a simple distance matrix and screening for "0" values would confirm this. 

Creating a frequency table of duplicate RNA must be a feature of Bioconductor, but in any case screening for duplication (technically duplicate records) is a formal SQL database command. 

It can be done a Perl/Python but its a bit clunky for a data set this size. I'd do it by setting the sequence as the key within a hash, the inefficiency has been solved (but its a weird way to do it). 

You would have a database for "headers" for a given sequence, which would take up space, but I would assess the potential level of duplication first.