I have Arlequin output files (*.arp) from fastSimcoal2 that I'm trying to convert to genepop files (to read into adegenet). The Arlequin files are using the "DNA" marker (50 bp long), and each includes ~2,500 samples.

When trying to use the program PGDspider to convert these (either the GUI or the CLI; v2.1.1.5), things proceed smoothly until the 1,000th allele is reached, where the program generates an error:

INFO  07-03 11:18:10,630 (GenepopWriter.java:parseAlignedSampleData:596)  -Allele "TGGCATCAGCTTCTTCTAAGCAGGCCCGCTTTGTCTAGCGACAGATCTCG" converted to "999"
INFO  07-03 11:18:10,630 (GenepopWriter.java:parseAlignedSampleData:596)  -Allele "ATCTTGTGGTCATGGAGCACCCAGAGCCAAACTCCTAAAGAAGACCCCGC" converted to "1000"
ERROR 07-03 11:18:10,630 (GenepopWriter.java:parseAlignedSampleData:611)  -data "1000" in ind "2_375" (population: Sample 2) is too long!!!
INFO  07-03 11:18:10,631 (GenepopWriter.java:parseAlignedSampleData:618)  -In GENEPOP, alleles cannot be coded with more than 3 digits.

Is there a way around this error? I've processed RADseq data with many 1,000s of alleles using adegenet before, so I know these types of files can be written into genpop--I just don't know how to specify this to PGDspider. There's a field in the .spid file that I might be able to use to fix this (see below), but I don't know what to populate that field with, and there aren't any suggestions from the (limited) documentation.

# Specify the locus/locus combination you want to write to the GENEPOP file:

Alternatively, if there are suggestions for running this conversion without using PGDspider, I'm all ears.

Thanks for your help!

  • $\begingroup$ Spooky bug, it looks like a simple bug in the code. However, the author my have been concerned with RAM capacity and hence the ceiling but a more explicit error code should be generated. You can split the data set into two (more?) lots of 1 to 999 and pipe these through PGDspider. You could write a new PGDspider or ask the author for a fix. However 1000 inputs isn't much data. $\endgroup$
    – M__
    Commented Mar 9, 2022 at 19:06
  • $\begingroup$ Given this is just above the threshold I would simply break the file into 3? parts. $\endgroup$
    – M__
    Commented Mar 9, 2022 at 19:08
  • $\begingroup$ I'm hesitant to break the files apart, only because the error is a result of PGDspider not separating alleles by sample. During the conversion PGDspider writes the alleles as 3 digit numbers, but it isn't restarting the numbering for new individuals in the Arelquin file. Hence, allele 625 in individual 1 is 625, and allele 1 in individual 2 is 626. I don't know how to fix that behavior, though... $\endgroup$
    – akoontz11
    Commented Mar 9, 2022 at 20:03
  • $\begingroup$ Right okay its a bug, you would have to go into the code. If it was counting in a higher base that could circumvent the issue. You could write an external database which collected (appended) the output before the clock resets and that's probably the easiest way to do it. $\endgroup$
    – M__
    Commented Mar 9, 2022 at 21:13

1 Answer 1


Ultimately, I achieved this using the R package strataG. The steps taken (in R) are shown below.

arp.object <- arlequinRead(arp.path)
gtype.object <- arp2gtypes(arp.object)
genind.object <- gtypes2genind(gtype.object)

I found that fastSimcoal2 shows an odd behavior when simulating DNA markers, in which sequences are concatenated together (regardless of marker blocks specified; relevant post here). Running the fastSimcoal2 simulations from strataG addressed this bug (and is more straightforward/reproducible, anyways).


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.