I am trying to simulate the flow in pipes between reservoirs. I have created my own pipe component (based on Modelica.Fluid) and it works fine when I simulate from one tank to another as shown below.
However, when I try to connect two pipes in series, as shown in the picture below, the model does not work. When I check my model, I'm told my model is balanced and has 402 equations and 402 variables.
However, when I try to simulate I get the following error message:
An independent subset of the model has imbalanced number of equations (143) and variables (144)
Any ideas where this error message originates from? How is it possible that a balanced system becomes unbalanced when simulating, and how could it work with one pipe, but not two in series?
The problem is something like:
model M
Real x,y;
equation
x = sin(x);
x = 3.0;
end M;
Where the total number of equations are balanced, but there is something causing some part of the system to be unbalanced (like forgetting a variable in the equations). OpenModelica internally partitions everything into sets of equations/variables that reach each other, which can give the error-message above. For the trivial cases like the one above, there is usually a different error-message though.
Related
I had as primary objective to make a controller for the transfer function (5.551* s^2), using root locus I made the controller shown below. Analyzing the step response in the Workspace using the step () function I had a satisfactory answer but when I try to transfer this answer to Simulink the response behaves differently, at steady state for example I wish to have the smallest possible error as it was obtained in Workspace but in Simulink there is a big error and for some reason at 8 seconds time (Simulink simulation time) there is a "jump" as shown on the display and when I change the simulation time there is a change in this "jump" too and I do not know why these changes between one environment and another.
Step response in Workspace
Step response in Simulink with 8s of simulation
Step response in Simulink with 12s of simulation
Simulink controller
Simulink transfer function
I expected to make a controller that has an error less than 5% and an overshoot smaller than 25%, so I first made a controller with two integrators to nullify the effects of zeros on the source, after that I added two more integrators on the source to try decrease the error, the zero at -0.652 I used the angular condition for this and the gain of 0.240251 I used the modular condition.
I wasn't expecting the most optimized behavior possible, just that it has minimum conditions that satisfy the imposed conditions, so I didn't worry for example about the four integrators at the source.
I tried use the sisotool() command thinking that I had done something wrong, but the result changed a lot when I was simulating Simulink so I discarded this option and kept the controller I made using root locus.
Your MATLAB code and your Simulink model are not the same, and hence the different results.
MATLAB allows you to define the non-causal plant model P_ball, then form the causal closed loop CL, which can have its step response generated.
Simulink does not allow you to model non-causal blocks (even if the overall model is causal) and hence will not allow you to implement s^2, which I assume is why you have used two differentiation blocks. But a numerical differentiation is not the same as a Laplace s operator.
You would have to make the plant causal by incorporating two poles that are large enough to not adversely effect the overall simulation. So your plant model needs to be something like 5.551*s^2/((s/1000 + 1)(s/1000 + 1)) which can be implemented using a Transfer Function block with a numerator of 5.551*1000*1000*[1 0 0] and a denominator of [1 2*1000 1000*1000].
Alternatively you could just implement PID * P_ball (where you manually do the 2 zero/pole cancellations) which is causal.
I've tried to repeat the same results with the same flow, and I don't understand the results are different in each situation.
I describe the situation I have a file with 192 instances and 37 features, y select in all cases the same columns and preprocess by Median and StdDev. It computes the PCA with 7 principal components. The following step is to run the k-means algorithm (k is between 2 and 8) from this 'new' dataset. The scatter plot shows the results for k=5.
I attached different images with my flows.
Image1: original flow
The first one is the original flow (it is painted of yellow color), which I would like to repeat without the rest of the options (the second image).
Image2: flows repeated
However, when I tried to do it, I saw that the results are different (the third image) Of course the colors don't determine the differences, however the clusters are different. In addition the Slhouette Scores are different too for the different flows.
Image3: results of the different flows
K-means initializes with the kmean++ and I have the question if I can "control" this, or if the way to initialize k-means is always randomly. I saw in other programmes that there is an option called seed which is used to control that an experiment can be repeated but I didn't see this option here or something similar.
I wonder if it is possible to obtain always the same results with the same flow (using k-means).
It seems that the issue happens because no random seed is set in the k-means widget. So initialization is different each time you repeat an experiment and because of nature of your data, the method converges differently. Can you please report your issue to Orange3 issue tracker.
I know it sounds strange and that's a bad way to write a question,but let me show you this odd behavior.
as you can see this signal, r5, is nice and clean. exactly what I expected from my simulation.
now look at this:
this is EXACTLY the same simulation,the only difference is that the filter is now not connected. I tried for hours to find a reason,but it seems like a bug.
This is my file, you can test it yourself disconnecting the filter.
----edited.
Tried it with simulink 2014 and on friend's 2013,on two different computers...if Someone can test it on 2015 it would be great.
(attaching the filter to any other r,r1-r4 included ''fixes'' the noise (on ALL r1-r8),I tried putting it on other signals but the noise won't go away).
the expected result is exactly the smooth one, this file showed to be quite robust on other simulations (so I guess the math inside the blocks is good) and this case happens only with one of the two''link number'' (one input on the top left) set to 4,even if a small noise appears with one ''link number'' set to 3.
thanks in advance for any help.
It seems to me that the only thing the filter could affect is the time step used in the integration, assuming you are using a dynamic time step (which is the default). So, my guess is that (if this is not a bug) your system is numerically unstable/chaotic. It could also be related to noise, caused by differentiation. Differentiating noise over a smaller time step mostly makes things even worse.
Solvers such as ode23 and ode45 use a dynamic time step. ode23 compares a second and third order integration and selects the third one if the difference between the two is not too big. If the difference is too big, it does another calculation with a smaller timestep. ode45 does the same with a fourth and fifth order calculation, more accurate, but more sensitive. Instabilities can occur if a smaller time step makes things worse, which could occur if you differentiate noise.
To overcome the problem, try using a fixed time step, change your precision/solver, or better: avoid differentiation, use some type of state estimator to obtain derivatives or calculate analytically.
I have been wondering this for some time now and was curious about the most logical implementation for simulating block diagram based time-domain models.
I don't know if that term is correct, but if you know Simulink you know what I mean.
There reason I am wondering is is that I have made some simulation models myself now, but I always get stuck when I am creating feedback loops. Most of the time this is not a problem when I am working with blocks that I can translate to the state-space domain, but when I get more complex elements this becomes a problem.
Practically I can not seem to get my head around how Simulink solves this.
I had thought that practically for every timesample every block calculates it current state and passes that to the connected blocks for the next timesample, however when you have:
->A->B->C->D
^-----|
4 blocks with a feedback to A and an input to A, it takes 3 timesamples to reach C, after which C will start emitting to A again. Before that C would have been emitting it's initial value. It takes 4 timesamples to reach D.
When A,B,C,D are simple laplace-like elements this is easily combined in a state-space or transfer function from A to D, however the results will be monumentally different. Because it will take 1 timesample from A to D and from C to A. I know that when the transfer function requires you, in general, to specify the initial conditions, but these conditions are not translateable (or I can not see it) to the block diagram solution.
How do you tackle this problem in a generic way?
I want to simulate a Plate Heat Exchanger Model and I use the default-Version in the Modelica-Fluid-Library. To specify the default-Version, I build in all neccessary parameters and equations for heat transfer (Nusselt, etc.) and pressure loss accordingly to the VDI Wärmeatlas 2006, Mm1. I have tried for a long time to find and correct all mistakes, but finally I come to a "dead point".
The error last messages were:
Check of Fluid_Test1_PHE_Temp7.Examples.HeatExchanger.HeatExchangerSimulation:
Error: The model is not well-posed.
The model has
484
scalar unknowns and
480
scalar equations.
Using the given settings of the parameters, the difference could be reduced to
4
Error: The following parameters don't have any value:
HEX.pipe_1.diameter
HEX.pipe_2.diameter
Warning: The following inputs lack binding equations:
HEX.pipe_1.heatTransfer.roughnesses
HEX.pipe_2.heatTransfer.roughnesses
Error: The problem is structurally singular:
It has 488 scalar unknowns and 484 scalar equations.
The Real part has 456 unknowns and 452 equations.
The Integer part has 32 unknowns and 32 equations.
The Boolean part has 0 unknowns and 0 equations.
The String part has 0 unknowns and 0 equations.
Attempting to further localize singularity.
The model has the same number of unknowns and equations.
Attempting to further localize singularity.
The model has the same number of unknowns and equations.
Attempting to further localize singularity.
The model has the same number of unknowns and equations.
The model has the same number of unknowns and equations.
Note: The input connector p of HEX.pipe_1.mediums[1] is not connected from the outside.
It is likely that it should have been connected, and recursive check will assume this.
The missing connection is a likely cause of errors in the model.
Note: The input connector h of HEX.pipe_1.mediums[1] is not connected from the outside.
It is likely that it should have been connected, and recursive check will assume this.
The missing connection is a likely cause of errors in the model.
The model has the same number of unknowns and equations.
Note: The input connector p of HEX.pipe_1.mediums[2] is not connected from the outside.
It is likely that it should have been connected, and recursive check will assume this.
The missing connection is a likely cause of errors in the model.
Note: The input connector h of HEX.pipe_1.mediums[2] is not connected from the outside.
It is likely that it should have been connected, and recursive check will assume this.
The missing connection is a likely cause of errors in the model.
The model has the same number of unknowns and equations.
The model Fluid_Test1_PHE_Temp7.Examples.HeatExchanger.HeatExchangerSimulation component HEX.pipe_1 is structurally singular.
when assuming the most generic outside couplings to all the flow variables of its connectors
and that non-physical connectors will impose suitable constraints.
The reported problems with connections are the likely cause of the singularity.
Singularity of Fluid_Test1_PHE_Temp7.Examples.HeatExchanger.HeatExchangerSimulation is in the component HEX.pipe_1, class Fluid_Test1_PHE_Temp7.Pipes.DynamicPipe.
ERROR: 3 errors were found
WARNING: 1 warning was issued
May anybody can help me? I also can send the model by Mail to somebody to let it check.
Greets
Georg
I don't have access to your model, but the error messages indicate that the issue is with the connections to HEX.pipe_1.mediums (which is an array). It would seem they are not (properly?) connected.
Do you have some reason to think that this is not the problem?
Also, before doing any more testing I would also strongly urge you to provide (non-zero) diameters for the HEX.pipe_1 and HEX.pipe_2 as well as provide "binding equations" for the roughness components of the heat transfer model. Such issues might "mask" other concerns.
Let me know if that helps.