-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mikado serialise: sqlalchemy.exc.InvalidRequestError: No transaction is begun. #206
Comments
Hi @AsclepiusDoc, many thanks for reporting this. I will try to replicate and solve it ASAP. |
Dear @AsclepiusDoc , I was able to reproduce the bug. I will fix it today. To avoid this, I would recommend using the pipeline manager we developed - Daijin, included in Mikado - to perform the analysis on cotton. Specifically, Daijin can be used to run all the mikado steps. In order:
This will ensure that the steps are executed correctly. Thank you for reporting the bug! |
PS:
|
…d by @AsclepiusDoc will raise an error.
Dear @AsclepiusDoc , now Mikado will die informatively when a situation like yours arises; this should make it easier to spot a problem in the pipeline's usage. The rationale is that if Mikado had not died during serialisation, the data present in the database would have been useless - Mikado would have had no way to link the ORFs with the transcripts present in the GTF (as their names change due to the juxtaposition of a label). |
…e log for Mikado serialise, and 09b97aa
Hello @lucventurini , Thank you so much for your help! That did the trick and I was able to get Mikado outputs. Additionally, I followed your suggestion and was able to get a Trinity output for Mikado however, I seem to have ran into another parsing issue with the Trinity .gff3 file. I have attached the error here if that is okay? Error:
Additionally, I grepped the string that was reported to be non-unique and got the following results:
Furthermore, I will look into the Daijin pipeline as you have recommended. Once again thank you for all your help! Kind Regards, Alex Lim |
Dear @AsclepiusDoc, the problem is that one of the lines is on chromosome 1 (rather than 10000001). That is clearly a mistake on GMAP part, as the culprit exon is actually missing from the correct chromosome (it's the starting exon of the model). Mikado presumes that models should belong to the same scaffold /chromosome, so this is flagged as a clear a mistake. I do not know why it happened; it looks like a bug in GMAP. I would try a different version of the program to see whether the bug represents itself again. Glad to hear that my suggestions solved the problem for you! |
* Fix EI-CoreBioinformatics#206. Now Mikado serialise will raise an error and exit when trying to add ORFs for transcripts that have not been serialised (if any has already). This will avoid a common mistake (see in EI-CoreBioinformatics#206) whereupon experimenters will try to use ORFs called on Mikado prepare's **inputs** rather than its output.
Hello @lucventurini ,
I have moved onto mikado serialise and have ran into another error. I was wondering if I could get your help?
Below is the error that I am currently getting.
Here is the command I am currently using:
mikado serialise --json-conf configuration.yaml --xml mikado.blast.xml.gz --orfs ../stringtie/longest_orfs.pep.transdecoder.bed
Additionally, I have attached a toy dataset of what I am working with.
Kind Regards,
Alex Lim
Question unrelated to the error if you have some time:
I was wondering if it was possible to learn what was done to generate the .gff3 file from the Trinity transcripts using GMAP. If my understanding is correct usually you get a standard alignment file in (.sam/.bam) format?
toy_bed.zip
The text was updated successfully, but these errors were encountered: