Use of conditionally enabled components

modelica-trac-importer commented 7 years ago

Reported by hansolsson on 26 Jul 2013 14:45 UTC For the following cases conditionally enabled components are used in non-connect - initial equations in Modelica.Electrical and Modelica.Magnetic:

Modelica.Electrical.Machines.Examples.SynchronousInductionMachines.SMEE_Generator variable smee.idq_dr Modelica.Electrical.Machines.Examples.SynchronousInductionMachines.SMEE_LoadDump variable smee.idq_dr Modelica.Electrical.Machines.Examples.SynchronousInductionMachines.SMEE_Rectifier variable smee.idq_dr

Modelica.Magnetic.FundamentalWave.Examples.BasicMachines.SMEE_Generator variables smeeE.idq_dr and smeeM.ir Modelica.Magnetic.FundamentalWave.Examples.BasicMachines.SMEE_Generator_MultiPhase variables smee3.ir and smeeM.ir

-- Similar the Modelica.Mechanics.MultiBody.Joints.FreeMotionScalarInit has r_rel_a conditional which causes issues in:

Modelica.Mechanics.MultiBody.Examples.Elementary.DoublePendulumInitTip variable freeMotionScalarInit.r_rel_a Modelica.Mechanics.MultiBody.Examples.Constraints.PrismaticConstraint variable freeMotionScalarInit.r_rel_a

-- It could be that the restriction is too strict. (And sorry that I did not find it earlier.)

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

modelica-trac-importer commented 7 years ago

Comment by hansolsson on 26 Jul 2013 14:47 UTC The restriction mentioned is in 4.4.5: "A component declared with a condition_attribute can only be modified and/or used in connections."

modelica-trac-importer commented 7 years ago

Comment by hansolsson on 29 Jul 2013 13:01 UTC The list above (using conditionally enabled variables outside of connect) should be a long longer (stopped check after 381 errors), e.g.:

Modelica.Electrical.Machines.Examples.AsynchronousInductionMachines.AIMC_DOL got errors due to Modelica.Electrical.Machines.Examples.AsynchronousInductionMachines.AIMC_DOL having (using rs.heatPort):

  replaceable output 
    Machines.Interfaces.InductionMachines.PartialPowerBalanceInductionMachines
    powerBalance(... final lossPowerStatorWinding = -sum(rs.heatPort.Q_flow) ...
  ...
  Modelica.Electrical.MultiPhase.Basic.Resistor rs(
   ...
   final useHeatPort=true,

Modelica.Electrical.Machines.BasicMachines.SynchronousInductionMachines.SM_PermanentMagnet uses damperCage:

  output Modelica.SIunits.Current idq_dr[2]...=
    damperCage.spacePhasor_r.i_ if useDamperCage;
  Machines.BasicMachines.Components.DamperCage damperCage ... if useDamperCage

-- Continuing the check in Modelica.Mechanics also found many (=86) of these issues: Modelica.Mechanics.MultiBody.Examples.Systems.RobotR3.Components.MechanicalStructure has (for r1.axis, r2.axis, ...):

   Modelica.Mechanics.MultiBody.Joints.Revolute r1(..., useAxisFlange=true,...);
equation
  tau = {r1.axis.tau,r2.axis.tau,r3.axis.tau,r4.axis.tau,r5.axis.tau,r6.
    axis.tau}

Modelica.Mechanics.MultiBody.Examples.Elementary.DoublePendulumInitTip also has (using model_r):

  SI.Position r_rel_a_1... = model_r.r_rel_a_1 if use_r;
  Model_r model_r ... if use_r;

Modelica.Mechanics.MultiBody.Visualizers.Advanced.Arrow using arrowLine

Visualizers.Advanced.Shape arrowLine ... if world.enableAnimation;
  Visualizers.Advanced.Shape arrowHead(
    ...
    r=rvisobj + rxvisobj*arrowLine.length,
    R=R) if world.enableAnimation;

Modelica.Mechanics.MultiBody.Visualizers.Advanced.DoubleArrow using arrowHead1

To me it seems we have to remove/loosen the restriction. Note that in many cases the potential issue cannot be made into an actual errors, since condition is "final=true" - or it is used in another variable with the same condition. However, I don't see how we can make such a rule that really covers the interesting cases and still is natural for users.

modelica-trac-importer commented 7 years ago

Comment by otter on 30 Jul 2013 07:27 UTC Replying to [comment:2 hansolsson]:

To me it seems we have to remove/loosen the restriction. Note that in many cases the potential issue cannot be made into an actual errors, since condition is "final=true" - or it is used in another variable with the same condition. However, I don't see how we can make such a rule that really covers the interesting cases and still is natural for users.

I discussed this issue with Hans on the phone. To summarize:

The specification seems to be not completely clear on conditionally declared components. If the specification is interpreted very strictly, the only allowed usage is to declare a component and use it in connections. Especially, all the following forms are most likely not legal:

model Test
  parameter Boolean use_R;
  Resistor R1          if use_R;    
  Resistor R2(R=R1.R)  if use_R;   // modifier with conditional component
  Real r2              if use_R;   // variables (with exception of connectors)
                                   // cannot be conditionally declared
  Real r3=2*r2         if use_R;   // Assignment of conditionally declared variable to another one
end Test;

model Test2
  Test test(final use_R=true, R1.R = 20); // modifier on conditional component
equation
  i = test.R1.p.i;                        // access of variable from conditional component
end Test2;

According to the ticket from Hans, several hundred of such usages occur in MSL 3.2.1. Of course, we must:

Clearly specify how conditional components can be declared and used and define this unambigously in the specification.
Adapt MSL to the specification or the specification to MSL.

Currently, no Modelica tool seem to report the definitions above as errors and therefore library developers did not recognize it. The current approach in the tools seems to be that checks are performed on the conditionally components that are enabled and if the equation counting is correct in this case, models are accepted.

I tried yesterday to rewrite one model, Modelica.Mechanics.MultiBody.Joints.FreeMotionScalarInit, so that it has no modifiers on conditionally declared components and only uses "connect(..)" on such components. After some hours I gave up, since the code became very complicated and I still did not manage. My current feeling is that this model cannot be rewritten in a backwards compatible way.

The issue is timing. The voting on Modelica Specification 3.2 rev.2 ends today (July 30), and MSL 3.2.1 Release Candidate 1 was planned to be released July 26, but was not due to the issue above and due to #1222.

Besides this issue also other issues with the specification will pop up (e.g. Hans reported already a minor issue with external objects). However, we cannot continue forever with improving the specification and MSL. At some time we must stop and make new releases (of the specification and of MSL) and fix detected issues in future releases. Note, it will take some time to clarify and fix conditional components since it is not an easy topic.

For these reasons, Hans and myself propose to accept the current situation, that is that conditional components are not well-defined in the Modelica specification 3.2 rev. 2 and that MSL 3.2.1 might use it wrongly, and still release both as soon as possible (spec and MSL 3.2.1 RC1 today). Please, give your opinion.

modelica-trac-importer commented 7 years ago

Comment by dhedberg on 30 Jul 2013 07:54 UTC I totally agree with you and Hans, we need to accept the fact that we're only humans! :-)

modelica-trac-importer commented 7 years ago

Comment by jmattsson on 30 Jul 2013 08:05 UTC JModelica.org for one does have a strict check for use of conditional components, but we don't support the mentioned parts of MSL yet (this being only one of the reasons). Considering how tricky this issue could be to define properly, I agree that it must be discussed at a design meeting, and that we should not wait with the releases.

This ticket should be a priority for the next design meeting, though.

modelica-trac-importer commented 7 years ago

Comment by dzimmer on 30 Jul 2013 08:09 UTC I agree to Martin.

Conditional components and statements are causing many troubles in Modelica currently. There are a few more issues related to this topic:

contradictions involving conditional statmenets. You can still write self-contradictory stuff and get away without error-messages. Example:

if Connections.isRoot(frame_a) then
  connect(frame_a, frame_of_something_rooted)
end if

if cardinality(frame_a) <= 0 then
  connect(frame_a,frame_b)
end if

conditional parameter and components and the check for balanced models. Currently there are many components (often boundaries as sources and sinks) that are used in a non-balanced way but pass the checker because their defaul parameterization is describing a balanced model. This is actually useful to us but a bit fishy actually.
etc.

We see there are some principal issues and I think this cannot be resolved within ticket discussions but needs some major discussion at the design meetings and probably also some significant changes to the spec to get rid of all these issues.

This should, however, been done properly without any pressure originating from a deadline. Hence, for the moment, it is the best to follows Martins proposal and go for a release. We may be so honest and add a remark to the spec that this part is not well defined.

modelica-trac-importer commented 7 years ago

Modified by otter on 30 Jul 2013 08:25 UTC

modelica-trac-importer commented 7 years ago

Comment by leo.gall on 30 Jul 2013 09:19 UTC Replying to [comment:6 dzimmer]:

We may be so honest and add a remark to the spec that this part is not well defined.

My proposal is to document this issue in the release notes of MSL 3.2.1. The spec is more or less final, but MSL is still beta, so it should be easier to change. And it's the logical conclusion of a library developer: document which parts of the spec have been ambiguous during implementation.

modelica-trac-importer commented 7 years ago

Comment by otter on 30 Jul 2013 10:09 UTC Partial fix in eae87739bb76595aeb933786c990f0c00a76c359: Fixed issues with conditional components in:

Modelica.Mechanics.MultiBody.Visualizers.Advanced.Arrow
Modelica.Mechanics.MultiBody.Visualizers.Advanced.DoubleArrow

modelica-trac-importer commented 7 years ago

Comment by otter on 30 Jul 2013 10:26 UTC Partial fix in 28bb15850efd7e9dae08efcf122770ce36cba235: Fixed issues with conditional components in: Modelica.Mechanics.MultiBody.Examples.Systems.RobotR3.Components.MechanicalStructure

modelica-trac-importer commented 7 years ago

Comment by christiankral on 30 Jul 2013 10:58 UTC Problem fixed for Machines and FundamentalWave library by using modifiers instead of initial equations in 9491140b162caf281ce137a40f815a711c96f777.

modelica-trac-importer commented 7 years ago

Comment by otter on 30 Jul 2013 14:20 UTC Partial fix in 13e2937ee1a7e9a373c5d178e6aef1222310fa52: Fixed issues with conditional components in: Modelica.Mechanics.MultiBody.Joints.FreeMotionScalarInit and all components using FreeMotionScalarInit.

modelica-trac-importer commented 7 years ago

Comment by ahaumer on 30 Jul 2013 15:25 UTC Partly fixed for Modelica.Electrical.Machines and Modelica.Magnetic.FundamentalWave in trunk by 180834d2d672d8a82ed6bb0a172d268c7a68d241 and for MSL 3.2 (maintenance) by 12e874bb81bc4c82e048d17340bea97c8e14f06c. Hans, please report any remaining issues - thanks in advance!

modelica-trac-importer commented 7 years ago

Comment by ahaumer on 30 Jul 2013 15:27 UTC I see: I missed the conditional damperCage currents. I'll have to investigate that today's evening!

modelica-trac-importer commented 7 years ago

Comment by otter on 31 Jul 2013 13:09 UTC Improved fix in ab41c6a5a6247a54efdec2e2a50673c069b34a68 for Modelica.Mechanics.MultiBody.Joints.FreeMotionScalarInit based on #1227

modelica-trac-importer commented 7 years ago

Comment by christiankral on 31 Jul 2013 13:49 UTC Problem for conditional damper cage in Machines and FundametalWave library is fixed with output connector being connected with conditional damper cage, see e6a020a43dfe822d11a03347bf4886c0d5166af5.

modelica-trac-importer commented 7 years ago

Comment by ahaumer on 31 Jul 2013 15:09 UTC Problem for losses in PowerBalance of QuasiStationary partialTransformer fixed by 6889064b379700691ddacf47eb654e02a4c895c3. Martin - if all other issues are fixed, please close the ticket.

modelica-trac-importer commented 7 years ago

Comment by otter on 31 Jul 2013 15:47 UTC Hans has re-checked MSL on the trunk with his new Dymola prototype and all issues with conditional components are fixed (so MSL is fully compliant to Modelica Spec 3.2 rev. 2). Therefore, this ticket is closed.

Note, in #1227 several suggestions are present to improve the description of conditional components in the specification.

modelica / ModelicaStandardLibrary

Use of conditionally enabled components #1223