profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/HansOlsson/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Hans Olsson HansOlsson Dassault Systèmes 55.71056172306926, 13.234561042716033 https://www.3ds.com/products-services/catia/products/dymola/latest-release/ Working on Modelica since 1999

modelica/ModelicaSpecification 43

Specification of the Modelica Language

modelica/Modelica-Compliance 15

A semantics compliance suite for the Modelica language

HansOlsson/Modelica_StateGraph2 3

Free library providing components to model discrete event, reactive and hybrid systems in a convenient way with deterministic hierarchical state diagrams. Modelica_StateGraph2 is not fully Modelica compliant and might never be. For clocked system Modelica 3.3 introduced state machines, but for non-clocked systems this is still a good alternative.

HansOlsson/GitModelicaTest 0

For refreshing understanding of git commands

HansOlsson/LaTeXML 0

LaTeXML: a TeX and LaTeX to XML/HTML/ePub/MathML translator.

HansOlsson/Modelica 0

Free (standard conform) library from the Modelica Association to model mechanical (1D/3D), electrical (analog, digital, machines), thermal, fluid, control systems and hierarchical state machines. Also numerical functions and functions for strings, files and streams are included.

HansOlsson/Modelica-Compliance 0

A semantics compliance suite for the Modelica language

HansOlsson/ModelicaBook 0

Source for my new Modelica Book

HansOlsson/ModelicaSpecification 0

Converted Modelica Specification

HansOlsson/Modelica_DeviceDrivers 0

Free library for interfacing hardware drivers to Modelica models. There is support for joysticks, keyboards, UDP, TCP/IP, shared memory, AD/DA converters and other devices.

pull request commentmodelica/ModelicaStandardLibrary

Add electrical quantities per length

In German, however, there is no explicit term "shut" that indicates how the capacitance or conductance component is connected, as this clear to engineers as we have no series capacitances / conductances in the physical representation of line/cable/wire models.

I can understand that, but the proposed types are in Modelica.Units.SI and the connection to line/cable/wire models aren't clear. It might be that a comment would be an alternative.

christiankral

comment created time in 2 days

pull request commentmodelica/ModelicaStandardLibrary

Add electrical quantities per length

Here we see:

  • admittivity does not exist
  • admittance exists, its value is the quotient of I over U, in circuit theory; also shunt admittance exists, in the domain of "Generation, transmission and distribution of electricity", so in principle, we could choose "shunt admittance" instead of just "admittance"; however I don't think this is necessary, even though I'm not against it
  • reactivity does exist but its domain is "Nuclear Instrumentation"
  • susceptivity does not exist
  • susceptance exists, and is in circuit theory
  • impedivity does not exist

I would say it doesn't matter if they exist, as if they exist they are material properties, similar to resistivity and conductivity - and not an engineering unit for electrical lines/wires/cables.

I was misled by the units - but just because the units match, the quantities are not necessarily the same.

Furthermore, in absence of a precise position from the IEC, we are obliged to get info from other sources, I've checked several internet sites, selecting those that sounded high quality and mother tongue, and found much more frequently "resistance per unit length" than "resistance per length"

So, it seems to me that "resistance per unit length" is better than "resistance per length". The same applies obviously for the other quantities.

To me the obvious part isn't fully that obvious, since some of them like conductance are between the lines (or between line and ground), whereas some like resistance is along the line.

Calling out the between ones by using a different term like "shunt conductance per unit length" and "shunt capacitance per unit length" would differentiate those more clearly from "resistance per unit length"; and I see that you are not against "shunt admittance"; so I hope that would also be ok in this case, and it would at least avoid people using them incorrectly.

christiankral

comment created time in 2 days

pull request commentmodelica/ModelicaStandardLibrary

Add electrical quantities per length

Per length quantities are typical data sheet values provided by cable and overhead line manufacturers. These parameters are used in transmission line equations.

Ah, I see - and I now I understand my confusion. A normal resistive component has a resistance and the inverse of that is conductance. For the telegraph equation: Resistance per length is for one wire (and the next one sort of in series); I had no problem with that. Conductance per length is between different wires, and thus also makes sense (sort of in parallel).

So my issue is that this difference between value for one wire and cross-conductance between wires isn't clear with the proposed names.

christiankral

comment created time in 2 days

pull request commentmodelica/ModelicaStandardLibrary

Add electrical quantities per length

Hmm... This makes me suspicious about the g-parameter for OLine.

BTW: For real ones we have:

  • Resistivity
  • Reactivity
  • Conductivity instead of conductance per length
  • Susceptivity instead of susceptance per length

For complex ones we have:

  • Impedivity instead of complex impedance per length
  • Admittivity instead of complex admittance per length

https://en.wikipedia.org/wiki/Electrical_resistivity_and_conductivity#Complex_resistivity_and_conductivity

christiankral

comment created time in 2 days

pull request commentmodelica/ModelicaStandardLibrary

Add electrical quantities per length

This PR includes:

  • resistance per length (Ohm/m)
  • reactance per length (Ohm/m)
  • impedance per length (Ohm/m)
  • conductance per length (S/m)
  • susceptance per length (S/m)
  • admittance per length (S/m)

Many of these names seem very misleading to me.

Specifically if you have an 1m wire with admittance S, and cut it in half you don't get an object with the same admittance per length, right?

If we look at https://en.wikipedia.org/wiki/Electrical_resistivity_and_conductivity we see that Conductivity can be seen as S*m/m2- which simplifies to S/m, but I wouldn't say it is "per length" but "per area divided by length".

I don't know the standard names of these, except resistivity for resistance.

christiankral

comment created time in 2 days

PullRequestReviewEvent

issue commentmodelica/ModelicaSpecification

Figure annotations don't support variable derivatives

Note that this issue should not be confused with the need for more general curve expressions. That is, plotting der(x + y) is a completely different topic, and I'd even say it's another step beyond plotting variable derivatives and simple expressions such as x + y.

I agree that plotting der(x+y) would be complicated, but if we support derivatives and simple expressions we could plot der(x)+der(y) - which is the same (assuming it exists).

henrikt-ma

comment created time in 3 days

issue commentmodelica/ModelicaSpecification

Are multiple dependencies on different versions of the same library allowed in Modelica?

However, since we want libraries to expose Interfaces for interoperability I don't see that internal use inside libraries will be overly useful for Modelica.

There is no nominal typing except for external objects, right?

There's also for operator overloading. However, my point was slightly different:

The interfaces should be compatible since they just boil down to the type and unit.

In many cases, but I could see that a new version renamed some connector-variables; and/or changed their type.

The problem isn't converting the libraries as much as it is making people convert their libraries...

Well, similar issue. To me one of main issues is that people are hesitant to do it - and also hesitant to use the new possibilities to simplify their work-flow.

casella

comment created time in 3 days

issue commentmodelica/ModelicaSpecification

Are multiple dependencies on different versions of the same library allowed in Modelica?

TL;DR: Having multiple versions together should be forbidden. I would say that it is already forbidden (but we can make it more explicit) as the used libraries in MODELICAPATH are loaded in the global scope, and the global scope can only contain one version of each library, https://specification.modelica.org/maint/3.5/scoping-name-lookup-and-flattening.html#static-name-lookup

Longer: As I understand having multiple versions of libraries would be somewhat easier if they are only used internally in other libraries, and not directly exposed to the user. I've heard that Lua has that (using internal tables), but I cannot find any link at the moment.

However, since we want libraries to expose Interfaces for interoperability I don't see that internal use inside libraries will be overly useful for Modelica. Thus if we want handle multiple versions of a library we also need to handle:

  • Multiple versions of a library used in the same model. I can see some possible syntax - but we don't have it yet.
  • Leading to user confusions when you have different versions of the same model; especially as they look similar and might even behave identically and/or have the same contents. (Yes, the models may have identical texts, but depend on other classes that differ.)
  • Especially as many operations (Create Connector, Duplicate, Propagate, ...) copy the component-classes, meaning that this confusion will propagate. It is not even certain we can connect the different versions together.
  • Explosion in number of versions. We are here discussing version x and y; but when can have multiple versions we might end up with: x, y, z, w, a, b, x.y, etc, and so on.

If there are any issues with converting libraries I think we should work on that instead.

BTW: Dymola can support the similar scenarios as the one in original post (except that libraries should be ordered), but the classes using outdated versions will be read-only (as I recall we can do it even if there are conversions in the case they wouldn't impact your library). The read-only part is needed because even if no conversion is needed to convert to the new version it might have introduced a new class or parameter, that didn't exist in the older version and keeping track of that would be too complicated.

casella

comment created time in 3 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentmodelica/ModelicaStandardLibrary

Fix missing or ambiguous SI-units in MultiBody.Sensors

 model CutForceAndTorque "Measure cut force and cut torque vector"    import Modelica.Mechanics.MultiBody.Types; -  Modelica.Blocks.Interfaces.RealOutput force[3](each final quantity="Force", each final unit="N")

This line is only formatting, right?

tobolar

comment created time in 5 days

PullRequestReviewEvent

issue commentmodelica/ModelicaStandardLibrary

startBackward and startForward should not be reference results

@HansOlsson, @henrikt-ma: OK?

Yes, that makes sense.

uschna

comment created time in 5 days

push eventmodelica/ModelicaSpecification

Thomas Beutlich

commit sha 8e6a235687726f57d17721c65fc819fc71307afa

Fix year in date reference

view details

Hans Olsson

commit sha 547d8c9cc9625538122b8ebbe7de6d620e906396

Merge pull request #3002 from modelica/fix-year Fix year in date reference

view details

push time in 5 days

delete branch modelica/ModelicaSpecification

delete branch : fix-year

delete time in 5 days

PR merged modelica/ModelicaSpecification

Fix year in date reference P: trivial

refs #2993

+2 -2

0 comment

2 changed files

beutlich

pr closed time in 5 days

push eventmodelica/ModelicaSpecification

Henrik Tidefelt

commit sha b48f4a45b0505a65293fb8b9053ac3919b540d17

Avoid just a '0' in \lstinline when generating HTML Fixes #2991. Actually, it's more of a temporary workaround and we'll have to return this once we've switched to a future version of LaTeXML where the upstream issue has been fixed.

view details

Henrik Tidefelt

commit sha a3c78d9e06f867a5cad73e276c248c7280012e97

Update comment after LaTeXML issue being fixed promptly on 'master'

view details

Hans Olsson

commit sha f71e3f13ed006e26453e2ebccebe773257703144

Merge pull request #2993 from henrikt-ma/just-one-zero Avoid just a '0' in \lstinline when generating HTML

view details

push time in 9 days

PR merged modelica/ModelicaSpecification

Avoid just a '0' in \lstinline when generating HTML

Fixes #2991. Actually, it's more of a temporary workaround and we'll have to return this once we've switched to a future version of LaTeXML where the upstream issue has been fixed.

+18 -2

0 comment

2 changed files

henrikt-ma

pr closed time in 9 days

issue closedmodelica/ModelicaSpecification

Missing integer zero literal in section 2.4.2

The integer literal 0 is not properly rendered in the generated HTML:

https://github.com/modelica/ModelicaSpecification/blob/80f268aa5f113830fd85c74568381b8542dd273e/chapters/lexicalstructure.tex#L156

https://specification.modelica.org/master/lexical-structure.html#integer-literals

grafik

closed time in 9 days

beutlich

push eventmodelica/ModelicaSpecification

Henrik Tidefelt

commit sha e8f31266dc1c325bd1856eb944e990801f4062e8

Fix formatting of 'when', 'elsewhen', and 'when initial()'

view details

Hans Olsson

commit sha abb1cc8aa7389ef595d94ba345fd8804b332c8f4

Merge pull request #3000 from henrikt-ma/cleanup/reinit Fix formatting of 'when', 'elsewhen', and 'when initial()'

view details

push time in 9 days

issue commentmodelica/ModelicaStandardLibrary

startBackward and startForward should not be reference results

Ok, so the problem is only in mode-equation, and the result is that mode is just shifted a bit in time, whereas startForward is somewhat unpredictable - but with small "integral".

I can understand removing startForward and startBackward, since they are false outside transients that aren't important for the reference (so if we just integrate the error we will get zero regardless of whether it matches the reference or not) - but keep mode, free, etc.

uschna

comment created time in 9 days

PullRequestReviewEvent

issue commentmodelica/ModelicaSpecification

Clarification on where reinit is allowed

B is explicitly mentioned in https://specification.modelica.org/maint/3.5/equations.html#initialization-initial-equation-and-initial-algorithm

henrikt-ma

comment created time in 10 days

push eventmodelica/ModelicaSpecification

Francesco Casella

commit sha 3fba2023cf0c25899614af3fbc1293677f9acb70

Turned equations into assignments in when-algorithm

view details

Hans Olsson

commit sha f414b8ead95c00eb525bc82da8b9d724a3d7a6f0

Merge pull request #2998 from modelica/casella-patch-1 Turned equations into assignments in when-algorithm

view details

push time in 10 days

issue commentmodelica/ModelicaSpecification

Clarification on where reinit is allowed

I don't see any problems with A and B (I would say that B more commonly occurs using when {initial(),..}). For C and D the problem is that when-equations should exclude "Clocked when-clause" here and in other cases.

A simpler example illustrating this:

  Real x;
equation 
  when Clock(1.0) then
    x*3=sample(time);
  end when;

According to https://specification.modelica.org/maint/3.5/synchronous-language-elements.html#clocked-when-clause we just have equations in clocked when-clause (and they become clocked) so this should be legal; which makes sense.

However, this is in contrast to https://specification.modelica.org/maint/3.5/equations.html#when-equations when-equations where we must have a variable in the left-hand-side in a when-equation; since the variable is discrete and held as pre(x) (the semantics of clocked when-clauses is different), and thus the following is illegal.

  Real x;
equation 
  when sample(1,1) then
    x*3=time;
  end when;

So the conclusion is that clocked when-clause shouldn't be seen as when-equation, and that also makes C&D illegal.

henrikt-ma

comment created time in 10 days

issue commentmodelica/ModelicaSpecification

Confusing syntax highlighting of comment variants

As a minor suggestion, I'd put the end in quotes:

/* Invalid nesting of comments, the comment ends just before 'end'

As a bigger suggestion, I'd like to point of the usefulness of rest-of-line comments for commenting out blocks of code:

True, and I had to search - seems that Dymola added comment command adding "// " (and de-comment) in May 2004.

beutlich

comment created time in 10 days

issue commentmodelica/ModelicaStandardLibrary

startBackward and startForward should not be reference results

For example in Mechanics.MultiBody.Examples.Systems.RobotR3.OneAxis axis.gear.bearingFriction.startBackward and axis.gear.bearingFriction.startForward are reference results. In Modelica.Mechanics.Rotational.Interfaces.PartialFriction:

		startForward = pre(mode) == Stuck and (sa > tau0_max/unitTorque or pre(
		  startForward) and sa > tau0/unitTorque) or pre(mode) == Backward and
		  w_relfric > w_small or initial() and (w_relfric > 0);
		startBackward = pre(mode) == Stuck and (sa < -tau0_max/unitTorque or pre(
		  startBackward) and sa < -tau0/unitTorque) or pre(mode) == Forward and
		  w_relfric < -w_small or initial() and (w_relfric < 0);
		locked = not free and not (pre(mode) == Forward or startForward or pre(
		  mode) == Backward or startBackward);
...
		mode = if free then Free else (if (pre(mode) == Forward or pre(mode) ==
		  Free or startForward) and w_relfric > 0 then Forward else if (pre(mode)
		   == Backward or pre(mode) == Free or startBackward) and w_relfric < 0
		   then Backward else Stuck);

Hence, startForward and startBackward depend from the value of w_relfric in pre(mode) == Stuck

I cannot see how that follows.

If we look closely we see that it w_small is 1e10 so w_relfric is not above w_small, and after the simulation starts initial() is false, so startForwardis not influenced by w_relfricafter the simulation starts.

uschna

comment created time in 10 days

PR opened modelica/ModelicaSpecification

Define experiment using a record.

Remove the empty experiment and define it using a record instead (per discussions). Closes #2985

+13 -9

0 comment

1 changed file

pr created time in 15 days