2

1.8

Hg CO2 / kg EtOH

1.6
1.4
1.2

Economy

Value chain

0.8

Equipment

0.6
0.4
0.2
0
Conventional

p2p

Variable values (P2P):

0 kg/s
0.904

Mass flow of water stream entering mixer after corn is ground

Mass flow of water (steam) stream entering jet

300/120

Temperature (C) of jet stream

5.192

Mass flow of water entering mixer upstream of fermentation vessel

0.086

Mass flow of urea entering mixer upstream of fermentation vessel

38.720 Temperature of stream entering mixer upstream of fermentation vessel

0.906 Fraction of water from the incoming stream that goes into the liquid stream outlet of the
mechanical press
0.98

Fraction of water in the feed solids that goes to the vapor stream

0.009

Fraction of stream leaving solids separation that is discarded

93.12

Temperature of stream entering the beer column

0.281

Recovery of water in beer column

0.141

Recovery of water in rectification column

0.373

Split fraction of impure ethanol stream sent to rectification column

0.001

Split fraction of impure ethanol stream sent to adsorption operation

0.080

Fraction of water removed from the mixture entering the adsorption operation

10.9785: CO2 OBJECTIVE FUNCTION

WITH DDGS Same:

Working with GAMS:

1. Be very careful about the variables. Be sure about the limits of the variables. Put bounds
before-hand so as to decrease the probability of error afterwards.
2. Try to give a starting value to variables whenever possible. If you have a good idea, give it.
However, sometimes, giving starting values might make the entire problem infeasible.
Depends on the problem itself. Ex In the corn ethanol plant design, if I tried putting
starting variables to the flowrates, the solution failed. However, variables such as
Temperature and Heat supplied worked better with starting variables.
3. Try to build the design unit by unit rather than the whole thing at once. In that way, it will
be really easy to find the part/equation which becomes infeasible during the solution.
4. Be careful that when you are building the code unit by unit, something that is getting
modelled now does not come at a later part of the model. If it comes, you have to model the
entire thing until there are no existing dependencies.
5. Debugging infeasible equations is the hardest part. A large equation which becomes
infeasible, when broken down to smaller parts and written as many small equations might
work perfectly fine. Again, this depends on the problem. In my code, some large equations
worked perfectly fine. Others didnt.
6. In some parts of the code, it might be useful to use inequalities rather than equalities. Again,
the place to use them is purely users choice and his/her understanding of the problem.
Sometimes, even that sign makes a difference to the entire solution. Be sure to check
however, that giving an inequality sign does not bring in erroneous values.
7. DO NOT USE SOMEONE ELSES code. Absolutely not. I did that and suffered a lot. Best
way is to build it from scratch. You will have knowledge of everything. Much easier to
debug them.
8. CONOPT solver has an upper limit on the value it can calculate. Change it using an options
file.
9. The ZERO PROBLEM: Be aware of the way in which GAMS work. Sometimes, you will
have variables in the denominator. Keep in mind that those values might become zero some
time during the solution. Results in infeasibility. Try to keep bounds or change the form of
the equation to prevent those errors. When a certain equation becomes infeasible, try to
find out why it became so. Mostly, its due to some strange values (0) creeping into the
equation. Use step1,Step 6, Step 5 for solving these errors.

10. Try Try Try. Do not give up. It will work. I debugged and re-ran my code probably 500+
times to reach . GAMS is one of the best solver out there for optimization problems but it
has its whole set of limitations. Its different than other commonly used languages. Hence,
coding an entire plant in it is a huge challenge.