#5074 closed defect (fixed)
The NF does not evaluate a structural parameter
Reported by: | Francesco Casella | Owned by: | Per Östlund |
---|---|---|---|
Priority: | high | Milestone: | 2.0.0 |
Component: | New Instantiation | Version: | |
Keywords: | Cc: |
Description
Please check Modelica.Electrical.Machines.Examples.Transformers.AsymmetricalLoad. The backend complains it cannot differentiate an equation containing the term plugToPin_n.plug_n.pin[plugToPin_n.k].v
. I guess in this case the parameter plugToPin_n.k
should be evaluated, as the old FE does.
Change History (4)
comment:1 by , 6 years ago
comment:2 by , 6 years ago
I'm not sure if we have a formal (or semi-formal) definition of "structural parameter", do we?
The PlugToPin_n model contains the following equations
pin_n.v = plug_n.pin[k].v; for j in 1:m loop plug_n.pin[j].i = if j == k then -pin_n.i else 0; end for;
from which it is clear that plugToPin_n.k
has a structural influence on the system of equations, as it determines the actual dependencies of the equations on the variables of the system.
Is this enough to qualify it as structural parameter? I would guess so. Of course if one does not evaluate it, it would be possible to change plugToPin_n.k
at runtime (assuming the back-end is improved to handle this case, that is), but I don't think this is worth missing the structural simplifications which are possible if it is indeed evaluated, which are substantial.
In fact, at the moment we only have two options with the new FE: if -d=evaluateAllParameters
is set, all parameters are evaluated, otherwise only structural parameters (whatever that means) are. Maybe we should introduce extra flags to allow a bit more flexibility, so that it is possible to exploit the trade-off between less runtime optimization and no need to recompile when changing parameters in a more nuanced way.
Anyway, in this case I think it is perfectly reasonable to classify plugToPin_n.k
as structural parameter and therefore to evaluate it also in the NF.
comment:3 by , 6 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Fixed in a4c80fe7, by evaluating all parameter subscripts like the old frontend does. I didn't add a flag this time, partially for performance reasons and partially because I suspect this is one of those "nice to have, but unlikely to be fixed" things.
Is there any reason why
plugToPin_n.k
should be considered structural? I.e. is there some better reason than it just being used as a subscript? Because I'm not sure if evaluating all subscripts is really desirable.Note that the old frontend doesn't actually think it's structural, it just evaluates non-structural parameters too.