#5687 closed defect (fixed)
Evaluting structural parameters and array modifications
Reported by: | mahge930 | Owned by: | perost |
---|---|---|---|
Priority: | normal | Milestone: | 1.16.0 |
Component: | New Instantiation | Version: | |
Keywords: | Cc: |
Description
If you are not already aware of this, there seems to be a problem when constant evaluation is involved for array modifications
model ConservationEquation parameter Boolean aa = true; end ConservationEquation; model PartialMixingVolume parameter Boolean bp = true; ConservationEquation ba(aa = bp); Real p; end PartialMixingVolume; model Pipe PartialMixingVolume[2] ca(bp = {false, false}); end Pipe;
Gets correctly flattened to
class Pipe parameter Boolean ca[1].bp = false; parameter Boolean ca[1].ba.aa = ca[1].bp; Real ca[1].p; parameter Boolean ca[2].bp = false; parameter Boolean ca[2].ba.aa = ca[2].bp; Real ca[2].p; end Pipe;
However if you add an if equation, which I believe causes a constant evaluation as follows
model ConservationEquation parameter Boolean aa = true; end ConservationEquation; model PartialMixingVolume parameter Boolean bp = true; ConservationEquation ba(aa = bp); Real p; initial equation if ba.aa then p = 3; end if; end PartialMixingVolume; model Pipe PartialMixingVolume[2] ca(bp = {false, false}); end Pipe;
The model flattens to
class Pipe parameter Boolean ca[1].bp = false; final parameter Boolean ca[1].ba.aa = false; Real ca[1].p; parameter Boolean ca[2].bp = false; final parameter Boolean ca[2].ba.aa = {false, false}; Real ca[2].p; initial equation if {false, false} then ca[1].p = 3.0; end if; if {false, false} then ca[2].p = 3.0; end if; end Pipe;
The binding for ca[2].ba.aa is now cevaled to an array. Same for the loop condition.
It does not happen for the first element of the array. It only happens for the rest of the elements always (2nd, 3rd, ...).
Change History (6)
comment:1 Changed 4 years ago by mahge930
comment:2 Changed 4 years ago by perost
I know, we've got many tickets open about this issue in various forms, and it's what I've been trying to fix for several months now. It should hopefully be fixed any day now.
comment:3 Changed 4 years ago by mahge930
Oh Okay. I though so too. Then do your thing. Hopefully this helps.
comment:4 Changed 4 years ago by perost
- Resolution set to fixed
- Status changed from new to closed
Fixed in 4cf73067.
comment:5 Changed 4 years ago by casella
- Milestone changed from Future to 1.16.0
comment:6 Changed 4 years ago by casella
Backported to 1.14.0 and 1.15.0
BTW this is the reason of failure for a number of tests in the library coverage (e.g. Building models). e.g.
https://libraries.openmodelica.org/branches/newInst/BuildSysPro/files/BuildSysPro_BuildSysPro.IBPSA.Fluid.MixingVolumes.BaseClasses.Validation.MixingVolumeHeatMoisturePort.err
https://libraries.openmodelica.org/branches/newInst/Buildings_latest/files/Buildings_latest_Buildings.Experimental.DistrictHeatingCooling.Validation.IdealSmallSystem.err
The surprising thing is that these models can pass the FrontEnd and BackEnd as if nothing is wrong and then fail on compilation of generated code.