Issue 604 in fds-smv: Writing output much slower in multimesh model

[codesite...@google.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 604 by david.sh...@atf.gov: Writing output much slower in
multimesh model
http://code.google.com/p/fds-smv/issues/detail?id=604

Please complete the following lines...

Application Version: 5.2.5 Serial
SVN Revision Number: 2828
Compile Date: Dec 10, 2008
Operating System: XP

Describe details of the issue below:

I have discovered that writing output is much slower in multi-mesh
models. The decrease in speed is non-linear wrt number of frames and for
my simple test case resulted in 10x longer run times for a default
NFRAME=1000 model.

Nframes One Mesh (sec) Three Mesh (sec)
1000 123 1494
100 91 362
10 83 104
1 82 80
0 82 76

In my simple case I took a small domain (30000 cells) and split it into 3
smaller (10000 cell) meshes.

Attachments:
OneMesh.fds 781 bytes
ThreeMesh.fds 834 bytes

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

[codesite...@google.com]

Updates:
Status: Accepted
Owner: mcgratta

Comment #1 on issue 604 by mcgratta: Writing output much slower in
multimesh model
http://code.google.com/p/fds-smv/issues/detail?id=604

PRESSURE_CORRECTION has extra costs, although not as much as your results
suggest.
Could you post the .out file, which have a break down of the CPU time at
the end.

[codesite...@google.com]

Comment #2 on issue 604 by david.sh...@atf.gov: Writing output much slower

in multimesh model
http://code.google.com/p/fds-smv/issues/detail?id=604

I suspect it is only an issue with optimizing the code for writing the
output and
has nothing to do with the pressure solver. I also tried running it as
ISOTHERMAL
to see if it was a HT/Radiant issue, but which showed the the issue was
solely due
to writing output. When I decreased the NFRAMES to 1 and 0 the run times
were close
to the same, as I expected.

Attached are the out files

Attachments:
OneMesh.out 15.2 KB
ThreeMesh.out 34.3 KB

[codesite...@google.com]

Updates:
Status: Started
Labels: OpSys-Windows Performance

Comment #3 on issue 604 by mcgratta: Writing output much slower in
multimesh model
http://code.google.com/p/fds-smv/issues/detail?id=604

I removed the PRESSURE_CORRECTION in order to compare apples and apples.
Then I ran
the cases on one of our linux machines such that the disk was on the same
machine as
the CPU. I did this to eliminate the possibility of network traffic being a
problem.
The results

One Mesh case (483 time steps):

Time Stepping Wall Clock Time (s): 117.111
Total Elapsed Wall Clock Time (s): 121.809

Three Mesh case (443 time steps):

Time Stepping Wall Clock Time (s): 104.251
Total Elapsed Wall Clock Time (s): 108.964

The difference in wall clock time seem only related to the difference in
number of
time steps.

Attachments:
OneMesh.out 14.8 KB
ThreeMesh.out 31.3 KB

[codesite...@google.com]

Comment #4 on issue 604 by david.sh...@atf.gov: Writing output much slower

in multimesh model
http://code.google.com/p/fds-smv/issues/detail?id=604

Sorry about the pressure correction. I tried that also to see if it made a
difference, and I sent you the wrong outfile.

We found the same type of results here when running it on linux. It seems
that the
problem is ether due to XP or to computer hardware. I will troubleshoot
further on
my own.

Thanks for looking into this.

[codesite...@google.com]

Updates:
Status: Verified

Comment #5 on issue 604 by mcgratta: Writing output much slower in
multimesh model
http://code.google.com/p/fds-smv/issues/detail?id=604

On my XP laptop,

OneMesh (483 time steps):

Time Stepping Wall Clock Time (s): 114.384
Total Elapsed Wall Clock Time (s): 119.821

ThreeMesh (443 time steps):

Time Stepping Wall Clock Time (s): 123.540
Total Elapsed Wall Clock Time (s): 128.837

It seems that my laptop is not performing as well as the Linux machine.
Possibly due
to the fact that I have full disk encryption.

Also, FYI, we changed FDS prior to the latest release so that we "flush"
the output
files every time we write out to files. Previously, we did this every 10
time steps.
In your case, that means we're flushing every time step because you have a
relatively short run.

I'll mark as Verified to clear this off the table, but if you have more
info, we can
revive the case.