This page lists release notes of all official simuPOP releases. If you would like to see what has been changed since the last official release, you can check the ChangeLog of the development version of simuPOP.

1.  Release of simuPOP 0.9.8 -- it is time to upgrade. (Oct, 29, 2009)

I have just released simuPOP 0.9.8. With numerous enhancements in penetrance, quantitative trait and natural selection operators, all simuPOP operators have now been revisited, with full support for virtual subpopulations and complete documentation. Because version 0.9.9 will focus on pedigree and sampling related features, what you see now is pretty much the core for simuPOP 1.0. If you have been using simuPOP 0.8.8 for a relatively large project, you might want to wait for simuPOP 1.0. For all other users, it is highly recommended that you upgrade to this release. I cannot guarantee your script will work without modification under simuPOP 1.0, but this is a good time for you to test the new interface and propose any changes.

The biggest change you will notice is the removal of the stage feature of operators. Instead of specifying a stage for each operator, you now need to explicitly place your operators in parameters initOps, preOps, duringOps, postOps and finalOps of the simulator.evolve function. To convert your script to the new version, you will need to change preOps to initOps, postOps to finalOps, and spread your operators in parameter ops to parameters preOps, duringOps and postOps depending on which stage they are applied to the population.

This dramatic change aims to solve a long standing problem in simuPOP in that it is difficult to see at which stage and in which order operators in parameter ops will be applied during an evolutionary process. The original design gives each operator a default stage and allows you to change it if needed. However, it is not always clear what this default stage should be. For example, if you place a smmMutator before a stat operator using their default stages, the stat operator will not collect statistics for a population after mutation happens. This is because smmMutator is by default a pre-mating operator that applies to the parental generation, and a stat is by default a post-mating operator that applies to the offspring generation. In the new version, you are required to put operators in one or more of parameters preOps, duringOps and postOps so it is clear at which stage and in which order operators are applied.

The new version enhances support for virtual subpopulations (VSP) and overlapping generations. A new virtual splitter productSplitter is introduced that allows you to define VSPs such as male individuals between age 20 and 40. With a new parameter vspMap in combinedSplitter, you can now combine several VSPs into one and define arbitrarily complex VSPs such as, quoting an user request, a mating VSP with males between age 20 and 40 and females between age 15 and 30. Although default names are given to VSPs, you can now give shorter names to VSPs using the names parameter of a splitter. In addition, the cloneGenoTransmitter now copies all information fields from parents to offspring by default. This makes it much easier to use cloneMating in overlapping generations. A new section has been added to the user's guide to describe how to use these features to simulate age structured populations and overlapping generations.

All penetrance, quantitative trait and selection operators have been revisited. The changes are too numerous to list here so please refer to the simuPOP documentation for details. The most interesting change is that simuPOP now allows natural selection through the selection of offspring, using absolute fitness values returned by a selector during the production of offspring. Although this is a slower way of doing natural selection in the standard random mating scheme, it can make a difference when you are using non-random mating or when you need to explicitly simulate the survival of offspring.

The use of demographic function has also been changed. Instead of passing subpopulation sizes to a demographic function such as demo_func(gen, oldSize), the whole parental population is passed so you need to define you function as demo_func(gen, pop). There are two reasons for this change. First, when there are virtual subpopulations, oldSize might not be enough to determine subpopulation sizes of the offspring generation. Second, the new demographic function allows you to split and merge subpopulations in this function so the burden of demographic changes does not have to spread to a demographic function and operators such as splitSubPops and mergeSubPops.

Among all new features, the new way to access individual information field is most useful. In addition to member functions individual.info and individual.setInfo, you can now access information fields as attributes of individuals so that you can use ind.b = ind.a + 5 instead of the cumbersome ind.setInfo(ind.info('a') + 5, 'b'). I expect this to be used extensively in simulations that involve more than a few information fields.

2.  Release of simuPOP 0.9.7. (Sep, 26, 2009)

simuPOP takes another stride towards its 1.0 release when backward compatibility will be enforced. Before that, you are seeing another incompatible release that will likely break your existing script. Please be patient with me: all the changes are for the better and your suffer is expected to be over in a few months. Although new users are encouraged to use the latest release, existing users are not recommended to upgrade unless you need to use some of the new features described below. Note that the online documentation always reflects the latest release.

The first major change is the reorganization of utility modules. Instead of several separated modules, simuPOP is now organized as a package. Module simuUtil is now simuPOP.utils, and simuRPy is now simuPOP.plotter. The simuOpt module is kept out of simuPOP but the simuOpt.simuOpt class has been renamed to simuOpt.simuParam due to potential name conflicts. A completely rewritten set of classes and functions that simulate trajectories of allele frequencies have been added to simuPOP.utils. The new functions are more flexible and can handle complicated demographic and genetic features such as population split and merge, varying and population-specific selection pressures, and gene gene interaction.

Another big change that will affect many existing scripts is the separation of initSex from operators initByFreq and initByValue. For the sake of convenience, initByFreq and initByValue have always calls initSex by default. This has lead to some errors when multiple initialization operators are used and some of them are sex-dependent. With the introduction of a new operator initInfo that initializes individual information fields, initSex has been separated from these two operators. Consequently, initSex now needs to be explicitly used whenever randomMating is used.

At a more advanced level, the way how during-mating operators are handled has been changed slightly. The concept of '''genotype transmitter''' and related special handling of these operators have been removed. Consequently, all during-mating operators are handled according to a simpler set of rules. The most visible change is that recombinator should now be used in the ops parameter of a mating scheme to replace the default genotype transmitter. The existing usage (use it in simulator.evolve) is allowed, but will lead to reduced performance.

The tagging operators have been revisited in this release. New operators idTagger, summaryTagger and pedigreeTagger have been introduced, and the existing operators such as inheritTagger have been enhanced. The introduction of idTagger allows you to give every individual in an evolving population an unique ID so that you can easily identify ancestors. A function population.indByID has been added to look up an individual by its ID from a multi-generational population. This feature is currently used to dump all recombination events, but will be used in all pedigree-related features (e.g. pedigree ascertainment) later on. Please check the use's guide for details.

Finally, simuPOP now accepts locus-specific allele names. That is to say, the same numeric alleles can corresponds to different alleles at different loci. This feature is introduced so that simuPOP can better handle the HapMap and other genetic datasets that uses the same 0 and 1 coding for different nucleotides at different loci. Adding locus-specific allele names make it easy, for example, to selected a subset of loci from these datasets with losing their allele information.

3.  Release of simuPOP 0.9.6. (Aug, 6, 2009)

The stat operator is the biggest and most complicated operator of simuPOP. There were some long-standing usage problems with this operator but the solutions were far from trivial. Only until last month did I gather some time and energy to rewrite this operator, and I am happy that I did it because with the revision of this operator, I finally see some light of the 1.0 release.

The first problem is with variable alleleFreq[loc][allele] and other counting and frequency variables. Because it is difficult to know in advance which alleles are in the population, alleleFreq[loc][allele] might fail. Although I have forced alleleFreq[loc] to have at least two elements, which solves the problem for diallelic markers, alleleFreq[loc][allele] can be invalid in other modules. To address this problem, I have added a special dictionary type defdict to simuPOP, which is now used for allele, genotype, haplotype and heterozygote counts and frequencies. This dictionary returns 0 for unrecognized keys so alleleFreq[loc][allele] will return 0 if specified allele does not exist in a population. Because only existing alleles are listed, alleleFreq[loc].keys() lists available alleles and you can use len(alleleFreq[loc]) to get number of alleles at locus loc. Because of this, statistic numOfAlleles have been removed.

The second problem is how to control which variables to output and whether or not to calculate statistics for all subpopulations. Parameters blah_param (e.g. LD_param) have been used for each statistic but these parameters were difficult to use. The new stat operator now has a vars parameter that allows you to specify which variables to output, and use special variable names (e.g. alleleFreq_sp) to control whether or not statistics should be calculated for all subpopulations. An additional parameter suffix has been introduced to allow for change of variable names.

The new stat operator now supports parameter subPops so that you can calculate statistics for specified (virtual) subpopulations. This makes it easy to calculate partial statistics such as pairwise Fst. More importantly, the use of virtual subpopulations allows you to calculate, for example, allele frequency among cases and controls, and association tests among only smokers.

Other than these, there has been several new statistics such as sumOfInfo, meanOfInfo, varOfInfo, minOfInfo, maxOfInfo for the calculation of basic statistics of specified information fields, new genotype based genetic association tests (Chi-square and Armitage trend test), and new statistics for population structure (Nei's Gst). Perhaps more importantly, all statistics of the stat operator has now been carefully documented with examples. Please check the relevant sections of the user's guide and reference manual for details.

There have been other interface changes. If your scripts use functions rng(), population.ancestor(), nested lists for parameters lociPos and lociNames of function population, and parameter rep of operators, please check the ChangeLog or updated user's guide because these functions and parameters have been changed.

4.  Release of simuPOP 0.9.5. (Jun, 22, 2009)

I am glad to announce the release of simuPOP 0.9.5. This release is marked by significant improvements in mutation operators. Many new mutators have been added with new features introduced to existing mutators. For example:

  1. Mutators can now be applied to virtual subpopulations (e.g. sex different mutation rates)
  2. A new matrixMutator that mutates alleles according to a mutation rate matrix.
  3. Specialized mutators for diallelic and nucleotide loci (snpMutator and acgtMutator).
  4. New mixedMutator that can apply multiple mutators with certain probabilities.
  5. New contextMutator that can apply different mutators according to the context of mutated allele.
  6. A new map in and map out feature that allows the use of mutation models when interpretation of alleles differs.

The interface of several existing mutators have also been changed. For example, the maxAllele parameter of a kamMutator is changed to k (with a different meaning), and the generalized stepwise mutation model has been merged to smmMutator. Please refer to the updated simuPOP user's guide (http://simupop.sourceforge.net/manual/build/4_userGuide.html#mutation) for details.

There has been a few other style changes. For example, the preOps and ops parameters of simulator::evolve now accept single-form inputs (ignore [] when there is only one operator). In addition, parameter rate of the recombinator has been renamed to rates because this parameter accepts multiple recombination rates. This change is expected to break a lot of scripts. Please change your scripts accordingly.

5.  Release of simuPOP 0.9.4. (May, 20, 2009)

varPlotter in simuRPy.py has always been the most complex Python operator in simuPOP. It has a class hierarchy of five classes that handle different types of figures. A large number of parameters are provided to customize many features of your figures. As a result, this operator has been a nightmare to test and maintain. I could not even document it properly because I was not sure which combination of parameters were supposed to work.

I am glad to report that varPlotter and the whole simuRPy module have been rewritten. Instead of providing a giant class that provides many features, the new simuRPy module provides four operators: varPlotter, scatterPlotter, infoPlotter (with histPlotter and qqPlotter as two special cases) and boxPlotter. These operators are small in size but are very powerful in the sense that you can customize every aspect of your figures using derived keyword parameters.

A derived keyword parameter is a parameter that

  1. Can be prefixed with a R function name to be passed to a specific R function. For example, par_mar=[1,2,2,2] will pass mar=[1,2,2,2] to R function par.
  2. Can be suffixed with an iterator name to pass different values to different replicate, subpopulation, etc. For example, lty_rep=[1, 2, 3] will pass lty=1, lty=2, lty=3 to replicate 1, 2, and 3.
  3. Can accept an expression as its value. For example, plot_main='!"Freq at gen %d" % gen' will pass main="Freq at gen 10" at generation 10.

Utilization of such a mechanism greatly simplifies the implementation of these operators, and on the other hand allows arbitrary parameters to be passed to the underlying R functions. Please visit http://simupop.sourceforge.net/manual/build/5_userGuide.html#simurpy for detailed explanations and a few examples.

Enjoy!

6.  Release of simuPOP 0.9.3. (Apr. 3, 2009)

I have just released the 0.9.3 version of simuPOP. This version fixes a number of bugs, including the memory leak problem with operator infoExec and infoEval. A few minor features are added to this version, most notably the ability to direct your operator output to any Python function. An example has been given in the updated user's guide.

Progress has also been made to the simuPOP documentation. All genotype transmitters are now properly documented. A few more examples are added to the online cookbook, including a function to save simuPOP population in popGene format. This makes Yaji Xu, author of this function, the first simuPOP user who contributes to the online cookbook. Thanks!

7.  Release of simuPOP 0.9.2. (Feb 20, 2009)

As I have announced before, the development of the 0.9.x series will not consider backward compatibility. This is again the case for today's 0.9.2 release. Briefly speaking, the following areas have been revisited, revised, and documented:

Operators:

  • Initializers: initSex, initByFreq, and initByValue. No significant change.
  • Expression and statements: pyOutput, pyEval, pyExec, infoEval, infoExec. Minor interface changes. infoEval can no longer change individual information field.
  • Demographic models:
    • migrator: Change interface, add support for virtual subpopulation, add mode=ByIndInfo
    • pyMigrator: Removed because its functionality can now be achieved by the ByIndInfo mode of a migrator.
    • splitSubPops: Renamed from splitSubPop. Add support for multiple subpopulations and the ability to split by information field.
    • resizeSubPops: Add support for resize by proportions.
  • Miscellaneous operators: Polish and add examples for dumper, savePopulation, setAncestralDepth, ifElse, pause, turnOnDebug, turnOffDebug and ticToc.

Utility module:

  • revise how module simuOpt handles environmental variables and commandline options. The biggest change is the replacement of --noDialig by --gui=False where -gui can take other values. This option also affects other functions that use a GUI.
  • revise simuOpt.setOptions which takes parameters gui and revision. Function requiredRev is removed.
  • rewrite function simuOpt.getParam and make it a class simuOpt.simuOpt. More specifically, if you have
    par = simuOpt.getParam(options)
    if len(par) == 0:
       sys.exit(0)
    
    # unpack parameters
    (help, v1, v2, v3) = par
    
    if help:
        print simuOpt.usage(par, options)
    
    # run simulation
    simulate(v1, v2, v3)
    
You should remove --help from options (-h and --help are now handled automatically) and use
par = simuOpt.simuOpt(options)

if not par.getParam():
   sys.exit(0)

# unpack parameters
v1, v2, v3 = par.asList()
simulate(v1, v2, v3)
# or simply use parameters as attributes of the simuOpt object.
simulate(par.v1, par.v2, par.v3)
# or change your interface to pass the simuOpt object directly, which
# is easier to use if there are a large number of parameters.
simulate(par)

Website:

There are many more small changes. Please refer to user's guide and reference manual for details.

8.  simuPOP 0.9.1 has been released today. (Jan 13, 2009)

The first thing you need to know: this version is incompatible with previous simuPOP versions! Although the overall structure and most features are unchanged, your existing script will most likely not work without modification.

The second thing you need to know: although most dramatic changes have already been made, the following simuPOP versions may not be compatible with this version. Although population, simulator and mating schemes can be considered stable, operators and utility modules will be under revision. The situation will continue until simuPOP 1.0 is released. Backward compatibility will be kept again from that version. Despite of the inconveniences, you may want to take the opportunity to express your concern about simuPOP during this time because changes will be much more difficult to incorporate after simuPOP 1.0 is released.

The conclusion: If you are happy with simuPOP 0.8.8, keep using it. If you are learning simuPOP, or if you are starting a new project, it might be a good idea to jump in this version.

There has been major interface changes and some core changes during the past few months. Many functions and parameters have been renamed, combined, or removed. During this process, I have rewritten the simuPOP reference manual and user's guide. If you are not sure what have been changed, the simuPOP user's guide is now your best source of information. The operator part of this document is not finished yet, but it already has 70+ examples that demonstrate all the features of simuPOP. In addition, the simuPOP reference manual now has accurate information about every functions for population, virtual subpopulations, simulator and mating schemes.

Version 0.9.1 introduces two new features: support for customized chromosome types such as human mitochondrial chromosomes and support for customized genotype transmitters for mating schemes. These are quite advanced features so I will not describe them here. Please refer to relevant sections in the simuPOP user's guide if you are interested.

There are numerous interface changes. Most important ones include:

Population:

  • Rename population::savePopulation to save. Remove parameters compress and format.
  • Support customized chromosome types.
  • Rename arrGenotype to genotype, add setGenotype.
  • setIndInfo and indInfo now support virtual subpopulations.
  • Many other member functions have been adjusted.

Operator:

  • Combine parameter output and outputExpr in operators, the latter is now specified as output='!expr'.
  • Remove parameter grp.
  • Allow parameter rep to accept a list of replicates.
  • Add parameter subPops so that (some) operators can be applied to a list of (virtual) subpopulations.
  • Add initSex() operator, remove pyInit(). Add parameter initSex to operators initByFreq and initByValue.
  • Remove all locus=blah shortcut for loci=[blah], allow parameter loci to take both forms of input.
  • Remove operator pyIndOperator() and some taggers.
  • Move case control sampler and affected sibpair sampler to the Python level. largePedigreeSample and nuclearFamilySample are temporarily unavailable.
  • Remove indRange parameter in initializer and dumper, add subPops as a list of (virtual) subpopulations.

Mating schemes:

  • Combine parameters newSubPopSize, newSubPopFunc to subPopSize, which can accept both types of parameters.
  • Combine numOffspring, mode and numOffspringParam to numOffspring, which now accept a tuple-like input.
  • Combine sexMode and sexParam to sexMode, which now accepts a tuple-like input.
  • Rename pyMating to homoMating.
  • Separate during-mating operators used in mating schemes as genotype transmitters.
  • Allow specification of per-mating scheme during mating operators.
  • Move all pre-defined homogeneous mating schemes to the Python level.

Simulator:

  • Replace parameter 'end' to 'gen' in simulator::evolve.
  • Remove the group feature and the step function.
  • Add simulator::populations().

External modules:

  • Many functions in simuUtil are removed. They will be added later, perhaps in different form.
  • simuOpt is unchanged.
  • new features in simuRPy.
  • hapMapUtil will be removed later.

Bundled scripts:

  • They are not working yet. They will be adapted to the new interface later.

I sincerely apologize for any inconvenience these changes may cause. I will do my best to help you modify your existing scripts if you send your questions to this list.

9.  Release of version 0.8.8 (Oct 25, 2008)

I am pleased to announce the release of simuPOP 0.8.8. This is a maintenance release without the introduction of any new feature. On the contrary, it removes several rarely used features and adjusts the interface of several functions. For example, all arrBlah() functions are now marked obsolete. These functions can be used now, but will be removed when simuPOP 1.0 is released.

Due to the change of interface, current simuPOP users are not encouraged to upgrade.

10.  Release of version 0.8.7 (Aug, 29, 2008)

Dear simuPOP users,

I am glad to announce the release of simuPOP 0.8.7. This release fixes a few bugs found by a simuPOP user, and a long-lasting bug that prevents windows users from saving simuPOP files in gzip compressed format.

The biggest change of this release is the drop of support for binary and XML formats. They were provided for historic reasons but do not stand a place in simuPOP after the windows/gzip bug is fixed. simuPOP files saved in these obsolete formats can still be loaded. Because simuPOP now support only one file format, file extension is no longer important. The recommended extensions are now .pop for populations and .sim for simulators.

Due to the seriousness of a migration related bug, all simuPOP users are recommended to upgrade.

11.  Release of simuPOP 0.8.6 (Jun 20, 2008)

Dear simuPOP users,

After more than two months' intensive work, simuPOP 0.8.6 is finally released today. This release fixes a number of bugs and introduces a few important features so I strongly suggest that all simuPOP users to upgrade.

Six bugs are fixed in this release. They range from minor memory management problems to incorrect interplay between ancestral generation, information fields and migration. An upgrade is recommended because these bugs may lead to incorrect output for complicated simulation scenarios that involve migration and information fields.

A number of new features are added to simuPOP. For example, migrator now supports migration out of virtual subpopulations. An obvious application of this feature is to migrate mostly or only males from a population. Two new operators resizeSubPop amd initSex are introduced. The latter was separated from other initializers such as initFreq and is used when you only need to initialize sex.

The virtual subpopulation interface has been changed a little bit. More specifically, there is now no subpopulation-specific virtual subpopulations. If different virtual subpopulations are desired for different subpopulations, a combined virtual splitter should be used. This change is likely to break your current scripts that use virtual subpopulation but changes to your scripts should be straightforward.

Current development of simuPOP has been focusing on easy handling of pedigrees. Although simuPOP allows the evolution of multi-generation population and provides methods to record and access pedigree information, locating relatives other than direct parents have been difficult. In this release, two functions are provided to locate and trace arbitrary relative information from a multi- generation population. An infoParentsChooser is provided to mate between individuals and individuals whose indexes are specified in some information fields. A new consanguineousMating mating scheme is provided as a shortcut for infoParentsChooser and mendelianOffspringGenerator. Interested users should have a look at a new example doc/cookbook/Mating_consanguineous.py. Note that these features should be considered experimental. The whole interface may change when it stabilizes in the 0.8.7 release cycle.

There are many other small improvements such as the addition of individual::intInfo(), population::ancestor(), and the polish of tk parameter input dialog. Please refer to ChangeLog for details.

Enjoy!

12.  Version 0.8.5 is released (Apr. 3, 2008)

simuPOP 0.8.5 is released today. The previous versions of simuPOP has provided a flexible framework to define arbitrary nonrandom mating schemes. Despite the power of this framework, users have found it unconvenient to construct commonly used nonrandom mating schemes each time from scratch. Therefore, I have added a bunch of nonrandom mating schemes such as homogamy (using homogamousMating), polygyny and polyandry (using polygamousMating), random mating with alpha individuals (using alphaMating), and haplodiploid mating.

The last mating scheme requires native support of haplodiploid populations in the simuPOP core. Starting from this version, you can specify ploidy=Haplodiploid when you create a population. Recombinator acts differently in such a

 population by copying the first copy of paternal 

chromosomes directly to an offspring.

This version also addresses an concern of why simulator::evolve() has to specify ending generation, instead of how many generations to evolve. A new parameter

 gen is introduced, and the use of the old parameter end is 

depreciated (working but with a warning message).

13.  Release of simuPOP 0.8.4 (Mar, 8, 2008)

I am glad to announce the release of simuPOP 0.8.4. This release fixes a few bugs in the new mating schemes introduced in 0.8.2 and 0.8.3, and adds a few new features such as a combined splitter, operators infoEval and infoExec. A few examples of nonrandom mating schemes are added to the doc/cookbook directory. They will be explained in detail in an upcoming simuPOP cookbook.

Users of advanced mating schemes are highly recommended to upgrade.

14.  Release of simuPOP 0.8.3 (Jan 17, 2008)

I am glad to announce the release of simuPOP 0.8.3. This version continues to improve non-random mating by adding pedigree tracing and handling capacities. For example, using parentTagger, one can now save the pedigree of the whole evolution, and replay the pedigree using a new pedigreeMating mating scheme. By creating a pedigree manually, it is easy to implement a gene-dropping algorithm using simuPOP.

Functions in hapMapUtil.py are also updated when I use them for more hapMap-related simulations.

15.  Release of simuPOP 0.8.2 (Nov, 19, 2007)

Every major release of simuPOP introduces a major feature to simuPOP. For the 0.8.x series, simuPOP is making great progresses in the simulation of heterogeneous populations. This is achieved by the introduction of virtual subpopulations, and more flexible mating schemes. Operators are expected to work with virtual subpopulations soon.

A 'virtual subpopulation' refers to any groups of individuals, defined by a 'virtual splitter'. For example, all males, all affected individuals, or all individuals having an information field age with value 5 can form a virtual subpopulation. In contrast to subpopulations, virtual subpopulations are dynamic because individual properties are variable.

By setting virtual splitters to subpopulations, various operations can now be performed on specific virtual subpopulations. For example, it is now easy to calculate LD between affected individuals, or individuals with any other specific property. Future versions of simuPOP would allow heterogeneous mutation, recombination etc on different virtual subpopulations.

In this release, the mating schemes are reorganized to allow heterogeneous mating schemes. Two important concepts: parents chooser and offspring generator are introduced. Different parent choosers and offspring generators can be combined freely to form arbitrary mating schemes. Moreover, different mating schemes can be applied to different subpopulation, even virtual subpopulations. For example, it is now possible to apply selfing to, e.g. 20% of the parents, and random mating to the rest of the parents. Using hybrid parents choosers, it is possible to implement aged population and non-random mating schemes that consider, for example, geographic information.

Hybrid mating schemes tend to be slow because a parents chooser will be called repeatedly. If the algorithm of picking parents is complicated, it is recommended to implement this algorithm in C++. I have included a sample script scripts/demoNonRandomMating.py to demonstrate how to do this.

Please refer to the relevant section of the user's guide and reference manual for details about virtual subpopulations, various virtual splitters, new mating schemes like selfMating, pyMating and heteroMating, and varous parents choosers and offspring generators. Although a lot of testing has been done, and the performance penalty of the new features has been kept minimal, normal users are not recommended to upgrade. I expect the new features to become mature in the 0.8.x release cycle.

16.  Release of simuPOP 0.8.1 (Oct 05, 2007)

I am glad to announce the release of simuPOP 0.8.1. This is a regular maintenance release with a few bug fixes and improvements. The first major new feature is that information fields can now be passed to pyPenetrance and pySelector operators, which allows easy simulations of environmental factors. In addiiton, chromNames parameter is added to the constructoe of population so that chromosome names can be tracked with function chromNames(), chromName() and chromByName() functions.

17.  Release of simuPOP 0.8.0 (Aug 4, 2007)

I am glad to announce the release of simuPOP 0.8.0, the result of more than one year's hard work since the release of simuPOP 0.7.0.

This release contains numerous new features, optimization and bug fixes that greatly improve the use of information fields, binary modules, and the usability of simuPOP. Most importantly, with the help from a graduate research assistant, the online help system and simuPOP reference manual have been overhauled. I strongly encourage all simuPOP users to upgrade.