COLTT influences Unit Operation behaviour?

COLTT influences Unit Operation behaviour?

Postby greTol » 03 July 2015, 15:54

I created a Unit Operation (MixerSplitter ;) ) in Visual Studio without ATL and registered it using the command shell and regsvr32. When adding this unit operation to a flowsheet in COFE, the behaviour changes depending on if I select 'Enable Logging' in COLTT 2.2 or not.

In case I DO select 'Enable Logging', I can add my unit operation, connect streams, the unit validates, and at last the flowsheet fails during the calculation (COFE error message: "Solve failed:failed to solve unit UnitOperation_2: calculate failed for unit UnitOperation_2: PH flash calculation failed: CalcEquilibrium failed: CalcEquilibrium failed: CalcEquilibrium failed:Invalid flash specification: Unsupported flash specification 2").

When I DO NOT select 'Enable Logging' and try to add my unit operation, COFE32 immediately crashes without any error message.

Is there an explanation for this change in behaviour?
What can I learn from this regarding my implementation of the unit operation?

If it helps investigating, I can provide COLTT log files, make a desktop video, deliver the dll or even send the source code (MS Visual Studio project).
Last edited by greTol on 08 July 2015, 08:44, edited 1 time in total.
greTol
 
Posts: 20
Joined: 26 August 2013, 14:45

Re: COLTT influences Unit Operation behaviour?

Postby jasper » 06 July 2015, 07:57

Can you attach the COLLT log?

From your message I would think there is a problem with the flash specification. Can you post the code that creates the flash specification?
User avatar
jasper
 
Posts: 1128
Joined: 24 October 2012, 15:33
Location: Spain

Re: COLTT influences Unit Operation behaviour?

Postby greTol » 08 July 2015, 08:44

I attached a COLTT log file that was recorded when 'solve' failed.

In the other file, the calculate function of this mixerSplitter unit can be found. It is basically a copy of the function I got from the COLaN example.
Attachments
calculateUnitOperation.zip
calculate() function of the unit operation implementation (UnitOperation.cpp)
(2.46 KiB) Downloaded 888 times
cofe_070315_152756.zip
coltt log file: inserting unit operation in COFE, connecting streams, run flowsheet
(21.74 KiB) Downloaded 890 times
greTol
 
Posts: 20
Joined: 26 August 2013, 14:45

Re: COLTT influences Unit Operation behaviour?

Postby jasper » 08 July 2015, 09:13

The log only contains the validation step, no calculation step. So I cannot see too much from there.

Can you send me the implementations of

GetTemperatureFromPHFlash

and

SetFromFlowTPX

I am not sure which is the failing flash, as I do not have a log on that; are these also copies from the CO-LaN example? The CO-LaN example does not give this error though... The first one is

Code: Select all
      //generate flash specifications
      CVariant flashSpec1,flashSpec2;
      CBSTR overall(L"overall");
      //flash specification 1: overall enthalpy
      flashSpec1.MakeArray(3,VT_BSTR);
      flashSpec1.AllocStringAt(0,L"enthalpy");
      flashSpec1.SetStringAt(1,NULL);
      flashSpec1.SetStringAt(2,overall);
      //flash specification 2: overall pressure
      flashSpec2.MakeArray(3,VT_BSTR);
      flashSpec2.AllocStringAt(0,L"pressure");
      flashSpec2.SetStringAt(1,NULL);
      flashSpec2.SetStringAt(2,overall);
      //perform PH flash
      hr=iEqRoutine->CalcEquilibrium(flashSpec1,flashSpec2,CBSTR(L"unspecified"));


for which the flash specifications look ok. The second one reads

Code: Select all

      //generate flash specifications
      CVariant flashSpec1,flashSpec2;
      CBSTR overall(L"overall");
      //flash specification 1: overall temperature
      flashSpec1.MakeArray(3,VT_BSTR);
      flashSpec1.AllocStringAt(0,L"temperature");
      flashSpec1.SetStringAt(1,NULL);
      flashSpec1.SetStringAt(2,overall);
      //flash specification 2: overall pressure
      flashSpec2.MakeArray(3,VT_BSTR);
      flashSpec2.AllocStringAt(0,L"pressure");
      flashSpec2.SetStringAt(1,NULL);
      flashSpec2.SetStringAt(2,overall);
      //perform TP flash
      hr=iEqRoutine->CalcEquilibrium(flashSpec1,flashSpec2,CBSTR(L"unspecified"));



which also looks ok. Alternatively, send me your entire code (perhaps removing the pieces that are IP sensitive) and I can have a look.

Thanks.
User avatar
jasper
 
Posts: 1128
Joined: 24 October 2012, 15:33
Location: Spain

Re: COLTT influences Unit Operation behaviour?

Postby greTol » 08 July 2015, 12:50

I corrected the code that creates the flash specification, it is not causing errors anymore.
But that does not change the general behaviour:
If I let COLTT log my UnitOperation, I can solve the flowsheet (COFE32 and COFE64, COLTT log attached).
Without logging, the flowsheet immediately crashes when trying to add the UnitOperation (COFE32) or error messages appear and it is not possible to connect streams (COFE64).
For the latter case I attached screenshots.
COFE64_no_rpc_server.png
COFE64_no_rpc_server.png (55.34 KiB) Viewed 17851 times


My initial question remains:
Is there an explanation why the behaviour depends on the logging?

I will send the source files via email.
Attachments
gooop32_070815_141130.zip
COLTT log, COFE32 COFE64, solve UnitOperation
(8.01 KiB) Downloaded 905 times
COFE64_outstanding_references.png
COFE64_outstanding_references.png (18.67 KiB) Viewed 17851 times
greTol
 
Posts: 20
Joined: 26 August 2013, 14:45

Re: COLTT influences Unit Operation behaviour?

Postby jasper » 08 July 2015, 14:11

The crash is due to the port and parameter collections being destroyed, but they are static class members. They have an initial reference count of zero, and the reference could should be increased.

A simple solution is to AddRef both of these collections in the unit operation constructor.

The initial reference count in an earlier version of the wizard was 1 on COM objects. I have changed that to zero, so that they can be immediately assigned to smart pointers, without tricks like Attach. A quick scan on your objects: this will be a problem for the objects (materials, parameters) that you add to the collections (the collection in your project does not keep a reference count on its members).

So the nicer solution: switch to the new collection object generated by the wizard. And use COMSmartPtr objects instead of direct pointers.

I see you commented out the AddRef in the get_parameters and get_ports; this will surely lead to a crash as well. They will be Released() by the software that makes the call.

May I suggest you generate a new project with the wizard? If you add a unit operation to the project, it will ask you to generate a unit operation frame-work. This will be nicer than what you have now, a much better starting point. The collection issues will be solved. There is example code on how to create ports and parameters in the generated unit operation code. Validate will be partially implemented. And I do not think re-doing your Calculate is a lot of work (compared to fixing what you have now).
User avatar
jasper
 
Posts: 1128
Joined: 24 October 2012, 15:33
Location: Spain


Return to Unit Operations

Who is online

Users browsing this forum: No registered users and 2 guests

cron