You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is an incredibly useful package and I've been using it a lot since last year.
Recently, I started designing my primers using the DECIPHER package. It returns several variants of forward and reverse primers which, in combination, amplify all sequences in a certain group. The thing is that these sequences are not necessarily degenerated at fixed positions. Actually they often come out with different lengths.
It would be awesome to be able to check the specificity of the entire pool of primers using primerTree, so my idea here would be to generate and supply my own combinations of forward and reverse primers (maybe with expand.grid() or something like it) instead of letting enumerate_primers() do it. Or even better, adjust the forward and reverse parameters of search_primer_pair() to accept a vector with more than one sequence, and then generate the combinations from that.
All the best,
Thiago
The text was updated successfully, but these errors were encountered:
Hey Thiago, that's an interesting idea. The way to do that might be to write a wrapper function to take in primer combinations, run primerTree and then merge the results, filtering out duplicate hits. One thing to keep in mind is that you can have two forward primers amplifying something as well, so you'd have to run all combinations of all the primers (not just each forward primer with each reverse) to get a comprehensive picture. Let me mull this over a bit and think about how challenging that would be to implement. It may also end up taking a crazy amount of time depending on how many primers you have and how many ambiguous bases there are.
I forked the package and managed to tweak the functions just enough for my immediate needs. It takes character vectors, disambiguates them with DECIPHER::disambiguate() (which takes vectors, but is not a good dependency to have) and then passes these to expand.grid(). It works well to test multiplexed PCR reactions, but I did not consider testing all forward-forward and reverse-reverse combinations, though. Now that you mentioned it, it is quite important in my use case.
Yeah, It could take quite a while in some cases, but I bet it would be quicker than any alternative I know. Maybe test all combinations could be optional, because it will only become important in some cases (too many degenerated bases or vector of forwards (or reverses) with sequences that are completely different from each other).
Hello, everyone!
This is an incredibly useful package and I've been using it a lot since last year.
Recently, I started designing my primers using the DECIPHER package. It returns several variants of forward and reverse primers which, in combination, amplify all sequences in a certain group. The thing is that these sequences are not necessarily degenerated at fixed positions. Actually they often come out with different lengths.
It would be awesome to be able to check the specificity of the entire pool of primers using primerTree, so my idea here would be to generate and supply my own combinations of forward and reverse primers (maybe with
expand.grid()
or something like it) instead of lettingenumerate_primers()
do it. Or even better, adjust theforward
andreverse
parameters ofsearch_primer_pair()
to accept a vector with more than one sequence, and then generate the combinations from that.All the best,
Thiago
The text was updated successfully, but these errors were encountered: