Missing elements when parsing Boolean expressions
Running
node ../modelica-json/app.js -f Buildings/Templates/Plants/HeatPumps/Interfaces/PartialHeatPumpPlant.mo -o json
with
- modelica-json commit f0b714b (current master)
- MBL commit 07dfbd5 (current master)
yields the following JSON object for the enable annotation of typPumChiWatPri_select1:
"element_modification": {
"name": "enable",
"modification": {
"equal": true,
"expression": {
"simple_expression": {
"logical_expression": {
"logical_or": [
{
"logical_and": [
{
"arithmetic_expressions": [
{
"name": "typDis"
},
{
"name": "Buildings.Templates.Plants.HeatPumps.Types.Distribution.Constant1Variable2"
}
],
"relation_operator": "=="
}
]
}
]
}
}
}
}
}
Several parts of the Boolean expression used in the binding of the enable attribute are missing and the logical_or and logical_and clauses are not balanced:
https://github.com/lbl-srg/modelica-buildings/blob/master/Buildings/Templates/Plants/HeatPumps/Interfaces/PartialHeatPumpPlant.mo#L270-L278
enable=(have_pumChiWatPriDed
or have_chiWat and typArrPumPri==Buildings.Templates.Components.Types.PumpArrangement.Headered)
and typDis==Buildings.Templates.Plants.HeatPumps.Types.Distribution.Constant1Variable2),
@JayHuLBL Can you look into this? (This issue is surprising because such expressions are commonly used in MBL templates so I wonder why we did not detect that earlier. This may be a regression.)
[EDIT] This is not a regression: commit a46a361 (used in first release of ctrl-flow) yields the same JSON object for the enable annotation of typPumChiWatPri_select1.
The raw-json for the enable annotation of typPumChiWatPri_select1 is attached.
typPumChiWatPri_select1.raw.json
There seems to be several issues.
- In https://github.com/lbl-srg/modelica-json/blob/master/lib/jsonquery.js#L1330 the function returns
undefinedifrel.rel_opis falsy. The termhave_pumChiWatPriDedis then resolved asundefinedas it is the unique term of a relation with"rel_op": "". - For the other relations we also have
"rel_op": ""which seems incorrect as we should have "and" or "or" operators, no?
@AntoineGautier Would you please check if the branch issue255_booleanExp fixed the issue?
The raw-json output is fixed with issue255_booleanExp.
The json output still bundles some terms of the expression into a string, rather than a recursively parsed object (see below). But this could be addressed in another issue for good separation of concerns.
"element_modification": {
"name": "enable",
"modification": {
"equal": true,
"expression": {
"simple_expression": {
"logical_expression": {
"logical_or": [
{
"logical_and": [
{
"arithmetic_expressions": [
{
"name": "(have_pumChiWatPriDed or have_chiWat and typArrPumPri == Buildings.Templates.Components.Types.PumpArrangement.Headered)"
}
]
},
{
"arithmetic_expressions": [
{
"name": "typDis"
},
{
"name": "Buildings.Templates.Plants.HeatPumps.Types.Distribution.Constant1Variable2"
}
],
"relation_operator": "=="
}
]
}
]
}
}
}
}
}
The following issue is more related to the issue #241 and #247. I will further look into it.
It seems that we would need to address the 3 issues at the same time and a good decision about at which point the simple_expression should be string.
Closing this as the original issue is fixed — with the limitations mentioned in https://github.com/lbl-srg/modelica-json/issues/255#issuecomment-2541097551.