Add extra variables for easier check of derivative calculations of table blocks

[HansOlsson]

In order to check the derivative-approximation a simple possibility is to just integrate it and see that it is roughly the same as the original. It doesn't replace the reference results, but it helps in analyzing potential errors.

As an example simulate ModelicaTest.Tables.CombiTable1Ds.Test34 and plot d_t_new.u, integrated, integrated2. They should all be almost identical to each other. The parameter with Evaluate=false is added so that tools don't have the amazing idea of seeing through the differentiation combined with integration. There is no need to have references for these variables.

Possible extensions:

• assert for equality (a bit complicated due to double integration)
• turn it into a block
  • so that we don't mix graphics and text
  • it can be re-used for derivative test-models not extending from those base-classes
• figure-annotations

Summary by CodeRabbit

• New Features
  • Enhanced several dynamic models with improved integration and derivative calculations.
  • Refined simulation modules now establish advanced relationships between input signals and their computed rates of change, boosting the accuracy and complexity of system dynamics.

[beutlich]

1. Is this related to ContinuousClock is not suitable for testing derivatives in ModelicaTest.Tables #4325?
2. Should the comparisonSignals.txt files be adapted to actually track the new signals?

[HansOlsson]

1. Is this related to ContinuousClock is not suitable for testing derivatives in ModelicaTest.Tables #4325?
2. Should the comparisonSignals.txt files be adapted to actually track the new signals?

1. Not really; both are good ideas.
2. No. They are intended to compare within the model - regardless of any reference. Also having them in the reference just seem unnecessary.

[beutlich]

OK for me.

[coderabbitai]

Walkthrough

The pull request introduces new variables, parameters, and equations in several Modelica files. In the TestDer models, a new real variable integrated is added (initialized with d_t_new.u) along with a parameter factor1 to manage symbolic simplification. A derivative equation is defined as der(integrated) = factor1 * d_t_new.y. In the TestDer2 models, similar changes are made by adding integrated2 and der_integrated2 with corresponding derivative equations that involve both first and second derivatives, using outputs from d_t_new and d2_t_new.

Changes

Files	Change Summary
ModelicaTest/Tables/CombiTable1Ds.mo ModelicaTest/Tables/CombiTable1Dv.mo	In TestDer: Added Real integrated (initialized to d_t_new.u), parameter Real factor1; added equation der(integrated) = factor1 * d_t_new.y. In TestDer2: Added Real integrated2 and Real der_integrated2 with equations to define der(integrated2) and der(der_integrated2) (using d2_t_new.y).
ModelicaTest/Tables/CombiTable2Ds.mo ModelicaTest/Tables/CombiTable2Dv.mo	Similar modifications as in the CombiTable1D files, with the addition of descriptive annotations. In TestDer: Integrated variable annotated as "Integral that should equal d_t_new.u" and a factor1 parameter annotated to prevent symbolic simplification, with its corresponding derivative equation. In TestDer2: Added integrated2 and der_integrated2 with derivative equations.
ModelicaTest/Tables/CombiTimeTable.mo	Introduced new variables and equations in both TestDer and TestDer2. In TestDer: Added Real integrated and parameter Real factor1 (with integrated initialized to d_t_new.u) and defined its derivative as factor1 * d_t_new.y. In TestDer2: Added integrated2 and der_integrated2 with similar derivative relationships.

Sequence Diagram(s)

sequenceDiagram
    participant DT as d_t_new
    participant TD as TestDer
    participant Fac as factor1
    DT->>TD: Provide u (initialize integrated)
    DT->>TD: Send y for derivative calculation
    TD->>TD: Compute der(integrated) = Fac * y

Loading

sequenceDiagram
    participant DT as d_t_new
    participant D2T as d2_t_new
    participant TD2 as TestDer2
    participant Fac as factor1
    DT->>TD2: Provide u (initialize integrated2)
    TD2->>TD2: Compute der(integrated2) = Fac * der_integrated2
    D2T->>TD2: Send y for second derivative (der(der_integrated2))

Loading

Poem

I'm just a bunny with code so neat,
Hopping through equations with joyful feet!
Integrated values and derivatives in play,
Factor1 guides my bounds all day.
In the Modelica garden, I happily roam,
Celebrating changes in a mathematical home!

---

📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between be949b2 and 37e6da2.

📒 Files selected for processing (5)

• ModelicaTest/Tables/CombiTable1Ds.mo (1 hunks)
• ModelicaTest/Tables/CombiTable1Dv.mo (1 hunks)
• ModelicaTest/Tables/CombiTable2Ds.mo (1 hunks)
• ModelicaTest/Tables/CombiTable2Dv.mo (1 hunks)
• ModelicaTest/Tables/CombiTimeTable.mo (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms (1)

• GitHub Check: external_c_checks_cmake_windows-msvc

🔇 Additional comments (18)

ModelicaTest/Tables/CombiTable1Dv.mo (4)

16-17: Well-crafted diagnostic variables for derivative verification.

The addition of integrated and factor1 variables provides an elegant way to verify derivative approximations by integrating them and comparing to the original signal. The Evaluate=false annotation is crucial to prevent symbolic simplification from optimizing away this verification mechanism.

---

19-21: Good implementation of initial equation and derivative relationship.

The initialization of integrated to equal d_t_new.u and the equation der(integrated)=factor1*d_t_new.y create a mathematical verification loop that will allow users to check if the derivatives are properly approximated in the table blocks.

---

28-32: Well-designed second-order verification setup.

The integrated2 and der_integrated2 variables extend the verification to second derivatives, allowing more comprehensive validation of the table interpolation methods. The initialization equations are correctly set to match the expected mathematical behavior.

---

34-35: Properly chained derivative equations for second-order verification.

These equations correctly implement the chain of integration that allows for verifying both first and second derivatives simultaneously, as described in the PR objectives. This will be useful for testing higher-order interpolation methods.

ModelicaTest/Tables/CombiTimeTable.mo (4)

13-14: Consistent implementation of diagnostic variables.

The addition of integrated and factor1 variables matches the pattern implemented in other files, providing a unified approach to derivative verification across different table types.

---

16-18: Correctly implemented initialization and derivative relationship.

The initial equation and derivative equation create the mathematical verification framework needed to validate the derivatives generated by the CombiTimeTable.

---

25-27: Well-structured second-order verification variables.

The integrated2 and der_integrated2 variables complete the second-derivative verification framework, consistent with implementations in other table types.

---

28-32: Proper initialization and derivative equations for second-order checks.

These equations correctly set up the mathematical relationships needed to verify both first and second derivatives in the time table implementation.

ModelicaTest/Tables/CombiTable1Ds.mo (4)

16-17: Well-designed verification variables for derivative testing.

The addition of integrated and factor1 with appropriate annotation provides the mathematical framework needed to verify the correctness of table derivatives.

---

19-21: Correctly implemented integration verification.

The initialization and derivative equations properly establish the mathematical relationship that will allow users to verify derivatives as mentioned in the PR description for Test34.

---

28-32: Well-structured second-order verification variables and initialization.

The integrated2 and der_integrated2 variables with their initial equations correctly extend the verification to second derivatives.

---

34-35: Properly implemented second-order derivative verification.

These equations correctly establish the chain of integrations needed to verify second derivatives, completing the verification framework.

ModelicaTest/Tables/CombiTable2Dv.mo (4)

13-14: Consistent implementation of derivative verification variables.

Adding integrated and factor1 extends the derivative verification framework to 2D table implementations, maintaining consistency with other table types.

---

16-18: Mathematically sound verification approach.

The initialization and derivative equation correctly implement the mathematical relationship that allows integration to verify differentiation.

---

25-29: Well-structured second-order verification for 2D tables.

The integrated2 and der_integrated2 variables with their initial equations properly extend the verification framework to second derivatives in 2D tables.

---

31-32: Properly implemented second-order integration chain.

These equations complete the verification framework by establishing the proper chain of integrations needed to verify second derivatives.

ModelicaTest/Tables/CombiTable2Ds.mo (2)

13-18: Well-implemented verification mechanism for derivative calculations.

The addition of integrated and factor1 creates an elegant verification mechanism by integrating the derivative approximation. When the derivative is accurate, the integrated value should match the original signal, providing a visual verification method.

The parameter factor1 with Evaluate=false is appropriately implemented to prevent symbolic simplification that might otherwise eliminate the integration+differentiation test mechanism.

---

25-32: Comprehensive second-derivative verification extension.

The implementation for TestDer2 extends the verification mechanism to second derivatives with well-structured equations and variables. The relationship between integrated2, der_integrated2, and the derivatives from d_t_new and d2_t_new is correctly established to enable verification through comparison of integrated signals.

The initialization of variables ensures proper starting conditions for the verification mechanism.

---

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai plan to trigger planning for file edits and PR creation.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[HansOlsson]

The summary by coderabbit misses the intent as far I can tell, and a text " In the TestDer models, a new real variable integrated is added (initialized with d_t_new.u) along with a parameter factor1 to manage symbolic simplification" is misleading as the intent is to "avoid" (not "manage") symbolic simplifications.