Opened 4 years ago

Closed 4 years ago

#5782 closed discussion (fixed)

Failure to instantiate EletricalEnergyStorage Libray

Reported by: johti17 Owned by: perost
Priority: low Milestone: 1.16.0
Component: New Instantiation Version: v1.14.0
Keywords: Translation Cc:

Description

When attempting to initialize the EletricalEnergyStorage the initialization fails with the following message:

[2] 17:50:33 Translation Error
[ElectricalEnergyStorage: 1058:11-1060:26]: Function parameter aging was not given by the function call, and does not have a default value.

[3] 17:50:33 Translation Error
[ElectricalEnergyStorage: 1058:11-1060:26]: Function parameter temperature was not given by the function call, and does not have a default value.

The translation, however, works fine with the old frontend.
I guess the issue is that the library is not compliant with the standard. I keep this open if anyone has time to verify.

Change History (8)

comment:1 Changed 4 years ago by perost

The issue seems to be that the OF adds default arguments to record parameters when generating record constructors, while the NF doesn't. I.e.:

record R1
  Real x = 1.0;
end R1;

record R2
  R1 r1;
end R2;

results in the OF generating the constructor:

function R2
  input R1 r1 = R1(1.0);
  output R2 res;
end R2;

while the NF generates:

function R2
  input R1 r1;
  output R2 res;
end R2;

The NF probably needs to emulate the OF in this case. Here's a minimal model that replicates the issue:

record R1
  Real x = 1.0;
end R1;

record R2
  R1 r1;
end R2;

function f
  input R2 r2;
end f;

model M
equation
  f();
end M;

comment:2 follow-up: Changed 4 years ago by casella

@perost, I'm not 100% sure what the specification says about this, but I always gave it for granted that if you instantiate a record parameter with default bindings, you get those parameter values by default. Having to re-type those values explicitly as modifiers would seem impractical for me from an end-user perspective.

BTW, in the text you mention record parameter but in the sample code I see time-varying variables. Do I miss something?

comment:3 in reply to: ↑ 2 ; follow-up: Changed 4 years ago by perost

Replying to casella:

@perost, I'm not 100% sure what the specification says about this, but I always gave it for granted that if you instantiate a record parameter with default bindings, you get those parameter values by default. Having to re-type those values explicitly as modifiers would seem impractical for me from an end-user perspective.

Yes, there are clearly default arguments in this case, the question is mostly how to implement it internally in the compiler.

BTW, in the text you mention record parameter but in the sample code I see time-varying variables. Do I miss something?

Sorry, I was talking about record constructors. So parameter = function input parameter, not parameter variability.

comment:4 in reply to: ↑ 3 Changed 4 years ago by casella

Replying to perost:

Sorry, I was talking about record constructors. So parameter = function input parameter, not parameter variability.

Aha.

Could it be that this issue is the cause of some of the errors we get with libraries such as Buildings?

comment:5 Changed 4 years ago by johti17

  • Component changed from *unknown* to Frontend
  • Owner changed from somebody to pero
  • Status changed from new to assigned

comment:6 Changed 4 years ago by casella

  • Owner changed from pero to perost

comment:7 Changed 4 years ago by casella

  • Component changed from Frontend to New Instantiation
  • Milestone changed from Future to 1.16.0

comment:8 Changed 4 years ago by perost

  • Resolution set to fixed
  • Status changed from assigned to closed

Fixed in 091047e1. Half the models in the library now works as well as with the old frontend, the other half needs a bit more work it seems.

Note: See TracTickets for help on using tickets.