Conditional components (and connectors) make parameters structural

[rurubino1]

In using the ReducedOrder thermal zones package (eg. Buildings.ThermalZones.ReducedOrder.RC.ThreeElements) I came into an issue when writing automatic calibration scripts which try to adjust some parameter of the thermal zone, eg. the area of external walls.

The Buildings library uses extensively the conditional components concept for example for including (or not) an external wall RC element, eg. something like if AExt >0. I guess it's a nice feature so one can "remove" parts of the model safely just by setting surface areas = 0.

The issue is if I try to apply a calibration factor to such a parameter like AExt, eg. somewhere I define AExt = CF*AExt, then CF becomes structural and I cannot change it after compilation (which makes the automatic calibration impractical). I tried setting a min value >0 in the declaration of CF but that didn't help.

Is there a way to "force" Dymola/Modelica to consider that my CF is always >0 so it can be safely modified after compilation without affecting the structure of conditional components? I have previously worked around this issue by duplicating classes in Buildings.ThermalZones.ReducedOrder.RC. and manually removing all conditional statements but I would like to avoid this messy solution and just extend/use the standard classes in my models. Any suggestion or workaround greatly appreciated!

[mwetter]

@rurubino1 : We have been thinking about this issue in the past and I don't think there is a way around it, short of forcing the user to set a boolean parameter such as "have_construction' which the user would have to set to false if he/she were to enter 0 for the surface area. So, your calibration script will have to re-translate the model before simulating it (which I think is what you want to avoid).

Maybe you can play a trick and scale the conductance and density rather than the surface area, which would have the same mathematical effect.

[rurubino1]

@mwetter thanks. That's what I was afraid of... I am going to calibrate R and C values only then and leave the surface areas fixed before translation.

Now, I think I have the same issue with the mSenFac parameter as well, which seems weird: is it also used in some conditional statement do that it cannot be changed after compilation? Or is it because it is declared as final in Buildings.ThermalZones.ReducedOrder.RC.OneElement (when instantiating volAir) ? This would be more annoying since I really think I need to calibrate the air volume.

thank you in advance

[rurubino1]

And another question regarding mSenFac : can you please explain why in Buildings.Fluid.Interfaces.LumpedVolumeDeclarations it is declared with min=1? Shouldn't one be allowed to scale "down" the thermal mass ?

[mwetter]

mSenFac=1 means that only the heat capacity of the air is taken into account, but no additional mass such as due to furniture. So a value below 1 would not be physical.

mSenFac is a structural parameter to simplify the equations for the case where it is 1, which is typically the case in fluid flow systems.

And note that you probably also have to scale the convection coefficient as this also scales with the surface area.

[rurubino1]

I understand the original meaning of mSenFac, but what if I want to calibrate the air volume capacity (eg. using some test data) because I only have an approximate guess of VAir ? In this case I might need a value <1 if I over-estimated the VAir. I thought I could use mSenFac to by-pass the issue of VAir being structural.

If I understand correctly the equation simplification you mention is in Buildings.Fluid.Interfaces.ConservationEquation

  if computeCSen then
    U = m*medium.u + CSen*(medium.T-Medium.reference_T);
  else
    U = m*medium.u;
  end if;

since computeCSen depends on mSenFaccorrect? I tried to remove this ifblock and always use the first equation but I see no effect :(

PS: thanks for the warning on convection coefficient(s). I think I took care of that by setting (for example) k=CF_size*sum(AExt)*alphaExtOutdoor in alphaWall, where alphaExtOutdoor is in W/m²-K

[mwetter]

@rurubino1 : You should be able to change VAir rather than mSenFac (and then have your code translate the model prior to simulation). The parameter mSenFac only applies to the sensible heat, so you would get the wrong behavior of moisture storage if you attempt to reduce the volume with this parameter.

You should see a change in results if you change mSenFac. The calculation is in ConservationEquation.mo, e.g., at

  final parameter Modelica.SIunits.HeatCapacity CSen=
    (mSenFac - 1)*rho_default*cp_default*fluidVolume
    "Aditional heat capacity for implementing mFactor";
protected 
...

  // Parameter for avoiding extra overhead calculations when CSen==0
  final parameter Boolean computeCSen = abs(mSenFac-1) > Modelica.Constants.eps

If recompilation is something you really need to avoid, you could try to connect an instance of Modelica.Thermal.HeatTransfer.Components.HeatCapacitor to the connector intGainsConv and then adjust its capacity. I haven't tried it but this should work (due to the index reduction).

[rurubino1]

@mwetter thank you for your suggestions. I meant I didn't see an effect on the structural nature of mSenFac when I removed the if statement. Maybe the if statement for equation simplification is not the only cause of the structurality? I do see an effect of mSenFac, with recompilation. No effect without recompilation, eg. via a parameter sweep, as expected. Good point on moisture, for the moment I'm considering only sensible heat but this would be a limitation. Anyways, I do need to avoid recompilation, so I'll explore your suggestion to calibrate the air thermal mass, or simply use other parameters to calibrate the model assuming the air volume and thermal mass is "correct" (ie. reasonably guessed).