Wrong assert in EmbeddedPipe

[jelgerjansen]

When using the EmbeddedPipe model in a floor heating configuration, the following asserts are active:

assert(RadSlaCha.alp2 < 1.212, "In order to use the floor heating model, RadSlaCha.alp2 need to be < 1.212");
assert(RadSlaCha.d_a/2 < RadSlaCha.S_2, "In order to use the floor heating model, RadSlaCha.alp2RadSlaCha.d_a/2 < RadSlaCha.S_2 needs to be true");
assert(RadSlaCha.S_1/RadSlaCha.T <0.3, "In order to use the floor heating model, RadSlaCha.S_1/RadSlaCha.T <0.3 needs to be true");

I think the last assert is wrong: you want the thickness of the screed layer above the pipe to be thicker than 0.3 times the pipe spacing such that the assumption of 1D heat transfer (in the Koschenz model) still holds.

This is also confirmed by:

1. The floor heating system properties used in De Schipjes (pipe spacing of 15 cm, screed layer of 6 cm)
2. The asserts for using the model as TABS

    assert(RadSlaCha.S_1 > 0.3*RadSlaCha.T, "Thickness of the concrete or screed layer above the tubes is smaller than 0.3 * the tube interdistance. The model is not valid for this case");
    assert(RadSlaCha.S_2 > 0.3*RadSlaCha.T, "Thickness of the concrete or screed layer under the tubes is smaller than 0.3 * the tube interdistance. The model is not valid for this case");

3. A figure in the TRNSYS 16 user manual
   

However, the same TRNSYS user manual states the following equations and criteria for floor heating systems:

This table is in contradiction with the figure, but given the other arguments, I still think that the assert should become:
assert(RadSlaCha.S_1/RadSlaCha.T >= 0.3, "In order to use the floor heating model, RadSlaCha.S_1/RadSlaCha.T >= 0.3 needs to be true");

@open-ideas/developers @Mathadon since most of you used this model in the past but never raised an issue: do you agree with this? Or can you think of any reasons why the assert should stay as is?

[Mathadon]

Koschenz and Lehmann:

where dx is the pipe spacing. So your analysis is correct :)

However! If you see where RadSlaCha.tabs is used:

  final parameter Real corr = if RadSlaCha.tabs then 0 else sum(-(RadSlaCha.alp2 / RadSlaCha.lambda_b * RadSlaCha.T - 2 * 3.14 * s) / (RadSlaCha.alp2 / RadSlaCha.lambda_b * RadSlaCha.T + 2 * 3.14 * s) * exp(-4 * 3.14 * s / RadSlaCha.T * RadSlaCha.S_2) / s for s in 1:10) "correction factor for the floor heating according to Multizone Building modeling with Type56 and TRNBuild (see documentation). 
        If tabs is used, corr=0 - fixme: deprecated?";

and at the definition of g(s) in the screenshot above:

It looks like corr is an attempt to numerically approximate the infinite sum for cases where RadSlaCha.S_1/RadSlaCha.T >= 0.3 does not hold. So the assert seems to have been designed to ensure that the correction term is activated by the user.

Probably it's best to remove tabs from the definition of RadSlaCha and to compute the correction term when needed.. I.e. when the inequality does not hold.

It looks like TrnSys does something similar, hence the funny inequality in the documentation.