ArrayIndexOutOfBoundsException in JDAS

[nickvandewiele]

After ca. 2h30min of creating reactions for the core species (due to QM), my simulation was finally able to be solved, and then this happened:

The model core has 11128 reactions and 685 species.
The model edge has 178534 reactions and 5634 species.
The chem.inp file has 685 species (excluding inert gases).
The chem.inp file has 11128 reactions (excluding duplicates).
Running time: 168.668 min
Memory used: 451.74 MB / 1123.29 MB (40.22%)

Solving reaction system...
ERROR: java.lang.ArrayIndexOutOfBoundsException: 685
    at jing.rxnSys.JDAS.initializeConcentrations(JDAS.java:615)
    at jing.rxnSys.JDASSL.solve(JDASSL.java:164)
    at jing.rxnSys.ReactionSystem.solveReactionSystem(ReactionSystem.java:1431)
    at jing.rxnSys.ReactionModelGenerator.modelGeneration(ReactionModelGenerator.java:1401)
    at RMG.main(RMG.java:96)

CRITICAL: 685

I have been browsing through the issue list, but could not find this error message. I guess this is a new type of issue?

FYI: Pruning turned on; PDep turned off; QM turned on; DASSL solver. RMG based on 64e937b

[gmagoon]

Please save your SolverInput.dat and SolverOutput.dat in your ODESolver folder (i.e. don't overwrite) and we can have a look tomorrow.

[nickvandewiele]

SolverInput.dat is existing, but empty. SolverOutput.dat is non-existing.

[gmagoon]

Hmm...that may be the problem...though there may have recently been changes that I am not aware of that delete the files at some point

[nickvandewiele]

make test (running the 13HXD example) , does not yield the same error and finishes smoothly...

[rwest]

Towards the end of the log file before this exception was anything fishy going on with pruning?

[nickvandewiele]

Another simulation crashed with the same error, and Pruning was not turned on, in this case.

[nickvandewiele]

I now copied all the binaries from Greg's RMG-Java/bin folder into mine, and still get the same crash... Does RMG use executables in other folders besides /bin/ as well?

[rwest]

I think for QMTP jobs it uses stuff in greg's folder or something like that (but perhaps it first copies them into $RMG/bin?) , otherwise everything is in $RMG/bin, I think

[gmagoon]

Based on further discussions with Nick it seems like this probably has something to do with the use of Restart. Until the exact problem is pinpointed and fixed, the temporary workaround seems to be avoiding use of Restart.

[nickvandewiele]

Browsing through the open issues list, it seems that #169 reports the broken Restart Write/Read feature already some months ago. However, #169 discusses mainly the P-dep kinetics as the origin of the broken restart feature. Both issues might not necessarily be related...

[nickvandewiele]

The bug is caused by the failure in the Species.equals(Species) method for a species comparison with the IDTranslator for one particular species C3H2lin, with the following adjacency list:

1 C 1 {2,D} {4,S} 2 C 0 {1,D} {3,D} 3 C 1 {2,D} {5,S} 4 H 0 {1,S} 5 H 0 {3,S}

the JDAS.getRealID(Species) method therefore creates a new id number, which exceeds the fixed array length of y, previously defined in JDAS.initializeConcentrations(...).

This is very peculiar, because it seems that a fundamental JAVA type (i.e. Map) is at the origin of the failure.

[rwest]

Resonance isomer problem? How are you getting the thermo?

let me expand that briefly: when a species has several resonance isomers, the one with lowest energy is chosen to be the characteristic chemgraph. Perhaps if you change your mind by coming up with a new estimate for one of them and set a different isomer to be the characteristic chemgraph, then the species isomorphism check may fail.

[nickvandewiele]

a resonance isomer exists, yes.

However, the ChemGraph attribute in both species, which is used in the Species.equals(...) method had the same adjacency list, checked while debugging. I used the equality of both printed chemgraph's to decide that RMG/JAVA had failed to recognize the object.

[nickvandewiele]

Moreover, when filtering out this troublesome species, both in species.txt and coreReactions.txt my simulation finally did what i should have done, namely terminating normally.

[rwest]

Weird. Could you step into the Species.equals method? Does it do a graph isomorphism check?

[gmagoon]

I seem to recall some issue with C3H2 before...possibly issue #154 ? As I recall, @mrharper came up with an explanation with what was going wrong, but the details escape me

[nickvandewiele]

Yes, I agree #154 is related to this issue. However, the error trace is different. This could be explained by the use of newer RMG version, where the error would be caught in a different place.

[gmagoon]

OK, I thought some more about this and remember a few more details: as I recall, @mrharper found that there was some conflict between alternative radical representations in the resonance isomer, which can be 2 or 2T (n.b. there is also 2S) and there was an issue with them not being recognized as equivalent

[rwest]

If it helps, for some C3H2-related commits see f39d344ec4b679c0fc3cd1c1dc00688a1ed98235 and 37c25ac1a4e917363a2f2811e716b1d2b72d8a14.

[nickvandewiele]

Thanks, @rwest for these references.

These commits showed that carbene_S is a forbidden structure, therefore @mrharper changed the adjacency list of these C3H2 species to comply with the non-carbene_S representation.

So far, I have no idea how to step into the graph isomorphism part because they are behind a Map.containsKey(Species) expression. These Java types cannot be stepped into, therefore i can't get to the downstream graph isomorphism part...

[rwest]

Hmm. the Map.containsKey() uses .equals() (and potentially .hashCode()) Could you get close to the problem, then stick a breakpoint inside Species.equals() and hashCode()? (or just inspect the code there and have a guess at the problem?). Are you sure the chemgraphs are identical (eg comparing 2T versus 2 as @gmagoon mentioned)?