"Fit failed due to crash in CarbonXS"

schro-cat commented 7 years ago

I am getting chronic failures when the program is writing the carbon.out file. It successfully completes the fit and writes some or all of the carbon.out file before crashing. I'm able to directly go into the carbon.out file to extract the data, but the majority of the time it isn't completing.

I have restarted the program and my computer. I have also set the CarbonXS folder as an exclusion from my AV and tried completely disabling my AV with no change. This happens with multiple samples, so it's not one glitchy file.

-Mike

Iter # Chi^2 Alambda 1 13.75015 .10E-01 2 13.75015 .10E+00 3 9.96214 .10E-01 4 9.96214 .10E+00 5 8.45746 .10E-01 6 8.45746 .10E+00 7 8.45746 .10E+01 8 8.45746 .10E+02 9 8.45746 .10E+03 10 8.45746 .10E+04 11 8.11272 .10E+03 12 8.11272 .10E+04 13 8.11272 .10E+05 14 7.99601 .10E+04 15 7.99601 .10E+05

Final Parameters Old Value New Value(esd) Description CarbonXS.exe Process Complete Error: Fit failed due to crash in CarbonXS

lktsui commented 7 years ago

I've tracked this problem down to a bug in the LISTPAR function in the Fortran code. The function blows up if excessively large values are encountered that it can't print out (a common theme in this codebase). Switching to scientific notation should fix everything.

Current fixes are being worked on in this branch. https://github.com/lktsui/carbon_xs_gui/tree/LISTPAR_fix_branch

lktsui commented 7 years ago

Two major possible sources of crashes were encountered and fixed:

There were cases where the Singular Matrix warning wasn't being sent to console so CarbonXS GUI couldn't detect it. This has been fixed in 69d2a2a625072e1cbfb1dd2d9cd16d96a32823ae.
A major case of crashes is that the output of the initial and final parameters to console and carbon.out relies on a function that dynamically rewrites the format statement based on the size of the parameters to make everything line up nicely in decimal notation. This fails with a hard crash if any of the parameters that are put in are very large because the final generated format statement is not guaranteed to be valid. We've completely stripped this out and replaced this with a simple print of everything in scientific notation so that arbitrarily large numbers can be handled gracefully. The diff is shown here: https://github.com/lktsui/carbon_xs_gui/commit/0f8d6515e1aa5f186bffd36d09f98c0b2b31fd87?diff=split

lktsui / carbon_xs_gui

"Fit failed due to crash in CarbonXS" #8