Have a couple unit ops written with Cape-open that work fine with COCO and Aspen, but do not load with DWSIM. Is there a known issue with Cape-Open? any suggested work around? I also tried the cape-open excel unit op from AmsterCHEM, and that did not run. The error I receive is
"Error creating CAPE-OPEN Unit Operation: System.NullReferenceException: Object reference not set to an instance f an object. at DWSIM.DWSIM.simulationObjects.UnitOps.CapeOpenUO.Init() in C:\Users\Daniel.....\CapeOPenUO.vb: Line 332
at DWSIM.DWSIM.simulationObjects.UnitOps.CapeOpenUO..ctor(...) in C:\Users\Daniel.....\CapeOPenUO.vb: Line 87"
Last edit: cevans3098 2015-04-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So I think I found the problem. The error was occurring in DWSIM in the following code in CapeOpenUO.vb
If Not _couo Is Nothing Then
Dim myuo As CapeOpen.ICapeUtilities = TryCast(_couo, CapeOpen.ICapeUtilities)
If Not myuo Is Nothing Then myuo.Initialize()
Dim myuo2 As CapeOpen.ICapeIdentification = TryCast(_couo, CapeOpen.ICapeIdentification)
If Not myuo2 Is Nothing Then
If Not Me.GraphicObject Is Nothing Then myuo2.ComponentName = Me.GraphicObject.Tag
If Not Me.GraphicObject Is Nothing Then myuo2.ComponentDescription = Me.GraphicObject.Name
End If
myuo.simulationContext = Me.FlowSheet
End If
I was using the newest capeopen wrapper from Bill Barrett at the EPA. I have an email into him. If I use the CapeOpen.dll from DWSIM (in the references folder), everything works fine. The issue I found with the newest dll from Bill is that the TryCast were both returning nothing in DWSIM.
Dim myuo As CapeOpen.ICapeUtilities = TryCast(_couo, CapeOpen.ICapeUtilities)
TryCast(_couo, CapeOpen.ICapeUtilities) returned nothing
Dim myuo2 As CapeOpen.ICapeIdentification = TryCast(_couo, CapeOpen.ICapeIdentification)
TryCast(_couo, CapeOpen.ICapeIdentification) returned nothing
Last edit: cevans3098 2015-04-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Did he send you another DLL? The one I'm using he sent me some time ago, because the official one wasn't working with .NET 4.0, and he helped me to get it working with DWSIM. Check if your UO still works with COCO and Aspen after updating the library.
The DLL in DWSIM has no C++ bindings, it is pure, 100% managed code. Some earlier versions had a few C++/CLI code parts that caused an error when saving simulations with CAPE-OPEN UOs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I spoke with Bill today and he believes you are still using version 1. I downloaded V2 from the EPA website and it worked with COCO and Aspen, but not with DWSIM. Here is his email to me:
I’m glad you got it to work.
I incremented the assembly version, and I gave them one with version 2. They have one that is version 1.0 in their application folder, but still has an EPA 2011 copyright date, when I look at it’s details.
CAPE-OPEN should be releasing a Primary Interop Assembly soon. This should resolve these issues.
Bill
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am receiving another error when trying to save a worksheet with a cape-open object. When I hit the save button, an critical error box pops up with the message:
Object reference not set to an instance of an object
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The error only occurs with my UO using V1 from the EPA. I have not implemented a persistence interface in my UO. Do I need to do this? is this a CapeOpen interface or something different?
Craig
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It is an interface for the saving/loading process, described in the CAPE-OPEN standards. It shouldn't break the saving process if you don't have it implemented, though. I'll take a look at it tonight.
I did some further debugging and in overloads sub InitNew() on line 300 myuo is also nothing
When I look at the cape-open object _cuco, I do not see any access to IPersistStreamInit.
Edit: 2pm PST
I just received an email from Bill Barrett from the EPA regarding his wrapper. Here is the what he says
Craig,
I had them in there at one point, but commented them out. I don’t remember why, but it may have been that I was never able to properly use them and COCO restored the unit operations without them anyway. COCO would create a new instance, reconnect the streams to the ports, and return the parameters to their prior values when it loaded the flowsheet.
On the .NET side, there was no need for them either as you could just serialize the flowsheet using either a binary, XML or JASON serializer.
Without digging much deeper, the Dim line implies that they are treating _couo as a COM object, not a .NET one. I am attaching the persistence interfaces I had used before. IsDirty returns S_OK or S_FALSE.
Bill
If Bill's wrapper is the issue - does anyone have a .net example of a cape-open UO that works with both DWSIM, COCO and ASPEN?
Craig
Last edit: cevans3098 2015-04-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If the Unit Operation doesn't implement any of the IPersist interfaces, the _istr variable will be null. The Object will have to be restored using the parameters and ports stored information only.
_instr leaves this module as nothing because it can not be cast to IPersistStreamInit or IPersistStream
Craig
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is a problem on DWSIM's side indeed, regarding the saving/loading process when _istr is null, which I'll fix in a minute.
Regarding Bill's library, I couldn't download v2 from USEPA website, but I have it installed here because of COCO I guess. I'll try to use it in DWSIM and if everything goes OK I'll update the reference accordingly.
Regards,
Daniel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I saw that also today, I tried changing the cape-open reference in DWSIM to V2.0 and saw all those same errors... I quickly changed it back. I didn't know if that was me or Bill's changes. Glad you saw the same thing.
Let me know how I can help
Craig
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The library is now more elegant, with more well-defined types instead of the generic "objects". I just commited the updated code to GitHub but didn't test my modifications yet, can you test them there?
You were getting the errors because almost all functions and procedures have a different signature in v2. If you change the type of a single argument of a function which implements an interface procedure, .NET doesn't recognize it as implemented anymore and then you'll get nothing.
Daniel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have been using the version of CapeOpen (V1) shipped with DWSIM for a while now since it appear V2 would require a bigger fix. Did you make any changes to the code to resolve the saving/loading process when _istr is null?
Craig
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I reverted these changes as soon as I found the new library unusable.
With these changes, DWSIM compiled without errors, but you won't be able to use CAPE-OPEN with it because it is like the interfaces weren't implemented in Bill's library. For instance, DWSIM can't find the basic "ICapeUtilities" interface in any CAPE-OPEN UO by trying to cast the COM object to ICapeUtilities as defined in Bill's library, and that's the first one it tries to find during the initialization procedure. The same code works just fine with v1. I don't know about the rest of the interfaces, but a property package manager failed to initialize also because of a missing interface.
Very strange.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess we'll have to speak with Bill about it. He did mention that he believed the problem was that DWSIM was treating things as a COM object and not a .net object. I'll inquire more and see if I can get more details from him.
Craig
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That might be the problem. If that's the case then I won't upgrade, because I can't have different code parts to handle different types of CAPE-OPEN objects... everything is working fine so far, I don't see a reason to change it.
If the interface is correctly implemented by a component then it can be used in DWSIM normally as of now.
v1 works very, very well with every CAPE-OPEN object I've tested so far, including all UOs in COCO, TEA, ChemSep, some proprietary components, etc. I don't see a reason to change it now, specially when taking into account that CO-LaN is about to release an official Interop Library as Bill wrote himself...
What are the advantages of v2 when comparing to v1 when used in your code? Do you have to change a big amount of code in order to use v1?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I spoke too soon - my UOs are not working - numerous issues I think. I even tried using one of Bill's MixerExample11.vb example, to see if I could narrow down the issues, but that does not work either.
Do you have any source code for a a mixer example or a similar UO that you know works I could review? I can also send you my COUO code if you'd like to see it. All I have is a material inlet and a material outlet
Craig
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Have a couple unit ops written with Cape-open that work fine with COCO and Aspen, but do not load with DWSIM. Is there a known issue with Cape-Open? any suggested work around? I also tried the cape-open excel unit op from AmsterCHEM, and that did not run. The error I receive is
"Error creating CAPE-OPEN Unit Operation: System.NullReferenceException: Object reference not set to an instance f an object. at DWSIM.DWSIM.simulationObjects.UnitOps.CapeOpenUO.Init() in C:\Users\Daniel.....\CapeOPenUO.vb: Line 332
at DWSIM.DWSIM.simulationObjects.UnitOps.CapeOpenUO..ctor(...) in C:\Users\Daniel.....\CapeOPenUO.vb: Line 87"
Last edit: cevans3098 2015-04-20
So I think I found the problem. The error was occurring in DWSIM in the following code in CapeOpenUO.vb
I was using the newest capeopen wrapper from Bill Barrett at the EPA. I have an email into him. If I use the CapeOpen.dll from DWSIM (in the references folder), everything works fine. The issue I found with the newest dll from Bill is that the TryCast were both returning nothing in DWSIM.
Dim myuo As CapeOpen.ICapeUtilities = TryCast(_couo, CapeOpen.ICapeUtilities)
TryCast(_couo, CapeOpen.ICapeUtilities) returned nothing
Dim myuo2 As CapeOpen.ICapeIdentification = TryCast(_couo, CapeOpen.ICapeIdentification)
TryCast(_couo, CapeOpen.ICapeIdentification) returned nothing
Last edit: cevans3098 2015-04-21
Did he send you another DLL? The one I'm using he sent me some time ago, because the official one wasn't working with .NET 4.0, and he helped me to get it working with DWSIM. Check if your UO still works with COCO and Aspen after updating the library.
The DLL in DWSIM has no C++ bindings, it is pure, 100% managed code. Some earlier versions had a few C++/CLI code parts that caused an error when saving simulations with CAPE-OPEN UOs.
I spoke with Bill today and he believes you are still using version 1. I downloaded V2 from the EPA website and it worked with COCO and Aspen, but not with DWSIM. Here is his email to me:
I’m glad you got it to work.
I incremented the assembly version, and I gave them one with version 2. They have one that is version 1.0 in their application folder, but still has an EPA 2011 copyright date, when I look at it’s details.
CAPE-OPEN should be releasing a Primary Interop Assembly soon. This should resolve these issues.
Bill
Daniel
I am receiving another error when trying to save a worksheet with a cape-open object. When I hit the save button, an critical error box pops up with the message:
Object reference not set to an instance of an object
I'll try V2 ASAP then. Regarding the error while saving, did it occur with any CO UO or with yours only? Did you implement the persistence interfaces?
Regards,
Daniel
Daniel,
The error only occurs with my UO using V1 from the EPA. I have not implemented a persistence interface in my UO. Do I need to do this? is this a CapeOpen interface or something different?
Craig
Hi Craig,
It is an interface for the saving/loading process, described in the CAPE-OPEN standards. It shouldn't break the saving process if you don't have it implemented, though. I'll take a look at it tonight.
You can take a look at my implementation for the script UO here (lines 718 to 807): https://github.com/DanWBR/dwsim3/blob/master/DWSIM/Objects/UnitOps/CustomUO.vb
Daniel
Daniel,
So I did some further debugging and the error is save error is occurring in the CapeOpenUO.vb line 874
(https://github.com/DanWBR/dwsim3/blob/master/DWSIM/Objects/UnitOps/CapeOpenUO.vb)
_istr is nothing
I did some further debugging and in overloads sub InitNew() on line 300 myuo is also nothing
When I look at the cape-open object _cuco, I do not see any access to IPersistStreamInit.
Edit: 2pm PST
I just received an email from Bill Barrett from the EPA regarding his wrapper. Here is the what he says
Craig,
I had them in there at one point, but commented them out. I don’t remember why, but it may have been that I was never able to properly use them and COCO restored the unit operations without them anyway. COCO would create a new instance, reconnect the streams to the ports, and return the parameters to their prior values when it loaded the flowsheet.
On the .NET side, there was no need for them either as you could just serialize the flowsheet using either a binary, XML or JASON serializer.
Without digging much deeper, the Dim line implies that they are treating _couo as a COM object, not a .NET one. I am attaching the persistence interfaces I had used before. IsDirty returns S_OK or S_FALSE.
Bill
If Bill's wrapper is the issue - does anyone have a .net example of a cape-open UO that works with both DWSIM, COCO and ASPEN?
Craig
Last edit: cevans3098 2015-04-22
Daniel,
It looks like the issue has been previously identified. but I'm not sure the fix was implemented properly. Bill alluded to it in his email.
In the <OnSerializing()> Sub PersistSave rountine, line 222
https://github.com/DanWBR/dwsim3/blob/master/DWSIM/Objects/UnitOps/CapeOpenUO.vb
there is a comment
If the Unit Operation doesn't implement any of the IPersist interfaces, the _istr variable will be null. The Object will have to be restored using the parameters and ports stored information only.
_instr leaves this module as nothing because it can not be cast to IPersistStreamInit or IPersistStream
Craig
Hi Craig,
There is a problem on DWSIM's side indeed, regarding the saving/loading process when _istr is null, which I'll fix in a minute.
Regarding Bill's library, I couldn't download v2 from USEPA website, but I have it installed here because of COCO I guess. I'll try to use it in DWSIM and if everything goes OK I'll update the reference accordingly.
Regards,
Daniel
Oh my God, Bill changed EVERYTHING... haha :-(
Daniel,
I saw that also today, I tried changing the cape-open reference in DWSIM to V2.0 and saw all those same errors... I quickly changed it back. I didn't know if that was me or Bill's changes. Glad you saw the same thing.
Let me know how I can help
Craig
The library is now more elegant, with more well-defined types instead of the generic "objects". I just commited the updated code to GitHub but didn't test my modifications yet, can you test them there?
You were getting the errors because almost all functions and procedures have a different signature in v2. If you change the type of a single argument of a function which implements an interface procedure, .NET doesn't recognize it as implemented anymore and then you'll get nothing.
Daniel
It seems it is not working at all with TEA, maybe I'll have to revert my changes...
The new library isn't working at all. I've reverted my changes and you should probably use v1 that ships with DWSIM because it also works elsewhere.
Daniel,
I have been using the version of CapeOpen (V1) shipped with DWSIM for a while now since it appear V2 would require a bigger fix. Did you make any changes to the code to resolve the saving/loading process when _istr is null?
Craig
Hi Craig,
I've uploaded a fix to GitHub, can you try it?
Thanks,
Daniel
Daniel,
Looks like it is working - thanks for the help. Do you have plans to upgrade to V2.0?
Craig
Hi Craig,
I did upgrade to v2 last night but nothing was working anymore. You can try it if you want: https://github.com/DanWBR/dwsim3/commit/3c115916d9c3af1f2fd42b78aeb8d69a7fa214be
I reverted these changes as soon as I found the new library unusable.
With these changes, DWSIM compiled without errors, but you won't be able to use CAPE-OPEN with it because it is like the interfaces weren't implemented in Bill's library. For instance, DWSIM can't find the basic "ICapeUtilities" interface in any CAPE-OPEN UO by trying to cast the COM object to ICapeUtilities as defined in Bill's library, and that's the first one it tries to find during the initialization procedure. The same code works just fine with v1. I don't know about the rest of the interfaces, but a property package manager failed to initialize also because of a missing interface.
Very strange.
Daniel,
I guess we'll have to speak with Bill about it. He did mention that he believed the problem was that DWSIM was treating things as a COM object and not a .net object. I'll inquire more and see if I can get more details from him.
Craig
That might be the problem. If that's the case then I won't upgrade, because I can't have different code parts to handle different types of CAPE-OPEN objects... everything is working fine so far, I don't see a reason to change it.
If the interface is correctly implemented by a component then it can be used in DWSIM normally as of now.
v1 works very, very well with every CAPE-OPEN object I've tested so far, including all UOs in COCO, TEA, ChemSep, some proprietary components, etc. I don't see a reason to change it now, specially when taking into account that CO-LaN is about to release an official Interop Library as Bill wrote himself...
What are the advantages of v2 when comparing to v1 when used in your code? Do you have to change a big amount of code in order to use v1?
Daniel,
I am fine using V1.0, my UO are compatible with V1 and V2. I wasn't aware of the change that was made until I changed over to V2.
Everything appears to be working perfect now. Thanks so much for your help.
Craig
That's good news then. Let me know if you need more help or find a bug somewhere in DWSIM. :-)
Regards,
Daniel
Daniel,
I spoke too soon - my UOs are not working - numerous issues I think. I even tried using one of Bill's MixerExample11.vb example, to see if I could narrow down the issues, but that does not work either.
Do you have any source code for a a mixer example or a similar UO that you know works I could review? I can also send you my COUO code if you'd like to see it. All I have is a material inlet and a material outlet
Craig