Slow vtk writing for FireX

[XXstand]

Hi,

I've been running FireX recently and have noticed that its performance—particularly without GPU acceleration—is slower than standard FDS, especially when dealing with larger, more complex geometries.

Since I am not utilizing a GPU, I suspect the slowdown may be related to VTK formatting or I/O overhead. Do you have any suggestions on how we might accelerate FireX under these conditions? I'm especially interested in optimizations that can help improve performance in CPU-only environments.

Thanks!

[marcosvanella]

You can check if IO is your issue testing a case run with FireX and master and looking at the CHID_cpu.csv files. Where is the cost higher for FireX? in the DUMP column?

[johodges]

There is a known inefficiency in how we are currently writing the VTKHDF output files. I have a draft reworking this output on my fork that should be operational. However, it is not ready to merge into firemodels/FireX yet as I need to do some additional rework for the large HPC cases with thousands of processes. You can give it a try below:

https://github.com/johodges/fds/tree/FireX

[XXstand]

Thanks so much! I will give a try.

[XXstand]

Thanks. Here is the CPU comparasion. The major difference is the DUMP, which is expected.

[XXstand]

Another concern is MAIN function, which also shows 2 order of magnitude difference. Is that normal? Or MAIN should be like this because it has DUMP function?

[marcosvanella]

main should be of the order of the FDS master branch, this is probably related to the accounting of DUMP.

[johodges]

The difference in main is because I had not updated the accounting appropriately in one of the HDF dump routines. MPI processes which have less calls to MPI IO are waiting in MAIN while the processes with more calls to MPI IO are waiting in DUMP.

[XXstand]

Hi everyone,

I think it is better to move this discussion to issue.

Here is the issue:
#14755 (comment)

I will close the discussion.