Opened 9 years ago
Last modified 9 years ago
#3384 new defect
Issues with Modelica_Noise Beta 1 Frontend
Reported by: | Owned by: | somebody | |
---|---|---|---|
Priority: | high | Milestone: | Future |
Component: | Frontend | Version: | trunk |
Keywords: | Cc: | martin.otter@… |
Description
Please get https://github.com/DLR-SR/Noise/tree/MSL (https://github.com/DLR-SR/Noise/archive/MSL.zip) and load package Modelica Modelica_Noise Beta 1.
With OpenModelica 1.9.3NightlyBuild from today, the following problems occur:
Translating
simulate(Modelica_Noise.Blocks.Examples.NoiseExamples.NormalNoiseProperties) simulate(Modelica_Noise.Blocks.Examples.NoiseExamples.WeibullNoiseProperties)
gives the following error (unfortunately in German)
Variable mu konnte nicht im Geltungsbereich von Modelica_Noise.Blocks.Noise.GenericNoise$noise gefunden werden.
The issue seems to be
Blocks.Examples.NoiseExamples.NormalNoiseProperties: model NormalNiseProperties extends UniformNoiseProperties(pMean = mu, var = sigma^2, noise(redeclare function distribution = Modelica_Noise.Math.Distributions.Normal.quantile(mu=mu,sigma=sigma))); parameter Real mu = 3; parameter Real sigma = 1;
so propagation of parameters to function calls
Change History (3)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
NormalNoiseProperties and WeibullNoiseProperties are example models and they could be easily rewritten, so that no extends is used, but just an adapted copy of Modelica_Noise.Blocks.Examples.NoiseExamples.UniformNoiseProperties.
However, UniformNoiseProperties does not simulate either (it is flattened and code generated, but the C-Compiler gives an error). This could be related to a similar issue: In UniformNoiseProperties the noise is defined as:
parameter Real y_min = 0; parameter Real y_max = 6; Noise.GenericNoise noise( samplePeriod=0.001, redeclare replaceable function distribution = Modelica_Noise.Math.Distributions.Uniform.quantile (y_min=y_min, y_max=y_max), useAutomaticLocalSeed=false)
Here quantile is a function and the parameters y_min and y_max are passed to it
(I expected that this is just a "usual" redeclaration of a replaceable class, where modifiers are provided, and therefore assumed that this will also work in other Modelica tools that support replaceable classes). Could you please check whether this is an error in the code generation of OpenModelica, or whether OpenModelica does not support this variant of replaceable?
I thought that a similar pattern is already used in the MSL, but this seems to be not yet the case.
It might be possible to rewrite the code according to a function partial application (
according to Modelica Specification 3.2, section 12.4.2.1 Function Partial application). This language element is used in MSL in Modelica.Math.Nonlinear.Examples.quadratureLobatto3 and OpenModelica can simulate this model.
comment:3 by , 9 years ago
It might be possible to rewrite the code according to a function partial application (
according to Modelica Specification 3.2, section 12.4.2.1 Function Partial application). This language element is used in MSL in Modelica.Math.Nonlinear.Examples.quadratureLobatto3 and OpenModelica can simulate this model.
I just checked, and rewriting according to quadratureLobatto3 seems to be not possible: In quadratureLobatto3 a function is passed to a function as function argument. In Noise, the goal is to select a function and use this function in model Noise. After selection of the function, some function arguments get a parameter value.
So, I hope you are able to fix (or support) this feature in OpenModelica
This is not propagation of a parameter to a function call, but propagation of a parameter to be used as a binding in a function class. Which means the function is now referencing a parameter from outside its own scope. This is not something that that function classes can do by themselves, which is why OMC does not support it (lookup is only allowed for constants in enclosing classes, see the example in 5.3.1).
Simply allowing this and hoping for the best would not work in all cases since any expression calling this function would now depend on this parameter (which may be hidden inside any other call; you would not see the dependency from looking only at the expression). I suppose if mu was constant, most of these issues would disappear (or if OMC evaluated these as structural parameters).