COLTT influences Unit Operation behaviour?

[greTol]

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).

[jasper]

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?

[greTol]

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.

[jasper]

[greTol]

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 (55.34 KiB) Viewed 17910 times

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

I will send the source files via email.

[jasper]

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).