Hello, I have a new question. My experiment is an incubation with different treatments, and we have one larger metagenomic samples that we took from the initial community, and then from the end of the experiment: another genomic sample and 11 metatranscriptomics samples. I run the pipeline successfully with the 11 transcriptomic samples but I was wondering if I can add both genomic samples also to have a better and larger assembly. thanks!

Hello 👋🏼 that's a good question. My first answer is: yes, you CAN. but I am not sure about the implication of this action. MEGAHIT doesn't require any specification when it comes to assembly meta-omics data while SPAdes actually uses metaSPAdes flavour specifically for metaT, so there might be differences at algorithm level. I think you have 2 options to test: • use all samples together for creating the assembly • make 2 assembly separately and then combining them later and use them for the downstream modules (you can give an assembly to metatdenovo and it will avoid running the de novo assembly step) @Daniel Lundin did you ever try this combination?

As always, what you should do depends on what you want to use the data for. You can certainly do one big assembly. The advantage of this is that you would get one set of contigs and ORFs, which makes it possible to relate expression levels of genes (metaT) to their abundances (metaG). An interesting type of question you can address with that is if there are differences between genes in the ratio between metaT and metaG for the same sample that could indicate differential expression rather than just differential growth. (I'd try Megahit since that's the least resource hungry, and you wouldn't have to think about which flavour of the program.) The drawback of a big assembly is that it's big, and might be difficult to get through on the computational resources you have. We have an option to reduce sequencing depth using the

--bbnorm

parameter (see the docs) that might be useful for that. If you still can't do one assembly, you can either do several assemblies or do e.g. the metaT and then map metaG to that. (Not supported directly by the pipeline.) Or you can do several assemblies and then first cluster contigs or ORFs and then map all samples if you want to be able to compare expression and abundance levels of genes. (Neither this is supported by the pipeline.) A third option is to reconstruct MAGs from the metaG (e.g. with #CE9MS66BS) and then map your metaT to them (e.g. with #C01U1E95JQ5, under development). MAGs, and genomes in general, have the advantage of allowing analysis of co-transcription within genomes in a direct way, plus all genes will be uniformly annotated with taxonomy.

Great! So its possible to add both types of information together. I dont think the computational power will be an issue so I think ill try to do one big assembly. Thank you both!! I only have two metaG samples, so I think I might try to do MAGs but I dont know if Ill get too much information out of them.

Two samples is probably too little for MAGs. About the possibility of mixing metaT and metaG: I've never tried this, nor can I remember any published studies doing this. For the pipeline itself it won't pose a problem -- besides the amount of data -- but if assembly programs do this well or not (and which is best) is a bit uncharted territory. I would not worry so much, but look carefully at what proportions of reads from the different sample types map back to the assembly (contigs). Now, expect some differences, but more than, say, two-fold would make me do more investigation.

I want to try this because initially i was going to map the metaT reads directly to the metaG contigs but the mappings were very low, as low as 37%, so Im looking for alternatives to improve the mapping rates. Using the metaT assembly the mappings already improve but the lowest is still less than 60% which I think it's too low. Is it normal to get between 55 and 80% mapping rates with your pipeline?

Quite normal numbers, I'd say. We haven't done a lot of testing, but the complexity of the samples will of course influence this. The more the communities differ between samples, the more differential expression you see, the trickier it will be to assemble and mapping back rates will fall. In theory, depth normalization (

--bbnorm

) could help with this by lowering read depth for the most abundant sequences so that the less abundant become visible to the assembly program. Another possibility, though not supported by the pipeline, would be to make a second assembly based on reads that do not map back to the first. I've done this manually but couldn't map more than a few percent extra.

I havent added the

--bbnorm

because there are two samples that have like 80% rRNA so a massive part of the information in the other 9 samples would be remove to account for this... and i tried to assemble the unmapped reads and the assemblies were too short to be of any help.

My general advice is to use

--bbnorm

only when one has difficulties to get the assembly through. I would be interested in how it works on your setup though. Note, also, that normalization is done on the whole pool of reads, so having a few samples that are a bit underrepresented shouldn't hurt.

Do you mean in the initial set up with only metaT samples or the one that Im trying to run now with both? Why do you think it would be interesting?

The second. Interesting since it would test if normalization could actually help. My guess is that it wouldn't except if you have too much data, so don't spend time on this if you don't need to.