Problem(s) with COCO 3.2

Discusses use of COCO, the process simulation and modelling software suite from AmsterCHEM, downloadable from http://www.cocosimulator.org

Moderator: jasper

Re: Problem(s) with COCO 3.2

Postby jasper » 17 July 2017, 07:01

There is not much I can do without an fsd and a textual description only. Set point is not a port, but a parameter. COFE allows for converting parameters into virtual information ports.

RSP?

Restarting re-initializes the guess from a subset of specifications already in the flowsheet. This may lead to a better state than the flowsheet was in - particularly in case the solution was trying to go into a region where one or more units or streams could not be calculated.

I will be happy to analyze the reported issues further with more information on the flowsheet - at least the connectivity.
User avatar
jasper
 
Posts: 1128
Joined: 24 October 2012, 15:33
Location: Spain

Problem(s) with COCO 3.2 {009}

Postby nrgeng » 24 September 2017, 02:01

{Flowsheet Does Not Solve with Controller}

I am sending an fsd for your review. I am using COFE version 3.2.0.15.

This problem is probably connected to Postings 007 and 008. The flowsheet solves without Controller FC but not with Controller FC. Any ideas? Thanks.
nrgeng
 
Posts: 239
Joined: 16 February 2013, 12:45
Location: USA

Re: Problem(s) with COCO 3.2

Postby jasper » 24 September 2017, 19:59

Thank you for sending me this flowsheet. It allowed me to pinpoint a rather unpleasant bug: some errors in the solver where not reported to the solver process. The result was what you saw: the flowsheet says it solves, and then says it is done solving, while units remain not solved. This happened in the recycle analysis, and subsequent solver tasks are cancelled, but the error did not get reported.

The error is now properly indicated and is unrelated to the controller. The error is that flow constraints must be inside a closed recycle or on the start of a feed stream as the first unit. The reason for this is that if the flow constraint is not in a recycle but not the first unit in the stream, it must control its feed stream, which is also controlled by the upstream unit.

The controller is not the source of the trouble. The source of the trouble is the invalid flow constraint in one of the two feed streams, which has an upstream valve unit. But, you also delivered the same flowsheet without the controller, and concluded that it solved. It did not. It looked solved, as the same error in the flowsheet analysis did not get reported to the solver, but without the recycle the unit that showed the problem immediately got marked solved and the solver process finished. If you look at your case where the controllers is removed closely, you will see that it is not actually solved; the mass balance around the flow constraint is not satisfied.

Please find an update that fixes the error reporting issue, and now both samples will, correctly, not solve, and moreover indicate the cause. You can easily fix the setup by placing the flow constraint upstream of the valve.

As an aside, note that your measured variable is always equal to your controlled variable. Not sure if this was an actual example, but you can simply eliminate your controller and measure unit, and simply stick the ‘setpoint’ directly into the controlled stream.
User avatar
jasper
 
Posts: 1128
Joined: 24 October 2012, 15:33
Location: Spain

Re: Problem(s) with COCO 3.2

Postby jasper » 24 September 2017, 20:01

For completeness, the documentation on the flow constraint placement: http://cocosimulator.org/index_help.php?page=COFE/units.htm
User avatar
jasper
 
Posts: 1128
Joined: 24 October 2012, 15:33
Location: Spain

Problem(s) with COCO 3.2 {009a}

Postby nrgeng » 25 September 2017, 12:30

{Flowsheet solves with flow restraint in any position without error reporting}

Thanks for your response to this problem. I am using COFE version 3.2.0.16.

In the upper simulation from Posting 009's fsd, if you exchange the positions of the valve and the flow constraint, COFE reports the flowsheet as solved. The lower simulation with its error has been left unchanged and has gone unreported. Any ideas? Thanks.
nrgeng
 
Posts: 239
Joined: 16 February 2013, 12:45
Location: USA

Re: Problem(s) with COCO 3.2

Postby jasper » 25 September 2017, 21:37

I see - please find 3.2.0.17 that fixes that issue.
User avatar
jasper
 
Posts: 1128
Joined: 24 October 2012, 15:33
Location: Spain

Problem(s) with COCO 3.2 {010}

Postby nrgeng » 13 April 2018, 18:26

{Energy Mixer Problem}

Version: COFE 3.2.0.21
High and Low Temperatures are not provided by Energy Streams connected to Units so the Energy Mixer Unit will not solve. The lower loop solves because one of the inlet Energy Streams has its High and Low Temperatures specified. I have emailed an fsd file for your review. I hope this can be fixed.

Note: Please back up the emailed fsd file before attempting to solve it because it cannot be reset.

Energy Mixer Problem (Forum 18Apr 13).png
Document Explorer Display of Energy Mixer Problem
Energy Mixer Problem (Forum 18Apr 13).png (9.52 KiB) Viewed 24091 times
nrgeng
 
Posts: 239
Joined: 16 February 2013, 12:45
Location: USA

Re: Problem(s) with COCO 3.2

Postby jasper » 14 April 2018, 08:37

The energy mixer actually does its works as promised. In case both temperature limits are missing it sets them missing on the product as well.

COFE does not like this as it likes all attributes of the stream to be specified - so it is COFE that raises the error. In case items on a stream remain unspecfied, COFE will be unable to solve recycles in case the stream happens to be a cut stream.

There a number of possible solutions to the issue

1) COFE is modified to just to take into account the work on a stream, and ignore the other data, while solving. This may have as a side effect that the other data (e.g. temperature limits) are not actually converged upon solution, or
2) the energy mixer is modified to put some dummy temperature limits on the product (e.g. [0 K - 1e6 K], or [0 K - 0 K]) when the data are missing (in case of which the feed data is not likely to be originating from a thermal source - in your case it is not). This has the disadvantage that these dummy limits may be taken by the downstream unit as actual limits, or
3) the energy mixer is modified to no longer expose the limits in case they are not present on other of the source streams - this has the disadvantage of added complexity to the unit's logic and changing data on the product stream as a result of connecting / disconnecting a source stream, which may not be taken into account by the downstream unit

I am inclined to go with solution (1) - do you see any issues with this?
User avatar
jasper
 
Posts: 1128
Joined: 24 October 2012, 15:33
Location: Spain

Re: Problem(s) with COCO 3.2

Postby jasper » 14 April 2018, 10:44

I decided to go for

4) add a check box to the energy-mixer (and -splitter) dialog to suppress exposing the temperature limits on the products. If you check this box, your case will work.

As this must be done in Edit mode, there should not be problems with updating the stream. Nevertheless, as energy and information streams are updated upon first connection, I expect there to be cases in which the stream must be disconnected and reconnected.

Let me know if this gives any trouble - the updates are available via CUP.

Also, for the next issue you find, can you start a new topic? This one is getting somewhat lengthy and includes various different issues.
User avatar
jasper
 
Posts: 1128
Joined: 24 October 2012, 15:33
Location: Spain

Previous

Return to COCO (AmsterCHEM)

Who is online

Users browsing this forum: No registered users and 1 guest