search

gphocs-dev / G-PhoCS

G-PhoCS is a software package for inferring ancestral population sizes, population divergence times, and migration rates from individual genome sequences.
33 stars 4 forks source link

Found a bug in vision 1.3 runing with multithreads #25

Open shengwang opened 7 years ago

shengwang commented 7 years ago

When i ran a sampler under the tree (((B, C), A),Root) with a gene flow from C to A, there was a error: "Fatal Error 0025. Segmentation fault (core dumped)"

As longas A is the target species, the sampler run into the error. And B or C as the target is OK for running.

gphocs-dev commented 7 years ago

This is an odd one, which I haven't encountered before. I don't think that it has anything to do with the multithread version. If problem persists, then please send us your data files (to:ilan.gronau@idc.ac.il) and we'll see what's causing this.

pedrotaucce commented 7 years ago

Same thing to me. But I don't know the pattern. I've been running many G-PhoCS analysis and some of them work and some don't. Sometimes different migration bands from the same input file and same pops work and some don't, and sometimes replicas changing only the name of the control file and the name of the mcmc-trace.out work and others don't. I ran in a cluster, in my laptop and two servers, all of them experienced error in some analyses.

gphocs-dev commented 7 years ago

Again, we'd be happy to assist if you share your data files with us. Send files to ilan.gronau@idc.ac.il

ChristophePatterson commented 1 year ago

Hi there, I'm also receiving this same error. Using tree (((B, C), A),Root), any migration from A to B or A to C results in "Fatal Error 0025." with the number of "Fatal Error 0025." errors printed relating to the number of threads.

I can model migration from C to the ancestral population of B and C. And migration between B and C.

Is ilan.gronau@idc.ac.il still the best contact for this?

Many thanks,

Christophe

igronau commented 1 year ago

I haven't maintained the software in a while. My guess it that this is caused because the sampler starts to sample too many migration events. I assume that you meant " migration from A to the ancestral population of B and C" (and not from C). My suggestion is to see what happens when you turn off one of the migration bands.

ChristophePatterson commented 1 year ago

Hi, thanks for the response.

Yes, you are correct the text should have been"I can model migration from A to the ancestral population of B and C. And migration between B and C."

I have changed the configuration file as suggested. The error only occurs when trying to model migration from B or C toward A (Source B/C, target A). Migration from A towards B or C is fine. The error message still occurs when no other migration bands are implemented

As this software has not been maintained for a while would you suggest endouvering or switching to an alternative?

Cheers,

Christophe

igronau commented 1 year ago

Are you getting this error when you model a single migration band from B (or C) to A? This sounds odd. I can understand why this would happen with a migration band from two sister populations, or with two migration bands (e.g., one from B to A and one from A to the ancestral pop of B,C). What I typically suggest is to run one analysis without any migration bands, and then several analyses with one migration band per analysis. This typically provides a lot of useful information on the influence of migration on estimates of divergence times and pop sizes. Then, you can try to complicate the analysis by modeling multiple migration bands together. However, these models can "break" if there was a lot of ancestral gene flow. Other demography inference methods might not break, but it doesn't mean that they will produce reliable results.

ChristophePatterson commented 1 year ago

Yes, the error occurs even when there is only a single migration band between B (or C) and A. No other migration bands are present.

I have run a model without any migration bands. My current aim is to implement different combinations of migration bands to determine whether or not this influences divergence dates. A model with migration between B <--> C, and A <--> ancBC does shift back the divergence between B and C. I will now attempt several analyses with one migration band per analysis. However one of the migration bands that I would like to test is B or C towards A.

igronau commented 1 year ago

I see. This is interesting, since models with a single migration band between populations who don't share a direct parent in the tree typically don't cause problems. Can you examine the traces of parameter values produced before the program crashes. This might provide some insight into what's causing the problem. If migration rate is extremely high or some Ne is extremely low, this could cause issues.

ChristophePatterson commented 1 year ago

Thanks! I have successfully run all the models with a single migration band. All have run to completion, except the ones that have B -> A and C -> A. It is inconsistent whether or not the runs fail before or after printing sample 0 to the trace file - even which the same config file. When sample 0 is printed the migration rate between B/C -> A is 0.0000. I have had one instance where a run did progress beyond this point. The run that progressed beyond this (to around sample 3000 - which was then cancelled due to the short time constraints I placed on the script's run time) also continued printing 0.0000.

The other theta or tau values for sample 0 do not seem partially large or small in comparison to the other completed runs. theta is 4.5 to 5.3, tau is 3 to 7. (tau and theta print = 1000).

Of note is that migration bands for sample 0 for the runs that have complete (those with different mig bands that B/C -> A is also 0.0000 (mig-print = 0.0001) but then after sample 0 the migration rate converges on 0.001-0.002. (mig-print = 0.0001)

Is it possible that instead of the migration rate between extremely high causing the crash, the estimated migration values are extremely low and causing the crash?

Thanks again!