Errors running IDEAS>Buildings>Components>Examples in OMedit

[IsDols]

Hi,

I have a question about the (IDEAS>Buildings>Components>) Examples with a zone component. I keep getting errors while running them in the OMedit enviroment. Should it work in the OMedit enviroment, or does it only apply in Dymola? And if not is there a reason I get these errors?

Best, Isa

Messager Browser for CavityWalls example:

[1] 10:30:01 Translation Warning Ignoring unknown experiment annotation option: __Dymola_Algorithm = "Lsodar"

[2] 10:30:01 Translation Error Internal error NFAlgorithm.getInputsOutputs failed.

[3] 10:30:01 Translation Warning [IDEAS.BoundaryConditions.WeatherData.BaseClasses.getHeaderElementTMY3: 2:1-105:25]: Pure function ‘IDEAS.BoundaryConditions.WeatherData.BaseClasses.getHeaderElementTMY3‘ contains a call to impure function ‘Modelica.Utilities.Streams.readLine‘.

[4] 10:30:01 Translation Warning [IDEAS.BoundaryConditions.WeatherData.BaseClasses.getLongitudeTMY3: 2:1-48:21]: Pure function ‘IDEAS.BoundaryConditions.WeatherData.BaseClasses.getLongitudeTMY3‘ contains a call to impure function ‘IDEAS.BoundaryConditions.WeatherData.BaseClasses.getHeaderElementTMY3‘.

[5] 10:30:01 Translation Warning [IDEAS.BoundaryConditions.WeatherData.BaseClasses.getLatitudeTMY3: 2:1-48:20]: Pure function ‘IDEAS.BoundaryConditions.WeatherData.BaseClasses.getLatitudeTMY3‘ contains a call to impure function ‘IDEAS.BoundaryConditions.WeatherData.BaseClasses.getHeaderElementTMY3‘.

[6] 10:30:01 Translation Warning [IDEAS.BoundaryConditions.WeatherData.BaseClasses.getTimeZoneTMY3: 2:1-47:20]: Pure function ‘IDEAS.BoundaryConditions.WeatherData.BaseClasses.getTimeZoneTMY3‘ contains a call to impure function ‘IDEAS.BoundaryConditions.WeatherData.BaseClasses.getHeaderElementTMY3‘.

[7] 10:30:01 Translation Notification [IDEAS.Buildings.Components.Interfaces.PartialZone: 254:36-254:47]: From here:

[8] 10:30:01 Translation Error [IDEAS.Buildings.Components.Interfaces.PartialZone: 254:3-255:43]: Non-array modification ‘false‘ for array component ‘fixed‘, possibly due to missing ‘each‘.

[Mathadon]

@IsDols this may be similar to #1249 . Are you using the latest version of OpenModelica?

[Mathadon]

@IsDols I have pushed a fix to the master branch for the error message at the bottom of your post.

[IsDols]

Thank you for the quick response! Yes I am using the latest version of OpenModelica, I am sorry I don`t completly know what you mean with the last message .

[Mathadon]

I mean this one:

[8] 10:30:01 Translation Error
[IDEAS.Buildings.Components.Interfaces.PartialZone: 254:3-255:43]: Non-array modification ‘false‘ for array component ‘fixed‘, possibly due to missing ‘each‘.

@casella are you by any chance able to comment on the error message reported above?

[2] 10:30:01 Translation Error
Internal error NFAlgorithm.getInputsOutputs failed.

Thanks!

[casella]

Sure, but I need to know exactly which version of IDEAS is @IsDols using. The source code on master at line 254 looks good to me (i.e., it has the proper eachprefix to use a scalar value as a modifier for an array). @IsDols can you please check if it looks the same in the version that you are using?

[casella]

@Mathadon, maybe we should add the IDEAS library to our testsuite, so we can test it with OpenModelica systematically and regularly. What do you think?

[Mathadon]

@casella perhaps I misunderstood. I thought that there are two unique errors but your comment seems to suggest that my bug fix may have solved the error message?

[2] 10:30:01 Translation Error
Internal error NFAlgorithm.getInputsOutputs failed.

This is not an internal compiler error?

[IsDols]

@casella I am using IDEAS v 2.2.1 and I am using the nightly build OMedit v 1.19.0 enviroment

[casella]

@casella perhaps I misunderstood. I thought that there are two unique errors but your comment seems to suggest that my bug fix may have solved the error message?

My bad, I added further entropy 😄

@Mathadon, if you recently added each to line 254, that solves the second issue. @IsDols, you should use the latest version on master of the library so it works on both Dymola and OpenModelica. Scalar modifiers applied to arrays are not legal Modelica code, but unfortunately Dymola accepts them, so we often have this problem.

As to the first error, I would suggest @IsDols to try the latest 1.19.0 nightly build of OpenModelica, chances are that this problem has been fixed already in the compiler. If so, problem solved. Note that we will officially release 1.19.0 anytime soon. Otherwise please open an issue on the OpenModelica issue tracker and we'll try to fix that.

[Mathadon]

@IsDols I have pushed a fix to the master branch for the error message at the bottom of your post.

Yup, I solved it here :) b0873b1

[IsDols]

Thank you both! Yes the last error is fixed now indeed although it now gives me a new error in the Zone Interface:

[7] 15:00:57 Translation Error [IDEAS.Buildings.Components.Interfaces.ZoneInterface: 96:5-101:36]: cardinality may only be used in the condition of an if-statement/equation or an assert.

Though I will firstly reinstall the last Modelica nightly build and message again if the errors are still accuring

[IsDols]

Yes I do not have the first Translation warning anymore:

Only the ZoneInterface error is left:

[6] 15:49:40 Translation Error [IDEAS.Buildings.Components.Interfaces.ZoneInterface: 96:5-101:36]: cardinality may only be used in the condition of an if-statement/equation or an assert.

should I open an issue for that in the OpenModelica issue tracker as well? or is this the correct location to add this error

[Mathadon]

@IsDols this is the correct place to report it.

@casella the problem is this code:

    assert(cardinality(ports[i])<=2,
      "Each element of ports should have zero or one external connections but " +
      getInstanceName() +".ports[" + String(i) + "] has " + String(cardinality(ports[i]) - 1) + "." +
      " This can cause air to mix at the fluid port, without entering the zone, which is usually unintended.
      Instead, increase nPorts and create a separate connection.",
      level=AssertionLevel.warning);

The problem seems to be that the cardinality operator is used in the error message of the assert. Is this something that OpenModelica could consider to allow or should we remove it to be compliant with the standard?

[Mathadon]

@IsDols I have pushed a fix to the master branch, can you check once more?

[IsDols]

@Mathadon Yes the error is gone and the simulation is executed, thank you!

[Mathadon]

@IsDols okay glad to have this out of the way, thanks for reporting!

[casella]

Thank you both! Yes the last error is fixed now indeed although it now gives me a new error in the Zone Interface:

[7] 15:00:57 Translation Error [IDEAS.Buildings.Components.Interfaces.ZoneInterface: 96:5-101:36]: cardinality may only be used in the condition of an if-statement/equation or an assert.

Though I will firstly reinstall the last Modelica nightly build

That's not going to help here. Please read the description of cardinality in the latest released Modelica Language Specification, Section 3.7.4.3.

The policy of OpenModelica is to implement the Modelica Language standard. Other tools may accept code which is not valid according to the Standard, and of course they are free to do it, but then they are actually implementing a Modelica dialect, which is no longer tool-independent. If you want to develop a tool-independent Modelica library which is portable across Modelica tools, you need to stick to the standard.

In some cases the standard is actually evolving, so we may accept stuff which is not yet standardized, but probably will in the near future. That's not the case for cardinality, which has been deprecated 10 years ago. In fact, as with all deprecated features, it should eventually be banned outright. This may never actually happen, but for sure it won't be extended.

[casella]

EDIT: I see that apparently cardinality shows up within an assert. Are you 100% sure that is the cause of the error? In that case, this is an OpenModelica bug and it can be fixed easily.

[casella]

The error was indeed correct, cardinality() was used in in the error string input of the assert statement, but is only allowed in the condition input. @Mathadon's fix addresses this correctly.