search

delt0r / msms

A coalsecent simulator with selection
www.mabs.at/ewing/msms
18 stars 7 forks source link

Forward simulation frequency trace seems to be wrong in models where -ej is used #5

Closed ChristianHuber closed 11 years ago

ChristianHuber commented 12 years ago

I'm simulating a simple model where a population is split into two populations forward in time. The problems are related to a selective sweep that starts in population 1 some time before the split:

(all forward in time)

1) If the mutation has fixed in the population before the split, it is not automatically fixed in the second population after the population has split into two populations forward in time. The second population seems to start with zero frequency of the selected allele.

2) If the mutation has not yet fixed in the first population at split time, suddenly (in a single step) the mutation is fixed in the first population after the population split.

The actual model is:

msms -ms 100 1 -t 4 -r 4 1000 -I 2 50 50 0 -ej 1 2 1 -N 1000 -SI 2 2 0 0 -Smu 0.5 -Sc 0 1 5000 -Sp 0.5 -oTrace

I would think that one naturally assumes that the selected allele has the same frequency in both populations immediately after the split. I can provide a R script that runs the model and plots the frequencies in both populations.

ChristianHuber commented 12 years ago

The first problem is fixed now, but the second one not. If the mutation does not reach 100% in the first population before the split (forward in time), it immediately is fixed after the split. This seems to be very wrong.

delt0r commented 12 years ago

Once its fixed .... the simulation switches off selection. So i am not sure it quite behaving wrong... but rather just another dam issue with -Smark. Note that the -oTrace option is not valid after an absorbing state.

On Mon, Dec 3, 2012 at 7:29 PM, Christian Huber notifications@github.comwrote:

The first problem is fixed now, but the second one not. If the mutation does not reach 100% in the first population before the split (forward in time), it immediately is fixed after the split. This seems to be very wrong.

— Reply to this email directly or view it on GitHubhttps://github.com/delt0r/msms/issues/5#issuecomment-10964996.

I have no special talents. I am only passionately curious. --Albert Einstein

ChristianHuber commented 12 years ago

Now I see what got me confused... it seems like selection is turned on only after the population split, although it should be turned on all the time.

See f.e. this command:

msms -ms 100 1 -t 4 -r 4 1000 -I 2 50 50 0 -ej 0.1 2 1 -N 1000 -SFC -SI 0.2 2 0.001 0 -Sc 0 1 500 -Sp 0.5 -oTrace

A single mutation is introduced in population 1 at time 0.2 and is selected in that population. At time 0.1 there is a population split (a joining event backwards in time). However, in all simulation runs, the introduced mutation drifts neutrally before the split and is only selected and fixes after the split, although it should be selected all the time.

The same behavior with -Smu btw.

ChristianHuber commented 11 years ago

Note that this bug is not yet resolved. The first point is fixed, but not the second one. See also my previous comment: selection is not turned on in population 1 before the population split, although it should be turned on all the time.

delt0r commented 11 years ago

There is a workaround. Use a second -Sc option at the time split. In fact you will probably need one for every split/join i think.