Problem with smokeview and multi-slices

[albertolopezdearriba]

Hi all,

I'm having some problems postprocessing multi-slices with the latest smokeview release. The problem is very similar to issue #5591

New SMV releases (checked with SMV 6.6.0 and 6.6.1) show duplicated slices, wrong slice positions and/or wrong axis, although not for all simulations (it happened with large simulations). Older versions do not have this problem (checked with SMV 6.2.2 and SMV6.4.4)

I'm posting here some screenshots of the same simulation files (FDS 6.6.0, 18 meshes / >10.000.000 cells) postprocessed with SMV 6.6.0 (showing a y-slice millions of meters away from the model and several slices duplicated), SMV 6.6.1 (several slices duplicated and/or in wrong positions) and SMV 6.2.2 (correct).

SMV 6.6.0:

SMV 6.6.1:

SMV 6.2.2:

Slices were carefully placed on cell edges trying to avoid this problem, so that shouldn't be an issue. Cell size is the same for every mesh.

According to issue #5591 this could be happening at least from SMV 6.5.5. I didn't notice it before because my PC was automatically opening SMV files with an older SMV version and not with the one installed with Pyrosim or FDS-SMV installer. It seems that they don't change the windows registry.

You can find attached a reduced version of the simulation file. I deleted all the obstacles but the fire.

TEST_ERROR_SLICES.txt

Thanks in advance for your support.

Best regards,
Alberto.

[gforney]

try smokeview posted here
https://drive.google.com/drive/folders/0B_wB1pJL2bFQc1F4cjJWY2duWTA?usp=sharing
I have made some corrections which may help with your problem.

The slice menus (see attached) look correct with this smokeview according to the SLCF entries (below) you had in your input file.

&SLCF QUANTITY='VISIBILITY', VECTOR=.TRUE., PBX=-889.1/
&SLCF QUANTITY='VISIBILITY', VECTOR=.TRUE., PBX=-783.2/

&SLCF QUANTITY='VISIBILITY', VECTOR=.TRUE., PBY=-585.2/
&SLCF QUANTITY='VISIBILITY', VECTOR=.TRUE., PBY=-565.7/
&SLCF QUANTITY='VISIBILITY', VECTOR=.TRUE., PBY=-557.3/
&SLCF QUANTITY='VISIBILITY', VECTOR=.TRUE., PBY=-533.9/
&SLCF QUANTITY='VISIBILITY', VECTOR=.TRUE., PBY=-528.8/

&SLCF QUANTITY='VISIBILITY', VECTOR=.TRUE., PBZ=0.7/
&SLCF QUANTITY='VISIBILITY', VECTOR=.TRUE., PBZ=8.2/

[albertolopezdearriba]

Thanks Glenn.

I just tried it, but it showed me exactly the same problem than before:

I find it strange that, for example, the slice file for X=-889.1, that lies exactly on a cell edge, is read by SMV as X=-889.099976, but this happened in older versions as well.

SMV is also reading some slices that weren't defined for the simulation, as Y=0.0 or Z=-0.2, and when loaded they show data on arbitrary places, not even on that axis...

I think the problem must be with SMV grouping large slice files. I just checked a shorter simulation of almost the same scenario and it shows no problem at all. I'm guessing that there might be some counter that goes out of range (or something similar) while rebuilding the slice file information in SMV if files are too large. That would explain why some slices are correctly shown and others not. Does it make sense?

[drjfloyd]

As a note. When you provide a real number input like -889.1, the computer stores that as the closest real number to the inputted value at the precision of the variable. In this case, for the input of -889.1, -889.099976 is the actual number stored in the variable.

[gforney]

try to reproduce the problem with the case you uploaded

[albertolopezdearriba]

Dr Floyd, thanks a lot for the explanation.

Glenn, I launched the reduced case and found the same problem. After almost 200s of simulation we get this pictures:

SMV 6.4.4 (OK):

SMV 6.6.1 (ERROR):

With SMV 6.6.1 all slices seem to be mixed and locations are wrong. Loading a slice shows just part of the slice, and maybe some data on another planes.

Then I ran the same simulation for only 5s and SMV 6.6.1 reads the slices correctly:

I hope this helps to address the problem.

[Er9y714]

@albertolopezdearriba, could you please check again the slicefiles after removing .info file in the calculation directory?

I had encountered some problems in SMV due to remaining .info file from the previous calculation. #5283

[albertolopezdearriba]

Ok, I think it's solved. I removed the .info file and the problem disappeared. Old .info file was indeed different than the new one generated when opening SMV after deleting it.

It seems that .info file is different depending on SMV version, am I right?. And if it exists in the folder, SMV doesn't generate it again. So postprocessing during simulation time generated a .info file, and postprocessing with a different SMV version afterwards may lead to these problems if you don't delete that file (for example, SMV version in the simulation cluster is different from the one installed in your PC).

Thank you very much for your help.

[gforney]

smokeview should have detected that the .smv file was newer than the .info file and regenerated it. I will check to see what went wrong

[saschagottfried]

Even if the .smv file was newer than the chid_slice.info file, copying the working directory from cluster to somewhere else may change file attributes related to time. This could happen when people use Windows Explorer for file operations. After copying both files will have same timestamp and Smokeview may skip loading internal slice model from .smv file during startup and skips regeneration of chid_slice.info as well.

Relying on file timestamps for application logic works reliably when the application has exclusive access to application data. Otherwise it can lead to hard-to-debug corner cases. Usually FDS/SMV users are used to have access to files in working directories.

@gforney Can you make sure this issue is not related to serialization/deserialization of slice data? Did the internal format of chid_slice.info changed from SMV 6.2 up to SMV 6.6.X ?

Thanks in advance for your time to investigate.
Sascha

[gforney]

when you copy files using a windows computer, time stamps are preserved even if you copy files from a cluster to cluster, cluster to pc or pc to cluster (I'm assuming you are using samba to access the cluster) . you can do the same on a mac or a linux box by using tar and untar for copying files or by using the -p option of the cp command e.g. cp -p -r old_directory new_directory . I will investigate methods for creating cache files that do not depend on time stamps to know whether the cache file is up to date. In the mean time, if you copy files you need to do it in a way that preserves the times when the files were created.

[gforney]

when the new fds is release it will erase the boundary file and slice file cache files (now named chid.binfo and chid.sinfo) when it first starts running. This will guarantee that smokeview regenerates these files ie smokeview will not depend on modification files. In the mean time, before the next fds is released , the safest thing to do is to erase the .binfo and .sinfo files if you copy your case from a computer that does not update modifcation times properly

smokeview's that implement this new method are posted here
https://drive.google.com/drive/folders/0B_wB1pJL2bFQc1F4cjJWY2duWTA?usp=sharing