Closed modelica-trac-importer closed 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."
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.
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:
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.
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! :-)
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.
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:
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.
Modified by otter on 30 Jul 2013 08:25 UTC
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.
Comment by otter on 30 Jul 2013 10:09 UTC Partial fix in eae87739bb76595aeb933786c990f0c00a76c359: Fixed issues with conditional components in:
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
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.
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.
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!
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!
Comment by otter on 31 Jul 2013 13:09 UTC Improved fix in ab41c6a5a6247a54efdec2e2a50673c069b34a68 for Modelica.Mechanics.MultiBody.Joints.FreeMotionScalarInit based on #1227
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.
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.
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.
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