search

mufernando / graft

0 stars 0 forks source link

graft migration table #10

Closed mufernando closed 4 years ago

mufernando commented 4 years ago

We are assuming that ts1 and ts2 are independent after the split (so no migration between those pops after the split), but we could have two or more pops in ts2 that exchange immigrants.

In that case, to graft the migration table we would only have to remap the node and population ids in migration entries in ts2 after the split, and add them onto ts1 tables.

also need to write a test for this.

mufernando commented 4 years ago

well, given SLiM and msprime do not use the MigrationTable, it should just go in the docs that the graft function does not update Migration Table. I'm just gonna clear it out. sounds reasonable @petrelharp ?

petrelharp commented 4 years ago

We should remap it: msprime does use the migration table. But, go ahead and leave this for later if you want.

mufernando commented 4 years ago

ok, I was trying to get an example with migration in msprime and never got anything written to the Migration Table. is there a special case in which msprime uses it?

petrelharp commented 4 years ago

Well, this has migrations:

start_time=10
ts = msprime.simulate(
    population_configurations=[
        msprime.PopulationConfiguration(2),
        msprime.PopulationConfiguration(0),
    ],
    demographic_events=[
        msprime.MassMigration(time=start_time, source=0, dest=1),
    ],
    random_seed=1,
    start_time=start_time,
    record_migrations=True,
)

although my first example didn't - not sure why.

mufernando commented 4 years ago

hah! I didn't even know this record_migrations parameter existed -- I don't think it's documented yet. Thanks!

mufernando commented 4 years ago

It seems simplify does not know how to deal with the MigrationTable:

LibraryError: Migrations not currently supported by simplify

Not sure how I'll be able to test things, given we rely on simplify a lot.

mufernando commented 4 years ago

see: https://github.com/tskit-dev/tskit/issues/20

petrelharp commented 4 years ago

Good point.

mufernando commented 4 years ago

Implemented what I think is the right way to do this, but won't be able to test for now.

82edc5e

petrelharp commented 4 years ago

Looks good. I don't think we need to return a migration map, though, in the same way that we don't return an edge map?

mufernando commented 4 years ago

agreed. e61bfb538f4530adac4829364deb377f25f118b3

I'll close this issue and open a new one just to deal with the testing. See #11

mufernando commented 4 years ago

just noticed we are not doing the right thing when grafting the migration table. I think the requisite for a migration row to be added to the grafted table is that the m.node in new_nodes. right?