Transform library was developed with Dymola.
When trying to simulate in OpenModelica I get errors:
[12] 12:09:51 Translation Warning
[TRANSFORM.Fluid.Pipes.BaseClasses.PartialDistributedVolume: 12:26-12:31]: Non-array modification '0' for array component, possibly due to missing 'each'.
[13] 12:09:51 Translation Error
[TRANSFORM.Fluid.Pipes.GenericPipe_MultiTransferSurface: 118:3-135:83]: Variable pipe.pipe.flowModel: Cyclically dependent constants or parameters found in scope TRANSFORM.Fluid.Pipes.GenericPipe_MultiTransferSurface$pipe$pipe.FlowModel$pipe$pipe$flowModel: {Re_turb,Re_lam} (ignore with -d=ignoreCycles).
[14] 12:09:51 Translation Error
[TRANSFORM.Fluid.Pipes.GenericPipe_MultiTransferSurface: 118:3-135:83]: Variable pipe.pipe.flowModel: Cyclically dependent constants or parameters found in scope TRANSFORM.Fluid.Pipes.GenericPipe_withWall$pipe.FlowModel$pipe$pipe$flowModel: {Re_turb,Re_lam} (ignore with -d=ignoreCycles).
[15] 12:09:51 Translation Error
[TRANSFORM.Fluid.Pipes.GenericPipe_MultiTransferSurface: 118:3-135:83]: Variable pipe.pipe.flowModel: Cyclically dependent constants or parameters found in scope TRANSFORM.Fluid.ClosureRelations.PressureLoss.Models.DistributedPipe_1D.FlowModel$pipe$pipe$flowModel: {Re_turb,Re_lam} (ignore with -d=ignoreCycles).
[16] 12:09:51 Translation Error
Error occurred while flattening model TRANSFORM.Fluid.Pipes.Examples.GenericPipe_Tests.withWall
Is the library compatible with OpenModelica?
If not, what are the steps required to make it compatible?
TRANSFORM has been tested on OpenModelica as of version 1.16.1 and has found that OpenModelica has numerous errors and issues. As OpenModelica improves this may be revisited in the future.
Related
I'm making the interface package which can input the parameters of the models in the simulation loop.
To connect between the interface package and the simulation model, I used the Controlbus from the Standard Modelica Library Ver. 3.2.2.
Checking model was Okay, but if i simulate the model, the error like the picture below popped up.
And here's the equation related to this model
Omega_e = Omega_d * N_t[N];
Alpha_d = der(Omega_d);
To solve the differential equation, i think the solver need a specific parameter of N_t.
So i put the parameters from the interface model and sent the parameters using the Controlbus component in the Standard Modelica Library.
As in the picture above, i definitely put the parameters.
(Specific values of the parameters are deleted because it's a confidential)
I can't find what is the problem of this error.
Please help me guys.
Thank you very much.
Based on the incomplete model it's a bit tricky to say what happened, but:
Sending parameters through the control-bus (or a connector in general) is a bit complicated and not that encouraged.
It should be possible by declaring the "computed parameter" as parameter Integer N(fixed=false); initial equation N=myBus.N;, and don't have it as parameter in the connector.
If you don't declare it as parameter Dymola will try (and fail) to differentiate it.
If you declare it as parameter in the connector it will not be propagated (as connecting two parameters lead to an assertion).
In the QuestaSIM User's Manual version 10.5a it is stated on page 336:
In the most recent SystemVerilog standard (Std IEEE 1800-2012), two important concepts were established:
User-Defined Nettype (UDN) — UDN allows a definition of a net type
that can carry arbitrarily complex data using a built-in type (such as
real) or a user-defined type (such as struct). Consequently, UDN is a
generalization of the wreal net type from Verilog-AMS. In order to
allow connectivity of models that rely on UDNs, a more generic
connectivity mechanism is needed—the interconnect object.
But they really don't specify how the UDN is constructed. The syntax references to 'nettype' and 'interconnect' seem to come close to this description, but neither fulfills it - I can't assign interconnect, and I'm unable to use my own types with nettype. I'm creating a model that needs to drive user defined objects onto a UDN as defined in the spec.
module SomeModel(output nettype ObjectContainingProperties outputToInterconnect);
class ObjectContainingProperties;
endclass
ObjectContainingProperties ocp;
assign outputToInterconnect=ocp;
initial begin
ocp=new();
end
endmodule
but I get the error:
QuestaSim-64 vlog 10.5a Compiler 2016.04 Apr 4 2016
Start time: 18:55:05 on Dec 19,2016
vlog -ams -wireasinterconnect SomeModel.sv
-- Compiling module SomeModel
** Error: (vlog-13069) SomeModel.sv(11): near "nettype": syntax error, unexpected nettype, expecting IDENTIFIER.
How do I create and attach an object to a UDN - what is the syntax? Or how do I reliably drive objects of different types onto a net?
User defined nettypes are not part of SystemVerilog's OOP class type system. You can only define nettypes that are structures or arrays containing combinations of bits or real numbers. Classes are only used to get access to parameterized functions. (See 13.8 Parameterized tasks and functions).
You can only drive similar types onto a net. If you look at the prototype of a resolution function(from section 6.6.7)
function automatic T Tsum (input T driver[]);
You see that the function has one input argument that is an array. That will be populated with the values from all the drivers on the net - they must all be the same type.
The interconnect construct is just a conduit for a connection. It will assume the type of what ever it is connected to, and you will not be able to connect signals with different nettypes to the same interconnect
I am facing below coverity warning:
Type: Parse recovery warning (RW.ROUTINE_NOT_EMITTED)
Classification: Unclassified
Severity: Unspecified
Action: Undecided
Owner: Unassigned
Defect only exists locally.
Not sure what this means ??
The warning RW.ROUTINE_NOT_EMITTED is basically a parser warning which is generated when some piece of code is not analyzed due to previous errors.
But the real glitch I think is here that actual error you should fix is generated later in the sequence.
So I would suggest fix other below Coverity and this should be resolved.
In my case I forgot to include a header file for system structure. So due to this error parser could not parse something which generated the : RW.ROUTINE_NOT_EMITTED warning.
RW.ROUTINE_NOT_EMITTED means that the Coverity parser failed to understand some of the code running by it, but instead of discarding the entire file it recovered from the error and discarded the routine containing the error (since it's impossible to know whether the semantics were still valid or not).
This usually occurs when the dialect accepted by your compiler differs from the dialect accepted by the Coverity compiler, whether due to yours being further ahead of the curve on new language standards, by your compiler implementing its own extension to the language standard, or simply a bug in the Coverity compiler itself.
The best thing to do here would be to send a reproducer to Coverity support so that R&D can fix the issue in a future release. Otherwise, these are fairly safe to ignore - you won't get analysis defects reported for the function that was discarded, and inter-procedural analysis may miss some defects as well, but the odds of this are fairly low.
I have an array of connectors, and I want to connect another, smaller array of similar connectors, to a slice of this connector array. Example with a an array of x connectors, b an array of y connectors, x < y:
connect(a[:], b[1:x]); // works fine
connect(a[:], b[2:x+1]); // gives an error
The error I get in the second case (when checking the model in Dymola 2012) says:
Error: Failed to expand connect(a[:], b[2:x+1])
Is this a language or tool limitation? And is there a workaround (besides using for loops to connect each individual connector)?
That must be a tool limitation because the specification says:
Subscripts in a connector reference shall be parameter expressions or the special operator “:”.
The only workaround I can think of is a for-equation or the more obvious: filing a bug report to the Dymola team. I will do the same for OpenModelica (it generates equations, but the wrong ones).
I think we need more code here to understand what is going on. I don't see any apparent limitation in Dymola. For example, the following code works fine in Dymola 2012 FD01:
model SlicedConnectors
parameter Integer n(start=5);
Modelica.Blocks.Interfaces.RealInput a[n];
Modelica.Blocks.Interfaces.RealOutput b[2*n];
equation
connect(a[:],b[1:n]);
connect(a[:],b[(n+1):(2*n)]);
end SlicedConnectors;
So it doesn't seem to be slicing itself that is the issue but probably something more complicated (something about the specific connectors, variability of sizing, etc).
Previously in Matlab Stateflow 7.1 all variables and functions had to be included before they can be referred to in the state diagram or else it would throw an error when you tried to parse the diagram.
But now in 7.7 it doesn't catch those kinds of errors. Its still compiling the diagram because it catches other syntactic errors.
Am I missing an option somewhere? Can this be turned on?
The release notes to Stateflow 7.2 say:
Parsing a Stateflow Chart Without
Simulation No Longer Detects
Unresolved Symbol Errors
To detect unresolved symbol errors in
a chart, you must start simulation or
update the model diagram. When you
parse a chart without simulation or
diagram updates, the Stateflow parser
does not have access to all the
information needed to check for
unresolved symbols, such as exported
graphical functions from other charts
and enumerated data types. Therefore,
the parser now skips unresolved symbol
detection to avoid generating false
error messages. However, if you start
simulation or update the model
diagram, you invoke the model
compilation process, which has full
access to the information needed, and
unresolved symbols are flagged.
For more information, see Parsing
Stateflow Charts and Resolving Symbols
in the Stateflow and Stateflow Coder
User's Guide.
So it looks like that you need to "start the simulation, update the model diagram, or invoke the model compilation process" to get the flags.