You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Calling KPM calculator can result in the following:
ERROR: DimensionMismatch: arrays could not be broadcast to a common size; got a dimension with lengths 9724 and 9722
where the first length is rd.nr and the second in calc.Ea. This is due to KPM identifying 2 duplicate reactions and removing them (N.B. needs an assertion in KineticaKPM for this). These reactions should have been previously identified by rhash in push!(::RxData...; unique_rxns=true) but are not, so some duplicate reactions must be generating unique hashes somehow. As this applies on fresh RxDatas reconstructed from the same reaction tree, whatever input reactions must be different enough to always randomly generate different hashes. Need to check logic for rhash construction.
The text was updated successfully, but these errors were encountered:
The offending reactions are ["[CH2]/C=C/CCC(C)(C)C"] -> ["C=C[CH]CCC(C)(C)C"] and its reverse, which are found in the input network but not within the output KPM reactions.
It is currently unclear what KPM is considering as this reaction's 'duplicate', however this has also highlighted a problem with the KPM interface (see Kinetica-jl/KineticaKPM.jl#1)
Fixing the above issue within KineticaKPM seems to have resolved this, since there is no longer a disconnect between Kinetica inputs and KPM outputs. rhash construction is therefore fine, although this has highlighted an oversight in rhashes constructed within insert_inert!, which was fixed in ce82ea2.
Calling KPM calculator can result in the following:
where the first length is
rd.nr
and the second incalc.Ea
. This is due to KPM identifying 2 duplicate reactions and removing them (N.B. needs an assertion in KineticaKPM for this). These reactions should have been previously identified byrhash
inpush!(::RxData...; unique_rxns=true)
but are not, so some duplicate reactions must be generating unique hashes somehow. As this applies on freshRxData
s reconstructed from the same reaction tree, whatever input reactions must be different enough to always randomly generate different hashes. Need to check logic forrhash
construction.The text was updated successfully, but these errors were encountered: