09-015 gOCAPE-OPEN in Aspen Plus

[michelpons]

De: Michel Pons [technologyofficer@…]
Envoyé: Tuesday, September 08, 2009 9:09 AM
À: 'Michael Halloran'; 'Ahsan Akhtar'
Objet: RE: Status of work on COLTT

Michael,

I will send you through yousendit.com the log file named apmain_082009_125534.log that was the last one made by Ahsan on August 20.

Best regards

Michel
============================================================
De: Michel PONS via YouSendIt [delivery@…]
Envoyé: Tuesday, September 08, 2009 9:08 AM
À: technologyofficer@…
Objet: File Sent: apmain_082009_125534.zip

youSENDit File Sent
Thank you for trusting YouSendIt to send your important files.
Want to send and track multiple files at once?

Upgrade Now

.......................................................................................................................................................................................................................

File sent: apmain_082009_125534.zip
Recipients sent to: michaeljhalloran@…
File will be stored for: 7 days

Link to file:
​http://download.yousendit.com/cmcxM25La0Q5bEJjR0E9PQ

YouSendIt Inc. | Terms of Service | Privacy Policy | DMCA Policy | Opt Out

1919 S. Bascom Avenue, 3rd Floor Campbell, CA 95008

=============================================================
De: Michael Halloran [michaeljhalloran@…]
Envoyé: Monday, September 07, 2009 11:23 PM
À: Ahsan Akhtar
Cc: Michel Pons
Objet: Re: Status of work on COLTT
Hi Ahsan,

Sorry I must have missed this reply somehow. Thanks for resending it today.

Michel, do you have a log for the same run using 1.08.2 with Ahsan's fix applied? I'd like to compare it to the 1.08.2 log that you originally sent.

Regards
Michael
==========================================================
De: Ahsan Akhtar [ahsan.akhtar@…]
Envoyé: Monday, September 07, 2009 9:25 AM
À: 'Michael Halloran'; 'Michel Pons'
Cc: 'Malcolm WOODMAN'
Objet: RE: Update

Pièces jointes: Status of work on COLTT (42.8 Ko)

Michael,

I am enclosing my email that I sent to you last Saturday explaining the issue of Aspen Plus (from your email, it looks that you haven't received my email).

Regards

Ahsan
==========================================================
De: Michael Halloran [michaeljhalloran@…]
Envoyé: Sunday, September 06, 2009 6:25 PM
À: Michel Pons; Ahsan Akhtar
Cc: Malcolm WOODMAN
Objet: Update
Michel, Ahsan,

I have committed all my changes - a lot of files updated because of changes to 1) output so that searching for \"error\" only finds actual errors and 2) changes to a lot of header files to remove the causes of complier warnings, so that the build is much cleaner now. I've also updated the solution files and project files, again to clean up the build but to also get the release and debug build configurations correct for building from SourceForge.

One consequence of my changes is that it is not so easy to compare a 1.07 file with a file produced from this version automatically - it shows too many differences because many lines of output have changed. It's still reasonable to do by eye I think.

I have not committed my change for the persistence interface logger. I have tested with COFE and it seems correct but I would like to hear from Ahsan about the Aspen Plus problem first.

I have uploaded the two license files to a new folder called Documentation. Ahsan, these two files have changed since the last .msi was created so the next .msi will need to include these versions.

I have started using the TRAC system on SourceForge for recording issues, as we discussed. I've entered the last four that you sent Michel. You can find it here:

​https://sourceforge.net/apps/trac/cape-openloggin/

Select the View Tickets link and then the Active Tickets report to see the list. All the attachments are uploaded as well.

Michel, if you can put future issues in here as well, I'm sure we can arrange for email notifications to be sent. I got them for these four but perhaps that's because I was the raiser. We need to consider whether we want to put of the other already known issues in as well or whether we just start with these 4.

I'll send instructions on AnkhSVN shortly. It seems to be working pretty well so far.

Regards
Michael
=========================================================
De: Ahsan Akhtar [ahsan.akhtar@…]
Envoyé: Saturday, September 05, 2009 7:32 AM
À: 'Michael Halloran'
Cc: 'Michel Pons'
Objet: RE: Status of work on COLTT

Michael,

Before answering your query about commenting out the Release call, I would like to mention that I myself was not satisfied with this solution (although it fixed the issue 09-015) and that's why I told Michel during the PCNow session that I would need to discuss it further with Michael for its correctness. Sorry for not discussing the issue before committing the code on sourceforge (I should do it as I also spoke to Michel regarding this fix).

I commented out the line \"reinterpret_cast<IPersistStreamInit*>(*ppv)->Release();\" because I noticed that call to InitNew was not present in the log file generated by COLTT despite the fact that COLTT was executing the code block which was returning the pointer to IPersistStreamInit interface. I assumed that COLTT is causing a premature release of IPersistStreamInit interface.To confirm my assumption, I commented out all the code which was caching the IPersistStreamInit pointer returned by QueryInterface except the following two lines:

if (!(((CIPersistST*)pv)->m_pIPersistStreamInit))

hr = ((CIPersistST*)pv)->m_pUnkLoggedComponent->QueryInterface(IID_IPersistStreamInit, ppv);

i.e. I left the code un-commented which was QueryInterface IPersistStreamInit on actual logged component and it worked fine. Then I un-commented all the code except the line with release function call and it also worked fine.I think this is PME (AspenPlus) not release call which is causing reference count issue because the current logic was working fine with other cases as well and also according to COM rules (but I can't explain it as I was not able to debug the case).

Please also note that I was not able debug the case in VS2008 and I used message lines to debug the code. I also tried your advice to debug the case which I received in one of your earlier emails.

Your revised logic is correct and the previous logic had a defect that you mentioned in your email.

Please let me know if I have clarified my point clearly or not?

Ahsan
=========================================================
De: Ahsan Akhtar [ahsan.akhtar@…]
Envoyé: Thursday, September 03, 2009 10:36 AM
À: 'Michael Halloran'
Cc: 'Michel Pons'
Objet: RE: Status of work on COLTT

Michael,

I will send you response to this email tomorrow morning, God willing.

Regards

Ahsan
==========================================================
De: Michel Pons [technologyofficer@…]
Envoyé: Thursday, September 03, 2009 8:32 AM
À: 'Michael Halloran'; 'Ahsan Akhtar'
Objet: RE: Status of work on COLTT

Michael, Ahsan,

I must admit I have some difficulties understanding the logic and reading the code. The only help I can provide is in making tests of any proposed modification. But for this I would need a build of the new COLTT.

For the additional time, my impression is that SHMA can safely spend some additional hours. CO-LaN will pay for these according to the communication I saw from Ray Dickinson, CO-LaN’s president.

Best regards

Michel
=======================================================
De: Michael Halloran [michaeljhalloran@…]
Envoyé: Wednesday, September 02, 2009 10:26 PM
À: Ahsan Akhtar
Cc: Michel Pons
Objet: Re: Status of work on COLTT
Hi Ahsan,

Thanks for committing the file. I have had a look and I still don't think the logic in COMQuery is right.

I think that if m_pIPersistStream is undefined then the code must call QueryInterface, and if that call succeeds then it must store the returned pointer but also release it because the assignment to m_piPersistStream will cause an additional AddRef call - at least by my reading of the code for CCOMPtr in atlcomcli.h. If m_pIPersistStream is defined then the code should only return the logger interface appropriately addref'd. If m_IPersistStream is undefined and the call to QueryInterface fails then the code should return whatever the QI call returned for ppv.

With the logic done this way, the release call that you commented out would only be called once and the assignment to m_pIPersistStream would only be called once no matter how many times COMQuery gets called for IPersistStream. I think that's correct. So this is what I think the code should look like:

static HRESULT WINAPI COMQuery(void *pv, REFIID iid, LPVOID *ppv, DWORD dw)
{
ObjectLock lock(((CIPersistST*)pv));
HRESULT hr = S_OK;
char MsgBuffer[256] = \"\";

if (iid == IID_IPersistStream)
{
if (!(((CIPersistST*)pv)->m_pIPersistStream))
{
the QueryInterface call to the logged component sets ppv directly...
hr = ((CIPersistST*)pv)->m_pUnkLoggedComponent->QueryInterface(IID_IPersistStream, ppv);
if (SUCCEEDED(hr))

{

if the call succeeds then we don't actually want to return the current value of ppv so
cache the interface pointer returned by the QueryInterface call for use by the logger later.
(((CIPersistST*)pv)->m_pIPersistStream) = static_cast<IPersistStream*>(*ppv);

No need to AddRef ppv here because the QueryInterface call should have done that...
...but since m_pIPersisitStream AddRefs automatically because it is a smart pointer then we need to add:
reinterpret_cast<IPersistStream*>(*ppv)->Release();

}

}

if (SUCCEEDED(hr))

{

the normal case: either the QI call succeeded or m_pIPersistStream already had a value from a previous call...

Now substitute the logger's implementation of the requested interface instead

*ppv = static_cast<IPersistStream*>(((CIPersistST*)pv));

AddRef the logger's interface
reinterpret_cast<IPersistStream*>(*ppv)->AddRef();
((CIPersistST*)pv)->c_iid = iid;

}
else
{
This case will only happen if the QueryInterface call above failed...
in this case ppv is equal to whatever the QueryInterface call to the logged component returned...
...which is what a failed QueryInterface call to a logger should return
((CIPersistST*)pv)->c_iid = IID_NULL;
sprintf(MsgBuffer,\"%s : IPersistStream is not supported in the logged component\", ((CIPersistST*)pv)->m_sName.c_str());
}
}
else if (iid == IID_IPersistStreamInit)

I think it's important to get this right because we could be introducing a reference counting issue, and the logic used for persistence interfaces is used again for error interfaces, so if persistence is wrong then so are errors.

There's one thing I don't understand: in the original code, if m_pIPersistStream is defined when COMQuery is called then the code would assign the ppv passed into the call to m_pIPersistStream, which would overwrite the original ppv returned from QueryInterface in a previous call, then it would call release on that ppv. I think it should crash at this point because ppv is not going to be a valid IPersistStream interface pointer when the release call is made.

To help me understand this, and to help decide whether the revised logic I've described above is correct, can you explain more about why commenting out the Release call fixed the problem? I think the effect of not releasing this pointer at all is that there will be an outstanding reference count on the logged component at the end of a run which will look like a memory leak. Commenting out the Release call also doesn't address the problem that if the first call to COMQuery correctly sets m_pIPersistStream, a second call will overwrite it with an invalid interface pointer.

I'm aware that you are already over budget on the 150 hours block of work and I will try to reproduce the problem myself using coco, but I would appreciate any help you can provide and please record any time you spend on it so that we can reconcile it later.

Note that I have not cc'd this to Anjum and Malcolm because it is very technical, but please feel free to forward it if necessary.

Regards
Michael
========================================================
De: Ahsan Akhtar [ahsan.akhtar@…]
Envoyé: Tuesday, September 01, 2009 10:18 AM
À: 'Michael Halloran'; anjum.raheel@…
Cc: 'Woodman, Malcolm'; 'Michel Pons'
Objet: RE: Status of work on COLTT

Michael,

I have uploaded the IPersistST.h file on sourceforge that I changed to fix the bug in case of goCO with AspenPlus.

Regards

Ahsan
============================================================
De: Michael Halloran [michaeljhalloran@…]
Envoyé: Monday, August 31, 2009 6:28 PM
À: Ahsan Akhtar; anjum.raheel@…
Cc: Woodman, Malcolm; Michel Pons
Objet: Re: Status of work on COLTT
Hi Ahsan, Anjum,

Thanks for your efforts over the last three months dealing with these issues. I have not seen any commits to SourceForge from SHMA since Ahsan's last commit on July 30th. I think there is at least one change outstanding - the fix for the problem with gCO in Aspen Plus - and maybe there are others as well. Even though you are already over the 150 hours allocation could I ask that you commit all outstanding changes to SourceForge so that we have access to the latest version of the source code? I have a large number of changes outstanding myself because I have changed the content of entries written to the log in order to make it easier to find real errors. I would like to commit these fixes but because so many files have changed I would rather do it after your commit so that I can merge the changes together.

When Malcolm returns I'm sure we will find a resolution for the extra hours and for the small additional amount that I expect would be required to do the commit.

Regards
Michael
==================================================
De: Michel Pons [technologyofficer@…]
Envoyé: Tuesday, August 11, 2009 9:45 AM
À: 'Ahsan Akhtar'
Objet: RE: COLTT 09-015

Ahsan,

I am not in my office on Wednesday and till Friday afternoon, leaving in fact late this afternoon for a business trip. How about next week?

Best regards

Michel
==========================================================
De: Michel Pons [technologyofficer@…]
Envoyé: Thursday, August 20, 2009 1:10 PM
À: 'Michael Halloran'
Cc: 'malcolm.woodman@…'
Objet: COLTT 09-015

Michael,

Ahsan has just finished a remote session on the CO-LaN laptop that apparently led to the resolution of the problem labeled 09-015 (gO:CAPE-OPEN in Aspen Plus). I was able to run the case with COLTT enabled on the gO:CAPE-OPEN UO. Ahsan told me that the issue was about reference counting. I can’t tell which lines of code were modified. Ahsan wants to discuss the issue with you. He thinks other parts of the code need to be modified as well. The modifications have not been committed to SourceForge.

Best regards

Michel
===========================================================
De: Michel Pons [technologyofficer@…]
Envoyé: Wednesday, August 19, 2009 12:12 PM
À: 'Michael Halloran'; 'Ahsan Akhtar'
Objet: RE: Debugging Issue

Ahsan,

Do you feel another remote session on the CO-LaN laptop is worth setting up this week, following the info supplied by Michael ?

Best regards

Michel
===========================================================
De: Michael Halloran [michaeljhalloran@…]
Envoyé: Wednesday, August 19, 2009 9:43 AM
À: Ahsan Akhtar
Cc: Michel Pons
Objet: Re: Debugging Issue

Ahsan,

The simplest explanation is that the .pdb file you are using does not match the CoLoggersSt.dll that is being run in Aspen Plus. Can you check in the Visual Studio output window that when CoLoggersST.dll is loaded it is the DLL that you expect to be loaded i.e. it is in the right location, and that VIsual Studio reports that the debug symbols have been loaded. If both of those are correct then the problem is likely to be that the source code does not match the DLL and PDB files.

Another way to force a break is to add the line _asm{int 3}; into the code where you want to start debugging. If that doesn't work you know that the DLL you expect to be loaded is not being loaded.

Regards
Michael
============================================================
De: Ahsan Akhtar [ahsan.akhtar@…]
Envoyé: Wednesday, August 19, 2009 6:27 AM
À: 'Michael Halloran'
Cc: 'Michel Pons'
Objet: Debugging Issue

Michael,

Yesterday , I had a PCNow session on COLaN laptop. During the session, I was able to run the case in Debug mode (i.e. I could attach the PME EXE with VS and could run the application in debug mode) but couldn't debug the case as VS didn't stop at debug break point. I used the same code that I use here at SHMA (which is also uploaded on SF). Please also note that and I can debug code at SHMA using COFE without any problem.

Here is the sequence of steps that I performed to debug the case:

1. Uploaded the source code from SHMA on the COLaN laptop
2. Compiled the code in VS2008
3. Put the break point in the PersistenceLogger
4. Attached AspenPlus EXE with VS2008 and run the application in debug mode
5. Loaded the case file in AspenPlus and placed the goCape-Open unit operation in the flowsheet
6. COLTT generated the log file where I could see a line saying that IPersistStorage is not supported which also means that code executed which I intended to debug

but VS didn't stop at the break point.

Can you please give some advice on this problem. I can found only two differences between the two environments:

1. I had VS 2008 Professional Edition on my machine whereas COLaN laptop has VS 2008 Standard edition
2. I had English version of VS where COLaN laptop has French version.

Best Regards

Ahsan
=====================================================
De: Michel Pons [technologyofficer@…]
Envoyé: Tuesday, August 18, 2009 7:40 AM
À: 'Michael Halloran'
Cc: 'Ahsan Akhtar'; 'malcolm.woodman@…'
Objet: RE: COLTT 09-015

Michael,

I have now a virtual machine set up with Aspen Plus 7.1CP1, gPROMS 3.1.5, Visual Studio 2008 : Ahsan has positioned a remote debugging session this morning on the CO-LaN laptop for issue 09-015.

Best regards

Michel
=======================================================
De: Michael Halloran [michaeljhalloran@…]
Envoyé: Monday, August 17, 2009 11:27 PM
À: Michel Pons
Cc: Ahsan Akhtar; malcolm.woodman@…
Objet: Re: COLTT 09-015
Michel,

It seems to me that the problem is that with the 1.08.2 logger, the request to get the IPersistStorage interface fails and as a consequence the InitNew call is not made. I suspect the dialog that you don't see is invoked from InitNew rather than initialise. I can't tell from the code why the Query for IPersistStorage should fail, but this code has changed between 1.08.2 and 1.,07. I think Ahsan will need to debug this on your laptop to see what the PersistenceLogger is doing when asked for this interface.

regards
Michael
=========================================================
De: Michel Pons [technologyofficer@…]
Envoyé: Friday, August 14, 2009 5:14 PM
À: 'Michael Halloran'
Cc: 'Ahsan Akhtar'; 'malcolm.woodman@…'
Objet: RE: gO:CAPE-OPEN in Aspen Plus

Michael,

I resent the logfile you asked for through yousendit.com since it may have been blocked by your firewall. With 1.08.02 enabled on the gO:CAPE-OPEN UO, there is no question asked by gO:CAPE-OPEN about a gCO file. I can’t proceed much further (Aspen Plus does not hang), since the UO is then not configured about ports and parameters so I can’t connect ports to it.

Best regards

Michel
=======================================================
De: Michel PONS via YouSendIt [delivery@…]
Envoyé: Friday, August 14, 2009 5:11 PM
À: technologyofficer@…
Objet: File Sent: apmain_081009_124510_v10802.log

youSENDit File Sent
Thank you for trusting YouSendIt to send your important files.
Want to send and track multiple files at once?

Upgrade Now

.......................................................................................................................................................................................................................

File sent: apmain_081009_124510_v10802.log
Recipients sent to: michaeljhalloran@…
File will be stored for: 7 days

Link to file:
​http://download.yousendit.com/MnFoOU1lK3hqV0N4dnc9PQ

YouSendIt Inc. | Terms of Service | Privacy Policy | DMCA Policy | Opt Out

1919 S. Bascom Avenue, 3rd Floor Campbell, CA 95008

=========================================================
De: Ahsan Akhtar [sidathyder5@…]
Envoyé: Friday, August 14, 2009 4:51 PM
À: Michel Pons
Objet: Re: COLTT 09-015
Michel,

Yes, I will need VS to debug the case.

Best Regards

Ahsan
=========================================================
De: Michel Pons [technologyofficer@…]
Envoyé: Friday, August 14, 2009 4:38 PM
À: 'Ahsan Akhtar'
Objet: RE: COLTT 09-015

Ahsan,

Tuesday August 18 is fine with me. In the meantime should I attempt to install Visual Studio 2008 in the VM dedicated to COLTT 09-015?

Best regards

Michel
===========================================================
De: technologyofficer@…
Envoyé: Wednesday, August 12, 2009 7:50 AM
À: Michael Halloran
Cc: Ahsan Akhtar; malcolm.woodman@…
Objet: Re: gO:CAPE-OPEN in Aspen Plus

Michael,

I have not the log with me (being out of my office). But in both cases the Initialize is said to proceed well, i.e. no error. I do think that the dialog box comes indeed from the Initialize method. I will check also in the proprietary log file made by gO:CAPE-OPEN. I have to review how to configure it.

Best regards

Michel
============================================================
De: Michael Halloran [michaeljhalloran@…]
Envoyé: Wednesday, August 12, 2009 12:07 AM
À: Michel Pons
Cc: Ahsan Akhtar; malcolm.woodman@…
Objet: Re: gO:CAPE-OPEN in Aspen Plus
Michel,

Do you have a log for the 1.08.2 case? I think that gO:CAPE-OPEN displays the dialog in the Initialise call. I would like to know what the log says is happening then. Does Aspen Plus hang at the point when you expect to get the dialogue or does it continue as normal but with the GO;CAPE-OPEN Unit not configured correctly?

Regards
Michael
============================================================
De: Ahsan Akhtar [ahsan.akhtar@…]
Envoyé: Wednesday, August 12, 2009 8:06 AM
À: 'Michel Pons'
Objet: RE: COLTT 09-015

Michel,

Will it be fine to have this session on Tuesday at 8 am Paris in the next week?

Best Regards

Ahsan
==================================================
De: Michel Pons [technologyofficer@…]
Envoyé: Monday, August 10, 2009 12:54 PM
À: 'Ahsan Akhtar'; 'Michael Halloran'
Cc: 'malcolm.woodman@…'
Objet: COLTT 09-015

Pièces jointes: apmain_081009_124051_v107.log; apmain_081009_124510_v10802.log

Ahsan, Michael,

To bring some light on the above referenced issue, I provide attached the logs obtained with v1.07 and v1.08.02. My understanding is that whatever goes wrong is within the Initialize method where my guess is that the request for a gCO file is made. It is clear from the logs that after leaving Initialize, the number of ports is zero in v1.08.02 and 2 in v1.07.

Best regards

Michel
===================================================
De: Michel Pons [technologyofficer@…]
Envoyé: Monday, August 10, 2009 11:26 AM
À: 'Michael Halloran'; 'Ahsan Akhtar'
Cc: 'malcolm.woodman@…'
Objet: gO:CAPE-OPEN in Aspen Plus

Hi,

I am trying to document an issue about Aspen Plus that involves the use of a gO:CAPE-OPEN Unit Operation.

With COLTT 1.07 enabled on gO:CAPE-OPEN, I get a simulation which seems close to what happens without COLTT: the simulation goes to its end giving the same results. There is however a Microsoft Visual C++ Runtime Library error message box displayed when exiting Aspen Plus saying Runtime Error! Program: C:
Pr… then R6025 – pure virtual function call and Aspen Plus aborts. So something is wrong.

With COLTT 1.08.02 I do not get as far. I start, like with COLTT 1.07 from an Aspen Plus bkp file where the CAPE-OPEN UO is not showing. I need to instantiate the UO. When instantiating a gO:CAPE-OPEN UO in Aspen Plus (or other PME), there is a window popping up and asking about the location and name of a gCO file that is the configuration file for the gO:CAPE-OPEN Unit Operation. This happens when COLTT v1.07 is enabled on gO:CAPE-OPEN while this requests does not happen when COLTT 1.08.02 is enabled on gO:CAPE-OPEN. Hence I can’t get any further there.

I have logged this issue as 09-015 and I have created a specific machine handling this case. It would be of interest to test COLTT 1.08.03 on this issue to figure out where we stand.

Best regards

Michel

[michelpons]

Zipped log file obtained with COLTT 1.07

[michelpons]

Log file obtained with COLTT 1.08.02

[michelpons]

Zipped log file obtained with COLTT 1.08.03

[michelpons]

I have run the combination of gO:CAPE-OPEN UO in Aspen Plus while using COLTT 1.08.03 (Build Oct 19, 2009). My observations are that enabling COLTT 1.08.03 on the go:CAPE-OPEN UO now leads to the same behaviour as without COLTT or with COLTT 1.07. I have attached the zipped log file obtained (apmain_102409_144515_v10803.zip).

I recommend closing this defect since 1.08.03 behaves properly regarding this issue.

[michaelhalloran]

Closed as recommended since the original problem with 1.08.2 is not reproducible with 1.08.3