Multiple slices at same coordinate #1436
Comments
|
the source of the problem is that the vertical grid solution in 2 of your meshes is 0.2 m but you specify two slices 0.1 m apart. I do not see the problem when slices are 0.2 m or a greater distance apart (If you do see a problem in tthis case then submit a another test case). Until I come up with a fix I suggest you do not pick slices that are closer together than the grid you specified. |
|
Thanks, that is useful to know! Is it OK to ask for one quantity at one Z-value and a different quantity at another, nearby Z-value? For example, temperature at Z=1.5m and visibility at Z=1.8m, in a model with some 0.4m-size cells? (Those two quantities are actually required for standard analysis in the UK -- the logic being that Z=1.5m could represent a firefighter crouching to avoid a hot smoke layer, and Z=1.8m is a reasonable height for sightlines to emergency signs.) I tried that combination as an example, and it turned out OK, but this has always seemed to be an intermittent problem. |
|
smokeview has a list of all slice files in the .smv file. it has logic to
group these slices into subsets (used call them multti-slices). it uses
the slice type (eg temperature vs visibility), orientation (xy, xz, yz
plane) and position to determine whether two slices belong together. the
distance criteria I use is based on the grid spacing and smokeview gets
confused if two slices are closer together than the grid spacing (thinks
slices you want to belong in different groups are in the same group) - if
other parameters are different then you are ok (again temperature vs
visibility). I've played around with the distance criteria but have not
had success yet. I'm also investigating parsing the input file to get
slice menu information.
you should be careful specifying slices closer together than the grid
spacing (e.g. vertical grid spacing is 1.0 m and you specify a slice at
z=1.2 and 1.7 dont know if fds interpolates or snaps to nearest grid
location - ie will these two slices have the same values).
…On Fri, Sep 16, 2022 at 11:50 AM obscureed ***@***.***> wrote:
Thanks, that is useful to know!
Is it OK to ask for one quantity at one Z-value and a different quantity
at another, nearby Z-value? For example, temperature at Z=1.5m and
visibility at Z=1.8m, in a model with some 0.4m-size cells? (Those two
quantities are actually required for standard analysis in the UK -- the
logic being that Z=1.5m could represent a firefighter crouching to avoid a
hot smoke layer, and Z=1.8m is a reasonable height for sightlines to
emergency signs.) I tried that combination as an example, and it turned out
OK, but this has always seemed to be an intermittent problem.
—
Reply to this email directly, view it on GitHub
<#1436 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC6UCRV47Q7ULHYWCSW2AY3V6SJNZANCNFSM6AAAAAAQNOUMGA>
.
You are receiving this because you commented.Message ID:
***@***.***>
--
Glenn Forney
|
|
There was some discussion earlier (#1026) about slices being given IDs. Would it be possible to use the ID, as well as the other attributes you mention, to group related slices together (or, more importantly, to separate unrelated slices)? Then, if a user is determined to have closely-spaced slices, they can give them different IDs. (At first it sounds unreasonable to ask for closely-spaced slices, but they are closely-spaced according to the coarsest mesh. In the finest mesh, which is presumably where the important stuff is happening, there may be separate results to look at.) Anyway, for my purposes, the QUANTITY difference is enough to keep all the slices I want separate, so I'll mark this issue as closed. Thanks for your time! |
|
I forgot about slice ids. fds outputs an integer slice id to the .smv file for each &SLCF enty in the input file. i used it and the label (Temperature ,density etc) fds also outputs to group slices together . that seems to work a lot better and makes the code simpler. I still have a lot of testing to do but take a look at your cases with smokeviews posted here |
|
I took the smokeviews down. they seem to work for your case but were not working for other cases I tested on. (loading wrong slice) I'm taking a look |
|
smokeview is back up. let me know if it fixed your issue or if you see any other problems |
|
I've tried that test version of smokeview on the case that I sent (as run in FDS6.7.9), and it works: the slice at z=1.5m shows results at 1.5m in the finer mesh and at 1.6m in the coarser mesh; there is a single slice to select at z=1.6m, and it shows results from all meshes. So I'll mark this as closed. Thanks for your efforts! |
Occasionally, in a model with mesh blocks of different resolutions, where a slice requested at a single fixed coordinate, such as
&SLCF PBZ= 1.600, QUANTITY='PRESSURE', /then that slice will be listed in the Smokeview Load/Unload...Slice...Pressure list as multiple slices. Loading one of these will load only some of the results. The interface looks slightly like the image in a previous issue, #120 (except that was back in the days of slices and multi-slices).
I've attached an example, which is near-minimal. Run that, open it in Smokeview and try to load the pressure slice at Z=1.6 -- the interface gives you a choice of two, the first one being the finer mesh.
Some observations:
• There is only one Z=1.6 slice in the example if the slice at Z=1.5 is removed, or if it is moved after the Z=1.6 slice in the input file.
• There are still two Z=1.6 slices in the example if the last mesh block is removed, but they are labelled by the mesh blocks in the GUI.
• In the full-scale cases where I see this, there are typically several mesh blocks at each resolution. There is no very clear pattern of how many slices will be presented in the GUI -- when it is more than one slice at Z=1.6 (or whatever), it is not as simple as one slice per mesh resolution, etc. There can be more slices than there are mesh resolutions. It's possible that all the meshes in a single slice have the same resolution, but I'm not sure. (The most common case is correct behaviour, with just one slice for the whole model.)
• I associate the issue with asking for slices at locations that are not cell/cell boundary values in one of the meshes. In the supplied example, though, the problem is Z=1.6m, which is a boundary value for the 0.1m- and 0.2m-resolution meshes.
• If you automate postprocessing in a .ssf file, then LOADSLICE will pick just one slice, and the results are incomplete. One possible workaround there is to use LOADSLICEM on all the meshes. (But beware PRESSURE: #1433)
• Cutting down a large model to make this small example, I sometimes saw that the list of slices was not correctly sorted -- sometimes the multiple Z=1.6 slices were both before and after a Z=1.8 one.
• The workaround in the GUI is to select each of the slices, one after the other. This is laborious and error-prone.
• The supplied example has all-negative x and y values, but I do not think this is relevant.
This behaviour has been around for many versions, on Linux and on Windows. In the past, I typically saw it while running large models, and I had no time to cut it down to a reportable case until now. It is still present in the current release (FDS 6.7.9, SMV6.7.21) on Linux.
reducedQ.fds.txt
The text was updated successfully, but these errors were encountered: