Why are these migration posterior distributions are ragged?

[Burak Karaceylan]

Hello,

I'm using Migrate 4.2.14 on CIPRES for longer runs. I can't seem to figure out why are my migration distirbutions so ragged? I have tried tweaking multiple settings bu failed so far. Shorter preliminary runs with version 4.4.4 on my PC didn't have this problem. Can anyone help me, please?

[Burak Karaceylan]

Sorry I seem to have failed to upload the outfile.pdf with the parmfile. Here it is.

19 Mart 2020 Perşembe 13:21:24 UTC+3 tarihinde Burak Karaceylan yazdı:

[Peter Beerli]

Burak,

it seem that you need to increase the upper limit for the migration parameter, change to 10000

(remember that M is m/mu). The curves look otherwise good, the flat  curves for migration suggest that there is not much infromation in the data 

you could run a model that sets the migration rate all to the same; a model that is custom-migration={ xmmmmxmmmmxmmmmx}

and compare the maximum likelihoods, but first I suggest to change the upper limit 

Peter

 

--
You received this message because you are subscribed to the Google Groups "migrate-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to migrate-suppo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/migrate-support/abc27631-1c35-4634-acd5-285412e0f977%40googlegroups.com.
<outfile.pdf>

[Burak Karaceylan]

Thanks for quick response Mr. Beerli!

I ran another one with your suggestions and I also changed the prior distribution to exponential (which seems to help). Next step I will do comparisons with custom migration models.

A question though. I reduced the migration limit because most of the parameters are peaking around zero (this was suggested in some tutorial). Here you can see most of the distributions are positive skewed but some are negative skewed.

I've seen some rough guides on this on the web but, what should be the decision to increase or decrease the boundaries be really based on?

19 Mart 2020 Perşembe 15:07:52 UTC+3 tarihinde Peter yazdı:

Burak,

it seem that you need to increase the upper limit for the migration parameter, change to 10000

(remember that M is m/mu). The curves look otherwise good, the flat  curves for migration suggest that there is not much infromation in the data 

you could run a model that sets the migration rate all to the same; a model that is custom-migration={ xmmmmxmmmmxmmmmx}

and compare the maximum likelihoods, but first I suggest to change the upper limit 

Peter

 

On Mar 19, 2020, at 6:39 AM, Burak Karaceylan <bkara...@gmail.com> wrote:

Sorry I seem to have failed to upload the outfile.pdf with the parmfile. Here it is.

19 Mart 2020 Perşembe 13:21:24 UTC+3 tarihinde Burak Karaceylan yazdı:

Hello,

I'm using Migrate 4.2.14 on CIPRES for longer runs. I can't seem to figure out why are my migration distirbutions so ragged? I have tried tweaking multiple settings bu failed so far. Shorter preliminary runs with version 4.4.4 on my PC didn't have this problem. Can anyone help me, please?

--
You received this message because you are subscribed to the Google Groups "migrate-support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to migrate...@googlegroups.com.

[Peter Beerli]

I ran another one with your suggestions and I also changed the prior distribution to exponential (which seems to help). Next step I will do comparisons with custom migration models.

you will some models with fewer parameters will have much higher marginal likelihoods than your general n-island model

A question though. I reduced the migration limit because most of the parameters are peaking around zero (this was suggested in some tutorial). Here you can see most of the distributions are positive skewed but some are negative skewed.

Your earlier plots had most migration rates showing flat distributions suggesting little power; if your _all_ your migration distributions are near zero and do not extend far to the right (not like yours) then one could think about shrinking the prior range. 

You may want to look at:

Beerli, P., Mashayekhi, S., Sadeghi, M., Khodaei, M., & Shaw, K. (2019). Population genetic inference with MIGRATE. Current Protocols in Bioinformatics, e87. doi: 10.1002/cpbi.87

Beerli, P. (2009). How to use MIGRATE or why are Markov chain Monte Carlo programs difficult to use? In Bertorelle, Giorgio, Bruford, M W, Hauffe, Heidi C, Rizzoli, A, & Vernesi, C (Eds.), Population Genetics for Animal Conservation (pp. 42-79). Cambridge University Press, Cambridge UK.

[see attached files] 

I've seen some rough guides on this on the web but, what should be the decision to increase or decrease the boundaries be really based on?

Could you cite these ‘rough’ guides, if they are not mine then I would want to know about them.

Otherwise, I think that your outputs look fine now

Peter

[Burak Karaceylan]

Thank you sir! This has been very helpful.

Those guides I mentioned are mostly online answers in places like researchgate that I stumbled upon while googling my specific questions, not complete tutorials like found on your website.

[Burak Karaceylan]

 Hello again sir!

I've been comparing different models for my populations. My populations are more or less equidistant from each other on the same latitude. So, I was expecting a stepping stone model would be more probable. But n-island model seems to be selected over other models. However the thing is, only one migration parameters in n-island model is around 2000, the rest are below 10 (mode). Howcome a full-migration model that estimates near 0 values for nearly all migration parameters is chosen over the stepping stone model? I don't know how can I interpret this results.

Model                                          Log(mL)   LBF     Model-probability
---------------------------------------------------------------
1:stepping_stone_symmetric :    -1634.78    -4.59        0.0087
2:single_migration_rate         :    -1633.28    -3.09        0.0388
3:west_to_east_mig               :   -1632.33    -2.14        0.1003
4:full_migration                      :    -1630.19     0.00        0.8523

[Peter Beerli]

Burak,

I would be interesting to know the population models of your other cases (single and west to east)

In general your model do not really deliver that different outcomes, it is true that I would think that a model with <1% probability could be 

discounted, but the other ones you should not.

I assume that your ’ss’ model forces symmetry in places where the data does not, that is the reason why your full model wins over it because it allows to have that freedom, perhaps 3->1 and 1->3 give an indication of that. 

I would assume that a model that is similar to your ’ss’ model but instead of ’s’ uses ‘*’ will win; because your ss models forces 0 in several places whereas the full model does not. 

Are these model just random guesses? or do you have particular hypotheses to test, there are many choices in different models.

-show us the result of all models

-run an additional model as asked above.

Peter

 

--
You received this message because you are subscribed to the Google Groups "migrate-support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to migrate-suppo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/migrate-support/3b46247b-31cd-4ba1-b8d9-1174573e16ec%40googlegroups.com.
<outfile_ss.pdf><outfile_full.pdf>

[Burak Karaceylan]

Dear Peter,

I've noticed that ttratio is the rate ratio (kappa), so I had to rerun all of the models after setting the right value.

I've tried 5 different models. Two of them are full migration models. In one of the full migration models all the parameters are free, in the other one there is a single average value for all migration routes. I also tried two stepping stone models. One of them forces symmetric migration rates, the other one doesn't. Lastly a recurrent migration model starting from the westmost population towards the eastmost population.

I've tried west to east and stepping stone models taking into consideration the evolutionary history and the current distribution of the species. Full migration model was also tested as we suspect some anthropogenic factors may be affecting the distribution. There is a disagreement in the results between asymmetric stepping stone and full migration model. Does this mean the data isn't strong enough?

Model                                Log(mL)   LBF     Model-probability
---------------------------------------------------------------

1:outfile.west_to_east:             -1655.20    -5.06        0.0048
2:outfile.stepping_stone_symmetric: -1654.82    -4.68        0.0070
3:outfile.stepping_stone_asymmetric:-1652.19    -2.05        0.0974
4:outfile.fullmigration_singlerate: -1651.87    -1.73        0.1341
5:outfile.fullmigration:            -1650.14     0.00        0.7566

7 Nisan 2020 Salı 15:00:34 UTC+3 tarihinde Peter yazdı:

To unsubscribe from this group and stop receiving emails from it, send an email to migrate...@googlegroups.com.

[Peter Beerli]

Burak,

I do not think that a slight mispecification of the ttratio is relevant at all, for msats it will make a differences if you use different rates (site rate variation)

It seems that your data is happy with a single migration rate for all migration directions (your single migration parameter model looks good), this suggests that most likely you do not have enough power to make clear statements what is going on beyond that there is immigration among your populations. what happens if combine some or your populations or run subsets of populations? A single locus is certainly not very powerfull, that said the figures for the singlemigrationparameter looks nice.

Peter

To unsubscribe from this group and stop receiving emails from it, send an email to migrate-suppo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/migrate-support/81ecafbd-1acd-4856-9a1e-23057708e497%40googlegroups.com.
<full_migration.pdf><west_to_east.pdf><stepping_stone_symmetric.pdf><stepping_stone_asymmetric.pdf><singlerate.pdf>

[Burak Karaceylan]

Dear Peter,

Thank you for all your help! The fact that there is migration between all populations and an average approximation to a global migration rate as in single migration model is good enough for me. That being said, I can certainly try running subset of populations based on geographical locations. However, I'd like to ask a question: since we know that there is migration between all populations, is it a valid approach in this case to estimate migration rates between all population pairs seperately?

16 Nisan 2020 Perşembe 23:14:49 UTC+3 tarihinde Peter yazdı:

Burak,

[Peter Beerli]

Burak,

first there was a typo in my message: I said: 

 for msats it will make a differences if you use different rates (site rate variation)

of course I meant to say

 for MTDNA it will make a differences if you use different rates (site rate variation)

the problem with looking at pairs and thus ignoring the others is that there are effects: look at the ghost population paper* I wrote long time ago,

but that said many researchers have done pairwise analysis to look at directionality and have found convincing results.

Peter

* https://peterbeerli.com/papers/pdfs/beerli_2004.pdf

To unsubscribe from this group and stop receiving emails from it, send an email to migrate-suppo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/migrate-support/adff87aa-c0d9-4c58-9ebd-460cbc410e78%40googlegroups.com.

[Burak Karaceylan]

Hello,

Sorry for bumping this topic up but I just want to make sure I'm not making any errors with the analysis. I have decided to discuss the full-migration model with an average global M value. I have two questions that I'd be very happy if you could help me with: (1) Does it make sense to multiply this average M with the ϴ of a population to calculate an average immigration rate for that population? If so, does this value represent an average immigration rate to that population from all populations together or from each population separately (2) ϴ for an example population is estimated as 0,0016 and the substitution rate for the gene is 0.0051 substitutions per site/My per lineage and since there is only one generation per year the value to use for the mutation rate is 51 x 10^-10. So,  calculation of Ne from ϴ=xNeμ (x=1 for mtDNA) yields around 313.725. Does this look about right?

Thank you for your time,

18 Nisan 2020 Cumartesi 21:01:23 UTC+3 tarihinde Peter yazdı:

To view this discussion on the web visit https://groups.google.com/d/msgid/migrate-support/adff87aa-c0d9-4c58-9ebd-460cbc410e78%40googlegroups.com.

[Peter Beerli]

On Aug 6, 2020, at 7:10 PM, Burak Karaceylan <bkara...@gmail.com> wrote:

(1) Does it make sense to multiply this average M with the ϴ of a population to calculate an average immigration rate for that population? If so, does this value represent an average immigration rate to that population from all populations together or from each population separately

if the migration rates are rather similar among all populations than this will be OK, otherwise ???? 

It is from each population separately, for example you have 3 population and estimate xmmmxmmmx then you would have M_2->1 and M_3->1 with the same value but if you think of calculating the overall immigration number into population 1 then it would be N(1) * ( M_2->1 + M_3->1) 

(2) ϴ for an example population is estimated as 0,0016 and the substitution rate for the gene is 0.0051 substitutions per site/My per lineage and since there is only one generation per year the value to use for the mutation rate is 51 x 10^-10. So,  calculation of Ne from ϴ=xNeμ (x=1 for mtDNA) yields around 313.725. Does this look about right?

Theta = Ne*mu =  0.0016  ===>  Ne = 0.0016 /(0.0051*10**-6)=313725; not sure whether your . is a spacer or not in the US people use commas to separate: 313,725

Peter

To unsubscribe from this group and stop receiving emails from it, send an email to migrate-suppo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/migrate-support/c633ca6f-a3c2-4124-b3ff-b199766d0b8do%40googlegroups.com.

[Burak Karaceylan]

The decimal point is the thousand separator indeed! Sorry for failing to mention that. 

Thank you very much for answering my questions,

7 Ağustos 2020 Cuma 02:33:37 UTC+3 tarihinde Peter yazdı:

To view this discussion on the web visit https://groups.google.com/d/msgid/migrate-support/c633ca6f-a3c2-4124-b3ff-b199766d0b8do%40googlegroups.com.