decreasing times error

[jkreinz]

Hi Joshua,

I have my files formatted to run for allele age + selection estimation, but I'm thinking I must have gone wrong somewhere as the program keeps throwing an error "Times are not in decreasing order!"

The command I run is: /ohta2/julia.kreiner/software/selection/sr -G 1 -N 109868 -D test_derivedcounts.txt -P dom_popsizehistory_deorder.txt -o $path/output/${lname} -a, where I've kept years and pop size unscaled.

Here's the head of my popfile and count input file, and I've also attached a full version for inpsection/testing.

test_derivedcounts.txt 13 16 0 0 0 0 -89 -89 2 2 -90 -90 4 4 -91 -91 4 4 -97 -97 2 2 -98 -98 2 2 -99 -99 2 2 -100 -100 2 2 -410 -410 0 0 -418 -418

dom_popsizehistory_deorder.txt 109868.20575394991 0 0 35014.67057441156 0 -89 35014.67057441156 0 -90 35014.67057441156 0 -91 35150.23096022847 0 -97 35150.23096022847 0 -98 35150.23096022847 0 -99 35150.23096022847 0 -100 58640.33186376603 0 -410 58640.33186376603 0 -418

Thanks for your help! Julia

[Schraiber]

Julia,

I think the main issue that you need to reverse your files. If you take a look at the example, you start at the most ancient time (the most negative time) at the top and then the bottom is the present (time 0). I can definitely see how the error message is misleading though.

Also, you absolutely should convert your times and popsizes into "diffusion units". Take a fixed N0, say the most ancient population size, and then time should be /(2*N0) and the population size should be /(N0). That way your time is measured in units of 2N0 generations and your population sizes are relative to N0. It will be very bad if you don't do this.

Best, Josh

[jkreinz]

Thanks Josh -

I was thinking because I specified N and G that the program was doing the automatic conversion to diffusion units (a run msg says a "Specified both generation time and base population size. Assuming times are measured in years, converting all units to 2N0 generations").

I've done the scaling manually now and reversed the files, no longer specifying N or G in the command, and I'm still getting the same runtime error about times not being in decreasing order (now the years column really is no longer decreasing from the top down). I flipped it back, and got the same error but toggling the most recent time point (age = 0) to a non-zero value fixed it. A new error appears that the "Final time point is not infinity OR final epoch not constant". I changed the age of the oldest timepoint to be -Inf and now it is running successfully. Does this sound kosher?

Julia

[Schraiber]

Julia,

Wow you're right! I forgot that past-Josh was smart enough to put that thing to convert units. You can either manually do things as you have or you can have the software do it. My bad!

Okay now looking at the files again, and double checking the code, I think you had it right in the first place: the pop size file should start in the present at the top and decrease through the past. I'm not sure why you had an issue in the first place---The code should output a specific error, telling you which timepoints are not in the right order. Did you get anything like that?

When you say you toggled the most recent time point (age = 0) to fix it, do you mean in the popsize file or the input file or both? It's not clear that that should be a problem

Similarly, when you get the error that final time point is not infinity..." it should tell you exactly which timepoint is not infinity. Again, this seems weird because your file looks like your final pop size is constant. Nonetheless switching it to be -Inf should be fine.

Sorry that things are parsing weirdly!

Best, Josh

[jkreinz]

No worries at all!

Yeah the code does give an indicator of what's wrong ("Time 1 <= Time 2; -0.434758 <= -0.408914") which is how I figured to switch the file order back. When I do, I still get the same decreasing times error, despite the times obviously decreasing (but the indicator for the timepoint error is wrong "Time 0 <= Time 1; 0 <= -0", when timepoint 0 = 0 and timepoint 1 = -0.0104549). Changing the age of the first time point to a non-zero value in the pop history file fixes the decreasing times error. The "Final time point is not infinity OR final epoch not constant" error also indicates the time point line (Size Rate Time \n 1 0 -0.434758).

[Schraiber]

This is very strange, I'm honestly not sure what's going on. The last timepoint issue shouldn't be a problem because the rate is 0, but changing to -Inf should also not be a problem, so that's definitely the right thing to do.

Regarding the most recent timepoint, I'm honestly very unsure what's going on. I'd have to dig into the code to try to parse it out, but that's not gonna be possible for at least a week or two. Maybe give it a shot as it stands and see if your results make sense?