Ticket #175 (new enhancement)
Identifying MOs by pointers if not named
Reported by: | michelpons | Owned by: | Michael Halloran |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | COLoggers | Version: | 2.1 |
Keywords: | Cc: | michaelhalloran |
Description
A number of PMEs are not naming Material Objects or are giving the same name to all their Material Objects. This prevents a proper analysis of the logging made on whatever involves MOs. The idea would be to allow the end-user to ask for pointers to be printed instead of names for MOs.
Change History
comment:2 Changed 11 years ago by michelpons
From private communication of Michael Halloran:
I committed fix 283 this evening which implements this option. Please try and let me know if there are any problems.
Just add the line:
COLTT.MaterialObject.UsePointersForNames=true
to the ini file to activate it, and:
COLTT.MaterialObject.UsePointersForNames=false
to switch it off.
comment:3 Changed 11 years ago by michelpons
With build 283, I get indeed a pointer as a replacement to the name, but strangely enough it is always the same pointer which appears. Since the flowsheet used involves several streams, I am puzzled by the fact that a single pointer appears all along the log file. Log file provided by other means than SourceForge TRAC since too large.
From michaelhalloran private communication:
COLTT does not set names so I think that HYSYS must use \"MO Name\" as a default. In that case the option to use pointer values as names would override what the PME is doing.
I suggest something like:
COLTT.MaterialObject.UsePointersforName=1
Which would have the effect that the log would report a pointer value as the object name, like this:
MaterialObject <00FBAC40> : Call to GetCompoundList
MaterialObject <00FBAC40> : Return from GetCompoundList -Succeeded
This one option would apply to 1.0 and 1.1 Material Objects. They are different in COLTT and could be distinguished in the option, but I think a simulation is either using one or the other and if you have the name problem you probably don't care whether it's 1.0 or 1.1. Is that right?
The option could also be extended to other object types using the same style.
Initially I would only put the option in the .ini file, because the Controller dialog is getting crowded and because object-specific options could require a new dialog altogether.