Smokeview does not show BNDF data at boundaries of meshes #1915
Comments
|
This might be an FDS issue. Let me investigate further. |
|
box_burn_away1b.smv.txt |
|
what happens when you load a boundary file ?
…On Thu, Aug 1, 2024 at 2:48 PM Kevin McGrattan ***@***.***> wrote:
box_burn_away1b.smv.txt
<https://github.com/user-attachments/files/16460746/box_burn_away1b.smv.txt>
Remove the .txt and load this file into Smokeview. Run a Tour and notice
that when one of the two obstructions disappears, the remaining one has a
transparent face through which you can see the inside of the obstruction,
and since these inner linings are one-way mirrors, it appears that the
faces are missing unless you look at it from the outside. I understand the
one-way mirror effect for inside surfaces, but why does the shared plane
disappear when the first obstruction disappears. Does Smokeview only draw
one of the two abutting planes?
—
Reply to this email directly, view it on GitHub
<#1915 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC6UCRUUCMW7Q2LNMUKTDIDZPJ7ILAVCNFSM6AAAAABID4VHSOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRTG42DAMZVGM>
.
You are receiving this because you were assigned.Message ID:
***@***.***>
--
Glenn Forney
|
|
It works fine. All six faces of the remaining OBST are colored |
|
think the problem is the blockage is crossing a mesh interface. if the blockage is totally within a mesh do you see the problem? |
|
This is only a problem at the mesh interface. I should have mentioned that. |
|
update your repo and try again. |
|
Yes, that works now, but NGDGU. For this same case, load a boundary file and see that it remains after both blocks have been removed. You might need to use the red wall as background to see it. It might only be possible to view the boundary image from one direction because I think this has to do with surface orientation and the mesh boundary, our old nemesis. |
|
can you upload box_burn_away1b.fds . you just uploaded the .smv file earlier. should have realized - had to google NGDGU |
|
don't need to upload - I see what you are seeing in a different case. |
|
box_burn_away1b.fds.txt |
|
I'm back to looking at this case. does the box_burn_awaay_1b.fds.txt need to be updated? I'm getting this error when running with the latest fds. it runs with 6.9.1 ERROR(375): OBST OBST-1 is VARIBALE_THICKNESS or HT3D and needs a MATL_ID |
|
Move from the |
|
2 cell disappearing blockage case illustrating problem |
|
I forgot to upgrade my Smokeview. This older version shows the patch. |
|
I'm extracting data from the wrong patch. I am using data from the patch for the entire internal mesh interface and extracting values for the portion of the obst . the problem is that for a different case when the blockage disappears it would show the extra patch |
|
OK, but the data for the exposed patch appears to be within the large patch of the interface between the meshes. The key is to stop drawing it once the backing obst disappears. |
|
The problem is there is no information in the boundary file that connects
the mesh interface patch to the blockage. I"ll need to write a new routine
that loops over all blockages and draws data for those blockages that are
adjacent to the mesh interface. I was hoping it was easier for fds to
output the patch to the boundary file. I'll think about it. maybe there is
an easier way
…On Tue, Aug 20, 2024, 4:49 PM Kevin McGrattan ***@***.***> wrote:
OK, but the data for the exposed patch appears to be within the large
patch of the interface between the meshes. The key is to stop drawing it
once the backing obst disappears.
—
Reply to this email directly, view it on GitHub
<#1915 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC6UCRUOEDZ7B4Y345NB62LZSOTUFAVCNFSM6AAAAABID4VHSOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJZG4ZTQNRWGE>
.
You are receiving this because you were assigned.Message ID:
***@***.***>
|
|
Yes, let's ponder. The problem is that MPI process 0 only knows that there are solid objects in the ghost cells created by OBSTs controlled by MPI process 1. We do not cycle over these OBST faces that face outward into another mesh. |
|
this is a 2 mesh case. mesh with dark/thick black outines is mesh 1, other mesh is mesh 2. blockage is in mesh 2. the blue face is on the interface between mesh 1 and 2. this blue face was also a part of a blockage in mesh 1 that disapeared a short time earlier. patches exist for this mesh interface for both boundary files in mesh 1 and mesh 2. which boundary file should smokeview use to color the blue face - the boundary file in mesh 1 ? currently smokeview is using the boundary file for the mesh containing the blockage (mesh 2) but I found the data to be entirely ambient. the boundary file for mesh 1 contained non-ambient temperatures at the mesh interface
|
|
input file for case illustrated in previous comment |
|
note, my changes used to make image are not ready to be pushed up yet |
|
looks like box_burn_away1 is not displaying corrrectly with latest smokeview. I'm taking a look. Looks like it is drawing boundary file patches from two meshes |
Run the case called
Fires/box_burn_away1.fdsusing 4 MPI processes. In Smokeview, load a boundary file ofWALL TEMPERATURE. You will see something like thisIt's been a long time, but is there a reason why the boundary data is not colored on the mesh boundaries? Is this related to the fact that we want to see through the forward facing walls?
The text was updated successfully, but these errors were encountered: