IMP issueshttps://git-r3lab.uni.lu/IMP/IMP/-/issues2017-11-10T03:44:08+01:00https://git-r3lab.uni.lu/IMP/IMP/-/issues/79Metaquast not working2017-11-10T03:44:08+01:00Shaman NarayanasamyMetaquast not workingMetaQUAST report does not appear in the IMP main reportMetaQUAST report does not appear in the IMP main reportShaman NarayanasamyShaman Narayanasamyhttps://git-r3lab.uni.lu/IMP/IMP/-/issues/139Error in idba_hybrid_assembly_22018-09-24T11:33:30+02:00Cedric LacznyError in idba_hybrid_assembly_2Dear all,
there seems to be an error in
https://git-r3lab.uni.lu/IMP/IMP/blob/master/rules/Assembly/hybrid/idba.hybrid.rules#L63
It seems that this would translate to:
`input[2]` translate to `'Assembly/mgmt.se.idba_hybrid.mt.unmapped...Dear all,
there seems to be an error in
https://git-r3lab.uni.lu/IMP/IMP/blob/master/rules/Assembly/hybrid/idba.hybrid.rules#L63
It seems that this would translate to:
`input[2]` translate to `'Assembly/mgmt.se.idba_hybrid.mt.unmapped.fq',`and `input[3]` to `'Assembly/mgmt.r1.idba_hybrid.mg.unmapped.fq',`
Put differently, this looks to me like it would merge M*G*-SE and M*T*-R1…
Best,
Cedrichttps://git-r3lab.uni.lu/IMP/IMP/-/issues/140Why are Fasta index and BAM index not created by distinct rules, but in the v...2018-10-01T15:52:58+02:00Cedric LacznyWhy are Fasta index and BAM index not created by distinct rules, but in the variant_calling rule?The following seems to be suboptimal to me:
https://git-r3lab.uni.lu/IMP/IMP/blob/master/rules/Analysis/variant.rule#L11
https://git-r3lab.uni.lu/IMP/IMP/blob/master/rules/Analysis/variant.rule#L18
Shouldn't the respective files be part...The following seems to be suboptimal to me:
https://git-r3lab.uni.lu/IMP/IMP/blob/master/rules/Analysis/variant.rule#L11
https://git-r3lab.uni.lu/IMP/IMP/blob/master/rules/Analysis/variant.rule#L18
Shouldn't the respective files be part of the `input:` **and** have a respective rule, rather than being created within the `variant_calling` rule, if they do not originally exist?
`{input[1]}.bai` is probably less of an issue as it is *independent* for metaG and metaT, but since `{input[0]}.fai` is the merged assembly of both types (`mg` and `mt`), it needs to be created only *once*.
Could it be that executing this rule for `mg` and `mt` *in parallel* could create issues/overwritings/collisions here?
Best,
Cedric