-
Notifications
You must be signed in to change notification settings - Fork 42
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
improving bulkSize
option in runQTLseqAnalysis()
#5
Comments
Hey Hugo, In regard to your second question, no, it is just the number of diploid individuals. I can make that clearer in the the documentation. This is the way I interpreted Tagaki et al's simulation. Is there a reason that you can think of that it should be on based on haploid copies? Thanks again for your input and possible collaboration. |
Hi Ben, I have to confess I myself don't have extensive experience in collaborating with code. But, my advice here would be to maybe make a release of your current version (instructions here), because this is the published one and is working. You might also want to consider making sure the users install the latest release version with devtools (see here). Then, maybe create a development branch (e.g. called Regarding the second question, I'll open a new issue for more discussion 😄 |
Different bulkSizes have been added to QTLseqr v7.0.0 |
(before moving on to the issue, firstly thanks a lot for developing this very convenient package!)
In
runQTLseqAnalysis()
the optionbulkSize
only uses an integer of length 1. Therefore, if I understood the code rightly, the allele frequency simulation samples frequencies assuming both bulks have the same number of individuals.However, in practice the two bulks might not have the same number of individuals. Perhaps it should be considered that the user could provide either one or two values for
bulkSize
. Then, instead of only generating one vector of "null" allele frequencies (temp_freq
), two vectors could be generated, one for each pool?Something like this might work?:
Also, is it the case that this parameter should be the number of genome copies pooled, which for a diploid it would be 2x number of individuals pooled? If so, the documentation could be a bit more explicit about this, maybe?
I'm glad to fork and implement the suggestion above, but just wanted to check if it makes sense.
The text was updated successfully, but these errors were encountered: