Real copy of Solution

[Alfred Mechsner]

Hello,

is it possible to make under Python a real copy of a Solution object?

   g=Solution("gri30.xml")
   g.TP=300, 1e5
   x=g

x now is just a reference to the original  Solution instance g.

Is it possible to produce a completly new and undependent copy of the Solution object?

Many thanks

Alfred

[Ray Speth]

Alfred,

I think your best bet is to just instantiate two Solution objects and copy the state:

g=Solution("gri30.xml")
g.TP=300, 1e5

x=Solution("gri30.xml")
x.TDY = g.TDY

Regards,

Ray

[Alfred Mechsner]

Hello Ray,

this is clear, of course.

But what to do, when you need a copy  of a Solution instance way down in a deep iteration, but you don't know, from what "xxx.cti" file this Solution object was created.
Isn't it possible to have a fresh copy of the underlying C++ object?

Many Thanks

Alfred

--
You received this message because you are subscribed to the Google Groups "Cantera Users' Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cantera-user...@googlegroups.com.
To post to this group, send email to canter...@googlegroups.com.
Visit this group at http://groups.google.com/group/cantera-users.
For more options, visit https://groups.google.com/d/optout.

[Ray Speth]

Hi Alfred,

The Python interface does not provide a method for copying the underlying C++ objects. One option for the case you described would be to use the "name" attribute of the Solution object to store the path to the input file.

While the C++ objects themselves are (mostly) copyable, I've generally found it to be more efficient if you can avoid creating multiple Cantera objects based on the same input file. The Reactor classes are an example of this: you can build a network with several reactors that all share the same Solution object to do calculations, as each reactor keeps track of its own state separately. That said, I would consider making the Python objects copyable if I had an example where that was more efficient or contributed to making the code significantly more clear.

Regards,

Ray

To unsubscribe from this group and stop receiving emails from it, send an email to cantera-users+unsubscribe@googlegroups.com.

[Uvidus Nox]

Hello Ray,

I can see where you are going with this, and truth said, having multiple copies of solutions floating around will likely increase the likelihood of errs.

There are however cases where mixing of different 'solutions' (or copies thereof) are required without changing the initial 'solutions'; e.g. ct.mixture can mix 2 'solutions' which causes change to the T/P of the second object (correct me if I'm wrong; but this is my experience thus far). 

- Usecase of this is to calculate the oxygen requirement of some fuel and oxidiser, without mingling with the initially defined properties.

At the moment I bypass this limitation by copying both object into new ones, mix these, calculate the required numbers and dispose of both 2 copies together with the mix object; of course the problem is that the code has no way to find out what xml/cti was used by the source (fuel/oxi) objects. The easy way is to add an extra attribute to the solution class being used, e.g.:

def ctsolution(inputFile='gri30.xml', phaseName = None, ...):

   #cantera solution wrapper (contains some additional info)

   sol = ct.Solution(inputFile, phaseName, ...)

   #store inputFile name:

   sol.__finp__ = inputFile

   return sol

It would obviously preferable when the used 'xml/cti' could be requested directly from the 'solution' object itself, offering more straightforward means to instantiate an additional 'solution' object without having to bother to supply the 'xml/cti' location explicitly. Also: trying to figure out this property from a prior defined 'solution' object will also create a tad more obscure code (at least).

I hope that you might be able to shed some light concerning tackling this issue.

Regards and thank you in advance,

Uvi

To unsubscribe from this group and stop receiving emails from it, send an email to cantera-user...@googlegroups.com.

[Ray Speth]

Uvi,

You're right, re-using Solution objects within Mixture doesn't work very well. I think this is a flaw in how Mixture is implemented. It would probably be better if it worked more like how Reactors work, with Mixture storing a state vector for each contained Solution and not expecting them to have a specific state. Then class Mixture becomes a lightweight, trivially copyable class with multiple copies able to reference the same underlying Solution objects.

Storing the input file name is an option, but it only works for Solution objects that are generated from a file. In the development version, there is already the option to create a phase directly from an XML or CTI string, and there are some new features that allow creating phases programmatically, without using an input file in either format.

Regards,

Ray