Issue2884 pid autotuning

[mwetter]

This merges the PID autotuning to the master.

[mwetter]

@SenHuang19: This requires considerable more work. Please also see the email I sent.

[JayHuLBL]

@SenHuang19 Run the model Buildings.Fluid.HeatExchangers.Examples.WetCoilCounterFlowPControlAutoTuning, we have the results as below:

It seems that although the tuning process is triggered at 100 seconds and 2100 seconds, the control gain con.con.k and con.con.Ti constantly equal the start values. Could you please double check the results?

[SenHuang19]

@SenHuang19 Run the model Buildings.Fluid.HeatExchangers.Examples.WetCoilCounterFlowPControlAutoTuning, we have the results as below: It seems that although the tuning process is triggered at 100 seconds and 2100 seconds, the control gain con.con.k and con.con.Ti constantly equal the start values. Could you please double check the results?

@JayHuLBL Before merging the master branch, the results appear to be fine. I will thoroughly review it.

[SenHuang19]

@SenHuang19 Run the model Buildings.Fluid.HeatExchangers.Examples.WetCoilCounterFlowPControlAutoTuning, we have the results as below: It seems that although the tuning process is triggered at 100 seconds and 2100 seconds, the control gain con.con.k and con.con.Ti constantly equal the start values. Could you please double check the results?

@JayHuLBL Before merging the master branch, the results appear to be fine. I will thoroughly review it.

@JayHuLBL

• The control gains, con.con.k and con.con.Ti, remain constant at the initial values because the first tuning attempt fails, as detailed in the log file.
• The failure of the initial tuning is due to recent modifications to the valve, which appear to reduce the delay effects.
• I made several adjustments to the example to ensure it works, including minor changes to the valve parameters and those of the relay controllers (see Issue2884 pid autotuning #4054) based on the updated response.

[JayHuLBL]

The CI test is failing with error as below:

rCheck = checkModel("Buildings.Fluid.Movers.Validation.ControlledFlowMachineDynamic");
Pedantic check of Buildings.Fluid.Movers.Validation.ControlledFlowMachineDynamic
-------------------------------------------------
Error: the model is too complex for the current license.
Your license must be upgraded to handle this model.
-------------------------------------------------
Error: ERRORS have been issued.
Declaring variable: Boolean rCheck ;

[mwetter]

The error with the license check occasionally occurs when the license manager takes too long to start and in the meantime Dymola proceeded without checking out the license. Restarting the CI tests helps.

[JayHuLBL]

@mwetter Thanks! It now passed the test. I will have another look and then let you know if it is ready for your review.

[JayHuLBL]

@mwetter It's ready for your review.

[mwetter]

@SenHuang19 @JayHuLBL :
This PR still has a few issues. First, note that I deleted the parameter u_s_start as it has no effect. The start value is overridden as soon as the tuning is initiated. So I set the start value of the sampler to 0.

• A minor thing to address is the default value for yHig and yLow. The parameter yHig has a default of 1 but yLow has no default. This is inconsistent. Is there a rational for it? If so it needs to be documented.
• The documentation of yLow and yHig needs to be improved. It is not clear what they are used for.
• The "guidance for setting the parameters" is not clear. This needs to be made clearer.
• The main issue is that the example WetCoilCounterFlowPIControlAutoTuning, formerly called WetCoilCounterFlowPControlAutoTuning, does not work: The autotuning is interrupted and the message is Autotuning failed. The controller gains are unchanged. The only change I think compared to the older version is that the stroke time of the valve is now 120 s (the default) and not 240 s. Changing the stroke time is not a design choice in HVAC control. This change was somewhat accidental as I introduced a base class, but I have not seen a valve with a stroke time larger than 120 s. I am surprised why a faster process fails the tuning, as it should be easier to control. This hints towards some bug for which there needs to be an explanation and/or a better example.

[SenHuang19]

@SenHuang19 @JayHuLBL : This PR still has a few issues. First, note that I deleted the parameter u_s_start as it has no effect. The start value is overridden as soon as the tuning is initiated. So I set the start value of the sampler to 0.

• A minor thing to address is the default value for yHig and yLow. The parameter yHig has a default of 1 but yLow has no default. This is inconsistent. Is there a rational for it? If so it needs to be documented.
• The documentation of yLow and yHig needs to be improved. It is not clear what they are used for.
• The "guidance for setting the parameters" is not clear. This needs to be made clearer.
• The main issue is that the example WetCoilCounterFlowPIControlAutoTuning, formerly called WetCoilCounterFlowPControlAutoTuning, does not work: The autotuning is interrupted and the message is Autotuning failed. The controller gains are unchanged. The only change I think compared to the older version is that the stroke time of the valve is now 120 s (the default) and not 240 s. Changing the stroke time is not a design choice in HVAC control. This change was somewhat accidental as I introduced a base class, but I have not seen a valve with a stroke time larger than 120 s. I am surprised why a faster process fails the tuning, as it should be easier to control. This hints towards some bug for which there needs to be an explanation and/or a better example.

Thank you so much for the edits and comments. I will create a PR to address the issues.

[SenHuang19]

@mwetter @JayHuLBL
Hi Michael and Jianjun, just report some preliminary findings from my investigation on the example WetCoilCounterFlowPIControlAutoTuning.

The tuning failure is due to a symmetric response from the controlled system. An asymmetric response is typically easier to achieve during the transient period at the start of the simulation. When the valve stroke time is 240s, the transient period is longer, resulting in an overlap with the tuning period. In this case, the tuning completes successfully.

However, when the valve stroke time is reduced to 120s, this overlap no longer occurs, causing the tuning to fail.

I attempted to adjust the yHig and yLow parameters to modify the response when the valve stroke time is reduced to 120s, and it appears to be working now.