1 | | = EMSO Language Changes Suggestions = |
2 | | |
3 | | '''NOTE: The suggestions below are being implemented in the [../browser/branches/newlanguage newlanguage repository branch].''' |
4 | | |
5 | | == '''ext''' keyword for ''global'' parameters == |
6 | | |
7 | | Currently the '''ext''' keyword is used to obtain a ''global'' parameter. |
8 | | I've observed that this keyword is not well suited for its meaning. |
| 1 | = EMSO Language Changes (version 0.9.52 and above) = |
| 2 | |
| 3 | == '''ext''' keyword replaced by '''outer''' == |
| 4 | |
| 5 | The '''ext''' keyword was used to obtain a ''global'' parameter, it was replaced by '''outer'''. |
| 6 | I've observed that this keyword was not well suited for its meaning. |
60 | | * With the current '''ext''' implementation this is also possible, but the ''source'' parameter needs to be on the FlowSheet. In this case what about if you need two distillation columns on the same FlowSheet!? |
61 | | |
62 | | ||Who || Opinion || Why || |
63 | | ||Rafael || '''agreed''' || proposed the change || |
64 | | ||Paula || '''agreed''' || because this change gives more flexibility to the user || |
65 | | ||Arge || '''in doubt''' || if two streams are used in a model with different number of '''NComp''', is it possible to set '''stream1.NComp''' and '''stream2.NComp''' to different values in that model? [[Color(red, please check the new explanation - it is not possible to have streams on the same model with different number of NComp using the outer command but it is possible for different models.)]] Please, enhance the example connecting a stream from SubProcess '''SUB01''' to SubProcess '''SUB02''', in order to see the applicability.|| |
66 | | |
67 | | == CalcObject's == |
| 58 | * With the old '''ext''' implementation this is also possible, but the ''source'' parameter needs to be on the FlowSheet. In this case what about if you need two distillation columns on the same FlowSheet!? |
| 59 | |
| 60 | == CalcObject's are now Plugin's == |
84 | | Another problem with the Plugin's is that each Plugin '''call''' (e.g. '''PP.LiquidEnthalpy(T, P, z)''') generates a units of measurement warning. |
85 | | In order to solve this problem I suggest the specification of the '''Type''' attribute even for '''outer''' Plugins (as exemplified above). |
86 | | Then we can add new property set window where the user should register a DLL for each '''Type''' of Plugin. |
| 77 | Another old problem with the Plugin's is that each Plugin '''call''' (e.g. '''PP.LiquidEnthalpy(T, P, z)''') generates a units of measurement warning. |
| 78 | In order to solve this problem, we created '''Type''' attribute. |
| 79 | This attribute can be set even for '''outer''' Plugins (as exemplified above). |
| 80 | Then we a new property set window was added, using this new dialog the user can register a DLL for each '''Type''' of Plugin. |
110 | | We are planning to add attributes also for '''Model'''s and we need to define a syntax for their declaration. |
111 | | |
112 | | === Option 1 === |
113 | | |
114 | | Something similar to the types declaration: |
115 | | {{{ |
116 | | #!mso |
117 | | Model MyTankModel (Icon="Tank", IconSize="normal", Brief="Model for a special kind of tank", |
118 | | Info="The model documentation. This should be more detailed than Brief, |
119 | | possibly spanning in multiple lines. |
120 | | It also should be good a have some wiki formating support in the documentation. |
121 | | Then we can have the library of models documentation automatically built based on it.") |
122 | | PARAMETERS |
123 | | ... |
124 | | VARIABLES |
125 | | ... |
126 | | end |
127 | | }}} |
128 | | |
129 | | === Option 2 === |
130 | | |
131 | | A new section for setting the attributes: |
| 99 | Now we also have attributes for '''Model'''s, they are set using a new section called '''ATTRIBUTES''': |
| 100 | |
151 | | === Option 3 === |
152 | | |
153 | | Leave the attributes handling to the graphical interface (as gPROMS does), then: |
154 | | * Models remain as they are today |
155 | | * The user edits graphically: |
156 | | * which models appear on the '''pallet''' |
157 | | * the documentation of the model (probably with a graphical editor with support for '''bold''', ''italics'', lists, etc |
158 | | * which variables should appear on results |
159 | | * which variables can be specified or not (this can be even refined supporting ''specification sets'') |
160 | | * which is the icon for the model |
161 | | * the relative position where the ports are shown |
162 | | |
163 | | All the information configured graphically by the user can be stored in a XML file on the same folder of the models. |
164 | | |
165 | | ||Who || Opinion || Why || |
166 | | ||Rafael || '''option 3''' || With option 3 we have a clear distinction between the graphical interface and the models || |
167 | | ||Paula ||'''option 2''' || Because the graphical interface is so far from a usable version and with option 2 a parser can be made to automaticaly generate the documentation in pdf, wiki and to the graphical interface || |
168 | | ||Arge ||'''option 2''' || In agreement with Paula's comment about parsers and also because the graphical interface can overwrite those attributes and store them in a XML file of the flowsheet without changing the library models || |
169 | | |
214 | | I think it should be a good idea to directly distinguish texts from UOM in some way: |
215 | | * We could use the simple quote for UOM, eg. 'kg/h' |
216 | | * We could use the '''{''', eg. {kg/h} |
217 | | |
218 | | ||Who || Opinion || Why || |
219 | | ||Rafael || '''in doubt''' || I still don't know which is the better way to distinguish a Text from a UOM || |
220 | | ||Arge || '''agreed''' || Single quote seems to be the better solution, and it helps to distinguish an equation name from an UOM at the beginnig of an expression || |
221 | | ||Paula || '''agreed''' || I prefer single quote || |
| 159 | In recent versions we decided to distinguish texts from UOM using a different notation: |
| 160 | * Units of measurement are declared with single quote, eg. 'kg/h' |
| 161 | * Text elements are declared with double quote, eg. "This is a Text" |
241 | | In order to fix this kind of problem the following changes are proposed: |
242 | | - add a '''final''' modifier for the attributes, preventing it to be changed |
243 | | - add another attribute called '''DisplayUnit''', which should be compatible with '''Unit''' (the GUI will report all results converted to this UOM) |
244 | | - the limits are considered to be in respect to the '''Unit''' and not '''DisplayUnit''' |
245 | | - declare all UOM in '''types.mso''' as '''final''' |
246 | | |
247 | | Sample code with the propositions included: |
| 181 | In order to fix this kind of problem the following changes were implemented: |
| 182 | - added a '''final''' modifier for the attributes, preventing it to be changed when deriving from it |
| 183 | - added another attribute called '''DisplayUnit''', which should be compatible with '''Unit''' (the GUI will report all results converted to the '''DisplayUnit''') |
| 184 | - now the limits are considered to be in respect to the '''Unit''' and not '''DisplayUnit''' |
| 185 | - now all UOM declared in '''types.mso''' has the '''final''' attribute set |
| 186 | |
| 187 | Sample code showing the news for UOM: |