EMSO Language Changes (version 0.9.52 and above)

ext keyword replaced by outer

The ext keyword was used to obtain a global parameter, it was replaced by outer. I've observed that this keyword was 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 the ext used to.

In the above example streams from SUB01 cannot be connected with streams of SUB02.

Another example:

• You have a model for a tray of a distillation column, and need a parameter to be the same for all trays
• Then you declare such a parameter as outer on the tray model
• And declare the parameter on the distillation column (each outer tray parameter will point to the distillation column one)
• 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?!?

CalcObject's are now Plugin's

This is another example of keyword which is not directly understood by the users. Then we adopted Plugin instead of CalcObject.

Usage:

Error: Failed to load processor mso

No macro or processor named 'mso' found

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. In order to solve this problem, we created Type attribute. This attribute can be set even for outer Plugins (as exemplified above). Then we a new property set window was added, using this new dialog the user can 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 time using the GUI without need to change the models.

The screenshot for the plugins configuration follows:

Plugin Declaration on FlowSheet?

The declaration of a Plugin on a FlowSheet? also changed:

Error: Failed to load processor mso

No macro or processor named 'mso' found

Model Attributes

In previous versions only types had 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. Now we also have attributes for Models, they are set using a new section called ATTRIBUTES:

Error: Failed to load processor mso

No macro or processor named 'mso' found

Switcher for equations

In previous versions, continuous-discrete modeling is supported in EMSO only using the if statement. But some more complex situations cannot be modeled with just a 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 trivial if. For this case, a State Transition Network (STN) is needed.

For this case the Switcher parameter type was added, 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! :)

Units Of Measurement (UOM)

In previous versions of EMSO, there was Units Of Measurement (UOM) support 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")

In recent versions we decided to distinguish texts from UOM using a different notation:

• Units of measurement are declared with single quote, eg. 'kg/h'
• Text elements are declared with double quote, eg. "This is a Text"

Another UOM problems

In previous versions of EMSO, there was Units Of Measurement (UOM) support for variables, parameters, equations, etc. But there was a potential problem when deriving types with a UOM:

Error: Failed to load processor mso

No macro or processor named 'mso' found

The above model has serious problems:

• P derived from a pressure type but has a length unit
• What about the limits if the UOM changed?

In order to fix this kind of problem the following changes were implemented:

• added a final modifier for the attributes, preventing it to be changed when deriving from it
• added another attribute called DisplayUnit?, which should be compatible with Unit (the GUI will report all results converted to the DisplayUnit?)
• now the limits are considered to be in respect to the Unit and not DisplayUnit?
• now all UOM declared in types.mso has the final attribute set

Sample code showing the news for UOM:

Error: Failed to load processor mso

No macro or processor named 'mso' found

Not Yet Implemented Suggestions

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

Other suggestion for the OPTIONS section is to tell the simulator to use the steady-state solution as initial condition for the dynamic simulation. In this case the NLP for the initialization is not necessary, because all derivatives are set to zero. A suggestion to set this option could be using the InitialFile?:

Error: Failed to load processor mso

No macro or processor named 'mso' found

Who	Opinion	Why
Arge	agreed	proposed the change
Rodolfo	agreed	will solve my problem with the gasifier that is not initializing, but the steady-state is working fine