The number of individuals you can pool and loci you can target depends on several things, including the frequency of cut-sites the enzymes you are choosing, and the ratio of cut-sites between the two enzymes, and your size selection, etc. Is there a reference genome available? Or one for a related organism? If so you can simulate the double digest and calculate how many loci are expected in a given size selection range. You can also then calculate what proportion of those loci are sequence-able- fragments flanked on both ends by the same cut site (say, both ends were sheared by MspI in an PstI-MspI digest) will not sequence, yet will appear as more fragments when you look at your size-selected library on a Bioanalyzer or Tapestation. Let me know if you need any help with simulation if you decide to go that route.

Another issue you will encounter is in processing of polyploid data. Most pipelines (Stacks, pyRAD) are designed for diploids (e.g. they assume no more than 2 alleles, and the genotyping models only account for homozygotisty vs heterozygosity of 2 alleles). Depending on how long ago the genome duplication occurred, paralogs may be clustered together (as they have not had sufficient time to diverge), and will fail filtering in the aforementioned pipelines. I believe you can work around this by setting loose heterozygosity thresholds, and not filtering for number of alleles. Additionally, stacks offers a deleveraging algorithm for splitting overmerged clusters... However you would still need to employ a polyploid aware genotyping model (not offered in pyRAD or STACKS). Sorry I can't be of more help in this regard- all of my organisms are diploid.

Polyploidity might be a problem. I would try to get diploid cells from your study object.

Thanks for your nice suggestions, yes we do not have a reference genome. But we are trying to partially sequence one of a related genus genome to our modeled genus. But my concern is normally how many individuals we can pool to have maximum data with the genome sizes as our species have.

The determinant of pooling size is how many loci you are targeting (manipulated by enzyme choice and size selection) and at what average coverage. You can get a preliminary estimate of this using simulation, or by just biting the bullet and running a test set with a realistic size selection and then adjusting for subsequent libraries. There isn't a normal number that will work for all projects. For one of my projects I am targeting ~40,000 loci at a coverage of 30X and am able to pool 96 individuals per HiSeq 2000 lane. For another project we needed less loci to achieve the goals of the study and so we targeted less loci but pooled 144 individuals. 

Without knowledge of the genome or related genome it is difficult to estimate how many fragments will be contained in a given size selection range. If you let me know what the most closely related genome is I would be happy to run the simulations for you (takes a few minutes...) or I can provide scripts. Keep in mind that an incomplete genome (many contigs, gaps) will yield a less reliable estimate. So far in our projects simulation has been somewhat reliable predictor. 

If you know what proportion of loci will be sequence-able (you can estimate this also using simulated digest) than you can estimate the number of targeted loci from the bioanalyzer or tape station trace. 

Thanks Tyler please attach the script for simulation at [email protected]

I will attach it to you in an email... Within the .tar.gz archive you will find:

• fragsim.pl: Perl script to simulate RE fragmentation using any number of restriction sites
• radsim.tsv: Example tab-delimited output of the program- shows number of fragments of each size, and for each "Type" of fragment (e.g. flanked by PstI on both ends, etc)
• radsim.pdf: Example of the graphical outputs

I don't know how well versed you are in working from the command-line, but you will need to have the following installed (possibly incomplete list):

If you have trouble installing any feel free to message me.. I am sorry I do not have a manual written up, as this was not intended for distribution- however you are obviously free to use it. Just please acknowledge me if it ends up being helpful.

To use the program, you will need to execute and provide any command-line input. If you run the program as:

./fragsim.pl -h

You will see the argument options which are currently built in. If you do not, than most likely some dependency is not installed.

You can provide restriction sites as so:

./fragsim.pl -r G^AATTC C^CGG

Where the "^" indicates the cleavage site in a single direction of the sequence. The output will be a tab-delimited table showing the number of fragments for each type at each size, taking the form of:

Length      Missing      R1-R1           R2-R2          R1-R2              Sum

1             0              0                     26                  2                   28

[....]

Where "Missing" indicates fragments which were terminated by contig boundaries, thus were prematurely terminated due to the incompleteness of the assembly. More "Missing site" fragments means a less accurate estimate of the number of loci in a given size range. If you have a contig-level assembly, I recommend you concatenate fragments together at random, and perform replicate concatenations to assess the variation in your estimate.

To calculate the number of loci in a size range (say 250bp to 350bp) you can either use some basic scripting skills, or just load the tsv table into excel.

The "algorithm" is actually pretty simple- if anyone wants details on how to do this simulation let me know and I can elaborate.

If you have any questions or hit any bugs let me know. And anyone else who wishes to use this please feel free to email me, just acknowledge me if you find it helpful.

Thanks a lot Tayler, if I need any further favor I will ask.

@Tayler I want to ask that what's the genome size of your modeled species.

For the simulated digest? I have used the script on genome sizes between 1 to 6 billion bases. Obviously you will need enough memory on your machine to load the entire genome at once as I didn't need to consider any memory issues with my hardware