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.
Related
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.
I met an error during initialization when using ThermoSysPro library.
It seems like the Turbine5.Pe is larger than Turbine2.Pe, so the result is negative. but I checked my parameters, there shouldn't be such a problem.
Is this because the nonlinear solver couldn't solve the equation in the following picture?
There is not enough information and I would recommend to set Details and/or Nonlinear iterations in Simulation setup>Debug>Nonlinear solver diagnostics to get more information.
The full expression causing the problem is sqrt((Turbine2.Pe^2-Turbine5.Pe^2)/(Turbine2.Cst*Turbine2.proe.T))
Since the two Pe-values have fixed=true it seems unlikely that they are wrong, but it is impossible to see without the complete model.
However, it is also possible that either Cst or proe.T is negative, or computed to a negative value based on other values.
Without a complete model that is impossible to tell.
According to the comparison between ThermoSysPro(Open source library from EDF https://github.com/alex19941215/ThermoSysPro ) and ThermalPower(Commercial library from Modelon https://www.modelon.com/library/thermal-power-library ), there should be some inspiration for people faced with the same situation.
Here is the code form ThermoSysPro library:
Connectors.FluidInlet Ce
Connectors.FluidOutlet Cs
Here is a type code from Thermal Power library:
Interfaces.FlowPort feed(
h_outflow(start=hstartin))
Interfaces.FlowPort drain(
p(start=pstart),
h_outflow(start=hstartout))
From the code, we can see that in the Thermal Power library each connector's attribute is assigned values according to the parameters, but in the ThermoSysPro library, the connector is using default values, probably zero. So that's why the Thermal Power library has better performance in the term of initialization convergence
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.
It seems Matlab is giving incorrect results for multinomial logistic regression.
In their example documentation using Fisher's Iris dataset [link], they give coefficients for the model which can be used on the same data set itself to get the modeled probabilities.
load fisheriris
sp = categorical(species);
[B,dev,stats] = mnrfit(meas,sp);
PHAT=mnrval(B,meas);
However, none of the expected value aggregates match the population aggregates which is a requirement for a MaxEnt classifer (See slide 35 [here], or Eq 14 [here], or Agresti "Categorical Data Analysis" pg 298, etc.)
For example
>> sum(PHAT)
>> 49.9828 49.8715 50.1456
should all equal 50 (population values), likewise for other aggregations
If the parameters
B=[36.9450 42.6378
12.2641 2.4653
14.4401 6.6809
-30.5885 -9.4294
-39.3232 -18.2862]
were used instead then all aggregated sufficient statistics match.
Additionally it seems odd that Matlab is solving it with likelihoods, which can produce an error,
Warning: Maximum likelihood estimation did not converge. Iteration
limit exceeded. You may need to merge categories to increase observed
counts
where the only requirement, proved by MLE consideration, is that the expected values match and no likelihood evaluation is needed.
It would be a nice feature that if instead of true classes are given we can give an option for including just the aggregate information.
Submitted a technical error review within Mathworks website. Their reply:
Hello [----],
I am writing in reference to your Technical Support Case #01820504
regarding 'mnrfit'.
Thanks a lot for your patience and reporting this issue. This appears
to be unexpected behavior. It appears to be related to an existing
issue we have in our records, that "mnrfit" does not give correct
maximum likelihood estimates in certain cases. Since the "mnrfit"
function is not finding the maximum likelihood estimates for the
coefficients, we calculated the actual MLEs. When we use these
estimates, we get the desired result of all 50s in this case.
The issue is that, for this particular dataset in our example, the
classes can be separated perfectly. This means that the logistic
function, in order to get exact zero or one probabilities, needs to
have infinite coefficients. The "mnrfit" function carries out an
iterative procedure with the coefficients getting larger, but it stops
at a point where the results have the issue that you have found. We
certainly agree that "mnrfit" could be made to do better. Our
development team is working on it.
At this stage, I am not able to suggest a workaround other than to
write a custom implementation as my colleague and I had tried. For
now, I will be closing this request as I have already forwarded it to
our records. However, if you have any additional questions related to
this case, please do not hesitate to reach me.
Sincerely,
[----]
MathWorks Technical Support Department
I am currently working with a Modelica model in Dymola to simulate a chemical process. The reactor modeling itself is done to a satisfying extent, but I'm having a hard time implementing these models into Modelica, especially with respect to getting the various Media definitions to interconnect and communicate, so to speak. This is also the key achievement of the Modelica implementation of the model.
At the moment I'm struggling with a specific type of error which, even though it appears quite obvious and straight-forward, I find relatively hard to solve. The errors are of the type:
Note: The input connector p of coopolReactor_2706_1.medium 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 coopolReactor_2706_1.medium 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 has the same number of unknowns and equations.
The model EmulsionPolymerizationToolbox.Test.Test_2706 component coopolReactor_2706_1 is structurally singular.
when assuming the most generic outside couplings to all the flow variables of its connectors.
In the specific code which gave this error message, I've mimic'ed a simple lumped volume extending base classes from the Modelica Standard Library, but the error is still the same as for my complete reactor models. That's why understanding and solving this problem is vital to the progress of my assignment.
I've been searching a bit online to find out more about what could cause this problem, without much luck. Could someone please elaborate a bit on these kind of errors, and maybe even suggest solutions? Any inputs from this board will be useful to me.
Thanks in advance.
Regards, Fredrik.
It's possible this is actually a Red Herring. It appears as though this message is generated because of an imbalance in equations. Dymola then searches for the source. It may be that when it seems an imbalance in your component, it also notices that you have an unconnected input and reports that, even if that may not be your problem.
Another thing to keep in mind is that one of the new features in Modelica 3.x was the addition of rules about local balancing of equations and unknowns. One impact of these rules was that for medium models to be balanced, it was necessary to mark some of the variables as inputs (implying they would be specified from the outside). This use of the input qualifier isn't meant to indicate that these variables need to be connected to (or even specified via equations or modifications). Instead, it is really just a way of indicating how many equations are provided by the media model and how many are provided outside.
So where does this leave you. Well, I could be completely wrong (let's not overlook that possibility). But if I'm right, this indicates that you have an imbalance that has nothing to do "unconnected inputs". I suppose the only real help my answer gives is to encourage you to look for other "missing" equations.
If you actually posted code of your simple case, someone might be able to spot the missing equation.