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:

Plugins Configuration screenshot

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

OPTIONS section

Previous versions of EMSO support only a few common options for the solvers, such as relativeAccuracy and absoluteAccuracy. However, each solver has its own specific design options.

Now besides common options, there are solver specific options declared as follows:

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

This way the user can supply any option to the solver. EMSO will not check if the options are really supported by the solver at the time of reading the file. The options will be checked only when the solver DLL is loaded (when actually trying to solve the problem).

The set of options which all NLASolver implementations should support:

Option Type Description
RelativeAccuracy? real the desired relative accuracy of the solution, default 1e-3
AbsoluteAccuracy? real the lowest value to be considered relevant when solving the problem, default 1e-6
MaxIterations? int the maximum number of iterations, default 100

The set of options which all DAESolver implementations should support:

Option Type Description
EventAccuracy? real the accuracy in time when detecting state events (actually handled by EMSO, solver developers should not worry about this), default 1e-2
RelativeAccuracy? real the desired relative accuracy of the solution, default 1e-3
AbsoluteAccuracy? real the lowest value to be considered relevant when solving the problem, default 1e-6

Not Yet Implemented Suggestions

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
Last modified 13 years ago Last modified on Apr 24, 2007, 1:14:52 PM

Attachments (1)

Download all attachments as: .zip