QC for 1855 by silastittes · Pull Request #1858 · popsim-consortium/stdpopsim

silastittes · 2026-07-10T22:11:43Z

Tests fail!

Here's how I built the dictionary within the test. I downloaded the salome2012 genetic map

wget https://stdpopsim.s3-us-west-2.amazonaws.com/genetic_maps/AraTha/salome2012_liftover_maps.tar.gz
tar -xvf  salome2012_liftover_maps.tar.gz

Made a list of the chromosome files and calculated the mean rate for each

maps = ["salome2012_liftover_maps/TAIR10_lifted_chr1.txt",
"salome2012_liftover_maps/TAIR10_lifted_chr2.txt",
"salome2012_liftover_maps/TAIR10_lifted_chr3.txt",
"salome2012_liftover_maps/TAIR10_lifted_chr4.txt",
"salome2012_liftover_maps/TAIR10_lifted_chr5.txt"]

og_maps = {str(i+1): msprime.RateMap.read_hapmap(f).mean_rate for i,f in enumerate(maps)}

Wrong map file? Missing step? Something else?

Do we need an additional test besides the chromosome means?

mergify · 2026-07-10T22:12:30Z

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

Queue this pull request

petrelharp · 2026-07-10T23:02:37Z

Hm. We need to disentangle this with current ongoing changes, seems like. I'll have a look.

petrelharp · 2026-07-11T15:22:48Z

Tests fail!

More specificially: for instance,

E assert (4.3132238886295825e-08 * 0.0152284263959391) == np.float64(2.400225747652611e-09)

where the number on the left is what @silastittes has calculated and on the right is what's in @srgibbon17's PR.

And gee, what you're doing sounds exactly like what I thought @srgibbon17 was doing? @srgibbon17, shouldn't just doing this and multiplying by (1-sigma)/(1+sigma) do the trick?

maps = ["salome2012_liftover_maps/TAIR10_lifted_chr1.txt",
"salome2012_liftover_maps/TAIR10_lifted_chr2.txt",
"salome2012_liftover_maps/TAIR10_lifted_chr3.txt",
"salome2012_liftover_maps/TAIR10_lifted_chr4.txt",
"salome2012_liftover_maps/TAIR10_lifted_chr5.txt"]

og_maps = {str(i+1): msprime.RateMap.read_hapmap(f).mean_rate for i,f in enumerate(maps)}

(BTW, you should put this code in comments in the test file, @silastittes!)

(Also perhaps add a test for the recombination rate at a particular point on some chromosome?)

petrelharp · 2026-07-11T15:23:26Z

Oh, I see: @srgibbon17 has

_selfing_correction = 1 - _sigma / (2 - _sigma)

and @silastittes has

        rate_correction = (1 - selfing_rate)/(1 + selfing_rate)

Which one is right?

srgibbon17 · 2026-07-11T17:18:02Z

I think _selfing_correction = 1 - _sigma / (2 - _sigma) should be correct (and is also implemented here for Oryza sativa).

What @silastittes has with rate_correction = (1 - selfing_rate)/(1 + selfing_rate) is pulled directly from Nordborg, but Nordborg is working with the census population size $N$ directly, while most inferred demographic models work with effective population size $N_e = N/(1+F)$. I originally applied the same correction as @silastittes has here before seeing the example for Oryza sativa! Making that substitution should get back to what I have.

srgibbon17 · 2026-07-11T17:32:20Z

Separate from that, I think the estimated mean recombination rates might be subtly different.

@silastittes built msprime.RateMaps directly from the estimated recombination maps, but I pulled my averages from the stdpopsim GeneticMap which extends the rate map to be 0 if the rate map is shorter than the chromosome length. I am not sure which approach is preferred in this case, but here are a few thoughts/details:

Specifically, I calculated the average rates using

import stdpopsim
species = stdpopsim.get_species("AraTha")

for chrom in species.genome.chromosomes:
    contig = species.get_contig(chrom.id, genetic_map="SalomeAveraged_TAIR10")
    avg_rr = contig.recombination_map.mean_rate
    print(f"Chr. {chrom.id}: {avg_rr}")

One motivation for calculating the mean recombination rates this way is that the chromosome wide rate should match the result from calculating the mean recombination rate from the genetic map. So, for example, this test should pass with how I calculated things (since the same 0 recombination rate extension is applied in both cases)

import stdpopsim, numpy as np

species = stdpopsim.get_species("AraTha")

for chrom in species.genome.chromosomes:
    contig = species.get_contig(chrom.id, genetic_map="SalomeAveraged_TAIR10")
    rate_map_avg = contig.recombination_map.mean_rate
    
    chr_avg = chrom.recombination_rate
    
    assert(np.isclose(rate_map_avg, chr_avg))

silastittes · 2026-07-13T17:29:46Z

That makes sense. We should cite the Caicedo et al. for the AraThal PR too then right?

Thinking about how to do the mean rate calculation for the test, and adding a local rate test now.

petrelharp · 2026-07-13T18:56:32Z

That makes sense. We should cite the Caicedo et al. for the AraThal PR too then right?

No need to cite Caicedo. I read Nordborg et al, and everything we need is pretty clearly explained there. We don't need to cite someone else for telling us how to read Nordborg.

And: can we make sure we're doing this right? (Which means carefully explaining things?) @silastittes it looks like you're using (1-F)/(1+F) from this equation:

right? Whereas @srgibbon17 is using 1 - F from this comment:

and F is defined here:

Also note that Nordborg says that (1-F)/(1+F) = 1-s. So, there's two questions:

which rate adjustment to use: is it the one in "rescaled time units" or not? (this is not a question about rescaling by 2N, it's about the 1+F term or not)
which parameter (s or F) corresponds to our estimate of selfing rate?

Our time units ought to be generations, so I think we ought not to use rescaled units. But I think that @srgibbon17 is pointing out that we're just using an Ne that includes the effect of selfing, so one generation in our sims probably actually corresponds to 1/(1+F) generations - is that your thinking, @srgibbon17? I haven't double-checked how the selfing rate we're using was estimated, to make sure which thing it corresponds to.

petrelharp · 2026-07-13T18:57:37Z

@silastittes can you also provide a rationale for whichever mean rate calculation you think we should use?

silastittes · 2026-07-14T01:09:54Z

So two issues now

figure out the right selfing correction to apply

I haven't thought about this yet, but want to acknowledge we still need to figure that out. Happy to help, but was in the weeds on the second issue ...

reconcile the tests and code

I made a little function to extend the genetic map when the chromosome is longer. When I apply it to the current stdpopsim release it reproduces the mean recombination rates that mean_rate generates:

maps = ["/sietch_colab/stittes/tmp/salome2012_liftover_maps/TAIR10_lifted_chr1.txt",
"/sietch_colab/stittes/tmp/salome2012_liftover_maps/TAIR10_lifted_chr2.txt",
"/sietch_colab/stittes/tmp/salome2012_liftover_maps/TAIR10_lifted_chr3.txt",
"/sietch_colab/stittes/tmp/salome2012_liftover_maps/TAIR10_lifted_chr4.txt",
"/sietch_colab/stittes/tmp/salome2012_liftover_maps/TAIR10_lifted_chr5.txt",]

def rate_map_zero_adjusted(hapmap_file: str, chrom: str, spp: str = "AraTha"):
        map_ex = msprime.RateMap.read_hapmap(hapmap_file)
        species = stdpopsim.get_species(spp)
        chrom_length = species.genome.get_chromosome(chrom).length
        rate = map_ex.rate.copy()

        #extend to end of chromosome and remake map
        if map_ex.right[-1] < chrom_length:
            new_position = np.append(map_ex.position, chrom_length)
            new_rate = np.append(np.nan, rate)
        new_rate_map = msprime.RateMap(position = new_position, rate = new_rate)        
        return new_rate_map

og_maps = {str(i+1): rate_map_zero_adjusted(f, str(i+1)) for i,f in enumerate(maps)}

#Can we recreate the old means?
for chr in ["1", "2", "3", "4", "5"]:
    # with the current release installed, not this PR
    aratha = stdpopsim.get_species("AraTha")
    contig_cat = aratha.get_contig(chr, genetic_map = "SalomeAveraged_TAIR10")
    old_map = contig_cat.recombination_map

    print(np.isclose(old_map.mean_rate, og_maps[chr].mean_rate)) #all true

Is the above code correct, and/or is there an easier way in the context of a test?

I used this function (which I believe works) for the rate values in the test and updated the selfing correction, but our values still differ.

============================================================================ short test summary info =============================================================================
FAILED tests/test_AraTha.py::TestGenome::test_recombination_selfing_correction[3] - AssertionError: assert 1.8481460212041185e-08 == 2.0991601361354922e-09
FAILED tests/test_AraTha.py::TestGenome::test_recombination_selfing_correction[1] - AssertionError: assert 1.7819993539790216e-08 == 2.0449377650848874e-09
FAILED tests/test_AraTha.py::TestGenome::test_recombination_selfing_correction[2] - AssertionError: assert 1.9247415602980858e-08 == 2.223812153186693e-09
FAILED tests/test_AraTha.py::TestGenome::test_recombination_selfing_correction[5] - AssertionError: assert 1.837704068834849e-08 == 2.1089090575158218e-09
FAILED tests/test_AraTha.py::TestGenome::test_recombination_selfing_correction[4] - AssertionError: assert 2.0915452375673585e-08 == 2.4002257476526107e-09
FAILED tests/test_AraTha.py::TestGenome::test_selfing_correction_local - assert np.float64(2.2387625242718484e-09) == 1.950902806431916e-08
========================================================================== 6 failed, 32 passed in 5.38s ==========================================================================

The current values seem to small based on a quick sanity check for chromosome 1
3.5104764967290516e-08 * rate_correction == 1.781967764837082e-08.

Does the correction get applied twice somehow? Am I'm missing something else?

@silastittes can you also provide a rationale for whichever mean rate calculation you think we should use?

If I understand correctly, I agree it makes sense to use the mean rate that stdpopsim generates as @srgibbon17 suggested. If we don't there will be a slight mismatch between the chromosome-wide recombination rate and the value generated when using the mean_rate method.

Added a local rate test as you suggested too @petrelharp.

petrelharp · 2026-07-14T01:30:23Z

I'm sorry, I should have realized this is bumping into #1832 as well.

How different are the mean rates calculated in the two ways?

Also: I'm surprised that adding np.nan to the rate map should change the mean rate. That seems like a bug.

silastittes · 2026-07-14T02:29:52Z

I'm sorry, I should have realized this is bumping into #1832 as well.

How different are the mean rates calculated in the two ways?

The naive msprime means are:

{f"{str(i+1)}": msprime.RateMap.read_hapmap(f).mean_rate for i,f in enumerate(maps)}

{'1': np.float64(3.450876386829853e-08),
 '2': np.float64(3.712478235184855e-08),
 '3': np.float64(3.675733646147423e-08),
 '4': np.float64(4.3132238886295825e-08),
 '5': np.float64(3.533591716785435e-08)}

versus

{'1': np.float64(3.510538727338673e-08),
 '2': np.float64(3.791740873787229e-08),
 '3': np.float64(3.6408476617721134e-08),
 '4': np.float64(4.120344118007697e-08),
 '5': np.float64(3.620277015604653e-08)}

Also: I'm surprised that adding np.nan to the rate map should change the mean rate. That seems like a bug.

I think it works because the the chromosomes all end in 0.0, so adding nan shifts the rates to the next interval. Agree it's a bit hacky.

Here's chromosome 5 from the catalogue versus with the little function ...

left | right | mid | span | rate
-- | -- | -- | -- | --
0 | 27344 | 13672 | 27344 | nan
27344 | 271380 | 149362 | 244036 | 8.7e-08
271380 | 508092 | 389736 | 236712 | 8.3e-08
508092 | 778237 | 643164.5 | 270145 | 7.5e-08
778237 | 1166715 | 972476 | 388478 | 6.4e-08
1166715 | 1384731 | 1275723 | 218016 | 4.4e-08
1384731 | 1603468 | 1494099.5 | 218737 | 3.9e-08
1603468 | 1917138 | 1760303 | 313670 | 3.8e-08
1917138 | 2229414 | 2073276 | 312276 | 3.5e-08
2229414 | 2287469 | 2258441.5 | 58055 | 2.5e-08
⋯ | ⋯ | ⋯ | ⋯ | ⋯
23779396 | 24052883 | 23916139.5 | 273487 | 3.2e-08
24052883 | 24514178 | 24283530.5 | 461295 | 3.2e-08
24514178 | 24739811 | 24626994.5 | 225633 | 3.2e-08
24739811 | 25595063 | 25167437 | 855252 | 3.1e-08
25595063 | 25666426 | 25630744.5 | 71363 | 4.8e-08
25666426 | 25882447 | 25774436.5 | 216021 | 5.1e-08
25882447 | 26022890 | 25952668.5 | 140443 | 5.7e-08
26022890 | 26337325 | 26180107.5 | 314435 | 5.6e-08
26337325 | 26766420 | 26551872.5 | 429095 | 4.2e-08
26766420 | 26975502 | 26870961 | 209082 | 0

...

left | right | mid | span | rate
-- | -- | -- | -- | --
0 | 27344 | 13672 | 27344 | nan
27344 | 271380 | 149362 | 244036 | 8.7e-08
271380 | 508092 | 389736 | 236712 | 8.3e-08
508092 | 778237 | 643164.5 | 270145 | 7.5e-08
778237 | 1166715 | 972476 | 388478 | 6.4e-08
1166715 | 1384731 | 1275723 | 218016 | 4.4e-08
1384731 | 1603468 | 1494099.5 | 218737 | 3.9e-08
1603468 | 1917138 | 1760303 | 313670 | 3.8e-08
1917138 | 2229414 | 2073276 | 312276 | 3.5e-08
2229414 | 2287469 | 2258441.5 | 58055 | 2.5e-08
⋯ | ⋯ | ⋯ | ⋯ | ⋯
23779396 | 24052883 | 23916139.5 | 273487 | 3.2e-08
24052883 | 24514178 | 24283530.5 | 461295 | 3.2e-08
24514178 | 24739811 | 24626994.5 | 225633 | 3.2e-08
24739811 | 25595063 | 25167437 | 855252 | 3.1e-08
25595063 | 25666426 | 25630744.5 | 71363 | 4.8e-08
25666426 | 25882447 | 25774436.5 | 216021 | 5.1e-08
25882447 | 26022890 | 25952668.5 | 140443 | 5.7e-08
26022890 | 26337325 | 26180107.5 | 314435 | 5.6e-08
26337325 | 26766420 | 26551872.5 | 429095 | 4.2e-08
26766420 | 26975502 | 26870961 | 209082 | 0

petrelharp · 2026-07-14T14:46:35Z

I think it works because the the chromosomes all end in 0.0, so adding nan shifts the rates to the next interval. Agree it's a bit hacky.

Wait, this sounds just plain wrong (we don't want to shift rates to the next interval?) but also there is no difference between the two things you posted?

silastittes · 2026-07-14T19:47:15Z

Did some digging and figured out why my weird append of nan at the beginning was working. stdposim uses the rate_col=2 argument in read_hapmap, and I was not.

Here's the docstring from msprime for that argument:

:param int rate_col: The zero-based index of the column in the file
     specifying the rate in cM/Mb. If ``None`` (default) do not use the rate
     column, but calculate rates using the genetic map positions, as
     specified in ``map_col``. If the rate column is used, the
     interval from 0 to first physical position in the file is marked as
     unknown, and the last value in the rate column must be zero.

The function in the comments of the PR us updates and now looks like this:

def rate_map_zero_adjusted(hapmap_file: str, chrom: str, spp: str = "AraTha"):
        map_ex = msprime.RateMap.read_hapmap(hapmap_file, rate_col=2)
        species = stdpopsim.get_species(spp)
        chrom_length = species.genome.get_chromosome(chrom).length
        rate = map_ex.rate.copy()
        #extend to end of chromosome and remake map
        if map_ex.right[-1] < chrom_length:
            new_position = np.append(map_ex.position, chrom_length)
            new_rate = np.append(rate, 0)
        new_rate_map = msprime.RateMap(position = new_position, rate = new_rate)        
        return new_rate_map

Without applying the selfing correction, I get the same mean_rate values as we get in the release version of stdpopsim.

The tests are still failing for unclear reasons. Do you get the same rate values (right hand side) on your local install @srgibbon17?

FAILED tests/test_AraTha.py::TestGenome::test_recombination_selfing_correction[1] - AssertionError: assert 1.781967764837082e-08 == 2.0449377650848874e-09
FAILED tests/test_AraTha.py::TestGenome::test_recombination_selfing_correction[2] - AssertionError: assert 1.937839693555237e-08 == 2.223812153186693e-09
FAILED tests/test_AraTha.py::TestGenome::test_recombination_selfing_correction[5] - AssertionError: assert 1.837712630491788e-08 == 2.1089090575158218e-09
FAILED tests/test_AraTha.py::TestGenome::test_recombination_selfing_correction[4] - AssertionError: assert 2.091567275873253e-08 == 2.4002257476526107e-09
FAILED tests/test_AraTha.py::TestGenome::test_recombination_selfing_correction[3] - AssertionError: assert 1.8292173775123127e-08 == 2.0991601361354922e-09
FAILED tests/test_AraTha.py::TestGenome::test_selfing_correction_local - assert np.float64(2.2387625242718484e-09) == 1.950902806431916e-08

petrelharp · 2026-07-14T20:13:07Z

Hold on - I don't think that explains things? The weird appending was happening after the call to read_hapmap, not before? I'm probably missing something?

As for why the tests aren't passing, one of you has 1 - s / (1+s) and the other 1 - s / (2 - s).

silastittes · 2026-07-14T20:20:33Z

As for why the tests aren't passing, one of you has 1 - s / (1+s) and the other 1 - s / (2 - s).

Doh! Thank you.

codecov · 2026-07-14T20:44:00Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.82%. Comparing base (05f33ad) to head (59767a9).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1858   +/-   ##
=======================================
  Coverage   99.82%   99.82%           
=======================================
  Files         143      143           
  Lines        5030     5033    +3     
  Branches      515      515           
=======================================
+ Hits         5021     5024    +3     
  Misses          6        6           
  Partials        3        3

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

petrelharp · 2026-07-14T23:16:47Z

Turns out the reason that the "insert a nan into the rates" code above produced the same thing as stdpopsim was two wrongs making a right: see #1859.

petrelharp · 2026-07-14T23:39:23Z

Going back to the questions above: this is a bit of a problem since the right thing to do here is to solve #857; so what I think we'd like to do now is to do the least-bad solution and clearly document what we do (unless someone wants to deal with #857 now). Let's see:

On the one hand, our time units are supposed to be "generations", thus suggesting that recombination rate should be 1-F lower.
On the other hand, estimated values of Ne are probably that of Ne-reduced-by-selfing; in other words, one generation in the simulations is actually 1+F generations.
Is this consistent with the estimated mutation rates (from here)? Well, that's from mutation accumulation lines, and so that's per generation, and so the answer is "no".

So, we have the choice of either agreeing with the mutation rate (per generation) or with the Ne values (per adjusted-generation). Note that there is only a difference of 1+F, which is at most 2: not a large difference.

My vote is for sticking with "time units is generations", which is what @srgibbon17 has implemented (lower recomb by a factor of 1-F), since this would be the right thing if we were actually simulating selfing, and although this doesn't quite match with Ne, neither does mutation rate, and it's only off by a factor of about 2.

srgibbon17 · 2026-07-15T17:07:33Z

I've been out for a couple days, so apologies for the slow reply.

I suppose the "least-bad/best" way to calculate the mean rates might depend on how #1832 gets resolved? But, whether the mean rate includes an extension of zero or NaN on the flanking edges of the chromosome doesn't seem to affect the mean rates too much (e.g., for chromosome 1, the mean rate without adding flanking edges is 3.450876386829853e-08 vs. 3.510538727338673e-08 with adding them from this comment). But, I think what @silastittes and I have implemented is at least close to the "least-bad/best" option.

Re: how to pick the least-bad adjustment for the recombination rate? I agree with what @petrelharp outlined above. We have to pick between either the recombination rate or Ne agreeing with the time scale (but can't quite have both) and this is the closest to getting us to recombination rates being in "generations" which seems to be the least-bad option, in my opinion.

Also, I hadn't taken a close look at #857, but I will now!

petrelharp · 2026-07-15T17:12:46Z

Ah, sorry - I wasn't talking about the question about including the flanking zeros or not. What you're doing there seems good.

silastittes · 2026-07-16T19:29:49Z

Hey @srgibbon17, I'm working on addressing #1859. TL;DR I introduced a bug in the cM column when lifting over the coordinates to TAIR10. I noticed my mean rates are slightly different now that I'm using rate_col = 2 for read_hapmap. Namely, the rate means (before adding the selfing correction) that are adjusted for the chromosome end are now

{'1': np.float64(3.550101369046314e-08),
 '2': np.float64(3.7066078164228056e-08),
 '3': np.float64(3.638229478106127e-08),
 '4': np.float64(4.2697122435425374e-08),
 '5': np.float64(3.66415642846763e-08)}

Since our mean rate values matched before this, I'm guessing we both did the same thing previously and did read_hapmap without the rate_col = 2 argument? So I believe we need to update the mean_rate values in my test and your PR.

petrelharp · 2026-07-17T16:40:55Z

Note that you are effectively editing his PR in, @silastittes, since your PR will go onto his. So I suggest just making that change here, after @srgibbon17 confirms.

srgibbon17 · 2026-07-19T15:42:07Z

Hey @silastittes, that seems good to me. From Peter's comment, it seems like you'll make the necessary changes and edit the existing rates, so I don't need to edit my PR directly? But, if not, it's very simple to edit the mean rates myself

silastittes · 2026-07-20T17:05:56Z

Ok cool! Just made the updates. The tests passed locally cause I have the new map cached, but makes sense the local recombination rate will fail until we update the genetic map on AWS.

petrelharp · 2026-07-29T17:51:27Z

+        #        # extend to end of chromosome and remake map
+        #        if map_ex.right[-1] < chrom_length:
+        #            new_position = np.append(map_ex.position, chrom_length)
+        #            new_rate = np.append(rate, 0)


I think this should append nan not 0, since we don't know the recombination rate here (we don't think it's zero).

Suggested change

# new_rate = np.append(rate, 0)

# new_rate = np.append(rate, np.nan)

But, won't that be equivalent to just computing the mean rate directly without extending the maps? (If so that's good, let's do that?)

petrelharp · 2026-08-10T19:01:28Z

say, @silastittes @srgibbon17 can we get this finished off?

silastittes · 2026-08-10T20:37:07Z

Yes! I was waiting for the updated genetic map to be on AWS, but would you prefer we move forward without that updated first?

petrelharp · 2026-08-10T22:18:41Z

Ah sorry should we be bugging @andrewkern then?

petrelharp · 2026-08-10T22:20:11Z

There is, however, the unresolved comment above? Namely: I don't think that we should be appending 0 to the maps, I think we should treat the rate on those regions as unknown, in which case I think we don't need to extend the maps at all to compute the mean rates. And, I haven't seen any discussion or justification of the choice you did make there?

silastittes · 2026-08-11T00:36:35Z

I agree that leaving it as unknown makes more sense. I guess the rational is the current set up here matches what we do in genetic maps. Would it be at all confusing if users run mean_rate on a loaded contig and get a slightly different value than what we hard coded the chromosome values to be for the catalogue?

petrelharp · 2026-08-12T22:31:54Z

I think the current behavior there is a bug: #1832.

silastittes · 2026-08-13T15:25:37Z

Sounds good.

petrelharp · 2026-08-13T18:34:09Z

Sorry for all the nitpicking! Thanks!

petrelharp · 2026-08-13T18:35:25Z

Mind squashing these commits down, and then we'll merge?

AraTha recombination rate (take 2) pre-commit style updates comments and long_description edits Update stdpopsim/catalog/AraTha/species.py Co-authored-by: Peter Ralph <petrel.harp@gmail.com> edit comments and add/edit citations Update stdpopsim/catalog/AraTha/genetic_maps.py Co-authored-by: Peter Ralph <petrel.harp@gmail.com> Update stdpopsim/catalog/AraTha/species.py Co-authored-by: Peter Ralph <petrel.harp@gmail.com> added citation to Platt et al for recombination rate update changelog update changelog AraTha first pass QC for 1855 local test and revisions for mean test corrected to genetic map mean rate chromosome length adjustment selfing correction bug flake8 black and flake8 edits for AraTha genetic map bug fix local test updated removed chromomsome extension for mean rate

silastittes changed the title ~~QC for #1855~~ QC for 1855 Jul 10, 2026

petrelharp mentioned this pull request Jul 14, 2026

add selfing rate #857

Open

2 tasks

petrelharp mentioned this pull request Jul 29, 2026

QC for recombination rate (AraTha) #1856

Open

petrelharp reviewed Jul 29, 2026

View reviewed changes

silastittes force-pushed the QC_pr1855 branch from 65e89a0 to 59767a9 Compare August 13, 2026 19:10

	# new_rate = np.append(rate, 0)
	# new_rate = np.append(rate, np.nan)

Uh oh!

Conversation

silastittes commented Jul 10, 2026

Uh oh!

mergify Bot commented Jul 10, 2026

Uh oh!

petrelharp commented Jul 10, 2026

Uh oh!

petrelharp commented Jul 11, 2026

Uh oh!

petrelharp commented Jul 11, 2026

Uh oh!

srgibbon17 commented Jul 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

srgibbon17 commented Jul 11, 2026

Uh oh!

silastittes commented Jul 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

petrelharp commented Jul 13, 2026

Uh oh!

petrelharp commented Jul 13, 2026

Uh oh!

silastittes commented Jul 14, 2026

Uh oh!

petrelharp commented Jul 14, 2026

Uh oh!

silastittes commented Jul 14, 2026

Uh oh!

petrelharp commented Jul 14, 2026

Uh oh!

silastittes commented Jul 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

petrelharp commented Jul 14, 2026

Uh oh!

silastittes commented Jul 14, 2026

Uh oh!

codecov Bot commented Jul 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

petrelharp commented Jul 14, 2026

Uh oh!

petrelharp commented Jul 14, 2026

Uh oh!

srgibbon17 commented Jul 15, 2026

Uh oh!

petrelharp commented Jul 15, 2026

Uh oh!

silastittes commented Jul 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

petrelharp commented Jul 17, 2026

Uh oh!

srgibbon17 commented Jul 19, 2026

Uh oh!

silastittes commented Jul 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

petrelharp Jul 29, 2026

Choose a reason for hiding this comment

Uh oh!

petrelharp commented Aug 10, 2026

Uh oh!

silastittes commented Aug 10, 2026

Uh oh!

petrelharp commented Aug 10, 2026

Uh oh!

petrelharp commented Aug 10, 2026

Uh oh!

silastittes commented Aug 11, 2026

Uh oh!

petrelharp commented Aug 12, 2026

Uh oh!

silastittes commented Aug 13, 2026

Uh oh!

petrelharp commented Aug 13, 2026

Uh oh!

srgibbon17 commented Jul 11, 2026 •

edited

Loading

silastittes commented Jul 13, 2026 •

edited

Loading

silastittes commented Jul 14, 2026 •

edited

Loading

codecov Bot commented Jul 14, 2026 •

edited

Loading

silastittes commented Jul 16, 2026 •

edited

Loading

silastittes commented Jul 20, 2026 •

edited

Loading