Skip to content

Usage of Tables #4743

Open
Open

Description

@AHaumer

Is it safe to use the external objects Modelica.Blocks.Types.{ExternalCombiTimeTable, ExternalCombiTable1D, ExternalCombiTable2D} and the functions Modelica.Blocks.Tables.Internal.* in own models without using a Tables-Block?
e.g.
model MyModel
import Modelica.Blocks.Types.ExternalCombiTable1D;
import Modelica.Blocks.Types.Smoothness;
import Modelica.Blocks.Types.Extrapolation;
import Modelica.Blocks.Tables.Internal.getTable1DValue;
parameter Real table[:,2] = ...;
Real x = ...;
Real y = getTable1DValue(tableID, 1, x);
protected
parameter ExternalCombiTable1D tableID=ExternalCombiTable1D(
"NoName", "NoName",
material.table, 2:2,
Smoothness.MonotoneContinuousDerivative2,
Extrapolation.HoldLastPoint,
false, ",", 0) "External table object";
end;
Sometimes it is desired to utilize the same interpolation in an own (text-based / non-graphical) model without workaround:
model MyModel
Modelica.Blocks.Sources.RealExpression realExpression;
Modelica.Blocks.Tables.CombiTable1Ds combiTable1Ds;
equation
connect(realExpression.y, combiTable1Ds.u);
end MyModel;

Activity

  1. added
    L: BlocksIssue addresses Modelica.Blocks
    discussionDiscussion issue that it not necessarily related to a concrete bug or feature
    help wantedExtra attention is needed
    on Feb 17, 2026
  2. AHaumer commented on Feb 18, 2026

    @AHaumer
    ContributorAuthor

    package Internal "Internal external object definitions for table functions that should not be directly utilized by the user"
    @beutlich @HansOlsson does that mean that usage of these functions is forbidden?

  3. HansOlsson commented on Feb 19, 2026

    @HansOlsson
    Contributor

    package Internal "Internal external object definitions for table functions that should not be directly utilized by the user" @beutlich @HansOlsson does that mean that usage of these functions is forbidden?

    The statement indicates that it is discouraged, not forbidden; see https://www.rfc-editor.org/rfc/rfc2119

    SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
    there may exist valid reasons in particular circumstances when the
    particular behavior is acceptable or even useful, but the full
    implications should be understood and the case carefully weighed
    before implementing any behavior described with this label.

    To me it is related to #4698 - i.e., the compatibility if you use Internal packages. (There's a similar issue with using the C-functions.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

L: BlocksIssue addresses Modelica.BlocksdiscussionDiscussion issue that it not necessarily related to a concrete bug or featurehelp wantedExtra attention is needed

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions