Related: Encountering a bug that keeps me from ana...
# mag
d
Related: Encountering a bug that keeps me from analyzing my samples https://github.com/nf-core/mag/issues/1031. If I am right with my short assessment of the issue than I cannot quickly sort this out with a config, because only one the the two issue (the file name collision) can be solved that way but not the treatment of the singled-ended long reads as paired-ended reads. I'll be back Monday, can we make a quick patch release when thats resolved (I can attempt to implement a solution next week if nobody beat me to it)?
<!subteam^S08MYEKMNTX> that is sort of blocking my progress for a project (we have a policy of only using released pipeline versions for specific projects). When could be the next possible release date for a release? I could also prep a release right now, or needs one/several of the other PRs added first?
d
Hi @Daniel Straub My plan was finishing all the snapshots before releasing 5.5.0. But if you are in a hurry, we can finish hybrid profile, do the template merge and release with that.
d
Thanks, sounds good! I had the thought to first check if the approach I want to do is better than the alternatives. So I'm running the hybrid co-assembly with a fork with the fix atm to actually judge if short-read-first hybrid co-assembly with SPAdes seems better than the long-read-first co-assembly (and my manual short read polishing). If the SPAdes assembly is indeed better, then I'd be in a hurry. I'll let you know 😉
Alright, no rush needed actually. To share the experience: The short-read-first hybrid co-assembly led to substantially more fragmented (such as 70 vs 7 contigs) and less MAGs (~400 vs ~800) than long-read co-assembly. However, the MAGs were very slightly more complete (such as 96% to 95%). So I go with the long-read co-assembly.
d
Good to know, thanks Daniel