F
Federico Zenith
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello everybody,
I am looking into a problem that probably someone had before, so I hope
I can avoid reinventing the wheel...
I am looking into different alternatives to simulate a chemical process
with a number of unit operations (heat exchangers, chemical reactors and
so on). There are some commercial products (such as Hysys) that do this,
but have a number of shortcomings: Hysys is overkill and is way too
bloated, and Simulink has a nasty habit of crashing on algebraic loops.
Therefore I am considering using C++ directly.
Until now I considered formulating the problem as a list of objects I
call UnitOps:
class UnitOp {...};
class HeatExchanger : public UnitOp {...};
class Tank : public UnitOp {...};
class Reactor : public UnitOp {...};
Each of the sub-classes will have its own states (temperature, liquid
level, whatever), but all should provide a list of parameters (contact
area, height, volume, specific heat of the entering fluid...) and a list
of functors in the form f(x) = 0 that describe the relations (in general
non-linear, but usually not freakishly so) between those parameters.
For instance, a heat exchanger would have a functor representing:
Q - U×A×ΔT = 0
don't worry about what that is if you don't know anything about heat
exchangers, it's just an algebraic relation among its parameters.
So, my idea would be to take a list of UnitOp*, merge all the parameters
from these, take all their functors, add some more functors to account
for the relations among different UnitOp (say we assign the entering
temperature of a heat exchanger, or that the entering flow is equal to
the one exiting from another unit - whatever), and when I have N
parameters and N functors I should be able to feed all this to a
root-finding algorithm as those I can find in the GSL.
The problems at this point are:
1) How do I make sure that the problem is well formed, and that the
functors are actually independent from each other? The system is
nonlinear, so checking a matrix' rank is no option. I cannot simply
assume that the system _is_ well formed, since it will be the program's
user's task to decide the equations determining the last functors, and I
need to tell him if something is wrong (and possibly what).
2) A lot of those functors represent explicit relations (like the heat
exchanger formula above), but if I feed everything to a root-finding
algorithm I would be using an implicit method. This is going to be a
serious performance hit as I would be using a solution space with many
more dimensions than strictly necessary. I cannot hard-code the direct
relations since in general I do not know which these are.
When I got to this point, I realised that I cannot be the first person
with such an issue, so I was wondering whether anyone here saw some
library or procedure that does something similar to what I described.
Any thoughts, anyone?
Cheers,
- -Federico
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFIWRpSBIpu+y7DlLcRAovhAJ92VIdHh2dk1kWp4LiX3lNdlAqsOACfQqM/
HnjvlbKuOY17E+Tp4jxY2EY=
=pLrD
-----END PGP SIGNATURE-----
Hash: SHA1
Hello everybody,
I am looking into a problem that probably someone had before, so I hope
I can avoid reinventing the wheel...
I am looking into different alternatives to simulate a chemical process
with a number of unit operations (heat exchangers, chemical reactors and
so on). There are some commercial products (such as Hysys) that do this,
but have a number of shortcomings: Hysys is overkill and is way too
bloated, and Simulink has a nasty habit of crashing on algebraic loops.
Therefore I am considering using C++ directly.
Until now I considered formulating the problem as a list of objects I
call UnitOps:
class UnitOp {...};
class HeatExchanger : public UnitOp {...};
class Tank : public UnitOp {...};
class Reactor : public UnitOp {...};
Each of the sub-classes will have its own states (temperature, liquid
level, whatever), but all should provide a list of parameters (contact
area, height, volume, specific heat of the entering fluid...) and a list
of functors in the form f(x) = 0 that describe the relations (in general
non-linear, but usually not freakishly so) between those parameters.
For instance, a heat exchanger would have a functor representing:
Q - U×A×ΔT = 0
don't worry about what that is if you don't know anything about heat
exchangers, it's just an algebraic relation among its parameters.
So, my idea would be to take a list of UnitOp*, merge all the parameters
from these, take all their functors, add some more functors to account
for the relations among different UnitOp (say we assign the entering
temperature of a heat exchanger, or that the entering flow is equal to
the one exiting from another unit - whatever), and when I have N
parameters and N functors I should be able to feed all this to a
root-finding algorithm as those I can find in the GSL.
The problems at this point are:
1) How do I make sure that the problem is well formed, and that the
functors are actually independent from each other? The system is
nonlinear, so checking a matrix' rank is no option. I cannot simply
assume that the system _is_ well formed, since it will be the program's
user's task to decide the equations determining the last functors, and I
need to tell him if something is wrong (and possibly what).
2) A lot of those functors represent explicit relations (like the heat
exchanger formula above), but if I feed everything to a root-finding
algorithm I would be using an implicit method. This is going to be a
serious performance hit as I would be using a solution space with many
more dimensions than strictly necessary. I cannot hard-code the direct
relations since in general I do not know which these are.
When I got to this point, I realised that I cannot be the first person
with such an issue, so I was wondering whether anyone here saw some
library or procedure that does something similar to what I described.
Any thoughts, anyone?
Cheers,
- -Federico
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFIWRpSBIpu+y7DlLcRAovhAJ92VIdHh2dk1kWp4LiX3lNdlAqsOACfQqM/
HnjvlbKuOY17E+Tp4jxY2EY=
=pLrD
-----END PGP SIGNATURE-----