#2486 closed defect (fixed)
Vector size unknown before compiling
Reported by: | Owned by: | Adrian Pop | |
---|---|---|---|
Priority: | high | Milestone: | 1.19.0 |
Component: | New Instantiation | Version: | trunk |
Keywords: | unbalanced; vectorsize; | Cc: |
Description
A MWE model made and developed in Dymola checks perfectly fine in 'pedantic mode' in Dymola stating '253 unknowns and equations'. However, when testing this model in OpenModelica, two things occur:
- The model checks succesfully, but states to be unbalanced with 249 equations and 241 variables.
- When attempting to simulate, the model states that the bector length must be known before compiling.
However, the latter should be ok as this was the main occuring error while debugging in Dymola and was solved by the proper inclusion of the necessary 'final' commands.
Attachments (1)
Change History (16)
by , 11 years ago
Attachment: | MWE_States.mo added |
---|
comment:1 by , 11 years ago
Component: | OMEdit → Frontend |
---|---|
Owner: | changed from | to
Status: | new → accepted |
This belongs to the FrontEnd, not OMEdit.
As far as I can tell this is a problem with calculation of mat.nSta inside IDEAS.Buildings.Data.Interfaces.Material record.
comment:2 by , 11 years ago
Yes, mat.nSta is indeed calculated in IDEAS.Buildings.Data.Interfaces.Material record, and nSta depicts the resulting vector size and number of states. However, the calculation of nSta, equal to
- final parameter Integer nSta(min=1) = max(1, integer(ceil(A*B/C)));
and al its parameters A, B, C are final, so i would suggest these are known at the beginning of the simulations. Does this requires to include
- annotation(evaluate=true)
or won't this change anything ? (if i change it in the above line, the same error remains).
comment:3 by , 11 years ago
This is a bug with propagation of redeclares and record modifiers.
I don't think you can do anything about it until I fix it.
comment:4 by , 11 years ago
Is this something that can be accomplished in a reasonable amount of time ?
comment:5 by , 11 years ago
I've been working on fixing this kind of issues the last weeks and I'm pretty close to a working prototype. If no other issues appear hopefully next week we can at least flatten this model. Then we can have a look if there are any issues with simulation.
comment:6 by , 10 years ago
Milestone: | 1.9.1 → 1.9.2 |
---|
This ticket was not closed for 1.9.1, which has now been released. It was batch modified for milestone 1.9.2 (but maybe an empty milestone was more appropriate; feel free to change it).
comment:7 by , 10 years ago
Milestone: | 1.9.2 → 1.9.3 |
---|
Milestone changed to 1.9.3 since 1.9.2 was released.
comment:12 by , 8 years ago
Milestone: | 1.11.0 → 1.12.0 |
---|
Milestone moved to 1.12.0 due to 1.11.0 already being released.
comment:13 by , 7 years ago
Milestone: | 1.12.0 → Future |
---|
The milestone of this ticket has been reassigned to "Future".
If you think the issue is still valid and relevant for you, please select milestone 1.13.0 for back-end, code generation and run-time issues, or 2.0.0 for front-end issues.
If you are aware that the problem is no longer present, please select the milestone corresponding to the version of OMC you used to check that, and set the status to "worksforme".
In both cases, a short informative comment would be welcome.
comment:14 by , 3 years ago
Milestone: | Future → 1.19.0 |
---|---|
Resolution: | → fixed |
Status: | accepted → closed |
This seems to work fine with the new frontend. I can't test the simulation since the model uses external data files I don't have, but checking it reports 253 variables and equations as expected.
comment:15 by , 3 years ago
Component: | Frontend → New Instantiation |
---|
Minimal working example "TEST" used in the ticket