#3357 closed defect (fixed)
inStream ignores min/max modifiers on stream connector flow variables
Reported by: | Owned by: | Per Östlund | |
---|---|---|---|
Priority: | normal | Milestone: | 1.9.4 |
Component: | Frontend | Version: | trunk |
Keywords: | inStream simplification | Cc: | Martin Sjölund |
Description
I might be mistaken, but simple tests so far seem to confirm that OpenModelica does not currently take min/max modifiers of flow variables in stream connectors into account in order to simplify expressions for inStream.
Consider the following simple scheme:
A (volume) -> B (flow) -> C (volume)
If it is known that the flow direction will always be from A to C, one can declare the connector for A as:
AdvectionPort adv(q(max=0)) supposing that q is the flow variable of a stream connector defined in AdvectionPort
Similarly, the connector for C could be:
AdvectionPort adv(q(min=0)).
However, this does not seem to influence the equations generated when the model is flattened. That is, expressions such as
smooth(0, if A.adv.q > 0.0 then ...);
smooth(0, if C.adv.q > 0.0 then ...);
are still generated, even though it is asserted that A.adv.q > 0.0 will always be false and C.adv.q > 0.0 will always be true.
Change History (10)
comment:1 by , 10 years ago
Component: | Unknown → Frontend |
---|---|
Owner: | changed from | to
Status: | new → accepted |
comment:2 by , 10 years ago
comment:3 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
follow-up: 5 comment:4 by , 10 years ago
Thanks for the ultraquick fix. Will this be available in the Ubuntu nightly repo?
comment:5 by , 10 years ago
Cc: | added |
---|
Replying to palm86@…:
Thanks for the ultraquick fix. Will this be available in the Ubuntu nightly repo?
It should, assuming that the nightly builds are ok. Adding Martin as Cc in case he has something to say about the nightly builds.
comment:7 by , 10 years ago
Is there an issue on trac that I can follow to know when the nightly builds are up again?
comment:9 by , 9 years ago
Milestone: | Future → pre1.9.4 |
---|
It doesn't make sense to keep closed ticket in the "Future" milestone that were simply forgotten to assign to the correct milestone in the past.
comment:10 by , 7 years ago
Milestone: | pre1.9.4 → 1.9.4 |
---|
Removing the pre1.9.4 milestone in favor of 1.9.4.
Fixed in 6f28e41/OMCompiler.