Version 23 (modified by Rafael de Pelegrini Soares, 15 years ago) (diff)

Improved switch command

EMSO Language Changes Suggestions

NOTE: The suggestions below are being implemented in the newlanguage repository branch?.

ext keyword for global parameters

Currently the ext keyword is used to obtain a global parameter. I've observed that this keyword is not well suited for its meaning.

The idea from http://www.modelica.org is to have outer parameters, which means a parameter from one of the parents. Then the simulator will look for the parameter in the parent tree until it finds it (maybe it is found only on the FlowSheet? but it can be matched before).

Usage example:

Error: Failed to load processor mso
No macro or processor named 'mso' found

Then when streams are instantiated on the FlowSheet? NComp will be a reference for NComp on the SubProcess?. Then we can have parameters which are global inside of a given context. If there is no intermediate declaration of the outer parameter, then it will be matched only on the FlowSheet? and will works exactly as it is today.

Who Opinion Why
Rafael agreed proposed the change
Paula agreed because this change gives more flexibility to the user
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 strems on the same model with different number of NComp using the outer command but it is possible for different models)?

CalcObject's

This is another example of keyword which is not directly understood by the users. I suggest to use just Plugin instead of CalcObject.

Usage:

Error: Failed to load processor mso
No macro or processor named 'mso' found

Another problem with the Plugin's is that each Plugin call (e.g. PP.LiquidEnthalpy?(T, P, z)) generates a units of measurement warning. In order to solve this problem I suggest the specification of the Type attribute even for outer Plugins (as exemplified above). Then we can add new property set window where the user should register a DLL for each Type of Plugin. This 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. Besides this, the Plugin can be changed any any time using the GUI without need to change the models.

Who Opinion Why
Rafael agreed proposed the change
Paula agreed because the warnings about unit checked in models cause a bad impression
Arge agreed the new proposition looks better

Model Attributes

Currently only types have attributes, examples:

Error: Failed to load processor mso
No macro or processor named 'mso' found

In the above type declarations, Brief, Lower, etc are attributes. We are planning to add attributes also for Models and we need to define a syntax for their declaration.

Option 1

Something similar to the types declaration:

Error: Failed to load processor mso
No macro or processor named 'mso' found

Option 2

A new section for setting the attributes:

Error: Failed to load processor mso
No macro or processor named 'mso' found

Option 3

Leave the attributes handling to the graphical interface (as gPROMS does), then:

  • Models remain as they are today
  • The user edits graphically:
    • which models appear on the pallet
    • the documentation of the model (probably with a graphical editor with support for bold, italics, lists, etc
    • which variables should appear on results
    • which variables can be specified or not (this can be even refined supporting specification sets)
    • which is the icon for the model
    • the relative position where the ports are shown

All the information configured graphically by the user can be stored in a XML file on the same folder of the models.

Who Opinion Why
Rafael option 3 With option 3 we have a clear distinction between the graphical interface and the models
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
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

Switcher for equations

Currently, continuous-discrete modeling is supported in EMSO using the if statement. But some more complex situations cannot be modeled with if.

For 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. This situation cannot be modeled by a simply if. For this case, a State Transition Network (STN) is needed.

For this case the Switcher is proposed, usage:

Error: Failed to load processor mso
No macro or processor named 'mso' found

In the piece of code above there are the following news:

  • A new basic type called Switcher
  • The Switcher type has an extra attribute called Valid which are the valid values for the switcher
  • There is a switch command which can be used in the EQUATIONS
  • 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! :)
Who Opinion Why
Rafael agreed proposed the change
Paula agreed this change is very usefull to overcome the limitations in if structure
Arge agreed very important resource

Units Of Measurement (UOM)

Currently EMSO support Units Of Measurement (UOM) for variables, parameters, equations, etc. The problem is that the units of measurement are declared exactly as string text (with double quotes, eg "kg/h")

I think it should be a good idea to directly distinguish texts from UOM in some way:

  • We could use the simple quote for UOM, eg. 'kg/h'
  • We could use the {, eg. {kg/h}
Who Opinion Why
Rafael in doubt I still don't know which is the better way to distinguish a Text from a UOM
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
Paula agreed I prefer single quote

OPTIONS section

Currently EMSO support few common options for the solvers, such as relativeAccuracy and absoluteAccuracy. However, each solver has its own specific design options. I suggest the following:

Option 1

Error: Failed to load processor mso
No macro or processor named 'mso' found

Option 2

Just a trial to keep it near to the types definition:

Error: Failed to load processor mso
No macro or processor named 'mso' found
Who Opinion Why
Arge agreed proposed the change
Rafael in doubt proposed the option 2

Attachments (1)

Download all attachments as: .zip