-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
wrong call to c1_korr in _calc_inner_elements() #734
Comments
Thanks, @PGorzalka, for digging this deep into the calculations. I agree that this is a copy-paste mistake as inner walls should be taken into account as only one half of their total capacity and not by using the corrected c1 value. Referring to VDI 6007 I found:
As we currently only take into account symmetrical thermal loads for inner walls I agree, that only one half of the wall should be used and therefore the line of code needs to be changed to
@PRemmen: you initially implemented these lines. Do you agree with this? |
Hmm, we might be taking only half of the thickness of the wall into account when calculating c1. You need to check the entire chain instead of only this one line of code... There are some test cases to validate the correctness of the calculations. The rest cases are defined in VDI 6007-1. I think the calculation of inner walls is part of the test cases. The test cases are implemented in Teaser and executed as part of the CI. So I assume the calculations are correct.Von meinem/meiner Galaxy gesendet
-------- Ursprüngliche Nachricht --------Von: David Jansen ***@***.***> Datum: 08.05.23 10:13 (GMT+01:00) An: RWTH-EBC/TEASER ***@***.***> Cc: Subscribed ***@***.***> Betreff: Re: [RWTH-EBC/TEASER] wrong call to c1_korr in _calc_inner_elements() (Issue #734)
Thanks, @PGorzalka, for digging this deep into the calculations. I agree that this is a copy-paste mistake as inner walls should be taken into account as only one half of their total capacity and not by using the corrected c1 value. Referring to VDI 6007 I found:
Where temperatures are identical in adjacent rooms, a symmetrical thermal load on the building components can be assumed. The equivalent model as shown in Figure 1 may then be reduced to a model consisting of the elements R1 and C1. Where the thermal load occurs on one side only, the equivalent model for the general case of a thermal load can be simplified as shown in Figure 2.
Figure 1:
Figure 2:
As we currently only take into account symmetrical thermal loads for inner walls I agree, that only one half of the wall should be used and therefore the line of code needs to be changed to
self.c1_iw = inner_walls[0].c1
@PRemmen: you initially implemented these lines. Do you agree with this?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Hey @mlauster , of course you're right and I already checked the rest of the chain. I already had an overview of these parts of the code because I used the "raw" r1/2/3 and c1/2 values for a more detailed model of a test building for this publication.
I also had a look into the VDI 6007 examples. All of them have multiple inner elements, so the second case of the direct link to |
What is the problem?
There seems to be an inconsistency in the
_calc_inner_elements()
function ofOneElement
toFourElement
. If only one inner element exists, the following code is executed:This seems to be a copy-paste mistake (note the "only one outer wall"): last line should be
self.c1_iw = inner_walls[0].c1
I talked about this today with @DaJansenGit and also had that impression after my first description of the topic.
Why do we want to solve it?
It produces wrongly high capacity values for zones with only one inner element. That happens always if set_inner_wall is called within a building with only one floor, i.e. no ceilings and floors are created.
How do we want to solve it?
c1_korr
andc1
a. remove replacement of c1 by c1_korr in wall.calc_equivalent.res()
b. in
_calc_parallel_connection()
, replace the unnecessary repetitions of direct calls to.c1
by an initial call to.c1_korr
or.c1
depending on which elements the parallel connection is calculated for.As 2.b is part of my current contribution to issue #679 , I would suggest correcting this small bug afterwards.
The text was updated successfully, but these errors were encountered: