temperature sensor dynamics

[Mathadon]

The temperature sensor dynamics of IBPSA.Fluid.Sensors.TemperatureTwoPort are artificially slowed when the flow rate decreases. This leads to larger time constants, which can cause a controller to fail. In my case the chiller evaporator temperature goes below zero because the temperature sensor reacts too slowly to the temperature change and the chiller is not disabled, e.g. at 10 % of the nominal flow rate.

This could be attributed to inadequate modelling, but since this effect is non-physical (?) I'd like to propose to change the implementation such that the temperature sensor time constant stays constant for a large range of flow rates, e.g. down to 5 % of the nominal flow rate.

A possible implementation is to change IDEAS.Fluid.Sensors.BaseClasses.PartialDynamicFlowSensor. The definition of k would then be changed from

k = Modelica.Fluid.Utilities.regStep(x=port_a.m_flow,
                                         y1= mNor_flow,
                                         y2=-mNor_flow,
                                         x_small=m_flow_small);

into

k = IBPSA.Utilities.Math.Functions.smoothHeaviside(x=port_a.m_flow,
                                         delta=0.05*m_flow_nominal);

Ideally we can find a reasonable value for the '5%' that is based on physics.

[mwetter]

I don't see why you replace regStep with smoothHeaviside, which then calls regStep. Also, your implementation has delta -> 0 (in smoothHeaviSide) and hence x_small -> 0 in regStep, which defeats the use of a regularization function.

Is the problem you are facing a too high time constant at low flow and then unstable control? The "model" beyond the current implementation is that the sensor has a small control volume. Using a control volume would yield the same dynamics as the current implementation. The implementation was done to make sure that the sensor output does only change very small if there is zero flow rate + numerical noise.

If the purpose of your reformulation is to keep the time constant large until we have very small flows, then one could reformulate mNor_flow (while making sure the system does not get stiff at the transition). Hence, before shifiting the problem, I wonder if you controller is not tuned properly, because delaying the closed loop control proportionally with the mass flow rate is in my view a reasonable approximation and avoids quick changes in closed loop delays around some flow rate, which can make the control tuning harder.

[Mathadon]

@mwetter I misinterpreted the model. It should have been delta=0.05*m_flow_nominal instead of delta=0.05*mNor_flow. I adjusted the code above accordingly. The purpose of the Heaviside is that it returns 1 for a broad range of flow rates, instead of port_a.m_flow, which is a difference compared to using RegStep directly.

I understand the reasoning behind the control volume, I'm just wondering how physical this model is. If the pipe nominal flow rate is 1 m/s and the sensor is 5 cm 'long' then the time constant when reasoning from this 'control volume model' is in the order of 1/20 s. The real dynamics of a temperature sensor are probably slower and are likely related to thermal diffusion through some material? This is more flow rate independent.

My idea was to modify the implementation such that the sensor output still stays constant for zero flow: the smoothHeaviSide returns k=0 for m_flow=0.

Your last paragraph: that is indeed my intention, but I did it by reformulating k instead of mNor_flow.

I'm not a control engineer so perhaps there exist other solutions. Actually, I fixed the problem now by using a dedicated filter instead of a temperature sensor with a time delay. However, that does not really matter at this point. I'd just like to make sure that our sensor implementation is sufficiently physical. If it is, then we should not change the implementation. Otherwise perhaps we should, to avoid similar issues in the future for other users who might not understand why their controller fails.

[mwetter]

@Mathadon :

Both implementations, your new and the current one, increase the order of the transfer function from actuator to sensor signal. So in this regard they are equally bad, but the increased order is needed to guard against numerical noise at zero flow. (Unless one would set allowFlowReversal = false and tau=0).

In the current implementation, a linear transfer function stays linear except for |m_flow| < m_flow_small = 1E-4 * m_flow_nominal. Such small flow rates are usually only when no more setpoint tracking occurs.

In your implementation, the non-linearity is at 5% of the nominal flow rate. For two way valves, you often still want to track set points. But now, we have this strong nonlinearity due to the regularization, which causes a large change in the control gain. This can cause an otherwise stable controller to become unstable. Moreover, this is compounded by the situation that flow control has already large gains if you use linear valves (or worse an air damper) and open them slightly, in particular if they have a small authority (e.g, are oversized).

Therefore, I think the current implementation is easier to ensure that the controller is stable.

I fully agree that the main sensor dynamics is not because of a control volume. Any other delay would need to be added to the output signal if it is of interest. But I would not encourage users to add such effects as it makes control tuning harder and is not of interest for most use cases.

[Mathadon]

I think I see your point. I will need to think a bit about this.

[mwetter]

@Mathadon : Do you want to close this issue or do you still think about it?