Compatibility with newest REACLIB

[Ludwig Jens Papenfort]

When one tries to run skynet with the newest reaclib ('default', reaclib2 format, with Chap 9, 10, 11) the network crashes while loading the reaclib. It isn't able to recognize the 'p' flag in the rates involving 'wc17p', which are completely absent in the current reaclib shipped with skynet.
Is there an easy way to solve this or has more profound implications?
The most recent default reaclib works fine with skynet, as long as one removes the 'wc17p' rates.

[Jonas Lippuner]

I can confirm that SkyNet cannot currently read the latest REACLIB file, because of the new 'p' flag that was introduced, but not documented. This will be an easy fix, but I want to understand the meaning of this new flag before I fix the issue.

As a temporary workaround, you could replace all occurrences of "wc17p" with "wc17 " (space instead of p is important) using search-and-replace. Then SkyNet can use the wc17 rates.

[Ludwig Jens Papenfort]

I tried the quick fix and it seems to run fine.

[Diego Vescovi]

Hi Jonas, I tried to run skynet with the newest reaclib too but the network crashes (core dump created) after some steps. The newest reaclib table includes beta-delayed fission rates from Mumpower+ 17. It seems that that 'p' flag is now removed and replaced with the correct flag 'w'. It looks like that the code is crashing when using those data. Did you compute some runs with them? Just to understand if it's a matter of calibrating the code or if deeper inspection to the physics is needed. Thanks, dvescovi

[Jonas Lippuner]

Sorry for the delay. I've traced this issue to a beta-decay reaction (te128 -> i128) that's erroneously flagged as a reverse reaction. SkyNet honors this flag and treats it as an inverse reaction, meaning the rate eventually blows up, leading to NaNs and a floating point exception. Removing the v flag of this reaction fixes the issue for me. I've emailed [e-mail] about this.