Changes between Version 29 and Version 30 of LanguageChanges


Ignore:
Timestamp:
Apr 13, 2007, 5:49:06 PM (15 years ago)
Author:
Rafael de Pelegrini Soares
Comment:

Updated LanguageChanges (changes implemented)

Legend:

Unmodified
Added
Removed
Modified
  • LanguageChanges

    v29 v30  
    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
     5The '''ext''' keyword was used to obtain a ''global'' parameter, it was replaced by '''outer'''.
     6I've observed that this keyword was not well suited for its meaning.
    97
    108The idea from http://www.modelica.org is to have '''outer''' parameters, which means a parameter from one of the ''parents''.
     
    5048Then we can have parameters which are ''global'' inside of a given ''context''.
    5149If there is no '''intermediate''' declaration of the '''outer''' parameter, then it will be matched only on the '''FlowSheet''' and will works exactly
    52 as it is today.
     50as the '''ext''' used to.
    5351
    5452In the above example streams from '''SUB01''' '''cannot''' be connected with streams of '''SUB02'''.
     
    5856 * Then you declare such a parameter as '''outer''' on the tray model
    5957 * And declare the parameter on the distillation column (each '''outer''' tray parameter will point to the distillation column one)
    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 ==
    6861
    6962This is another example of keyword which is not directly understood by the users.
    70 I suggest to use just '''Plugin''' instead of '''CalcObject'''.
     63Then we adopted '''Plugin''' instead of '''CalcObject'''.
    7164
    7265Usage:
     
    8275}}}
    8376
    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.
     77Another old problem with the Plugin's is that each Plugin '''call''' (e.g. '''PP.LiquidEnthalpy(T, P, z)''') generates a units of measurement warning.
     78In order to solve this problem, we created '''Type''' attribute.
     79This attribute can be set even for '''outer''' Plugins (as exemplified above).
     80Then we a new property set window was added, using this new dialog the user can register a DLL for each '''Type''' of Plugin.
    8781This way the simulator can check the units of measurement and number of arguments when checking the model and not only when the simulation is run.
    8882Besides this, the Plugin can be changed any time using the GUI without need to change the models.
     
    9286[[Image(PluginsConfiguration.png)]]
    9387
    94 ||Who || Opinion || Why ||
    95 ||Rafael || '''agreed''' || proposed the change ||
    96 ||Paula || '''agreed''' || because the warnings about unit checked in models cause a bad impression ||
    97 ||Arge || '''agreed''' || the new proposition looks better ||
    98 
    9988== Model Attributes ==
    10089
    101 Currently only '''types''' have attributes, examples:
     90In previous versions only '''types''' had attributes, examples:
    10291{{{
    10392#!mso
     
    10897
    10998In the above type declarations, '''Brief''', '''Lower''', etc are attributes.
    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:
     99Now we also have attributes for '''Model'''s, they are set using a new section called '''ATTRIBUTES''':
     100
    132101{{{
    133102#!mso
     
    149118}}}
    150119
    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 
    170120== Switcher for equations ==
    171121
    172 Currently, continuous-discrete modeling is supported in EMSO using the '''if''' statement.
    173 But some more complex situations cannot be modeled with '''if'''.
     122In previous versions, continuous-discrete modeling is supported in EMSO only using the '''if''' statement.
     123But some more complex situations cannot be modeled with just a '''if'''.
    174124
    175125For example, a safety valve which opens if the pressure is higher than 2 atm but closes only when the pressure is lower than the outside pressure.
    176 This situation cannot be modeled by a simply '''if'''. For this case, a State Transition Network (STN) is needed.
    177 
    178 For this case the '''Switcher''' is proposed, usage:
     126This situation cannot be modeled by a trivial '''if'''. For this case, a State Transition Network (STN) is needed.
     127
     128For this case the '''Switcher''' parameter type was added, usage:
    179129{{{
    180130#!mso
     
    196146}}}
    197147
    198 In the piece of code above there are the following news:
     148In the piece of code above, there are the following news:
    199149 * A new basic type called '''Switcher'''
    200150 * The '''Switcher''' type has an extra attribute called '''Valid''' which are the valid values for the switcher
     
    202152 * There is a '''when''' ... '''switchto''' command which can be used inside a '''case''' of a '''switch'''. NOTE: the '''when''' command is optional, however if this command is missing then the '''case''' is a '''black hole''': there is no way to get out! :)
    203153
    204 ||Who || Opinion || Why ||
    205 ||Rafael || '''agreed''' || proposed the change ||
    206 ||Paula || '''agreed''' || this change is very usefull to overcome the limitations in '''if''' structure ||
    207 ||Arge || '''agreed''' || very important resource ||
    208 
    209154== Units Of Measurement (UOM) ==
    210155
    211 Currently EMSO support Units Of Measurement (UOM) for variables, parameters, equations, etc.
     156In previous versions of EMSO, there was Units Of Measurement (UOM) support for variables, parameters, equations, etc.
    212157The problem is that the units of measurement are declared exactly as string text (with double quotes, eg "kg/h")
    213158
    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 ||
     159In 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"
    222162
    223163== Another UOM problems ==
    224164
    225 Currently EMSO support Units Of Measurement (UOM) for variables, parameters, equations, etc.
    226 But there is a potential problem when deriving types with a UOM:
     165In previous versions of EMSO, there was Units Of Measurement (UOM) support for variables, parameters, equations, etc.
     166But there was a potential problem when deriving types with a UOM:
    227167
    228168{{{
     
    239179 - What about the limits if the UOM changed?
    240180
    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:
     181In 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
     187Sample code showing the news for UOM:
    248188{{{
    249189#!mso
     
    264204}}}
    265205
    266 
    267 ||Who || Opinion || Why ||
    268 ||Rafael || '''agreed''' || Proposed the change ||
     206= Not Yet Implemented Suggestions =
    269207
    270208== OPTIONS section ==