Opened 9 years ago

Closed 21 months ago

Last modified 21 months ago

#1220 closed enhancement (fixed)

Handling of nested input variables

Reported by: jakesson Owned by: Jesper Mattsson
Priority: major Milestone: Future
Component: Modelica/FrontEnd Version: trunk
Keywords: Cc:

Description (last modified by Jesper Mattsson)

Currently, the input prefix is removed for variables that resides inside components, i.e., nested inputs. Only top level inputs are kept as inputs in the flattened model. This makes a lot of sense for nested inputs that are connected, but for unconnected nested inputs it is not clear how to generate top level input, if at all.

One particular case that would be convenient to support, is top-level connector components where all elements have explictly declared causalities in the connector declaration.

This mean that all inputs/outputs in top-level connector instances are inputs/outputs in the flattened model, in addition to top-level inputs/outputs (current implementation). This includes all elements of top-level connector instances that are themselves declared input/output.


package ConnectorTest 
  connector RealInput 
    input Real u;
  end RealInput;
  connector RealOutput 
    output Real y;
  end RealOutput;
  model FirstOrder 
    RealInput my_u;
    RealOutput my_y;
    Real x(start=1);
    der(x) = -x + my_u.u;
    my_y.y = x;
  end FirstOrder;
  model FirstOrderTest1 
    RealInput top_u;
    FirstOrder sys;
  end FirstOrderTest1;
  model FirstOrderTest2 
    input Real top_u;
    FirstOrder sys;
    top_u = sys.my_u.u;
  end FirstOrderTest2;

end ConnectorTest;

Clearly, FirstOrderTest2 gives a top level input, but currently, FirstOrderTest2 does not.

Change History (10)

comment:1 Changed 9 years ago by hubertus

I am not sure what the specification says, but Dymola treats only top-level inputs in a special way (e.g. allows input through files, or creates an input connector if tranlated as an S-Function. I am fairly sure that this is convention and not clearly laid out in the specification.

comment:2 Changed 9 years ago by jakesson

Milestone: 1.5.xFuture

comment:3 Changed 6 years ago by Tove Bergdahl

Owner: set to Jesper Mattsson
Status: newassigned

comment:4 Changed 5 years ago by jakesson

Description: modified (diff)
Type: defectenhancement

comment:5 Changed 5 years ago by jakesson

Description: modified (diff)

comment:6 Changed 5 years ago by Jesper Mattsson

Description: modified (diff)

comment:7 Changed 5 years ago by Jesper Mattsson

Description: modified (diff)

How about the following example:

record R1
  Real x;
  Real y;
end R1;

record R2
  input Real x;
  output Real y;
end R2;

model M
  input R1 r1;
  R2 r2;
  r2.y = r2.x + r1.x + r1.y;
end M;

When compiling M, should the members of r1 & r2 be treated as top-level inputs/outputs?

comment:8 Changed 4 years ago by Jesper Mattsson

Looking at some libraries, it seems like we should treat inputs and outputs inside top-level connectors as top-level inputs/outputs.

comment:9 Changed 2 years ago by Jesper Mattsson

Is this still wrong?

comment:10 Changed 21 months ago by Jesper Mattsson

Resolution: fixed
Status: assignedclosed

This has been fixed in other tickets.

Last edited 21 months ago by Jesper Mattsson (previous) (diff)
Note: See TracTickets for help on using tickets.