disregard ~1E6 'TIME OF ARRIVAL' boundary file values

[gforney]

consider the case in the fds repo:

fds/Verification/WUI/LS_ellipse_0ms_30deg.fds

The ‘no detection’ value is 1E6, so it would be good for smokeview to automatically disregard these (or say any value above 9.9E5), otherwise every time you load it the real data is masked by the big range of values. So don’t render the large values, don’t use them for any interpolation smokeview might do, and don’t include them in colorbar detection (I can change the writing of the *.bnd file if that would fix it?).

Here's what it looks like if I manually adjust the colorbar bounds:

‘lines’ colorbar type do not seem to work for boundary data:

[gforney]

@ericvmueller do you also have a test case for this quantity using a 'regular' boundary file ie the original boundary file format . I want to make sure changes I make work for both boundary file types

[ericvmueller]

Either of the zero slope cases in the WUI folder (LS_ellipse_0ms_00deg or LS_ellipse_5ms_00deg). They don't have GEOM so they use regular boundary files.

FYI I just committed a fix for regular boundary files (firemodels/fds#13918). Previously, if you didn't have CELL_CENTERED=T FDS was including the undefined value in the interpolation to nodes. So even if you mask out say >9.E5 in smokeview, there would have still been unrealistic high values introduced by this interpolation. So just make sure to update FDS before you run either of those cases.

[gforney]

@ericvmueller update your smv repo and rebuild smokeview. you'll need to set the bounds in the .bnd file for the time of arrival boundary file quantities by hand. after you do that try viewing these boundary files and let me know how they look

I also took a look at the 'line' colorbar. something is strange going on with the data . drop by and I'll show you what I'm talking about

[ericvmueller]

Looks good when I run the LS_ellipse_0ms_00deg case, but when I run a sloped one (GEOM) and I delete the *.bnd files first I'm getting an infinity value which messes up the colorbar

Should smokeview be determining the bounds automatically if it cant find the *.bnd file?

....the output looks good once I manually adjust the colorbar though. Thanks!!

[gforney]

for future reference, I haven't touched code yet to re-generate arrival time boundary .bnd files by masking large values. so for what you were seeing is expected

[ericvmueller]

Okay, no problem.

As for the issue of the 'line' colorbar... here's what the nodal data in the boundary file looks like for LS_ellipse_0ms_00deg, at the last time step:

(relative value is t_a/t_end)

Not sure if that helps with your question about data density

[gforney]

@ericvmueller update your smv repo and rebuild smokeview. smokeview should now rebuild .bnd boundary files if they are missing

let me know if I need to do anything for the "Fire residence time" boundary file quantity

[ericvmueller]

The 'fire residence time' quantity shouldnt need any special treatment.

I fixed FDS so the .bnd files it creates at runtime should have an upper bound that ignores the undefined (1E6) values:
firemodels/fds#13925

Let me know if you think the line colorbar issue is just down to coarseness of this case, in which case I can just close out this issue.

[gforney]

I made some changes that should improve things but the visualization is still pixelated - I think due to the coarsesness of the grid and/or data. I took a look at improving the line colorbar but didn't have much success. I think we can close this.

[ericvmueller]

Okay thanks for your help on this!