Closed GoogleCodeExporter closed 9 years ago
I would even propose a more general inclusion of energy source terms into the
energy balance. This could be radiation or anything else (laser absorption
etc.). Perhaps something like the functor approach, as used for reactor walls,
could be helpful here. The source term could either be a function of T(x)**n or
anything else. This would be very helpful.
Original comment by Burak.At...@gmail.com
on 29 Aug 2012 at 1:37
Hey,
I worked on this issue during my bachelor thesis supervised by Thomas Fiala @
TU Munich. We found an approach to simulate both, radiative and arbitrary
losses in counterflow flames. You find a patch attached. It is based on
revision r2704.
There are also two tutorial files attached which show the use from the cython
interface. It is tested for counterflow diffusion flames, but it may also work
for other one-dimensional flames. If you have further interests in the details
of the implementation I have also attached my bachelor thesis.
The patch should not interfere with other functions and scons test runs
smoothly (except of minor derivations not due to the changes). It would be nice
if this patch could get into a (separate) development branch of cantera
eventually.
Cheers
Andreas
Original comment by andi.rue...@gmx.at
on 28 Jan 2014 at 12:27
Attachments:
This looks like a good start on the physics side of adding support for
radiation, however I have some comments about the implementation.
First, I think the implementation would be simpler if you didn't add any terms
to the solution vector. You can simply add vectors m_qdotRadiation and
m_qdotExternal to StFlow, and use those for temporary storage.
Second, if qdotExternal was supplied using a Func1 object, like is done in the
reactor models, that could still work with grid adaptation.
Original comment by yarmond
on 29 Jan 2014 at 8:34
Andreas,
You may also want to implement this as a standalone that you compile against
the unmodified cantera source. I.e. use inheritance where you derive a class
from StFlow where you implement all your changes. With the current Cython
interface, this is fairly straight-forward, see Issue 175.
Just a thought.
-ingmar-
Original comment by ischo...@gmail.com
on 29 Jan 2014 at 9:27
Hey,
first of all, thank you for your positive feedback. I will definitely continue
to work on this subject.
Original comment by andi.rue...@gmx.at
on 31 Jan 2014 at 2:48
A refined version of this capability was added in r3369. Thanks again to
Andreas for working on this.
Original comment by yarmond
on 20 Jan 2015 at 10:16
Original issue reported on code.google.com by
dirk.gey...@googlemail.com
on 13 Nov 2011 at 8:56