Exception when using -Strace

[paula-tataru]

I used the following command to obtain a frequency trajectory:

java -jar -Xmx1G msms.jar -ms 2 1 -t 500 -r 399.9996 100000 -Sp 0.5 -N 100000 -SI 0.00625 1 0.1 -SA 10000 -SForceKeep -oSeqOff -oTrace > testTrace

Using the output saved in testTrace, I crated a file with just the frequency trajectory to run a new simulation with -Strace:

java -jar -Xmx1G msms.jar -ms 2 1 -t 500 -r 399.9996 100000 -Sp 0.5 -N 100000 -SI 0.00625 1 0.1 -SA 10000 -SForceKeep -oSeqOff -Strace trace

This gives the following exception (and output):

ms 2 1 -t 500 -r 399.9996 100000 -Sp 0.5 -N 100000 -SI 0.00625 1 0.1 -SA 10000 -SForceKeep -oSeqOff -Strace trace [3.2rc Build:102] 0x5ef9ca61208312

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 4449 2501 at at.mabs.model.selection.SuperFrequencyTrace.setIndexTime(SuperFrequencyTrace.java:76) at at.mabs.model.selection.SelectionData.getFrequency(SelectionData.java:287) at at.mabs.coalescent.CoalescentEventCalculator.nextCoalescentSelection(CoalescentEventCalculator.java:349) at at.mabs.coalescent.CoalescentEventCalculator.nextEventSelection(CoalescentEventCalculator.java:90) at at.mabs.coalescent.CoalescentEventCalculator.calculateCoalescentHistory(CoalescentEventCalculator.java:520) at at.MSLike.run(MSLike.java:301) at at.MSLike.runThreads(MSLike.java:424) at at.MSLike.runMe(MSLike.java:191) at at.MSLike.main(MSLike.java:543) at at.MSLike.main(MSLike.java:587)

The two files I have can be found here: https://www.dropbox.com/s/2e6jwssygd9ugiz/testTrace https://www.dropbox.com/s/tcjznukb7c36qnp/trace

Update: I just noticed the closed issue #13 and running that example gives the same type of error, and my build is newer than the corresponding fix.

[delt0r]

Yes its a bug. I don't know if it will be fixed before the refactor is out. Its all the same section of code.

Note also that when you use a file for selection you don't use -SI -SF or other selection options. They should be ignored but you never know. In this case it does not fix the issue however.

[delt0r]

There is a workaround. The problem is when the last time point in the provided trace is not at time 0. A final time entry at the end of the file is all that is needed.

So the next release won't quite fix this. Its weird and probabilistic as well.