Equilibrium Reactor Unit-COFE Crash

[nrgeng]

As part of an investigation of the usefulness of a particular reaction, two simulations were conducted at different temperatures using an Equilibrium Reactor Unit. The lower temperature (LT) simulation presented no problems during the study, but the high temperature (HT) simulation crashed above a threshold temperature of 550 C.

Since the LT simulation was well behaved, could the problem be caused by a "fast" reaction occurring at the HT? The data are (1) Keq = 3.0E+07 @ 300 C and (2) Keq = 1.3E+010 @ 800 C. If this indeed is the case, could the problem be detected and a error message be generated so as not to allow COFE to crash? You loose all of your changes when the crash occurs and recovery is by the use of Task Manager––not pretty.

PS. In the past, an error message has been generated regarding convergence.

[jasper]

Can you send me a document with this behaviour so that I can check what is happening?

[nrgeng]

I have emailed the requested document. This is the procedure used to cause a problem (two different responses).

Procedure to crash Equilibrium 300

1) load, Reset & Solve flowsheet
2) change to Reaction @ 800
3) solve flowsheet

a) does not solve--continuous loop
b) cannot Abort
c) use Task Manager to end COFE
"Running" in Task Manager

4) Procedure to crash Equilibrium 500

a) change to Reaction @ 800
a) select manual [Calculation of Unit]
b) similar to above for Equilibrium 300
"Not Responding" in Task Manager
c) once displayed the following
Error Message: "non convergence"

Thanks for any help in resolving this. (My flowsheet is useless)

[jasper]

Why this will not solve is a discussion we have had before.

The equilibrium reactions are solved in terms of reaction extent. You choose an equilibrium constant of 1.3e10, so the reaction is nearly instantaneous. If you are actually interested in the amount of unreacted material (which will be, considering the reaction order, somewhere in the sqtr(1.3E+010) concentration range), I think you will need to set up a specifialized solver and formulate the problem solving specifically for the amount of material that remains unreacted. The equilibrium reactor is not formulated that way, and such a problem is perhaps a bit too specific for the equilibrium reactor to change its formulation.

The reaction is

H2O + CH3OH -> 3 H2 + CO

The error, formulated as

f(X) = 3*ln(C[H2]) + ln(C[CO]) - ln(C[H2O]) - ln(C[CH3OH]) - ln(K)

and the degree of freedom is the normalized reaction extent, such that

f(H20) / fTot0 = f0(H2)/fTot0 + 3*X
f(CO) / fTot0 = f0(CO)/fTot0 + X
f(H2O) / fTot0 = f0(H2O)/fTot0 - X
f(CH3OH) / fTot0 = f0(CH3OH)/fTot0 - X

Now we need to find X such that f(X) is small, which requires solving X with a very high accuraty (do the math: fill out the above and differentiate w.r.t. X).

A new reaction standard specification is being formulated, that allows for completely instantaneous reactions. At that point, the reaction implementations in COUSCOUS will probably be revised to cater for this.

Remains the question why you see a crash. You should be seeing a convergence problem like I do:

error: calculate failed for unit Equilibrium 550: Solution failed: maximum number of iterations exceeded

For the one outside the loop this happens rather quickly. For the one inside the loop all iterations fail, which takes a bit longer. But if you are solving in a back ground thread, you should simply be able to abort the calculation. It takes about 10 - 12 seconds for me to abort, as the current reactor needs to finish not converging.

I cannot reproduce the crash. Can you give more info on how to make it crash?

[nrgeng]

Sorry that this keeps on being a topic of discussion. I did indicate in my posting that the problem might be this same one. Thanks for again providing more information on this topic on the manner in which the equations are postulated and solved.

How to know when to use an Equilibrium Reactor or recommend (be forced) to use a Fixed Conversion Reactor? The investigated reaction seems to solve at 300 C. Does it, is that correct? Does one use the Gibbs Reactor as a test to determine the "instantaneousness" of a particular reaction at a particular temperature?

Latest procedures and results
Fresh Windows 7 environment (cold boot)
COFE V2.6.0.28
load flowsheet

Equilibrium 500 (operation changed from previous)

reset & solve flowsheet
changed to Reaction @ 800
solve flowsheet
no Abort (red stop-sign) icon displayed
"Not Responding" in Task Manager
(In my previous forum posting #2, the above conditions falsely lead me to believe that COFE had crashed)
Did receive Error Message after waiting 55 s
(apparently did not wait long enough last time--never waited even close to 55 s before on a manual [Calculate this unit])

Equilibrium 300 (no change from previous operation)

reset & solve flowsheet
re-solved until solve time no longer changed from 172 ms
changed to Reaction @ 800
solve flowsheet
waited over 12 m, no pop-up error message on "iterations exceeded"
aborted, no response, waited 4 m, aborted 2nd time, waited 4 more min, aborted 3rd time, ended with Task Manager 11 m after initial abortion attempt. This type of activity fits my personal definition of a crashed s/w program.

Since you cannot reproduce the problem that still exists for me, it is time to take another direction. (Q1) Do we agree that the Reaction @ 300 is not "too fast" for use in the Equilibrium Reactor, since it seems to solve? If you do agree, then the Reaction @ 800 is the problem.

Best to avoid this trial-and-error situation, caused by Reaction @ 800, by a test to determine if a reaction is "too fast" for use in an Equilibrium Reactor. Three choices come to mind 1) look at chemical equation and guess, 2) determine Keg of a reaction and guess, or 3) use Gibbs Reactor to rate "degree of fastness" of a reaction. (Q2) Which of these or what other method(s) would you suggest as a test?

[jasper]

On the non-responsiveness, are you allowing a background thread? (edit -> preferences, Allow flowsheet solving in a background thread).

Regarding when can something not be solved: when

- d f(X) / d(X) becomes very high, or when f(X) changes more than the desired accuracy while X changes at machine precision
- when noise in f(X) makes that d f(X) / d(X) cannot be determined with sufficient accuracy

So it is not just a matter of how high is the equilibrium constant. It is more likely a matter of how close is the actual solution to one of the values of composition becoming zero (check the corresponding d f(X) / d X term that results from it). The best test really is: will it converge or not. I am not sure of any test that would tell you with certainty before attempting to solve.