Modified by otter on 28 Nov 2007 15:14 UTC
The conventions that you describe have been documented and have been available in the Modelica Standard Library from the beginning. Since MSL 2.1 this is described in "Modelica.UsersGuide.Conventions".
[[BR]]To improve the current status, it would be best to list concretly the issues for every library and send this to the corresponding library officer.

Reported by mtiller on 28 Nov 2007 14:35 UTC
As far as I know, there are no documented naming conventions for the Modelica Standard Library. This makes the library look like a patchwork of pieces. For example, if in the semiconductor models (and perhaps this is related to "spice compatibility"?), you see parameters that start with capital letters (e.g. Phic). The same parameter name in other libraries might be written a C_phi or Cphi or phi_c (the last being my preference).

Initially, I thought we had an informal convention that parameter names should be all lower case except in cases where the it as a single letter (e.g. R). Furthermore, if there were multiple words the words would be separated by underscores. Finally, abbreviations were very much frowned upon. I see "hints" of these conventions in the library, but they are not followed in anything close to a consistent manner.

We should really formalize some naming conventions so that at least future development can look consistent (and not just for instances, parameters and constants but also for class and package names).

Migrated-From: https://trac.modelica.org/Modelica/ticket/27

Reported by AHaumer on 19 Nov 2007 09:24 UTC
All elements with Rotational.support are wrong or at least misleading;
consider friction: fine that the friction torque appears at the support,
but the relative angular velocity which defines friction torque is NOT the absolute angular velocity of the shaft BUT the relative angular velocity of the shaft against the support! We may discuss the sources (like position, whether we want to define an absolute position or the position against support - which would be much easier to understand!)
Translational (in MSL 2.2.1) is not affected since we have no support.

Migrated-From: https://trac.modelica.org/Modelica/ticket/16

Modified by dietmarw on 16 Nov 2007 11:38 UTC
The code in source:/trunk/Modelica/Utilities/Examples.mo

has

function expression
**protected**  
**encapsulated** function term "Evaluate term of an expression" 
import Modelica.Utilities.Examples.expression.primary;
... 
end term;
**encapsulated** function primary ...
end primary;
...
end expression;

This uses import of item that is not in a package, and furthermore the item is protected. Remove 'encapsulated', and 'import' and it will automatically work.

Issue is also present in 2.2.2

Reported by HansOlsson on 14 Nov 2007 10:51 UTC
The code in http://trac.modelica.org/MSL/browser/trunk/Modelica/Utilities/Examples.mo

has

function expression
**protected**  
**encapsulated** function term "Evaluate term of an expression" 
import Modelica.Utilities.Examples.expression.primary;
... 
end term;
**encapsulated** function primary ...
end primary;
...
end expression;

This uses import of item that is not in a package, and furthermore the item is protected. Remove 'encapsulated', and 'import' and it will automatically work.

Issue is also present in 2.2.2

Migrated-From: https://trac.modelica.org/Modelica/ticket/8

Reported by dietmarw on 25 Feb 2008 16:02 UTC
This should be changed to 2008 and as MSL3.0 is not publicly announced this could also be put in the MSL3.0 release rather than MSL3.0.1.

I could fix it right away but wouldn't do so without explicit permission.

Migrated-From: https://trac.modelica.org/Modelica/ticket/47

Reported by AHaumer on 10 Dec 2007 17:41 UTC
We should consider renaming of Rotational.Interfaces.flange to "shaftEnd" to be more concise since in many cases "flange" means the mounting of the housing.

Migrated-From: https://trac.modelica.org/Modelica/ticket/31

Reported by otter on 10 Dec 2007 00:12 UTC
In package MultiBody.Forces most of the elements use cardinality. This has to be rewritten, using, e.g., conditional connectors for frame_resolve.

Migrated-From: https://trac.modelica.org/Modelica/ticket/30

Reported by AHaumer on 19 Nov 2007 09:28 UTC
All elements with Rotational.support are wrong or at least misleading;
consider friction: fine that the friction torque appears at the support,
but the relative angular velocity which defines friction torque is NOT the absolute angular velocity of the shaft BUT the relative angular velocity of the shaft against the support! We may discuss the sources (like position, whether we want to define an absolute position or the position against support - which would be much easier to understand!)
Translational (in MSL 3.0) has the same defect since the support has been introduced.

Migrated-From: https://trac.modelica.org/Modelica/ticket/18

Modified by dietmarw on 11 Dec 2007 14:56 UTC
In the MSL the svn property keyword "Id Author Revision Date" is already set on all *.mo files. So why isn't it used to create the versionBuild and versionDate fields automatically.

All what needs to be done is to change the code to display the following:

  versionBuild="$Rev:$",
  versionDate="$Date::             $",

Note the double colon and the number of white spaces in the versionDate field. This results in a truncated Date string.
I.e.

versionDate="$Date:: 2007-12-11 #$",

instead of

versionDate="$Date: 2007-12-11 15:33:48 +0100 (tir, 11 des 2007)"

Reported by dietmarw on 11 Dec 2007 14:54 UTC
In the MSL the svn property keyword "Id Author Revision Date" is already set on all *.mo files. So why isn't it used to create the versionBuild and versionDate fields automatically.

All what needs to be done is to change the code to display the following:

  versionBuild="$Rev:$",
  versionDate="$Date::             $",

Note the double colon and the number of white space in the versionDate field. This results in a truncated Date string.
I.e.

versionDate="$Date:: 2007-12-11 #$",

instead of

versionDate="$Date: 2007-12-11 15:33:48 +0100 (tir, 11 des 2007)"

Migrated-From: https://trac.modelica.org/Modelica/ticket/32

Reported by AHaumer on 22 Nov 2007 14:28 UTC
Redesign of Electrical.Analog.Basic.EMF (support) according to new design of Rotational (55357ac, 7555322) using a conditional support connector.

Migrated-From: https://trac.modelica.org/Modelica/ticket/23

This is a placeholder created during migration to preserve original issue numbers.

Migrated-From: https://trac.modelica.org/Modelica/ticket/43

Reported by dietmarw on 10 Jan 2008 10:03 UTC
I pulled this from the old Migration Issue Tracker _{(as I'm moving all the old items to our new trac website issue tracker at the moment)}:

I (Martin) will write to the authors of the libraries that they perform the conversion. If someone is not doing it, we have to discuss whether to remove the library or that some makes the upgrade (decision should be on a case to case basis)

Migrated-From: https://trac.modelica.org/Modelica/ticket/36

Reported by HansOlsson on 14 Nov 2007 10:53 UTC
Finalize release notes (already quite good, but still many changes not documented).

Migrated-From: https://trac.modelica.org/Modelica/ticket/9

Reported by HansOlsson on 6 Mar 2008 08:13 UTC
None

Migrated-From: https://trac.modelica.org/Modelica/ticket/50

Reported by AHaumer on 19 Nov 2007 09:37 UTC
Translational.Components.MassWithStopAndFriction (former Translational.Stop) is unphysical since velocity is re-initialized when the mass hits the stop but no force is calculated:
m . der(v)
A stop can't be modeled this way, a solution might be using a non-linear spring when the mass is near the stop. This doesn't matter in MSL <= 2.2.2 since no support is present (Translational.support was introduced in MSL 3.0).
Recommendation: define Stop / MassWithStopAndFriction as obsolete; model a proper stop.

Migrated-From: https://trac.modelica.org/Modelica/ticket/20

Modified by mtiller on 29 Nov 2007 14:01 UTC
I happened to be looking at the "current source" elements in Modelica.Electrical.Analog.Sources and I found it rather strange that the sign convention is that positive current flow is from the positive pin to the negative pin. Is this a typical convention?

I imagine this would be quite difficult to fix but I thought that I should at least raise the issue.

Modified by dietmarw on 29 Nov 2007 09:07 UTC
I happened to be looking at the "current source" elements in Modelica.Electrical.Analog.Sources and I found it rather strange that the sign convention is that positive current flow is from the positive pin to the negative pin. Is this a typical convention?

I imagine this would be quite difficult to fix but I thought that I should at least raise the issue.

Reported by mtiller on 28 Nov 2007 14:20 UTC
I happened to be looking at the "current source" elements in Modelica.Electrical.Analog.Sources and I found it rather strange that the sign convention is that positive current flow is from the positive pin to the negative pin. Is this a typical convention?

I imagine this would be quite difficult to fix but I thought that I should at least raise the issue.

Migrated-From: https://trac.modelica.org/Modelica/ticket/26

This is a placeholder created during migration to preserve original issue numbers.

Migrated-From: https://trac.modelica.org/Modelica/ticket/10

Reported by AHaumer on 7 Feb 2008 16:48 UTC

model Test 
  annotation (uses(Modelica(version="3.0")));
  Modelica.Blocks.Sources.CombiTimeTable combiTimeTable(table=[0,0; 1,1], 
    extrapolation=Modelica.Blocks.Types.Extrapolation.Periodic)
    annotation (Placement(transformation(extent={{-20,0},{0,20}})));
end Test;

Dymola's reply:

dsmodel.obj : error LNK2019: unresolved external symbol _ModelicaTables_CombiTimeTable_init referenced in function _Modelica_Blocks_Sources_CombiTimeTable_tableTimeInit_M
dsmodel.obj : error LNK2019: unresolved external symbol _ModelicaTables_CombiTimeTable_interpolate referenced in function _Modelica_Blocks_Sources_CombiTimeTable_tableTimeIpo_M
dsmodel.obj : error LNK2019: unresolved external symbol _ModelicaTables_CombiTimeTable_maximumTime referenced in function _Modelica_Blocks_Sources_CombiTimeTable_tableTimeTmax_M
dsmodel.obj : error LNK2019: unresolved external symbol _ModelicaTables_CombiTimeTable_minimumTime referenced in function _Modelica_Blocks_Sources_CombiTimeTable_tableTimeTmin_M
dymosim.exe : fatal error LNK1120: 4 unresolved externals
Error generating Dymosim.

Migrated-From: https://trac.modelica.org/Modelica/ticket/46

Reported by AHaumer on 19 Nov 2007 09:28 UTC
All elements with Translational.support are wrong or at least misleading;
consider friction: fine that the friction force appears at the support,
but the relative velocity which defines friction force is NOT the absolute velocity of the shaft BUT the relative velocity of the shaft against the support! We may discuss the sources (like position, whether we want to define an absolute position or the position against support - which would be much easier to understand!)
Rotational (in MSL 2.2.1, 2.2.2 and 3.0) has the same defect.

Migrated-From: https://trac.modelica.org/Modelica/ticket/19

Reported by otter on 19 Nov 2007 00:02 UTC
The components have been changed in a non-backward compatible way and a conversion script is needed

Migrated-From: https://trac.modelica.org/Modelica/ticket/13

This is a placeholder created during migration to preserve original issue numbers.

Migrated-From: https://trac.modelica.org/Modelica/ticket/49

This is a placeholder created during migration to preserve original issue numbers.

Migrated-From: https://trac.modelica.org/Modelica/ticket/52

This is a placeholder created during migration to preserve original issue numbers.

Migrated-From: https://trac.modelica.org/Modelica/ticket/40

Modified by dietmarw on 2 Jan 2008 13:30 UTC
I just stumbled across a minor error in the documentation (or in the SVN repository structure)

In [source:trunk/Modelica/package.mo@935#L661 Modelica.UsersGuide.ReleaseNotes] it says:

Released branch

Example: "Modelica/tags/V2_2_1/Modelica"

But the structure of the SVN-repository under tags is without the Modelica level (i.e. Modelica/tags/V2_2_1/package.mo).

On the other hand all other branches and the trunk follow the structure of having a toplevel "Modelica" folder first. So either the tags structure needs to be changed to match the folder structure of all the other branches and the trunk (I can do that quite easily and I think this is preferable) or the [wiki:ReleaseNotes] need to be changed. So what's the best solution?

PS: I posted this before in the design-list but never got a reply therefore I'm feeding this to the tracker.

Reported by dietmarw on 2 Jan 2008 05:38 UTC
I just stumbled across a minor error in the documentation (or in the SVN repository structure)

In [source:trunk/Modelica/package.mo@935#L661 Modelica.UsersGuide.ReleaseNotes] it says:

Released branch

Example: "Modelica/tags/V2_2_1/Modelica"

But the structure of the SVN-repository under tags is without the Modelica level (i.e. Modelica/tags/V2_2_1/package.mo).

On the other hand all other branches and the trunk follow the structure of having a toplevel "Modelica" folder first. So either the tags structure needs to be changed to match the folder structure of all the other branches and the trunk (I can do that quite easily and I think this is preferable) or the [wiki:ReleaseNotes] need to be changed. So what's the best solution?

PS: I posted this before in the design-list but never got a reply therefore I'm feeding this to the tracker.

Migrated-From: https://trac.modelica.org/Modelica/ticket/34

Reported by AHaumer on 13 Dec 2007 10:04 UTC
Testing Modelica.Utilities.Examples.readRealParameterModel, we get the error message:
Not possible to open file "Modelica/Utilities/data/Examples_readRealParameters.txt" for reading:
No such file or directory
Since directory "Modelica" doesn't exist, but MSL is installed in "Modelica 3.0".

Migrated-From: https://trac.modelica.org/Modelica/ticket/33

This is a placeholder created during migration to preserve original issue numbers.

Migrated-From: https://trac.modelica.org/Modelica/ticket/42

Reported by adrpo on 6 Mar 2008 21:30 UTC
The IF97_Utilities.mo contains a wrong escape sequence which SHOULD BE REJECTED by any Modelica tool. There is a typo in the line:

(in directory Modelica\help\Documentation\IF97documentation):
As you can see the last \IF97... should be \IF97...

Cheers,
Adrian Pop

Migrated-From: https://trac.modelica.org/Modelica/ticket/54

This is a placeholder created during migration to preserve original issue numbers.

Migrated-From: https://trac.modelica.org/Modelica/ticket/41

Reported by dietmarw on 10 Mar 2008 11:27 UTC
Dear Martin,
I retrieved this issue from the an old issue tracker on our website and moved the issue here before deleting that obsolete issue tracker.
Please feel free to put this on "invalid" if this is not an issue anymore.

• Gerd Kurzbach proposed to introduce a timer for embedded systems
  (missing "improvement suggestion")

Migrated-From: https://trac.modelica.org/Modelica/ticket/56

Reported by hubertus on 7 Dec 2007 14:54 UTC
Dear all,
It seems that brake in Modelica.Mechanics.Rotational.Components is not backward compatible with MSL 2.2.2, due to a sign change in equation:
flange_a.tau + flange_b.tau + tau = 0; (changed sign of tau)

Practical this means that a positive input to break now creates an acceleration.

Attached is a simple example based on MSL 3 and MSL 2.2.2.

Best regards,
Johan Windahl, Modelon

Migrated-From: https://trac.modelica.org/Modelica/ticket/29

This is a placeholder created during migration to preserve original issue numbers.

Migrated-From: https://trac.modelica.org/Modelica/ticket/51

Reported by JustinKGriffiths on 31 Jan 2008 20:10 UTC
I believe there is a mistake in the Standard Library. Currently I’m using version 2.2.1 but it is also in the latest release, version 2.2.2. In the …Rotational.ElastoBacklash model the torque function has a mistake. The function currently reads as follows,

tau = if b2 > b_min then (if phi_rel > b2 then c*(phi_rel - phi_rel0 - b2)
+ d*w_rel else (if phi_rel < -b2 then c*(phi_rel - phi_rel0 + b2) + d*
w_rel else 0)) else c*(phi_rel - phi_rel0) + d*w_rel;

At first glance this all looks fine but when both the backlash (b2) and phi_rel0 are non-zero then issues arise. Take for instance if b2 > 0 and phi_rel0 > 0 and phi_rel > b2 then (phi_rel – phi_rel0 – b2) < 0 which causes phi_rel to increase instead decrease. The same happens on the negative side when phi_rel < -b2 and phi_rel0 < 0. I believe the function should read,

tau = if b2 > b_min then (if phi_rel – phi_rel0 > b2 then c*(phi_rel - phi_rel0 - b2)
+ d*w_rel else (if phi_rel – phi_rel0 < -b2 then c*(phi_rel - phi_rel0 + b2) + d*
w_rel else 0)) else c*(phi_rel - phi_rel0) + d*w_rel;

This will remove the discontinuities from the equation.

Migrated-From: https://trac.modelica.org/Modelica/ticket/44

Modified by dietmarw on 7 Feb 2008 08:36 UTC
There are several places present in the current MSL where the annotation uses(Modelica(version="xxx")) is present (see below).
I think all of them should be removed as it makes no sense to have them present within the library.

Also (@HUBERTUS) the Incompressible.mo uses Modelica_Interpolation. Is that still correct?

A global grep found the following places:
source:/trunk/Modelica/Electrical/Analog/Examples/CauerLowPassOPV.mo#L5
source:/trunk/Modelica/Electrical/Analog/Examples/CauerLowPassSC.mo#L11
source:/trunk/Modelica/Electrical/Analog/Examples/CauerLowPassSC.mo#L86
source:/trunk/Modelica/Electrical/Analog/Examples/CauerLowPassSC.mo#L162
source:/trunk/Modelica/Electrical/Analog/Sensors.mo#L243
source:/trunk/Modelica/Mechanics/MultiBody/parts.mo#L2018
source:/trunk/Modelica/Mechanics/MultiBody/parts.mo#L2172
source:/trunk/Modelica/Media/Water/IF97_Utilities.mo#L4140
source:/trunk/Modelica/Media/Incompressible.mo#L1016
source:/trunk/Modelica/Thermal/FluidHeatFlow.mo#L138

Reported by dietmarw on 7 Feb 2008 08:34 UTC
There are several places present in the current MSL where the annotation uses(Modelica(version="xxx")) is present (see below).
I think all of them should be removed as it makes no sense to have them present within the library.

Also (@HUBERTUS) the Incompressible.mo uses Modelica_Interpolation. Is that still correct?

A global grep found the following places:
source:/trunk/Modelica/Electrical/Analog/Examples/CauerLowPassOPV.mo#L5CauerLowPassSC.mo
source:/trunk/Modelica/Electrical/Analog/Examples/CauerLowPassSC.mo#L11
source:/trunk/Modelica/Electrical/Analog/Examples/CauerLowPassSC.mo#L86
source:/trunk/Modelica/Electrical/Analog/Examples/CauerLowPassSC.mo#L162
source:/trunk/Modelica/Electrical/Analog/Sensors.mo#L243
source:/trunk/Modelica/Mechanics/MultiBody/parts.mo#L2018
source:/trunk/Modelica/Mechanics/MultiBody/parts.mo#L2172
source:/trunk/Modelica/Media/Water/IF97_Utilities.mo#L4140
source:/trunk/Modelica/Media/Incompressible.mo#L1016
source:/trunk/Modelica/Thermal/FluidHeatFlow.mo#L138

Migrated-From: https://trac.modelica.org/Modelica/ticket/45

Reported by otter on 29 Nov 2007 19:31 UTC
The test model

Media.Examples.SolveOneNonlinearEquation.Inverse_sh_TX

computes s1 and s2 via different equations (one of them the inverse). However s1 is equal to s2. There is an offset. This seem to indicate, that somehow a different integration constant is used. This seems to be a bug.

Migrated-From: https://trac.modelica.org/Modelica/ticket/28

This is a placeholder created during migration to preserve original issue numbers.

Migrated-From: https://trac.modelica.org/Modelica/ticket/53

Reported by dietmarw on 26 Feb 2008 10:18 UTC
During the test phase of MSL3.0 the folder

• source:/trunk/TestTables
  and the file
• source:/trunk/MSL30-near-final.zip
  where placed inside the trunk. By that the trunk looks rather messy and I would suggest to remove the zip file ASAP and move the TestTables folder inside source:/trunk/ModelicaDesign.

Migrated-From: https://trac.modelica.org/Modelica/ticket/48

Reported by AHaumer on 19 Nov 2007 00:23 UTC
Write a UsersGuide-package for Translational, similar as Rotational.

Migrated-From: https://trac.modelica.org/Modelica/ticket/15

Reported by AHaumer on 19 Nov 2007 09:26 UTC
All elements with Rotational.support are wrong or at least misleading;
consider friction: fine that the friction torque appears at the support,
but the relative angular velocity which defines friction torque is NOT the absolute angular velocity of the shaft BUT the relative angular velocity of the shaft against the support! We may discuss the sources (like position, whether we want to define an absolute position or the position against support - which would be much easier to understand!)
Translational (in MSL 2.2.2) is not affected since we have no support.

Migrated-From: https://trac.modelica.org/Modelica/ticket/17

Reported by AHaumer on 19 Nov 2007 00:22 UTC
Redesign ElastoGap the same way as Rotational.ElastoBacklash to achieve a smooth force (no "overshoot" due to damping force)

Migrated-From: https://trac.modelica.org/Modelica/ticket/14

Modified by dietmarw on 29 Nov 2007 10:14 UTC
It is quite annoying that there are components in the standard library (e.g springs, dampers) that have parameters that are "Real" with unit attribute. The SI units library should be extended to include types to support all the parameter types of standard library components.

Not only is this inconsistent (some components have to specify their parameter units while others do not) but it means repeated code (e.g. between Spring and SpringDamper) which is a bad practice and should not be reinforced by the standard library.

In the rotational package, (at least) the following components have this issue: Spring, SpringDamper, Damper, ElastoBacklash, IdealGearR2T

In the multibody package, (at least) the following components have this issue: Spring, Damper, SpringDamperParallel, SpringDamperSeries

In the translational package, (at least) the following components have this issue: Stop, Spring, Damper, SpringDamper, ElastoBacklash

In the heat transfer package, (at least) the following components have this issue: BodyRadiation, FixedHeatFlow, PrescribedHeatFlow

In the electrical package, (at least) the following components have this issues: HeatingResistor, EMF, IdealCommutingSwitch, IdealIntermediateSwitch, ControlledIdealCommutingSwitch, ControlledIdealIntermediateSwitch, IdealOpAmpLimited, IdealDiode, IdealOpeningSwitch, IdealClosingSwitch, ControlledIdealOpeningSwitch, ControlledIdealClosingSwitch

Modified by dietmarw on 27 Nov 2007 16:29 UTC
It is quite annoying that there are components in the standard library (e.g springs, dampers) that have parameters that are "Real" with unit attribute. The SI units library should be extended to include types to support all the parameter types of standard library components.

Not only is this inconsistent (some components have to specify their parameter units while others do not) but it means repeated code (e.g. between Spring and SpringDamper) which is a bad practice and should not be reinforced by the standard library.

In the rotational package, (at least) the following components have this issue: Spring, SpringDamper, Damper, ElastoBacklash, IdealGearR2T

In the multibody package, (at least) the following components have this issue: Spring, Damper, SpringDamperParallel, SpringDamperSeries

In the translational package, (at least) the following components have this issue: Stop, Spring, Damper, SpringDamper, ElastoBacklash

In the heat transfer package, (at least) the following components have this issue: BodyRadiation, FixedHeatFlow, PrescribedHeatFlow

In the electrical package, (at least) the following components have this issues: HeatingResistor, EMF, IdealCommutingSwitch, IdealIntermediateSwitch, ControlledIdealCommutingSwitch, ControlledIdealIntermediateSwitch, IdealOpAmpLimited, IdealDiode, IdealOpeningSwitch, IdealClosingSwitch, ControlledIdealOpeningSwitch, ControlledIdealClosingSwitch

Modified by dietmarw on 27 Nov 2007 14:02 UTC
It is quite annoying that there are components in the standard library (e.g springs, dampers) that have parameters that are "Real" with unit attribute. The SI units library should be extended to include types to support all the parameter types of standard library components.

Not only is this inconsistent (some components have to specify their parameter units while others do not) but it means repeated code (e.g. between Spring and SpringDamper) which is a bad practice and should not be reinforced by the standard library.

In the rotational package, (at least) the following components have this issue: Spring, SpringDamper, Damper, ElastoBacklash, IdealGearR2T

In the multibody package, (at least) the following components have this issue: Spring, Damper, SpringDamperParallel, SpringDamperSeries

In the translational package, (at least) the following components have this issue: Stop, Spring, Damper, SpringDamper, ElastoBacklash

In the heat transfer package, (at least) the following components have this issue: BodyRadiation, FixedHeatFlow, PrescribedHeatFlow

In the electrical package, (at least) the following components have this issues: HeatingResistor, EMF, IdealCommutingSwitch, IdealIntermediateSwitch, ControlledIdealCommutingSwitch, ControlledIdealIntermediateSwitch, IdealOpAmpLimited, IdealDiode, IdealOpeningSwitch, IdealClosingSwitch, ControlledIdealOpeningSwitch, ControlledIdealClosingSwitch

Modified by dietmarw on 27 Nov 2007 13:59 UTC
It is quite annoying that there are components in the standard library (e.g springs, dampers) that have parameters that are "Real" with unit attribute. The SI units library should be extended to include types to support all the parameter types of standard library components.

Not only is this inconsistent (some components have to specify their parameter units while others do not) but it means repeated code (e.g. between Spring and SpringDamper) which is a bad practice and should not be reinforced by the standard library.

In the rotational package, (at least) the following components have this issue: Spring, SpringDamper, Damper, ElastoBacklash, IdealGearR2T

In the multibody package, (at least) the following components have this issue: Spring, Damper, SpringDamperParallel, SpringDamperSeries

In the translational package, (at least) the following components have this issue: Stop, Spring, Damper, SpringDamper, ElastoBacklash

In the heat transfer package, (at least) the following components have this issue: BodyRadiation, FixedHeatFlow, PrescribedHeatFlow

In the electrical package, (at least) the following components have this issues: HeatingResistor, EMF, IdealCommutingSwitch, IdealIntermediateSwitch, ControlledIdealCommutingSwitch, ControlledIdealIntermediateSwitch, IdealOpAmpLimited, IdealDiode, IdealOpeningSwitch, IdealClosingSwitch, ControlledIdealOpeningSwitch, ControlledIdealClosingSwitch

Reported by mtiller on 26 Nov 2007 21:59 UTC
It is quite annoying that there are components in the standard library (e.g springs, dampers) that have parameters that are "Real" with unit attribute. The SI units library should be extended to include types to support all the parameter types of standard library components.

Not only is this inconsistent (some components have to specify their parameter units while others do not) but it means repeated code (e.g. between Spring and SpringDamper) which is a bad practice and should not be reinforced by the standard library.

In the rotational package, (at least) the following components have this issue: Spring, SpringDamper, Damper, ElastoBacklash, IdealGearR2T

In the multibody package, (at least) the following components have this issue: Spring, Damper, SpringDamperParallel, SpringDamperSeries

In the translational package, (at least) the following components have this issue: Stop, Spring, Damper, SpringDamper, ElastoBacklash

In the heat transfer package, (at least) the following components have this issue: BodyRadiation, FixedHeatFlow, PrescribedHeatFlow

In the electrical package, (at least) the following components have this issues: HeatingResistor, EMF, IdealCommutingSwitch, IdealIntermediateSwitch, ControlledIdealCommutingSwitch, ControlledIdealIntermediateSwitch, IdealOpAmpLimited, IdealDiode, IdealOpeningSwitch, IdealClosingSwitch, ControlledIdealOpeningSwitch, ControlledIdealClosingSwitch

Migrated-From: https://trac.modelica.org/Modelica/ticket/25

Reported by AHaumer on 22 Nov 2007 14:32 UTC
The Rotational.Sources (Position, Speed, Accelerate, Move) define the movement of the flange relative to the support connector (in previous version this was - misleading - defined as absolute movement).
Check whether a conversion script is necessary or possible.

Migrated-From: https://trac.modelica.org/Modelica/ticket/24

Reported by HansOlsson on 14 Nov 2007 11:01 UTC
I believe the relevant issues are:

• In my opinion there are some problems with default values for FilledShape. The default value for lineColor attribute is black (see 3.0 specification 14.5.1.2.). But in the Modelica code for “Library” icon I can not find a modification for lineColor. So the lines in the icon should be drawn in black instead in blue.
• It seems to me that the color which is used for Text primitives is defined by lineColor attribute. The only implementation of Modelica 2.2 language specification in OpenModelica uses fillColor for text rendering instead. Further versions of specification should include an appropriate hint.
• The current release of Modelica Standard Library 3.0 contains a lot of obsolete style() attributes for graphical properties.
• At the moment I do not understand the correct usage of origin and extent attributes in Transformation record used for placement of components. 3.0 specification says: “The origin attribute defines the position of the component in the coordinate system of the enclosing class. The extent defines the position, size and flipping of the component, relative to the origin attribute.” In the current release of Modelica Standard Library 3.0 the origin attribute is used very rarely. I understand that a translation can be defined by extent attribute as well as origin attribute but a “Usage Guide” or an example would be helpful for me to understand the correct interpretation of transformations.

Migrated-From: https://trac.modelica.org/Modelica/ticket/11

This is a placeholder created during migration to preserve original issue numbers.

Migrated-From: https://trac.modelica.org/Modelica/ticket/38

Reported by adrpo on 6 Mar 2008 21:32 UTC
The IF97_Utilities.mo contains a wrong escape sequence which SHOULD BE REJECTED by any Modelica tool. There is a typo in the line:

(in directory Modelica\help\Documentation\IF97documentation):
As you can see the last \IF97... should be [file://\IF97 \IF97]...

Cheers,
Adrian Pop

Migrated-From: https://trac.modelica.org/Modelica/ticket/55

Reported by otter on 16 Nov 2007 09:43 UTC
Rotational was restructured and changed a lot. All screenshots have to be redone and the documentation in UsersGuide updated

Migrated-From: https://trac.modelica.org/Modelica/ticket/12

Reported by AHaumer on 22 Nov 2007 14:26 UTC
Redesign of Translational according to new design of Rotational (55357ac, 7555322) with conditional support.

Migrated-From: https://trac.modelica.org/Modelica/ticket/22

Reported by fcasella on 21 Nov 2007 19:22 UTC
The pdf library documentation in

Modelica\help\Documentation\ModelicaStandardLibrary.pdf

still refers to 2.2.2, and should be updated.

Migrated-From: https://trac.modelica.org/Modelica/ticket/21

This is a placeholder created during migration to preserve original issue numbers.

Migrated-From: https://trac.modelica.org/Modelica/ticket/7

This is a placeholder created during migration to preserve original issue numbers.

Migrated-From: https://trac.modelica.org/Modelica/ticket/37

Reported by otter on 22 Jan 2008 12:09 UTC
Some users would like to have an explanation of the modelling of friction in the Rotational and Translational library. This explanation should be added to the UsersGuide of Rotational

Migrated-From: https://trac.modelica.org/Modelica/ticket/39

This is a placeholder created during migration to preserve original issue numbers.

Migrated-From: https://trac.modelica.org/Modelica/ticket/35