Not clear whether inner or outer diameter should be passt to storage facade

[jakob-wo]

The API of the StratifiedThermalStorage-facade does not specify whether the inner or outer dimensions (diameter and hight) of the storage shell be passt as arguments.
For volume and storage content (nominal_storage_capacity) calculation it should be the inner dimensions.
For heat transfer caclulation the wall thickness and insolation should be taken into account, right? But the facades does not have an argument for passing the wall thickness.

What diameter and hight are suposed to be used here?

[jakob-wo]

I had a closer look at the use of the diameter together with @FranziPl and we realized that the consequences go further than just to point out whether the inner or outer diameter (and hight) have to be passed:
The wall of a heat storage is a bent surface (usually) therefore we have to take into account the difference between inner and outer surface when calculating the thermal resistance (calculation of u-value):
R = 1/(alpha_i*A_i) + s/(lambda*A_w) + 1/(alpha_o*A_o)
where A is the Area/Surface with index i: inner, o: outer and w: wall.
The area of the wall is neither the inner nor the outer surface but in-between it is calculated using the logorithm of the radius as the formula of thermal resistance for heat transfer through a thick-walled pipe shows:
R = ln(r_o/r_i) / (2*lambda*pi*L)
where r is the radius and L is the length of the pipe.

We found that this effect can not be neglected when we compared losses of a thermal storage using one or the other radius (inner or outer) for the u_calue calculation.

[jakob-wo]

@jnnr, do you think this can be considered/included in the facade component?

[c-moeller]

After talking to @jnnr I think it is no problem to implement this, since as far as I understand we would only need to change the function of the u value calculation. We could also think about implementing it as a second method.

@jakob-wo Would it be sufficient to approach this with v0.0.4?

[jakob-wo]

I think I made my point with this issue. Next step sould be to open a PR and fix/implement this.

[jnnr]

After talking to @jnnr I think it is no problem to implement this, since as far as I understand we would only need to change the function of the u value calculation. We could also think about implementing it as a second method.

This is still valid: Adapting the u-value calculation would not involve any change in the facade, as the u-value is a parameter that is passed to the facade.

1. The function calculate_storage_u_value for the u-value calculation could be adapted.
2. Or it could be documented that there is a difference between inner and outer diameter and this is neglected.
3. Or it could be even removed, leaving it to the user to come up with a u-value, instead of coming up with alpha and lambda.

How big is the deviation anyway? I guess for large storages it should not have such a big influence. I got the formula from Planungshandbuch Fernwärme (https://www.energie-zentralschweiz.ch/fileadmin/user_upload/Downloads/Planungshilfen/Planungshandbuch_Fernwarrme_V1.0x.pdf, p. 43). The authors seem to be ok with the simplified formula.

[ChristophPelsLeusden]

The deviation is quantified in the file "Vergleich Ebene Wand - Dickwandiger Zylinder".
The order of magnitude of the deviation is comparable with: s_Iso/d.
Thus, it is right that the error is small for large storages. Nevertheless, I suggest to correct the error since we ourselves found the deviation during the validation process.
Corrections for fixing the issue have been outlined in "AP4_NK_Waermespeicher_v0-6" (Chapter 7).
The derivation of these equations can be found in "Herleitung Gleichungen Dickwandiger Zylinder.pdf"
For correcting the issue, 2 equations have to be modified, one new equation has to be implemented.

[jnnr]

We found out that implementing a more detailled version that takes into account the influence of the bent lateral surface on the thermal transmittance U would require an API change. It would involve a distinction between U at the top and bottom surfaces vs. the lateral surface. As the current API only provides a single U for the whole storage, we decided that we do not change this at the moment. The simplifying assumption will be documented in the docs (#163) . Here, I post our considerations in case that it may be useful at a later point in time.

[jnnr]

We documented the assumption in #163 and posted equations for a model that distintcs the bent and flat surfaces of the storages above. I will leave this issue open for reference but remove the milestone.

[c-moeller]

Does it make sense to put the explanation in the documentation? We have a section about theoretical considerations already: https://oemof-thermal.readthedocs.io/en/latest/theoretical_considerations.html

[ChristophPelsLeusden]

These considerations address a different issue. Thus, we should put the explanation in the doc and also document the equations to solve the issue.