Saving/restoring information for OneD simulations

[GoogleCodeExporter]

Currently, at least for a counterflow flame, only temperature and mass flow 
rates are saved as boundary conditions, but not the species information.
BC's are generally not updated when restoring simulation data.
Additionally, can additional information like pressure, refineCriteria, etc. 
also be stored in the xml file?
Thank you!

Original issue reported on code.google.com by thetruet...@googlemail.com on 18 Jun 2012 at 12:48

[GoogleCodeExporter]

Original comment by yarmond on 19 Jun 2012 at 4:53

• Changed state: Accepted
• Added labels: Component-Python, Milestone-2.1
• Removed labels: OpSys-Linux

[GoogleCodeExporter]

I just found one thing in that context that is particularly important and 
possibly misleading:
The .xml simulation data does include the pressure at which the simulation was 
run. However, this value is not restored with the rest of the simulation. At 
least, this is the case for python: The '_p' value in AxissymmetricFlow and the 
'pressure' value in derived classes is not adapted to the restored simulation, 
but rather remains at its initialized value.
If you then investigate the restored simulation, e.g. by using setGasState, 
Cantera internally uses the possibly wrong value for the pressure. This can 
cause some quite irritating results...

Original comment by thetruet...@googlemail.com on 4 Oct 2012 at 1:11

[GoogleCodeExporter]

Original comment by yarmond on 15 Dec 2012 at 3:31

• Changed state: InProgress
• Added labels: Component-1D

[GoogleCodeExporter]

The problems with the boundary conditions and pressure should be addressed by 
the changes in the following commits: r1992, r1993, r1994, r1995, r1996, and 
r1998.

Remaining things that could also be saved: refine criteria, solver tolerances, 
and whether the energy equation / species equations are enabled or not. (Are 
there any others?)

Original comment by yarmond on 18 Dec 2012 at 2:19

[GoogleCodeExporter]

Thanks a lot, these changes are great!
If the 'remaining things' are included as well, it would be perfect for me.

There is just one more things that might be interesting to save: The name of 
the reaction mechanism. However, I don't see that this is stored somewhere in 
the gas object. So, this could get more complicated than it sounds. It's more 
like a 'nice to have' feature anyway, since you need to define a gas phase 
before restoring a solution.

Two more rather unimportant, but 'nice to have' features would be:
- Defining a default initial grid, so you don't have to make one if you just 
want to restore a solution.
- An option to toggle the C++ verbosity on save/restore

Original comment by thetruet...@googlemail.com on 18 Dec 2012 at 8:56

[GoogleCodeExporter]

The ability to suppress the output from save/restore was added in r1991. This 
affects the C++ interface and the new Cython-based Python module, but not the 
legacy Python module.

Having a default initial grid sounds like a reasonable addition for the Cython 
module.

I think that restoring the reaction mechanism would be a little difficult using 
the current method of restoring. A higher-level restore function which 
reconstructs the entire simulation object based on the saved solution could 
handle this, though that's a bit beyond the scope of this Issue (feel free to 
create a new one if you like).

Original comment by yarmond on 19 Dec 2012 at 4:50

[GoogleCodeExporter]

Well apparently I should switch to Cython at some point;)

I in fact did not mean to include the entire reaction mechanism into the 
output. I just thought it would be useful to state the name of the reaction 
mechanism and possibly the path to it. However, since I guess this information 
isn't stored inside the phase object, this information is probably hard to 
obtain and indeed beyond the scope of this issue.
In the mean time, I can store this information in the description of the 
solution. Maybe you could encourage this practice by adding a description like 
'Computed using GRI30' in the tutorial file?

Original comment by thetruet...@googlemail.com on 19 Dec 2012 at 5:14

[GoogleCodeExporter]

Fixed with the following commits:

    r2194 - 'grid' parameter is optional (Cython only)
    r2197 - solver tolerances
    r2198 - whether energy / species equations are enabled
    r2199 - grid refinement parameters

Original comment by yarmond on 7 Mar 2013 at 6:54

• Changed state: Fixed

[GoogleCodeExporter]

Thanks a lot, Ray!

I just have one resulting issue and two questions:

When restoring an old simulation which did not have the entry 'energy_enabled', 
I got the following error:

***********************************************************************
CanteraError thrown by getFloatArray:
wrong xml element type/name: was expecting energy_enabledbut accessed domain
***********************************************************************

I resolved it by manually adding an entry for 'energy_enabled'.
I guess this is a minor issue which should go away when all new solutions are 
created using Cantera's save function. Hover, I'm not 100% sure so I wanted to 
tell you.

The questions I have are on saving the tolerances and the energy and species 
enabled flags. It appears that this value is saved several times in all 
domains. Is this really necessary? Which value is actually restored if these 
values are not equal in all domains?

Thanks a lot in advance!

Original comment by thetruet...@googlemail.com on 8 Mar 2013 at 11:46

[GoogleCodeExporter]

Changes in r2200 should make restoring from old XML files work.

The reason there are multiple values is because the actual implementation is 
more fine-grained than the typical usage. The energy_enabled flag is per grid 
point; species_enabled is done per species, per domain; tolerances are per 
component, per domain.

Original comment by yarmond on 8 Mar 2013 at 3:37