Assertion error in decoding

[trevorcousins]

Hi Stephan,

Thanks for this brilliant bit of software which you have been maintaining for 10+ years.

I encountered an error in the decoding (version 2.1.3)I suspect it is an underflow / overflow error.

I am trying to decode an orangutan, command line looks like this:
/home/tc557/MSCM2/msmc2-2.1.3/build/decode -m 0.00117312 -r 0.000293281 -l 18.388186752,11.732607744000001,1.9501360319999999,1.4972413247999998,1.1211273216,0.87359196288,1.06168767744,0.95656556736,0.83748919488,0.79523810496,0.7476692620799998,0.65183591616,0.55690469952,0.53003555904,0.49715417856,0.4683153696,0.48458067839999996,0.54814853184,0.64868491584,0.75359234496,0.8151072384,0.81064117056,0.76490591424,0.71553515904,0.69324118656,0.70562346816,0.7457171904,0.80733179904,0.8867707929599999,0.97038257472,1.03194321984,1.05693067584,1.05319663488,1.03961425152,1.037536656,1.06237043328,1.11802089984,1.1949283008,1.2724363392,1.3316906304,1.3702393536,1.4090227007999998,1.4837973695999997,1.6240555968000001,1.8259495488,2.010375744,2.0275854144,1.7775348864,1.4278278143999998,1.3317727488,1.5853074431999998,1.882153728,2.5943783423999998,4.1076796799999995,944.2419417599999,0.00105669253248,0.00113182265664,0.00100000385472,0.00101709269376,0.0010023149011199998,0.00100731825792,0.00099999798912,0.00114093193344,1.3242413184e+81 <infile> | gzip -c > <outfile>

but it gives me this error:
core.exception.AssertError@model/psmc_hmm.d(143):[1, 0.404196, 1.46307e+40, 1.66856e+139, 1.66856e+139, ....
and continues like that for a very long time. The error finishes with

??:? _d_assert_msg [0x58bb50]
??:? void model.psmc_hmm.PSMC_hmm.runForward() [0x54a12e]
??:? void decode.decodeWithHmm(model.psmc_hmm.PSMC_hmm) [0x57a7fb]
??:? void decode.run() [0x57a614]
??:? _Dmain [0x579d72]

You will note the input lambda vector has some very large numbers and some very small numbers (these come straight from the final.txt file - instability perhaps?).
If I replace the lambda vec with (i.e. cap the large and small numbers):
18.388186752,11.732607744000001,1.9501360319999999,1.4972413247999998,1.1211273216,0.87359196288,1.06168767744,0.95656556736,0.83748919488,0.79523810496,0.7476692620799998,0.65183591616,0.55690469952,0.53003555904,0.49715417856,0.4683153696,0.48458067839999996,0.54814853184,0.64868491584,0.75359234496,0.8151072384,0.81064117056,0.76490591424,0.71553515904,0.69324118656,0.70562346816,0.7457171904,0.80733179904,0.8867707929599999,0.97038257472,1.03194321984,1.05693067584,1.05319663488,1.03961425152,1.037536656,1.06237043328,1.11802089984,1.1949283008,1.2724363392,1.3316906304,1.3702393536,1.4090227007999998,1.4837973695999997,1.6240555968000001,1.8259495488,2.010375744,2.0275854144,1.7775348864,1.4278278143999998,1.3317727488,1.5853074431999998,1.882153728,2.5943783423999998,4.1076796799999995,5,0.1,0.1,0.1,0.1,0.1,0.1,0.1,0.1,10
then this solves the problem entirely. This makes me think it is underlow/overflow/numerical stability.

Just thought you should know.

Best,

Trevor

[stschiff]

Thanks, @trevorcousins. Yes, I think I'm not surprised this happens. Indeed with such an extremely large coalescence rate in the last bin, I think problems arise. I have not built in any safety checks there... Thanks for reporting, though! And good that it works with the capped numbers!