-
Notifications
You must be signed in to change notification settings - Fork 618
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
Sub-zero temperatures on upper layer temperature devices #10590
Comments
Thanks for the file. I'll take a look. |
@mcgratta The issue appears to be that the z range in the DEVC XB is 0 to 2.9. The grid size is 0.2 m. So the layer height calc is using the 15 devices at 0.1, 0.3, .... 2.9. With a DZ of 0.2 the height being integrated over is 3.0. In the calcs for temperature and layer height, however, we use DV%Z2-DV%Z1 which is 2.9. This throws the calc off. I think we need to return the sum of DZ used in the integral on each mesh as a another DV value that is summed over meshes and use that in the calcs rather than DV%Z2-DV%Z1. I am surprised this hasn't been discovered before but I guess all our examples have XB Z1 to Z2 as being grid boundaries. @KingCZE as a work around up the height of your UPPER TEMPERATURE to be at the top of the grid cell rather than the midpoint (i.e., make 2.9 ->3.0, etc.). Also as a note for future inputs, you don't have the most efficient MESH arrangement. The cost of an MPI calc is the amount of data that has to be shared at mesh boundaries. Dividing this as 3x2x1 rather than 6x1x1 would be more efficient as it would reduce the amount of data being passed (10000 wall cells to 6300 wall cells). |
That seems to fix the issue. I'll push up the changes. |
Wow, thank you, I will try it. I assumed that with the "finite volume method", it should rather be within the cell, but thank you for the explanation. About the mesh, I just chopped it from a bigger model and wrapped it open vents. I appreciate your suggestion though. |
FDS Source: Issue #10590 add DV%VALUE_4 for height of integrand for l…
The fix I just pushed up will avoid this issue in future releases. This was an error that I am surprised no one has found before. |
Sounds like a good Boris nominee. |
@mcgratta: I agree. Added it to the nominee list. |
closing issue. Fix is now in 6.7.8. |
Hi,
Has anyone encountered an issue with devices with upper layer temperature when the results look like this?:
s C
Time SUPPORT_TEMP_01
0 30.10862
1.807392 -566.3
3.614785 -566.299
5.422177 -566.3
7.224091 -566.301
...
Then it goes to some insanely high numbers, then suddenly back to sub-zero. Even the initial temperature is off - it should be 20 °C. The upper layer temperature on trigger is really odd - 614061 °C, 18578.3 °C,.... While HHR and everything else seems correct. Even the temperature slice file shows the correct temperatures and clearly shows that the zone temp devices trigger too early with totally unrealistic temperatures.
Using
CHECK_HT=.TRUE.
doesn't help, neither LES intead of VLES.Code lines example:
FDS version:
Current Date : May 13, 2022 16:47:54
Revision : FDS6.7.7-1109-g60d1a65d0-master
Revision Date : Tue May 10 15:32:45 2022 -0400
Compiler : Intel ifort 2021.2.0
Compilation Date : 12/05/2022 00:31
Current Date : May 13, 2022 19:15:32
Revision : FDS6.7.7-0-gfe0d4ef38-release
Revision Date : Thu Nov 18 17:10:22 2021 -0500
Compiler : Intel ifort 2021.4.0
Compilation Date : Fri 11/19/2021 08:57 AM
Current Date : May 14, 2022 00:00:15
Revision : FDS6.7.7-1109-g60d1a65d0-master
Revision Date : Tue May 10 15:32:45 2022 -0400
Compiler : Intel ifort 2021.2.0
Compilation Date : 11/05/2022 23:10
(without MPI)
The FDS file attached as TXT:
LAYER_TEMP_EXAMPLE.txt
FDS Forum link here:
https://groups.google.com/g/fds-smv/c/Oy31EV_N5Z4
The text was updated successfully, but these errors were encountered: