Maker protein match & tandem similar genes

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Maker protein match & tandem similar genes

Tim Fallon
Hi there,

I am aligning reference proteins to an insect genome through Maker, in preparation for using the gene models from the protein alignments as evidence to train SNAP (alongside de-novo assembled RNA-Seq).  I also plan on passing the protein alignments to a future Maker run as hints for SNAP / Augustus.

I’ve noticed that the maker blastx "protein_match” feature, which I presume is a result of Maker trying to make the blastx HSPs contiguous to format as a reference for exonerate (this Maker run did have protein2genome turned on), tends to fuse tandem genes from the same gene family.  See attached image.

The red regions highlight two de novo assembled transcripts which I aligned manually, from two genes that are homologous.  The top track is the blastx “match_part” features, the bottom track is the blastx “protein_match” features.  You can see that the protein_match fuses the two genes, using ~1000 bp in an intervening region, that doesn’t have blastx HSP support in the blastx “match_part” track.  The trick seems to be that a single reference protein, has blastx matches on both the left and right gene.

Cleary this isn’t a good gene model to train SNAP with, but would this misannotation screw up the hints passed to pretrained SNAP / Augustus?

Is there anyway to prevent this protein_match fusing of adjacent similar genes from happening?  For species that are closer, I’ve set the “eval_blastx” to be a lot higher (1e-50), and in that case the genes don’t get fused (but, with that level of stringent search, it is more like an orthology search, rather than just annotating general protein similarity).  I do have (rare) introns ~1000 bp, so I wouldn’t want to change the Maker “split_hit” parameter to be too low.

All the best,
-Tim

Timothy R. Fallon
PhD candidate
Laboratory of Jing-Ke Weng
Department of Biology
MIT





_______________________________________________
maker-devel mailing list
[hidden email]
http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org

smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maker protein match & tandem similar genes

Carson Holt-2
The protein_match features are the direct BLASTX results. Because of how BLAST works, if you have neighboring paralogs, it can place HSPs in both. So the final hit ends up being to large. The protein2genome feature is then the result of exonerate polishing these blast alignments (this will usually remove false merging and bad exon order). The protein2genome=1 option on the other hand just tell maker that you want to try and convert the exonerate hits directly into gene models (only do this for training and not final annotation). One way to drop the BLASTX results may be to filter the GFF3 results to keep only protein2genome features, pass those into protein_gff, and then turn off protein= for the next run. This forces the blastx results to be dropped. You may want to set blast_depth parameters to something like 10 in maker_bopts.ctl before doing this to trim per locus evidence depth to 10 if you are using too much input data.

—Carson



On Jun 13, 2017, at 11:35 AM, Tim Fallon <[hidden email]> wrote:

Hi there,

I am aligning reference proteins to an insect genome through Maker, in preparation for using the gene models from the protein alignments as evidence to train SNAP (alongside de-novo assembled RNA-Seq).  I also plan on passing the protein alignments to a future Maker run as hints for SNAP / Augustus.

I’ve noticed that the maker blastx "protein_match” feature, which I presume is a result of Maker trying to make the blastx HSPs contiguous to format as a reference for exonerate (this Maker run did have protein2genome turned on), tends to fuse tandem genes from the same gene family.  See attached image.

The red regions highlight two de novo assembled transcripts which I aligned manually, from two genes that are homologous.  The top track is the blastx “match_part” features, the bottom track is the blastx “protein_match” features.  You can see that the protein_match fuses the two genes, using ~1000 bp in an intervening region, that doesn’t have blastx HSP support in the blastx “match_part” track.  The trick seems to be that a single reference protein, has blastx matches on both the left and right gene.

Cleary this isn’t a good gene model to train SNAP with, but would this misannotation screw up the hints passed to pretrained SNAP / Augustus?

Is there anyway to prevent this protein_match fusing of adjacent similar genes from happening?  For species that are closer, I’ve set the “eval_blastx” to be a lot higher (1e-50), and in that case the genes don’t get fused (but, with that level of stringent search, it is more like an orthology search, rather than just annotating general protein similarity).  I do have (rare) introns ~1000 bp, so I wouldn’t want to change the Maker “split_hit” parameter to be too low.

All the best,
-Tim

Timothy R. Fallon
PhD candidate
Laboratory of Jing-Ke Weng
Department of Biology
MIT


<protein_match_example.png>


_______________________________________________
maker-devel mailing list
[hidden email]
http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org


_______________________________________________
maker-devel mailing list
[hidden email]
http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maker protein match & tandem similar genes

Tim Fallon
Hi Carson,

Thanks for the response! After sending my initial email, I did notice this particular issue was warned about in the Cambell et al. 2014 Maker protocols paper.  Perhaps future versions of the pipeline might have a workaround or warning for this presumably common issue. At least in my case, the genome I’m annotating has large introns, and also tandem gene clusters of homologous genes, so I’ve been unable to solve this issue entirely by changing existing parameters (e.g. split_hit), though perhaps exonerate / protein2genome direct gene annotation does handle it correctly.

Regarding the protein2genome only being a intermediate stage, as I’ve been working towards a final annotation, I’ve actually been mostly relying on the protein2genome direct gene annotation, as although I have a trained Augustus that is presumably getting the hints from the evidence, my main target genes have been producing subtly wrong gene-models (Augustus produced splice sit off by a handful of nucleotides, leading to unintended & unsupported amino acids in the protein).  I also trained SNAP, but those predictions were worse than the Augustus predictions.

Do you have any tips for using the Evidence Modeler integration of the Maker 3.0.0 beta?  That seems to be the best way to have the final gene models rely more on extrinsic evidence over my mildly incorrect ab-initio predictions.  Or perhaps PASA is more appropriate for gene-models that would strictly adhere to extrinsic de novo assembled transcript / predicted ORF evidence?

All the best,
-Tim

On Jun 23, 2017, at 12:27 AM, Carson Holt <[hidden email]> wrote:

The protein_match features are the direct BLASTX results. Because of how BLAST works, if you have neighboring paralogs, it can place HSPs in both. So the final hit ends up being to large. The protein2genome feature is then the result of exonerate polishing these blast alignments (this will usually remove false merging and bad exon order). The protein2genome=1 option on the other hand just tell maker that you want to try and convert the exonerate hits directly into gene models (only do this for training and not final annotation). One way to drop the BLASTX results may be to filter the GFF3 results to keep only protein2genome features, pass those into protein_gff, and then turn off protein= for the next run. This forces the blastx results to be dropped. You may want to set blast_depth parameters to something like 10 in maker_bopts.ctl before doing this to trim per locus evidence depth to 10 if you are using too much input data.

—Carson



On Jun 13, 2017, at 11:35 AM, Tim Fallon <[hidden email]> wrote:

Hi there,

I am aligning reference proteins to an insect genome through Maker, in preparation for using the gene models from the protein alignments as evidence to train SNAP (alongside de-novo assembled RNA-Seq).  I also plan on passing the protein alignments to a future Maker run as hints for SNAP / Augustus.

I’ve noticed that the maker blastx "protein_match” feature, which I presume is a result of Maker trying to make the blastx HSPs contiguous to format as a reference for exonerate (this Maker run did have protein2genome turned on), tends to fuse tandem genes from the same gene family.  See attached image.

The red regions highlight two de novo assembled transcripts which I aligned manually, from two genes that are homologous.  The top track is the blastx “match_part” features, the bottom track is the blastx “protein_match” features.  You can see that the protein_match fuses the two genes, using ~1000 bp in an intervening region, that doesn’t have blastx HSP support in the blastx “match_part” track.  The trick seems to be that a single reference protein, has blastx matches on both the left and right gene.

Cleary this isn’t a good gene model to train SNAP with, but would this misannotation screw up the hints passed to pretrained SNAP / Augustus?

Is there anyway to prevent this protein_match fusing of adjacent similar genes from happening?  For species that are closer, I’ve set the “eval_blastx” to be a lot higher (1e-50), and in that case the genes don’t get fused (but, with that level of stringent search, it is more like an orthology search, rather than just annotating general protein similarity).  I do have (rare) introns ~1000 bp, so I wouldn’t want to change the Maker “split_hit” parameter to be too low.

All the best,
-Tim

Timothy R. Fallon
PhD candidate
Laboratory of Jing-Ke Weng
Department of Biology
MIT


<protein_match_example.png>


_______________________________________________
maker-devel mailing list
[hidden email]
http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org


Timothy R. Fallon
PhD candidate
Laboratory of Jing-Ke Weng
Department of Biology
MIT



_______________________________________________
maker-devel mailing list
[hidden email]
http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org

smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maker protein match & tandem similar genes

Carson Holt-2
Augustus uses an HMM with scoring bonuses for evidence match. If a difference in the assembly breaks the ORF anywhere in the transcript relative to the evidence or removes high scoring transcript start/stop sequences, then Augustus will add/skip exons or trim/extend transcripts to capture what scoring bonuses it can as best it can. So wherever you see Augustus behaving weirdly, you likely have something off in the assembly (small stretch of NN’s or single basepair duplications/deletions that affect the ORF and scoring model). So what Augustus produces is the best fit gene model to hop around assembly anomalies while still producing a canonical model. 

In areas like the ones I describe above, EVM refuses to produce any model. So you can experiment with the EVM options in MAKER3, but what you may find is that problem regions tend to get no models with EVM. I believe using the pred_gff trick I mentioned previously may be the easiest work around. Also make sure to prefilter mRNA-seq evidence to avoid transcript joining (trinity has a jaccard_clip option which can help). Because if you are getting transcript joining in proteins, you are almost certain to get it in transcript evidence as well.

—Carson

On Jun 22, 2017, at 10:59 PM, Tim Fallon <[hidden email]> wrote:

Hi Carson,

Thanks for the response! After sending my initial email, I did notice this particular issue was warned about in the Cambell et al. 2014 Maker protocols paper.  Perhaps future versions of the pipeline might have a workaround or warning for this presumably common issue. At least in my case, the genome I’m annotating has large introns, and also tandem gene clusters of homologous genes, so I’ve been unable to solve this issue entirely by changing existing parameters (e.g. split_hit), though perhaps exonerate / protein2genome direct gene annotation does handle it correctly.

Regarding the protein2genome only being a intermediate stage, as I’ve been working towards a final annotation, I’ve actually been mostly relying on the protein2genome direct gene annotation, as although I have a trained Augustus that is presumably getting the hints from the evidence, my main target genes have been producing subtly wrong gene-models (Augustus produced splice sit off by a handful of nucleotides, leading to unintended & unsupported amino acids in the protein).  I also trained SNAP, but those predictions were worse than the Augustus predictions.

Do you have any tips for using the Evidence Modeler integration of the Maker 3.0.0 beta?  That seems to be the best way to have the final gene models rely more on extrinsic evidence over my mildly incorrect ab-initio predictions.  Or perhaps PASA is more appropriate for gene-models that would strictly adhere to extrinsic de novo assembled transcript / predicted ORF evidence?

All the best,
-Tim

On Jun 23, 2017, at 12:27 AM, Carson Holt <[hidden email]> wrote:

The protein_match features are the direct BLASTX results. Because of how BLAST works, if you have neighboring paralogs, it can place HSPs in both. So the final hit ends up being to large. The protein2genome feature is then the result of exonerate polishing these blast alignments (this will usually remove false merging and bad exon order). The protein2genome=1 option on the other hand just tell maker that you want to try and convert the exonerate hits directly into gene models (only do this for training and not final annotation). One way to drop the BLASTX results may be to filter the GFF3 results to keep only protein2genome features, pass those into protein_gff, and then turn off protein= for the next run. This forces the blastx results to be dropped. You may want to set blast_depth parameters to something like 10 in maker_bopts.ctl before doing this to trim per locus evidence depth to 10 if you are using too much input data.

—Carson



On Jun 13, 2017, at 11:35 AM, Tim Fallon <[hidden email]> wrote:

Hi there,

I am aligning reference proteins to an insect genome through Maker, in preparation for using the gene models from the protein alignments as evidence to train SNAP (alongside de-novo assembled RNA-Seq).  I also plan on passing the protein alignments to a future Maker run as hints for SNAP / Augustus.

I’ve noticed that the maker blastx "protein_match” feature, which I presume is a result of Maker trying to make the blastx HSPs contiguous to format as a reference for exonerate (this Maker run did have protein2genome turned on), tends to fuse tandem genes from the same gene family.  See attached image.

The red regions highlight two de novo assembled transcripts which I aligned manually, from two genes that are homologous.  The top track is the blastx “match_part” features, the bottom track is the blastx “protein_match” features.  You can see that the protein_match fuses the two genes, using ~1000 bp in an intervening region, that doesn’t have blastx HSP support in the blastx “match_part” track.  The trick seems to be that a single reference protein, has blastx matches on both the left and right gene.

Cleary this isn’t a good gene model to train SNAP with, but would this misannotation screw up the hints passed to pretrained SNAP / Augustus?

Is there anyway to prevent this protein_match fusing of adjacent similar genes from happening?  For species that are closer, I’ve set the “eval_blastx” to be a lot higher (1e-50), and in that case the genes don’t get fused (but, with that level of stringent search, it is more like an orthology search, rather than just annotating general protein similarity).  I do have (rare) introns ~1000 bp, so I wouldn’t want to change the Maker “split_hit” parameter to be too low.

All the best,
-Tim

Timothy R. Fallon
PhD candidate
Laboratory of Jing-Ke Weng
Department of Biology
MIT


<protein_match_example.png>


_______________________________________________
maker-devel mailing list
[hidden email]
http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org


Timothy R. Fallon
PhD candidate
Laboratory of Jing-Ke Weng
Department of Biology
MIT




_______________________________________________
maker-devel mailing list
[hidden email]
http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maker protein match & tandem similar genes

Tim Fallon
Hi Carson,

This region is definitely entirely correct at the genomic nucleotide level, no missassemblies.  Would you have any strong reservations about ditching the ab-initio prediction and sticking entirely with the est2genome predictions and protein2genome predictions?  Right now this is what I’m thinking, as troubleshooting the ab-initio training seems like it could be a long road.

All the best,
-Tim

On Jun 26, 2017, at 6:00 PM, Carson Holt <[hidden email]> wrote:

Augustus uses an HMM with scoring bonuses for evidence match. If a difference in the assembly breaks the ORF anywhere in the transcript relative to the evidence or removes high scoring transcript start/stop sequences, then Augustus will add/skip exons or trim/extend transcripts to capture what scoring bonuses it can as best it can. So wherever you see Augustus behaving weirdly, you likely have something off in the assembly (small stretch of NN’s or single basepair duplications/deletions that affect the ORF and scoring model). So what Augustus produces is the best fit gene model to hop around assembly anomalies while still producing a canonical model. 

In areas like the ones I describe above, EVM refuses to produce any model. So you can experiment with the EVM options in MAKER3, but what you may find is that problem regions tend to get no models with EVM. I believe using the pred_gff trick I mentioned previously may be the easiest work around. Also make sure to prefilter mRNA-seq evidence to avoid transcript joining (trinity has a jaccard_clip option which can help). Because if you are getting transcript joining in proteins, you are almost certain to get it in transcript evidence as well.

—Carson

On Jun 22, 2017, at 10:59 PM, Tim Fallon <[hidden email]> wrote:

Hi Carson,

Thanks for the response! After sending my initial email, I did notice this particular issue was warned about in the Cambell et al. 2014 Maker protocols paper.  Perhaps future versions of the pipeline might have a workaround or warning for this presumably common issue. At least in my case, the genome I’m annotating has large introns, and also tandem gene clusters of homologous genes, so I’ve been unable to solve this issue entirely by changing existing parameters (e.g. split_hit), though perhaps exonerate / protein2genome direct gene annotation does handle it correctly.

Regarding the protein2genome only being a intermediate stage, as I’ve been working towards a final annotation, I’ve actually been mostly relying on the protein2genome direct gene annotation, as although I have a trained Augustus that is presumably getting the hints from the evidence, my main target genes have been producing subtly wrong gene-models (Augustus produced splice sit off by a handful of nucleotides, leading to unintended & unsupported amino acids in the protein).  I also trained SNAP, but those predictions were worse than the Augustus predictions.

Do you have any tips for using the Evidence Modeler integration of the Maker 3.0.0 beta?  That seems to be the best way to have the final gene models rely more on extrinsic evidence over my mildly incorrect ab-initio predictions.  Or perhaps PASA is more appropriate for gene-models that would strictly adhere to extrinsic de novo assembled transcript / predicted ORF evidence?

All the best,
-Tim

On Jun 23, 2017, at 12:27 AM, Carson Holt <[hidden email]> wrote:

The protein_match features are the direct BLASTX results. Because of how BLAST works, if you have neighboring paralogs, it can place HSPs in both. So the final hit ends up being to large. The protein2genome feature is then the result of exonerate polishing these blast alignments (this will usually remove false merging and bad exon order). The protein2genome=1 option on the other hand just tell maker that you want to try and convert the exonerate hits directly into gene models (only do this for training and not final annotation). One way to drop the BLASTX results may be to filter the GFF3 results to keep only protein2genome features, pass those into protein_gff, and then turn off protein= for the next run. This forces the blastx results to be dropped. You may want to set blast_depth parameters to something like 10 in maker_bopts.ctl before doing this to trim per locus evidence depth to 10 if you are using too much input data.

—Carson



On Jun 13, 2017, at 11:35 AM, Tim Fallon <[hidden email]> wrote:

Hi there,

I am aligning reference proteins to an insect genome through Maker, in preparation for using the gene models from the protein alignments as evidence to train SNAP (alongside de-novo assembled RNA-Seq).  I also plan on passing the protein alignments to a future Maker run as hints for SNAP / Augustus.

I’ve noticed that the maker blastx "protein_match” feature, which I presume is a result of Maker trying to make the blastx HSPs contiguous to format as a reference for exonerate (this Maker run did have protein2genome turned on), tends to fuse tandem genes from the same gene family.  See attached image.

The red regions highlight two de novo assembled transcripts which I aligned manually, from two genes that are homologous.  The top track is the blastx “match_part” features, the bottom track is the blastx “protein_match” features.  You can see that the protein_match fuses the two genes, using ~1000 bp in an intervening region, that doesn’t have blastx HSP support in the blastx “match_part” track.  The trick seems to be that a single reference protein, has blastx matches on both the left and right gene.

Cleary this isn’t a good gene model to train SNAP with, but would this misannotation screw up the hints passed to pretrained SNAP / Augustus?

Is there anyway to prevent this protein_match fusing of adjacent similar genes from happening?  For species that are closer, I’ve set the “eval_blastx” to be a lot higher (1e-50), and in that case the genes don’t get fused (but, with that level of stringent search, it is more like an orthology search, rather than just annotating general protein similarity).  I do have (rare) introns ~1000 bp, so I wouldn’t want to change the Maker “split_hit” parameter to be too low.

All the best,
-Tim

Timothy R. Fallon
PhD candidate
Laboratory of Jing-Ke Weng
Department of Biology
MIT


<protein_match_example.png>


_______________________________________________
maker-devel mailing list
[hidden email]
http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org


Timothy R. Fallon
PhD candidate
Laboratory of Jing-Ke Weng
Department of Biology
MIT




Timothy R. Fallon
PhD candidate
Laboratory of Jing-Ke Weng
Department of Biology
MIT



_______________________________________________
maker-devel mailing list
[hidden email]
http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org

smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maker protein match & tandem similar genes

Carson Holt-2
est2genome and protein2genome will almost always be partial. Also the error rate on draft assemblies is much higher than most people realize. Beyond issues already mentioned in the previous e-mail, there is also the issue that organisms are diploid, but the assembly is haploid, so variation gets squashed which also breaks ORFs (there are several examples of this in both the mature human and mouse genome assemblies). For many draft assemblies, you can expect ORF affecting errors in as much as 10-15% of your annotations.

Try opening the cases with issues and manually editing them in Apollo. Possible sources of sequence guiding the annotation may become more apparent (look at mismatches in the mRNA-seq alignments relative to the assembly for example). And if not, and the region is just too complex for the predictor, then you can force the model with Apollo. 

—Carson


On Jul 6, 2017, at 6:45 AM, Tim Fallon <[hidden email]> wrote:

Hi Carson,

This region is definitely entirely correct at the genomic nucleotide level, no missassemblies.  Would you have any strong reservations about ditching the ab-initio prediction and sticking entirely with the est2genome predictions and protein2genome predictions?  Right now this is what I’m thinking, as troubleshooting the ab-initio training seems like it could be a long road.

All the best,
-Tim

On Jun 26, 2017, at 6:00 PM, Carson Holt <[hidden email]> wrote:

Augustus uses an HMM with scoring bonuses for evidence match. If a difference in the assembly breaks the ORF anywhere in the transcript relative to the evidence or removes high scoring transcript start/stop sequences, then Augustus will add/skip exons or trim/extend transcripts to capture what scoring bonuses it can as best it can. So wherever you see Augustus behaving weirdly, you likely have something off in the assembly (small stretch of NN’s or single basepair duplications/deletions that affect the ORF and scoring model). So what Augustus produces is the best fit gene model to hop around assembly anomalies while still producing a canonical model. 

In areas like the ones I describe above, EVM refuses to produce any model. So you can experiment with the EVM options in MAKER3, but what you may find is that problem regions tend to get no models with EVM. I believe using the pred_gff trick I mentioned previously may be the easiest work around. Also make sure to prefilter mRNA-seq evidence to avoid transcript joining (trinity has a jaccard_clip option which can help). Because if you are getting transcript joining in proteins, you are almost certain to get it in transcript evidence as well.

—Carson

On Jun 22, 2017, at 10:59 PM, Tim Fallon <[hidden email]> wrote:

Hi Carson,

Thanks for the response! After sending my initial email, I did notice this particular issue was warned about in the Cambell et al. 2014 Maker protocols paper.  Perhaps future versions of the pipeline might have a workaround or warning for this presumably common issue. At least in my case, the genome I’m annotating has large introns, and also tandem gene clusters of homologous genes, so I’ve been unable to solve this issue entirely by changing existing parameters (e.g. split_hit), though perhaps exonerate / protein2genome direct gene annotation does handle it correctly.

Regarding the protein2genome only being a intermediate stage, as I’ve been working towards a final annotation, I’ve actually been mostly relying on the protein2genome direct gene annotation, as although I have a trained Augustus that is presumably getting the hints from the evidence, my main target genes have been producing subtly wrong gene-models (Augustus produced splice sit off by a handful of nucleotides, leading to unintended & unsupported amino acids in the protein).  I also trained SNAP, but those predictions were worse than the Augustus predictions.

Do you have any tips for using the Evidence Modeler integration of the Maker 3.0.0 beta?  That seems to be the best way to have the final gene models rely more on extrinsic evidence over my mildly incorrect ab-initio predictions.  Or perhaps PASA is more appropriate for gene-models that would strictly adhere to extrinsic de novo assembled transcript / predicted ORF evidence?

All the best,
-Tim

On Jun 23, 2017, at 12:27 AM, Carson Holt <[hidden email]> wrote:

The protein_match features are the direct BLASTX results. Because of how BLAST works, if you have neighboring paralogs, it can place HSPs in both. So the final hit ends up being to large. The protein2genome feature is then the result of exonerate polishing these blast alignments (this will usually remove false merging and bad exon order). The protein2genome=1 option on the other hand just tell maker that you want to try and convert the exonerate hits directly into gene models (only do this for training and not final annotation). One way to drop the BLASTX results may be to filter the GFF3 results to keep only protein2genome features, pass those into protein_gff, and then turn off protein= for the next run. This forces the blastx results to be dropped. You may want to set blast_depth parameters to something like 10 in maker_bopts.ctl before doing this to trim per locus evidence depth to 10 if you are using too much input data.

—Carson



On Jun 13, 2017, at 11:35 AM, Tim Fallon <[hidden email]> wrote:

Hi there,

I am aligning reference proteins to an insect genome through Maker, in preparation for using the gene models from the protein alignments as evidence to train SNAP (alongside de-novo assembled RNA-Seq).  I also plan on passing the protein alignments to a future Maker run as hints for SNAP / Augustus.

I’ve noticed that the maker blastx "protein_match” feature, which I presume is a result of Maker trying to make the blastx HSPs contiguous to format as a reference for exonerate (this Maker run did have protein2genome turned on), tends to fuse tandem genes from the same gene family.  See attached image.

The red regions highlight two de novo assembled transcripts which I aligned manually, from two genes that are homologous.  The top track is the blastx “match_part” features, the bottom track is the blastx “protein_match” features.  You can see that the protein_match fuses the two genes, using ~1000 bp in an intervening region, that doesn’t have blastx HSP support in the blastx “match_part” track.  The trick seems to be that a single reference protein, has blastx matches on both the left and right gene.

Cleary this isn’t a good gene model to train SNAP with, but would this misannotation screw up the hints passed to pretrained SNAP / Augustus?

Is there anyway to prevent this protein_match fusing of adjacent similar genes from happening?  For species that are closer, I’ve set the “eval_blastx” to be a lot higher (1e-50), and in that case the genes don’t get fused (but, with that level of stringent search, it is more like an orthology search, rather than just annotating general protein similarity).  I do have (rare) introns ~1000 bp, so I wouldn’t want to change the Maker “split_hit” parameter to be too low.

All the best,
-Tim

Timothy R. Fallon
PhD candidate
Laboratory of Jing-Ke Weng
Department of Biology
MIT


<protein_match_example.png>


_______________________________________________
maker-devel mailing list
[hidden email]
http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org


Timothy R. Fallon
PhD candidate
Laboratory of Jing-Ke Weng
Department of Biology
MIT




Timothy R. Fallon
PhD candidate
Laboratory of Jing-Ke Weng
Department of Biology
MIT




_______________________________________________
maker-devel mailing list
[hidden email]
http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
Loading...