screen limiter

[Mathadon]

Shouldn't we use an assert instead of this:

protected
  Modelica.Blocks.Nonlinear.Limiter limiter(uMin=0, uMax=1) 
    "Limits the control signal to avoid incorrect use by the user";

?

[jelgerjansen]

@Mathadon what would be the main reason to change to an assert?
Does the Modelica.Blocks.Nonlinear.Limiter component leads to problems regarding computational efficiency or convergence?

[Mathadon]

Both! It adds computations that serve no use if the models are built up correctly. The min/max is evaluated on each function call even while iterating on the implicit solver, while an assert should only be evaluated after convergence of the implicit solver, which is consequently much less frequently.

[lucasverleyen]

@jelgerjansen @Mathadon I just had a look into this issue. I guess we can simply remove the limiter block without adding an assertion warning/error.

The limiter block is used in IDEAS.Buildings.Components.Shading.Screen and is used for the Ctrl input connector.
The screen model extends from Interfaces.PartialShading, in which the Ctrl input is defined as

Modelica.Blocks.Interfaces.RealInput Ctrl(min=0, max=1) if controlled 
"Control signal between 0 and 1, i.e. 1 is fully closed"

Hence, if I remove the limiter block in the screen model, I still get an error if I use a ctrl input smaller than 0 or greater than 1.

So I suggest removing the limiter block, without adding an assert statement. is this fine for you

[Mathadon]

@lucasverleyen I don't think you will get this error if you connect a non-constant to the input. So you'd need an assert to cover that case.

[jelgerjansen]

@lucasverleyen if you run IDEAS.Buildings.Components.Examples.BuildingShadeExample and change the ctrl block such that it generates e.g. negative values, you'll notice that the simulation runs without any warnings (and leads to erroneous) . I propose to add an assert like @Mathadon suggested.

[lucasverleyen]

@Mathadon @jelgerjansen good catch! I'll add the assert statement.

[lucasverleyen]

For completeness and according to @jelgerjansen's good suggestion, I have checked the results in the IDEAS.Buildings.Examples.ScreenComparison model. The results are shown below.
The blue curve = zone without screen
The green curve = zone with screen, input = 1
The red curve = zone with screen, input = -1 ---> gives unrealistic results, so I'll add an error assert.

[lucasverleyen]

@jelgerjansen to follow up on your comment. I tried to add the assert statement to the PartialShading model, but the screen control input is a boolean, and the assert leads to undeclared variables for shading models that have controlled=false. I also tried to add the assert in an if-statement (if controlled then assert() end if), but this leads to the same undeclared variables error if controlled=false. Hence, I have added the assert to the Screen model.

[jelgerjansen]

@lucasverleyen a solution for the problem you described could be circumvented by introducing an internal input Ctrl_internal and using that one in the assert:

protected
  Modelica.Blocks.Interfaces.RealInput Ctrl_internal;  
equation
  connect(Ctrl,Ctrl_internal);
  if not controlled then
    Ctrl_internal=0;
  end if;
  assert(0<=Ctrl_internal and Ctrl_internal<=1, "Error message");

@Mathadon what do you think? I think it makes more sense to integrate the assert in the partial model to guard against unrealistic control inputs for all screen models.
@lucasverleyen you also forgot to guard against control inputs larger than one. Please also update the error message accordingly.

[lucasverleyen]

@jelgerjansen I have implemented the changes as discussed.

• I have removed the assert statement from the screen model
• As you suggested, I have added the internal Ctrl_internal variable and the assert statement to the partial shading model.

However, the HorizontalFins model used the Ctrl input for the inclination angle of the fins, i.e. a value between 0 and 90° or 0 and 1.57, which violates the assert statement in the partial model. Hence, I have modified the HorizontalFins model by adding an internal variable (Ctrl_to_beta_internal) to linearly map the Ctrl input [0,1] onto the fin inclination angle [beta_min=0,beta_max]. I had to add a new internal variable because of the conditional declaration of Ctrl. If Ctrl is used, it is always a value between 0 and 1 for any shading model. Consequently, I have to update the reference results for HorizontalFinExample because the value of the Ctrl variable is used and has changed.

@Mathadon FYI

[lucasverleyen]

Update of reference results - as expected.

[jelgerjansen]

The reference results

Update of reference results - as expected.

Only the reference results of horizontalFinsBeta updated. This is because beta used to be directly controlled (sinus function from 0 to 90°), but now it is calculated as Ctrl*beta_max, where Ctrl is a sinus function from 0 to 1, but beta_max=84.3°C, thus changing the angle.

[jelgerjansen]

@lucasverleyen I further updated IDEAS.Buildings.Components.Shading.HorizontalFins as follows:

1. Define beta_max=acos(t/s) as a protected parameter
2. Remove dispLim and replace by disp_internal as this is automatically in the range [0,1] due to the definition and assert of Ctrl.

If you think something is still wrong, we can reopen this issue.

[bmare-renson]

Hi,

Due to the changes to the PartialShading and Screen model I now get an error using OCT when simulating with screens:

The component Ctrl is conditional: Access of conditional components is only valid in connect statements.

I believe that instead of using Ctrl in the Screen model it should be replaced by Ctrl_internal