Ticket #33 (new defect)
Ports made available by COLTT
Reported by: | michelpons | Owned by: | Michael Halloran |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | COLoggers | Version: | Development |
Keywords: | Cc: | michaelhalloran |
Description
I am running a tailormade Unit Operation (Test3) in Aspen Plus 7.1. When COLTT is not enabled on the UO, the UO ports do not appear. It means I can't connect the material streams defined to any port of the UO. Now, when COLTT is enabled on the UO, the ports appear on the UO, I can connect them and I can run the simulation. The log file attached tells what happens. COLTT should not change the behaviour between the PMC and the PME.
I am using the material of Ticket#20.
Attachments
Change History
Changed 15 years ago by michelpons
- Attachment apmain_110409_112202.log added
comment:1 Changed 14 years ago by michelpons
- Version changed from 1.08.3 to 1.08.4
I have run the same scenario with 1.08.4 and the problem is still there. The ports are showing up when COLTT is enabled on the UO while they are not visible when COLTT is not enabled. The log file obtained with 1.08.4 is attached.
Changed 14 years ago by michelpons
- Attachment apmain_063010_183917.log added
Log file obtained with 1.08.4
comment:2 Changed 14 years ago by michelpons
- Version changed from 1.08.4 to Development
I have run the same scenario with the devlopment version 1.08.5 build June 30, 2010 and I observe still that the ports are visible when COLTT is enabled on the UO. The log file obtained is attached.
Changed 14 years ago by michelpons
- Attachment apmain_063010_184115.log added
Log file obtained with 1.08.5 Build June 30, 2010
comment:3 Changed 14 years ago by michelpons
I have been running another FORTRAN based Unit Operation, this time in Aspen Plus 7.2 to check if an issue regarding port information display had been resolved in this new version. However the UO does not display its ports in Aspen Plus. The UO displays its ports only if COLTT is enabled on the UO. So I wonder what COLTT does to make this happen. Not having the same behaviour with or without COLTT enabled on a PMC is not good. I have attached the log file obtained.
Changed 14 years ago by michelpons
- Attachment apmain_072710_170635.log added
Log file obtained with COLTT 1.08.04 in Aspen Plus 7.2
comment:4 Changed 14 years ago by michelpons
I have re-run the scenario using COLTT 1.08.05 Build May 30, 2011. I observe that with COLTT enabled on the CAPE-OPEN UO, the UO Ports are available for connection to streams while without COLTT enabled on the CAPE-OPEN UO, the Ports don't show up. So the issue is still present. I have also noticed that the attached log, obtained under the above conditions, has some problem being read by the Viewer. This may lead to the cause of the issue.
Changed 14 years ago by michelpons
- Attachment apmain_060111_194613.log added
COLTT log file obtained with Build May 30, 2011
comment:5 Changed 14 years ago by michaelhalloran
Michel,
What sort of A+ run is this? It seems odd that the first call to the unit is a call to get_parameters to get the value of a parameter called RUNMODE - that happens even before the Initialize call, so one problem is that COLTT is not reporting the error in the calling sequence. But, other A+ runs do not do that, they call Initialize first. Is the source code for the unit available? How would the unit behave if Initialize wasn't called first? I don't know why COLTT would change that but it's worth understanding.
Note the logs from 110409 and 060310 show the same incorrect sequence.
Michael
comment:6 Changed 14 years ago by michelpons
The A+ version is v7.1. The strange behaviour you observe has been corrected in subsequently released A+ versions but in that version, A+ is calling CAPE-OPEN methods before a call to Initialize so this was not in compliance with the CAPE-OPEN standards that states that Initialize should be the first CAPE-OPEN method called on a PMC.
In your analysis you may refer to logs obtained with v7.2 or v7.3 versions which don't show the same behaviour since, after documented the issue to Aspentech, the problem had been corrected.
The source code for Test3 is not available. It is a FORTRAN 90 UO made with the FORTRAN 90 UO Wizard. I will check what happens with another FORTRAN 90 UO made with the same tool and for which I have the source code (but I can't compile it). Also I will try the same Test3 UO with another A+ version and will log it.
comment:7 Changed 14 years ago by michelpons
I have tried to reproduce the issue with a Fortran UO Mixer for which I have the source code. When plugging this UO in A+ 7.1, I am able to get the list of ports on the UO when the UO is logged. So this does not give clues about what happens. I am attaching the log obtained. I will open a new issue using this log because it does not load properly in the Viewer (error message at load time about some errors).
Changed 14 years ago by michelpons
- Attachment apmain_060211_075106.log added
Log file obtained with COLTT May 30 and FTNMixer
comment:9 Changed 13 years ago by michelpons
I have rerun the case using the COLTT 2.1 build dated Feb 25, 2012. The same issue is still present. Target resolution is presently 2.1. Should assess if this is still feasible.
Changed 13 years ago by michelpons
- Attachment apmain_022912_162807.zip added
Zipped log file obtained with COLTT 2.1 Build Feb 25, 2012
comment:10 Changed 12 years ago by michaelhalloran
Michel,
Can you provide the Test3 UO binaries/installer and the Aspen case file? That would help me investigate.
Log file obtained with COLTT 1.08.3 Build Oct 27, 2009