First, you need a "ground" component — like you would have in an electric circuit. The pump and pipe models only describe pressure changes as function of mass flow, enthalpy etc.

For example, adding a `Modelica.Fluid.Sources.Boundary_pT` with a fixed pressure of 1 bara and connecting it to the suction-side of the pump would provide a pressure reference.

Second, unless the pump has an efficiency of 1, the water in the closed circuit will heat up and you should dispose of the heat with a heat sink somewhere in the circuit.

Third, since your circuit model is entirely static (no dynamic components), finding a solution is probably impossible since the "heating-up" phenomenon mentioned above will not lead to a steady-state solution. Instead, you could replace the static pipe component with a `Modelica.Fluid.Pipes.DynamicPipe` and initializing its pressures, temperature and flow accordingly.

@Finn Haugen.

Please see attached file. It is a package containing the `MathExpression` model mentioned earlier and four simple
FunctionBlock.mo
examples of usage to show the versatility of the Modelica language.

An alternative to the suggestion by Arinomo23 is the following:

block MathExpression

  extends Modelica.Blocks.Interfaces.SISO;

  input Real expression=u "User defined expression" annotation(Dialog);

equation 

  y=expression;

end MathExpression;

To reduce code, it inherits the "SISO" block which already has one input "u" and one output "y".

By default, the expression sets "y=u" to keep the model balanced during code check (equations=unknowns). The "annotation(Dialog)" part enables "graphical" access to the expression input when the block is dragged into the diagram layer. Then, any expression can be entered from the GUI. You can also access public variables and parameters from other blocks in the expression, for example "2*mathExpression.u^2 + someOtherBlock.y + 23".

Note that when you edit the expression from GUI you should provide the fully qualified path to the variables, hence "mathExpression.u" rather than just "u".

If you don't need to graphically connect an output from another block to the expression, you can always use the "Modelica.Blocks.Sources.RealExpression" block from the standard library.   

Hi,

You could repost your question on Stack Overflow (https://stackoverflow.com/questions/tagged/modelica). There are a lot of helpful people...

BR. Rene

The variability problem is a consequence of the implementation of M as a parameter which is constant during simulation.

In your case it would probably be the best to copy the entire code of Modelica.Electrical.Analog.Basic.Transformer to a new model and modify it to your needs — e.g. remove the 'parameter' keyword from the declaration of M.

If you instead declare M as an input you can both use a constant value for M or the expression you mention.

I frequently define icons in classes rather than models. That way I can use the same icon in both models and packages. In Dymola, for example, I get a warning if I extend a package from an icon model. For example:

class valveIcon

  annotation(graphics(...)) // valve icons drawn here;

end valveIcon



model valveModel

  extends valveIcon;

  // equations here

end valveModel



package valvePackage

  extends valveIcon;

  // various valve models inside package

end valvePackage;

Yes, you can declare a vector of N layer models and subsequently use a 'for' loop to connect the outlet of layer[n-1] with inlet of layer[n]. See, for example, https://mbe.modelica.university/compone … _transfer/
Modelica currently hasn't go any language constructs for PDEs, so you will have to make the spatial discretization yourself.

You are right, stratified water is not the solution for you — that was just an example to point you in the direction of what is possible. You probably want each of your layers to be the combination of a flow resistance (air through pebble bed) and the convective heat transfer to the bed mass. For a start that can be constructed with a Modelica.Fluid.Pipes.DynamicPipe connected to a Modelica.Thermal.HeatTransfer.Components.HeatCapacitor via the heat port. The dynamic pipe model has a lot of features that you may want to disable. For instance, you could use a simple pressure drop model (NominalTurbulentFlow) and disable the dynamic mass, energy and momentum balance.


BR. Rene

PS. It's a great question. If you (re)post it on Stack Exchange (https://stackoverflow.com/questions/tagged/modelica) with tags 'modelica' and 'openmodelica' you may get many more replies and comments.

Hello Hans,

I think Modelica would be perfectly suited for the task. You can model a slice/layer of your heat storage as a component (class) and test it separately. Then you can instantiate and interconnect an array of N layers to simulate the distributed effect with the spatial resolution necessary for your studies.

In my work with disctrict heating systems I often use a model of of a thermal heat storage tank modelled in a similar way. It lets me take into account the stratification of water in the tank. The tank model is based on model in the freely available Modelica Buildings Library (Buildings.Fluid.Storage.Stratified.mo). I would advise you to take a look at that library and its excellent documentation and use the mentioned tank model as inspiration.

Best regards
Rene Just Nielsen

Hi Calum,

First of all, I would advise you to use another pump model than the MSL pump. It is not very user friendly and has at least two drawbacks:
- When you specify a pump curve the curve must have its maximum pressure exactly at V_flow=0 to avoid double solutions
- It does not work well at zero flow, zero speed or with reversed flow

These issues have been successfully fixed in the Modelica Buildings Library (MBL). There is even a paper describing in detail how these deficiencies have been circumvented in MBL (https://simulationresearch.lbl.gov/wett … tter.pdf).

Similary, the valve models in MBL are very easy to use.

So my advice is to use MBL for your system. However, I am unsure how well it is supported by OpenModelica.

Best regards
Rene Just Nielsen

You can extend the diagram grid from its default 200x200 in the model annotation, probably at the very bottom in your model text

Du burde overveje at skrive dit spørgsmål på engelsk. Det vil formentlig øge dine chancer for at få et svar...

This is indeed the functionality that Lluc referes to. In the `RealExpression` block you can refer to any variable in your system...

The MSL pumps are quite sensitive. They need the pump curve extremum to be at V_flow=0 which cannot be guaranteed.

I recommend that you take a look at the pumps in the Modelica Buildings Library!

Best regards,
Rene Just Nielsen

Hello Gorzki,

First, I suggest that you look more into the usage of `Stream connectors`: you must always assign some value to the outflowing enthalpy/mass fractions/trace substances of all ports. Also when you don't consider flow reversal. Maybe this small example can be of use to you: https://github.com/justnielsen/ModelicaTutorials
The Wiki part contains a small explanation of `Stream Connectors`

In general, when debugging a model like this it's a good idea to comment out the heat exchange part and just make to separate flow models (side `a_b` and side `a1_b1`) work. Then subsequently including the heat exchange.

Below is a balanced `equation` section of your condenser where all `*_outflow` variables are assigned.

Best regards,
Rene Just Nielsen

equation

   State_1 = Medium_1.setState_phX(
     port_b1.p,
     port_b1.h_outflow,
     port_b1.Xi_outflow);

   State_2 = Medium_2.setState_phX(
     port_b.p,
     port_b.h_outflow,
     port_b.Xi_outflow);


  // Outflowing enthalpy is the inflowing enthalpy plus heat added — applies to both "ends"
  port_b.h_outflow = inStream(port_a.h_outflow) + (Q/port_a.m_flow);
  port_a.h_outflow = inStream(port_b.h_outflow);

  port_a1.h_outflow = inStream(port_b1.h_outflow);
  port_b1.h_outflow = inStream(port_a1.h_outflow) + (Q/port_a1.m_flow);

  0 = port_a.m_flow + port_b.m_flow;
  0 = port_a1.m_flow + port_b1.m_flow;

  port_a.p = port_b.p;
  port_a1.p = port_b1.p;

  port_a1.Xi_outflow = inStream(port_b1.Xi_outflow);
  port_b1.Xi_outflow = inStream(port_a1.Xi_outflow);

  port_a.Xi_outflow = inStream(port_b.Xi_outflow);
  port_b.Xi_outflow = inStream(port_a.Xi_outflow);

  port_a1.C_outflow = inStream(port_b1.C_outflow);
  port_b1.C_outflow = inStream(port_a1.C_outflow);

  port_a.C_outflow = inStream(port_b.C_outflow);
  port_b.C_outflow = inStream(port_a.C_outflow);

Hello Abderezakabidi,

If what you refer to as 'functions' are really Modelica functions (and not models) then you need to pass the global parameters as arguments to the function.

If you simply need to share information across various components/systems (like an ambient temperature) then you can declare this "global variable" in the model containing your instatiated components/subsystems. See for example how Modelica.Fluid.System is used.

I recommend you take a look at Mike Tillers online Modelica book: https://mbe.modelica.university/

Best regards,
Rene Just Nielsen

Hello,

simply number.re

Look in Modelica.ComplexBlocks.ComplexMath.ComplexToReal.mo for an example

Best regards,
Rene Just Nielsen

Hi Emma,

I'm not a user of OpenHydraulics myself. But looking through your model you need to make at least two modifications:

1) you have connected port_b of VariableFlow1 to flange_a of  Cylinder_6M1. You should connect it to the hydraulics port instead.
2) your model extends from PartialFluid. You should instead extend from PartialFluidCircuit and redeclare the oil model. That is: replace the line

"extends OpenHydraulics.Fluids.BaseClasses.PartialFluid"

with

"extends OpenHydraulics.Interfaces.PartialFluidCircuit(redeclare OpenHydraulics.Fluids.GenericOilSimple oil);"

Best regards,
Rene Just Nielsen

Hi akhtarzeb,

Causality and flow-reversal should not be confused:

Causality refers to a way of modelling. Causal modelling is done in e.g. Simulink and in the Modelica.Blocks package and can be very easy to comprehead for the user because you can track the "signal path" in your models. Also algorithms in Modelica are causal i.e. "first do this, then that"...
In acausal modelling you write down relations in terms of equations and unknowns, not considering the order in which the problem is solved. You only need to end up with the same numbers of equation and uknowns. However, in order to be able to solve the model the translation causalizes the system using e.g. time varying boundaries as inputs to the model.

Flow-reversal: in thermo-fluid systems this is a choice by the component designer. Sometimes restricting component models to only allow flow in the "normal" direction will make the simulation faster. In the Modelica.Fluid components most of the components (including DynamicPipe) allow flow reversal. This can be set with the parameter "AllowFlowReversal". This is independent of your choice of static/dynamic balance equations.

Hi akhtarzeb,

Some of the fluid components in the Modelica Standard Library offer different possibilities to switch the mass, energy and momentum balances between static and dynamic. As far as I recall, only the DynamicPipe model implements a dynamic momentum balance.

The three balance equations are tightly coupled and will affec each other. But popularly speaking, you can say that the dynamics of the three balance equations do the following:
- Mass balance: pressure inertia — i.e. increasing inlet pressure will create a lagging outlet pressure
- Energy balance: thermal inertia — i.e. increasing fluid inlet temperature will create a laggin outlet temperature
- Momentum balance: mass flow inertia — creates a reluctance toward changing the mass flow rate. Much like and inductor in electrical systems.

A practical use of the dynamic momentum balance is in the study of water hammer effect. For example in long pipelines, shutting a valve instantaneously will (statically) cause the mass flow to stop immediately. If the dynamics are switched on, the reluctance towards reducing the flow will result in pressure shockwaves due to the energy stored in the moving fluid — which in real applications can destroy the equipment if the valve is closed too fast.

So why isn't the momentum balance dynamic by default? Because the time constant of the momentum balance is orders of magnitude smaller than the time constant of the energy balance. This will result in a stiff equation system which is slow to solve.

Best regards,
Rene Just Nielsen

Hello Twan,

First, I can't run your model since the component "IdealSource" is missing from the package so I can't reproduce your results.

However, looking at your results for the mass flow meter, the signs of the mass flow show that fluid is entering through port_b and leaving from port_a. That means that only port_a.Xi_outflow is valid for the component. If you want to see the mass fractions entering the mass flow meter you must look at the Xi_outflow value of the component connected in the upstream direction of the mass flow meter (or insert a mass fraction meter).

In other words, in terms of the "stream connectors" there is nothing wrong with your model. The value of port_b.Xi_outflow will be valid if you reverse the flow direction.

Best regards,
Rene Just Nielsen

Hi Alexxx,

It sounds to me as if you need a discretized model of your surface with N horizontal cells/control volumes to make up a temperature profile in two directions. If that is your case you must decide on a discretization scheme for your problem and look up the medium properties at each temperature in a cell.

Best regards,
Rene Just Nielsen

Hi Luk,

Yes, 'OutPort' is an old version of the present 'RealOutput'.

As far as I remember, 'OutPort' was defined as an array with size 'n' where 'n' was a parameter within the connector definition, hence the need for the modifier '(n=1)'

'RealOutput' is a scalar connector but can be instantiated as an array using square brackets.

To make your code work, you must replace all occurrences of 'Modelica.Blocks.Interfaces.OutPort portName(n=1)' with 'Modelica.Blocks.Interfaces.RealOutput portName'.

Similarly for arrays of ports you must replace 'Modelica.Blocks.Interfaces.OutPort portName(n=x)' with 'Modelica.Blocks.Interfaces.RealOutput[x] portName' where 'x' is an integer > 1.

Best regards
Rene Just Nielsen

Markus,

Your question is a bit unclear to me. If you just want to look up medium properties of gaseous nitrogen, use the following code:

  package N2 = Modelica.Media.IdealGases.SingleGases.N2 "Short name N2";

  N2.ThermodynamicState state = N2.setState_pT(p,T) "Assuming that you have pressure and temperature as state variables";

  N2.ThermalConductivity lambda = N2.thermalConductivity(state);

  N2.DynamicViscosity mu = N2.dynamicViscosity(state);

  N2.SpecificHeatCapacity cp = N2.specificHeatCapacityCp(state);

  N2.Density rho = N2.density(state);

Best regards,
Rene Just Nielsen

Thanks Joel, you're welcome.

BR Rene

Hi Joel,

You're welcome. I'm glad it worked for you.

Regarding animations: I haven't got much experience with the animations from the mechanical domain. But if you'd like to visualise e.g. the valve opening or the operation of a pump in the diagram view during simulation this is indeed possible with graphical annotations.

The company Claytex has an excellent blog with Modelica tips and tricks (http://www.claytex.com/blog) and this post (http://www.claytex.com/blog/how-to-buil … n-dymola/) is probably what you need to look at.

Best regards
Rene Just Nielsen

Hi Joel,

The problem might be the quadratic pressure drop equation which has two solutions (positive/negative flow). This can be solved in the first place by multiplying the equation with 'sign(Q2)'. Alternatively, you can use the function 'Modelica.Fluid.Utilities.regSquare()' in the equation. This ensures that the derivative is not zero when the flow is zero. Your pressure drop equation will look like this:

outlet.P = inlet.P - Modelica.Fluid.Utilities.regSquare(Q2) / Kv^2;

Best regards,
Rene Just Nielsen

Hello sgopal1,

I've struggled with the same issue many times with the Modelica.Fluid pump models.

The problem is — as the warning tells you — that the pump curve is not monotonically decreasing, meaning that the maximum of the curve is not at V_flow = 0 but to the right of it. The result is that there are two values of the volume flow giving the same pump head which is, numerically, a problem.

The reason for the non-monotonically decreasing curve is that, although you specify nominal points of V_flow and head that are monotonically decreasing, Modelica.Fluid.Machines.BaseClasses.PumpCharacteristics.PolynomialFlow will make a fit to the points without guaranteeing that the "leftmost" point has the maximum head. The figure in this spreadsheet https://docs.google.com/spreadsheets/d/ … sp=sharing shows you the nature of the problem.

I also share a small Modelica model that can plot the pump curve (polynomial) from the nominal values. Please see this link: https://drive.google.com/file/d/1kJVp3- … sp=sharing

In conclusion, I would say that your model (parameterization) is not to blame. Instead, the implementation of PolynomialFlow should make a greater effort to ensure a monotonical decrease.

Best regards,
Rene Just Nielsen

eric_hd,

I'm glad you found a solution to your problem and appreciate you sharing it with the community

Thanks,

BR,
Rene Just Nielsen

Knkc,

Everything looks correct. The one thing that causes the error is the fact that you try to deduce medium properties from 'PartialMedium' which is an 'interface' and not a medium model.

Replace 'Modelica.Media.Interfaces.PartialMedium' with e.g 'Modelica.Media.Water.StandardWater' and everything should be fine.

Best regards
Rene Just Nielsen

Hi sgopal1,

I don't think the problems are related to phase change (to begin with). However, I notice a couple of other things:

1) In both models you haven't assigned a usable medium model for "tJunctionIdeal1"
2) In the dynamic model you attempt to initialize "m_flows" for all the pipe models. You should remove this since "m_flows" is a vector to which you attempt to assign a scalar value.
3) You initialize all your components with no pressure drops (all pressures are 42 bar). You should change this.
4) The T-Junction components connect the pipes which all end with "volume model" (modelStructure = av_vb). This means that you constrain all the pressure states in the pipes to be equal. I my opinion, you should use the dynamic junction model instead and make sure that the pipes connected to that junction end with a "flow model". For example, the model structure of "Pipe" should be "a_v_b" and "pipe1" should be "av_b".
5) You could reduce the discretization of the pipe models until the simulation works well.
6) You should consider starting with simpler pressure drop models in the pipes. For example "NominalLaminarFlow" or "NominalTurbulentPipeFlow". The parameters needed for the models are nominal mass flow rates and pressure drops.
7) Since Dymola (in my case) chooses p and h as states, you should consider using initial enthalpies instead of temperatures.

Best regards,
Rene Just Nielsen

sgopal1,

I made a few modifications to your model (attached). Also see commented code lines in the file.

1) the parameter use_portsData was unspecified. I set it to false (indicating no pressure drop through the tank port(s).
2) I didn't quite understand your initializations in the code. I used the massDynamics/energyDynamics parameters in the System model to initialize the model with a fixed tank level instead
3) with a fixed tank pressure (1 bar) and no pressure drop through the tank port, it's not possible to let the pump control the outlet pressure (since this is already given by the tank model). So I let the pump control the mass flow rate.

You should note that if you run the simulation for long enough time the tank will overflow, causing the simulation to fail. You can avoid this by adding some sort of drain to the tank.

Best regards,
Rene Just Nielsen
Test3-revised.mo

sgopal1,

You don't give us too much information to help you out. An attached model or error message could have been useful.

However, assuming you are using components from Modelica.Fluid, since the model fails to solve at t=0 it is probably due to bad initial values. Try to set you initial values better.

BR
Rene Just Nielsen

Takataka1970,

You could take a look at the paper "Object-oriented Simulation Model of Thermoelectric Devices for Energy System Design" (Felgner/Frey).

BR
Rene Just Nielsen

Hi Takataka1970,

The problem lies in the connect statement

connect(relTemperatureSensor2.T_rel, combiTable1D1.u);

It doesn't specify which of the 'n' inputs of the combiTable you want to connect to the temperature sensor

You should do one of the following:
1) change the connect statement to connect(relTemperatureSensor2.T_rel, combiTable1D1.u[1]); — provided that the table has only one input entry.
2) replace the class combiTable1D with a combiTable1Ds (which has only one input).

Best regards,
Rene Just Nielsen

Hi Koch,

I'm working with stream connectors (and thermo-hydraulic systems) on a daily basis and I fully understand your frustration. I have only learned how to use stream connectors "the hard way".

Hopefully, this will help you along:

I have put togegher a minimalistic fluid library on https://github.com/justnielsen/ModelicaTutorialshttps://github.com/justnielsen/ModelicaTutorials which might give you some inspiration. I tried to keep the models, connectors, medium model etc. as simple as possible.

Further, in the Wiki section (https://github.com/justnielsen/Modelica … connectors) I have written a few words about stream connectors (why one energy balance must implemented with two equations).

Please feel free to use it as you like.

Best regards,
Rene Just Nielsen

Hi Jesper,

"Simple natural gas" is implemented as an ideal gas mixture (Modelica.Media.IdealGasses.MixtureGasses.SimpleNaturalGas) so it doesn't support phase change. That's why you get the error message saying that the gas temperature must be higher than 200 K.

The Modelica Standard Library (MSL) doesn't contain many two-phase gasses (only water/steam and R134a, I think). So you should probably look for an external medium library: CoolProp, RefProp or whatnot.

Hint: you should google "modelica external media" to find a solution.

Best regards
Rene Just Nielsen

Kirk,

This is possible in Dymola but, as far as I know, it is not yet possible in OpenModelica.

I believe that the feature of replacing models and packages through the GUI has been requested for some time, but it has not yet been prioritized by the developers.

So for now, the best way to get around the problem is to insert the line

replaceable package MyMedium = Modelica.Media.Water.StandardWater;

in the beginning of you simulation model (the one with all the thermofluid components). If you want to use another medium than water, the you only need to change that one line of code.

Then in all the instantiated models using a medium model, insert:

(redeclare package Medium=MyMedium)

right after the instance name.

See, for example,

Modelica.Fluid.Examples.PumpingSystem

Regards,
Rene Just Nielsen

Hi knkc,

According to your code below Refp[j] is not an input but is assigned a calculated value - one of the two expressions in the if statement.

The error message indicates that during initialization the value of Refp[j] becomes 17.24/(-7.41609) = -2.32468.

This means that one of the variables mdot, D, A, Mu_hc, Mu_I[j-1] must be negative.

Now, I don't know what the variables in your model represent but a guess would be that

1. mdot is a mass flow rate that is calculated from a pressure difference


2. the pressures are states in your model

Hi GN,

You must specify the full path to the circular class, i.e. your code should be

Modelica.Fluid.Fittings.Orifices.ThickEdgedOrifice Orifice1(geometry =Modelica.Fluid.Fittings.BaseClasses.Orifices.ThickEdgedOrifice.Choices.circular(diameter = 0.002, venaDiameter = 0.001, venaLength = 0.0016))  annotation(Placement(visible = true, transformation(origin = {-22, -2}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));

Best regards,
Rene Just Nielsen

Hi Jordan,

I am currently working on a model of a LiBr/water based absorption heat pump. For starters, I used CoolProp2Modelica (see http://www.thermocycle.net) which uses the external library CoolProp via a modified version of Modelica External Media.

However, I found that it runs rather slow since in Modelica Media you look up the aquaeous solution properties with Medium.*****_pTX()  allthough all LiBr/water properties are functions of T and X only.

Since I was "lucky" to find a great paper...

A computationally effective formulation of the thermodynamic properties of LiBr-H2O solutions from 273 to 500 K over full composition range (Pátek et al. 2006)

Thermodynamic properties of the LiCl-H2O system at vapor-liquid equilibrium from 273 K to 400 K (Pátek et al. 2007)

Thermodynamic Properties of Aqueous Solutions of Lithium Chloride (Chaudhari et al. 2010)