= EMSO Language Changes Suggestions =

'''NOTE: The suggestions below are being implemented in the [../browser/branches/newlanguage 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:
{{{
#!mso
Model stream
	PARAMETERS
	outer NComp as Integer(Brief = "Number of chemical components", Lower = 1); 

	VARIABLES
	F as flow_mol;
	T as temperature;
	P as pressure;
	z(NComp) as fraction (Brief = "Overall Molar Fraction");
	h as enth_mol (Brief = "Overall Molar Enthalpy");
	v as fraction (Brief = "Vapourisation fraction");
end

Model SubProcess
	PARAMETERS
	NComp as Integer(Brief = "Number of chemical components", Lower = 1);

	VARIABLES
	FL101 as flash; # flash model here uses the stream model
	FL102 as flash;
end

FlowSheet Flow
	DEVICES
	SUB01 as SubProcess;
	SUB02 as SubProcess;

	SET
	SUB01.NComp = 10;
	SUB02.NComp = 3;
end
}}}

Then when '''stream'''s 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:
{{{
#!mso
Model stream_therm as stream
	PARAMETERS
	outer  PP   as Plugin(Brief = "External Physical Properties", Type="PP");
	
	EQUATIONS
	h = (1-v)*PP.LiquidEnthalpy(T, P, z) + v*PP.VapourEnthalpy(T, P, z);
end
}}}

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:
{{{
#!mso
positive as Real (Brief = "Positive General Constant", Default=1.0, Lower=-1e-6);
negative as Real (Brief = "Negative General Constant", Default=-1.0, Upper=0.0);
fraction as positive (Brief = "Fraction" , Default=0.5, Upper=1.00001);
}}}

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

=== Option 1 ===

Something similar to the types declaration:
{{{
#!mso
Model MyTankModel (Icon="Tank", IconSize="normal", Brief="Model for a special kind of tank",
    Info="The model documentation. This should be more detailed than Brief,
    possibly spanning in multiple lines.
    It also should be good a have some wiki formating support in the documentation.
    Then we can have the library of models documentation automatically built based on it.")
    PARAMETERS
    ...
    VARIABLES
    ...
end
}}}

=== Option 2 ===

A new section for setting the attributes:
{{{
#!mso
Model MyTankModel
    ATTRIBUTES
    Icon="Tank";
    IconSize="normal";
    Brief="Model for a special kind of tank";
    Info="The model documentation. This should be more detailed than Brief,
    possibly spanning in multiple lines.
    It also should be good a have some wiki formating support in the documentation.
    Then we can have the library of models documentation automatically built based on it.";

    PARAMETERS
    ...
    VARIABLES
    ...
end
}}}

=== 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:
{{{
#!mso
Model SafetyValve
    PARAMETERS
    ValveMode as Switcher(Valid = ["closed", "opened"], Default = "closed")
    ...
    EQUATIONS
    switch ValveMode
    case "closed":
       flow = 0 * "mol/h";
       when P > 2*"atm" switchto "opened";
    case "opened":
       flow = k*sqrt(P - Pout);
       when P < Pout*1.1 switchto "closed";
    end
    ...
end
}}}

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 ===
{{{
#!mso
FlowSheet Myflowsheet
    ...
    OPTIONS
     time = [0:0.1:30];
     relativeAccuracy = 1e-8;
     absoluteAccuracy = 1e-9;
     DAESolver = "dasslc" {"maxorder" = 5, "maxlen" = 400};
end
}}}

=== Option 2 ===

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

{{{
#!mso
FlowSheet Myflowsheet
    ...
    OPTIONS
     time = [0:0.1:30];
     relativeAccuracy = 1e-8;
     absoluteAccuracy = 1e-9;
     DAESolver(File = "dasslc", maxorder = 5, maxlen = 400);
end
}}}

||Who || Opinion || Why ||
||Arge || '''agreed''' || proposed the change ||
||Rafael || '''in doubt''' || proposed the option 2 ||