hkmoffat / cantera

Automatically exported from code.google.com/p/cantera
0 stars 0 forks source link

Character limit on size of reactions returned by rxnEqs() in matlab implementation. #118

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
For a generic cantera solution:

gas=IdealGasMixture('mechanism.cti'),

if one uses:

rxnEqs(gas)

it returns a list of reactions with the ends of them cut off at 80 characters. 
I did some investigation and it appears that the issue is on the output 
function and not the .cti import (the stoichiometric matrix does have the right 
entries for these equations). I just want to report this as something that 
might be worth fixing to avoid confusion when working with empirical models 
that have long formats.

Original issue reported on code.google.com by addison....@gmail.com on 4 Oct 2012 at 5:34

GoogleCodeExporter commented 9 years ago

Original comment by yarmond on 4 Oct 2012 at 7:12

GoogleCodeExporter commented 9 years ago
Ray,
I was looking into this today and I have a few questions. The file "rxnEqs.m" 
appears to be a duplicate of "reactionEqn.m", except in "rxnEqs.m" the function 
"rxnstring" is used instead of "kinetics_get". I can't find "rxnstring" 
anywhere, and trying to use "rxnEqs.m" gives the error "Undefined function 
'rxnstring' for input arguments of type 'double'." Is there a reason "rxnEqs.m 
is still around? 

Second, the buffer length is hardcoded to 80 characters on line 128 of 
src/matlab/kineticsmethods.cpp. Is there a reason for this particular buffer 
length or can it be made larger to avoid this problem? Of course, one could 
write an arbitrarily long reaction string that will still be cut off for any 
given buffer length, so maybe this isn't worth fixing?

Bryan

Original comment by bryan.w....@gmail.com on 2 Jan 2014 at 8:25

GoogleCodeExporter commented 9 years ago
I agree that the file 'rxnEqs.m' should be removed. The function 'rxnstring' 
has been missing for a long time.

Increasing the buffer length would fix this for some cases, but there is of 
course a (probably minor) performance penalty for allocating an unnecessarily 
large buffer, and as you say, the reaction string can be arbitrarily long.

A robust fix for this is to have the kin_getReactionString method return the 
required buffer length if the given buffer is inadequate, so that the calling 
function can try again with a larger buffer, as is done for the phase_report 
method.

The same situation arises in principle for phase_getSpeciesName, 
phase_getElementName, and phase_getName, so it would be nice to write a generic 
function to handle this.

Original comment by yarmond on 3 Jan 2014 at 5:25