#3513 closed defect (fixed)
Missing support for operator interval
Reported by: | Lennart Ochel | Owned by: | Lennart Ochel |
---|---|---|---|
Priority: | high | Milestone: | 1.9.4 |
Component: | Run-time | Version: | |
Keywords: | Synchronous Features | Cc: | Maksimov Doe, Rüdiger Franke |
Description (last modified by )
This can be used as test case: Modelica_Synchronous.Examples.CascadeControlledDrive.SubClocked
.
Change History (13)
comment:1 by , 9 years ago
Owner: | changed from | to
---|---|
Status: | new → accepted |
comment:3 by , 9 years ago
Description: | modified (diff) |
---|
comment:4 by , 9 years ago
I think the generated code for interval operator should be something like this:
/* equation index: 129 type: SIMPLE_ASSIGN PI._Ts = interval(PI.u) */ void Modelica_Synchronous_Examples_CascadeControlledDrive_SubClocked_eqFunction_129(DATA *data, threadData_t *threadData) { TRACE_PUSH const int equationIndexes[2] = {1,129}; $PPI$PTs = data->simulationInfo.clocksData[clock_index].interval; TRACE_POP }
The issue is that clock_index
need to be resolved. I think it should be idx
within the function handleTimers in synchronous.c, right? Should we just pass it through the call hierarchy?
comment:5 by , 9 years ago
Cc: | added |
---|
comment:6 by , 9 years ago
The clock index is known for the system for which the equation is generated. In the C++ runtime we generate a constant clockIndex
for each equation. This is passed through one level (from the system to the equation).
void SubClocked::evaluate_129() { const int clockIndex = 2; _PI_P_Ts = _clockInterval[clockIndex - 1]; }
comment:7 by , 9 years ago
According to Modelica specification partitioning algorithm, variables on left and right sides of interval operator belong to the same subpartition. So in fact this operator will always return the interval of current subpartition.
comment:8 by , 9 years ago
Thanks for the input. I adjusted the code generation similar to the cpp runtime.
follow-up: 10 comment:9 by , 9 years ago
Do you also consider models with inferred sample time?
This is important for FMU export. The interval
is not known in this case and must be obtained at simulation time.
comment:10 by , 9 years ago
Compilation is fixed with 3a9e48.
All models mentioned in this ticket do simulate now. However I didn't compare the results yet.
Replying to rfranke:
Do you also consider models with inferred sample time?
I think that was already implemented, but I am not sure right now. Once we have verified simulations available it will be much easier to identify what is missing.
It's the same issue for: