[maker-devel] is using est_reads option safe?

[Carson Holt]

est_gff is the equivalent of est=, but because the alignment structure is
already in the GFF3, I don't need to align sequence with blastn/exonerate.
 model_gff and pred_gff are essentially the same with the difference being
that model_gff can be kept in the final results even without supporting
evidence, but pred_gff won't.  Pred_gff needs evidence support because it
is a potential model, where model_gff is considered a known model even if
the structure of that model may be uncertain.

other_gff is just a convenience method for passing through GFF3 features
to the final result.  It's impossible to have MAKER be aware of every kind
of possible entry, so if you have something more exotic in the final
output (sequence variant information, alternate alleles, promotor and
methylation site, etc.) then you can pass it in there and it will just be
printed into the file.  It's basically the equivalent of concatenating two
GFF3 files together, but it handles the proper reordering of sequence
information at the end of the GFF3 file (because technically you can't
just concatenate GFF3 files end-to-end).  You can also use the gff3_merge
tool that comes with MAKER to get the same effect.

--Carson



On 4/23/14, 3:55 AM, "Anurag Priyam" <a.priyam at qmul.ac.uk> wrote:

>Thanks, Carson.
>
>I now understand that I shouldn't use est_reds options.
>
>Does MAKER utilise est_gff for prediction or simply passes the
>annotations through to the output GFF? In that case how is it
>different from using other_gff / model_gff (what's the difference
>between these two?)
>
>I have both assembled and raw reads. Is it sufficient to just use the
>assembled set?
>
>-- Priyam
>
>On Tue, Apr 22, 2014 at 11:32 PM, Carson Holt <carsonhh at gmail.com> wrote:
>> The est_reads option doesn't do anything.  It in the run log for
>>backwards
>> compatibility with old jobs because MAKER has a restart capability (i.e.
>> people can rerun new MAKER versions against old MAKER output in the same
>> directory - it can reuse old raw results to avoid rerunning analysis
>> steps).  The est_reads was originally there for developer
>>experimentation,
>> but then it went away.
>>
>> You need to use an external tool like tophat and cufflinks to align
>>short
>> reads and assemble them into likely exon blocks (i.e. the GFF3
>>passthrough
>> option you mentioned).  Or you can assemble then without alignment using
>> something like trinity (then you can provide that result to the est=
>> options because it will be in fasta format).
>>
>> You should not use raw reads directly with MAKER, you need to preprocess
>> them using one of the methods mentioned for them to be useful.
>>
>> Thanks,
>> Carson
>>
>>
>>
>> On 4/22/14, 11:45 AM, "Anurag Priyam" <a.priyam at qmul.ac.uk> wrote:
>>
>>>Hi,
>>>
>>>I need to run MAKER against a genome with both raw (FASTQ) and
>>>assembled (FASTA) RNA-Seq data. I point MAKER to assembled data using
>>>est= options in maker_opts.ctl. Looking for how to point MAKER to the
>>>raw reads I came across this thread
>>>https://groups.google.com/forum/#!topic/maker-devel/oLEXJ4z4fDY where
>>>Dr. Carlson Holt points out that est_gff should be used. However, from
>>>MAKER's run log it seems that est_reads option is not deprecated, just
>>>hidden from plain sight by excluding it from maker_opts.ctl. So I set
>>>est_reads option in maker_opts.ctl and MAKER parses the control files
>>>and runs just fine.
>>>
>>>Now I am left wondering if it's safe to use est_reads. As in, could it
>>>impact the predicted set negatively?
>>>
>>>-- Priyam
>>>
>>>_______________________________________________
>>>maker-devel mailing list
>>>maker-devel at box290.bluehost.com
>>>http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>>
>>