Opened 5 years ago

Closed 5 years ago

#5518 closed defect (fixed)

newInst: Assert with a string parameter and unset default value can't be compiled

Reported by: Karim Adbdelhak Owned by: Per Östlund
Priority: critical Milestone: Future
Component: New Instantiation Version:
Keywords: assert, string, parameter, default value Cc: Adrian Pop

Description

The following model can't be compiled with "-d=newInst" but runs under the OF.

model testcase
    parameter Real ThresholdA;
    parameter Real ThresholdB;
    parameter String Value;

    parameter String A = "A";
    parameter String B = "B";

    Real MyThreshold;

  equation
    assert(Value == A or Value == B,
           "The value should be A or B");

    if (Value == A) then
      MyThreshold = ThresholdA;
    else
      MyThreshold = ThresholdB;
    end if;
end testcase;

Setting the value of Value to any string solves the problem, but it is quite confusing to me that it completely breaks when its not set. The error occurs somewhere before creating a BackendDAE.

I tried to make this minimal example smaller, but it seems that it works when there is only one condition in the assert. I am not quite sure what the NF does different than before, but i think it has something to do with the default values of unset strings. Seems unimportant, but that it does not compile at all should be fixed.

Change History (4)

comment:1 by Francesco Casella, 5 years ago

The NF complains

Internal error NFCeval.evalRelationEqual failed to evaluate ‘Value == "A"‘

which sounds ok to me. No value was given to Value, so the NF cannot evaluate it. I would say that it was the behaviour of the OF to be questionable. There is no such thing as a default value for Strings in the language spec, AFAIK.

@perost, what do you think?

comment:2 by Per Östlund, 5 years ago

The assert is not at all relevant to the issue, the actual problem is that the NF tries to evaluate the condition of the if-equation.

The issue is that the checks that the NF does to determine whether a condition can be marked as structural or not are not sufficient, it only checks for a few known impure functions. We actually have better checks already that I implemented for handling the -d=evaluateAllParameters flag better, but it's not used for if-conditions yet.

Should be easy enough to fix, but you'll have to wait until next week due to Swedish holidays.

comment:3 by Per Östlund, 5 years ago

Fixed in 4c957b7. The typing now uses the same function for checking if an if-condition is fixed or not as the instantiation uses for checking structural parameters.

comment:4 by Per Östlund, 5 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.