Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#6054 closed defect (fixed)

The NF incorrectly renders the actualStream operator

Reported by: Francesco Casella Owned by: Per Östlund
Priority: blocker Milestone: 1.17.0
Component: New Instantiation Version:
Keywords: Cc: Andrea Bartolini, Karim Adbdelhak

Description

Please consider the attached package, model TestActualStream.Test.

The PressureLoss component contains the following equation

h_a = actualStream(port_a.h_outflow);

which gets flattened in ploss1 as

ploss1.h_a = smooth(0, 
  if ploss1.port_a.m_flow > 0.0 then source.ports[1].h_outflow
                                else ploss1.port_a.h_outflow);

This is of course wrong, because the expression inside the smooth operator is discontinuous in general.

The definition of actualStream in Section 15.3 of the Specification is

actualStream(c.h_outflow) = if c.m_flow > 0 then inStream(c.h_outflow)
                            else c.h_outflow;

with no smooth() operator.

The smooth operator can be applied to expressions formed by multiplying the actualStream operator by its corresponding flow variable, as in case (1) mentioned in the Specification. That product is indeed smooth, because actualStream is discontinuous when the flow variable gets through zero. This case was indeed fixed in #5642.

However, the actualStream() operator by itself is not continuous and if not multiplied by its own flow variable it is explicitly recommended by the specification to generate an event when the flow variable crosses zero, so enclosing it in a smooth(0, ...) operator is not correct and should be avoided.

Attachments (1)

TestActualStream.mo (3.1 KB ) - added by Francesco Casella 4 years ago.

Download all attachments as: .zip

Change History (4)

by Francesco Casella, 4 years ago

Attachment: TestActualStream.mo added

comment:1 by Per Östlund, 4 years ago

I wasn't sure why we added smooth, the code even had a comment with the definition that included smooth even though as you say it's not in the specification. Turns out it was changed in the OF seven years ago in fd504b6e, and when implementing the connection handling in the NF we just copied it.

Anyway, it should be fixed in PR 6671.

comment:2 by Per Östlund, 4 years ago

Resolution: fixed
Status: newclosed

It seems the change didn't cause neither improvements nor regressions in the library coverage tests (there were some changes, but none that can be attributed to this). So unless you have something to add I'll consider this fixed.

comment:3 by Francesco Casella, 4 years ago

I checked the outcome on the test case, looks good. Thanks!

Note: See TracTickets for help on using tickets.