This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Carpet — Adaptive Mesh Refinement for the Cactus Framework http://carpetcode.org/".

The branch, master has been updated via 5930260426100d6a6c83aea5e80c6711e2970115 (commit) via 7d977402d5a81ac4941423715cde5bc383fb8b54 (commit) via 8c15ca1ed8101bb8aa9a072aa9a7ac54f8070874 (commit) from 4357322ccee0497e2d11fd35165b5029b37b7650 (commit)

Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below.

- Log ----------------------------------------------------------------- commit 5930260426100d6a6c83aea5e80c6711e2970115 Author: Peter Diener diener@cct.lsu.edu Date: Wed May 21 08:19:31 2014 -0700

CarpetIOHDF5: Reduce time spent in deciding not to do output.

Peter Diener noticed, during some scaling tests, that for his code a significant amount of time was spent by CarpetIOASCII, even though he only had it activated and didn't actually request any output. The reason is that in order to figure out whether to do output or not, there is a loop over all grid variables and a routine (TimeToOutput) is called. In this routine there is a check if the out_dir and out_vars parameters have been steered and if so update some internal data structures. It should be sufficient to do this before entering the loop over grid variables. The same issue is present in CarpetIOScalar and CarpetIOHDF5. The attached patches for CarpetIOASCII, CarpetIOScalar and CarpetIOHDF5 moves this check outside of the loop over grid variables and in addition bypasses the loop completely if the out_vars parameter string is the empty string. Note that the code where he noticed this problem uses large vectors of 1D grid arrays, and it turns out that Cactus counts each vector element as a distinct grid variables and the length of the loop over grid variables in my case was close to 100.000, which might explain why nobody has noticed this before.

Patch by Peter Diener, tiny addition by Roland Haas

commit 7d977402d5a81ac4941423715cde5bc383fb8b54 Author: Peter Diener diener@cct.lsu.edu Date: Wed May 21 07:50:15 2014 -0700

CarpetIOScalar: Reduce time spent in deciding not to do output.

Peter Diener noticed, during some scaling tests, that for his code a significant amount of time was spent by CarpetIOASCII, even though he only had it activated and didn't actually request any output. The reason is that in order to figure out whether to do output or not, there is a loop over all grid variables and a routine (TimeToOutput) is called. In this routine there is a check if the out_dir and out_vars parameters have been steered and if so update some internal data structures. It should be sufficient to do this before entering the loop over grid variables. The same issue is present in CarpetIOScalar and CarpetIOHDF5. The attached patches for CarpetIOASCII, CarpetIOScalar and CarpetIOHDF5 moves this check outside of the loop over grid variables and in addition bypasses the loop completely if the out_vars parameter string is the empty string. Note that the code where he noticed this problem uses large vectors of 1D grid arrays, and it turns out that Cactus counts each vector element as a distinct grid variables and the length of the loop over grid variables in my case was close to 100.000, which might explain why nobody has noticed this before.

Patch by Peter Diener

commit 8c15ca1ed8101bb8aa9a072aa9a7ac54f8070874 Author: Peter Diener diener@cct.lsu.edu Date: Wed May 21 07:45:21 2014 -0700

CarpetIOASCII: Reduce time spent in deciding not to do output.

Peter Diener noticed, during some scaling tests, that for his code a significant amount of time was spent by CarpetIOASCII, even though he only had it activated and didn't actually request any output. The reason is that in order to figure out whether to do output or not, there is a loop over all grid variables and a routine (TimeToOutput) is called. In this routine there is a check if the out_dir and out_vars parameters have been steered and if so update some internal data structures. It should be sufficient to do this before entering the loop over grid variables. The same issue is present in CarpetIOScalar and CarpetIOHDF5. The attached patches for CarpetIOASCII, CarpetIOScalar and CarpetIOHDF5 moves this check outside of the loop over grid variables and in addition bypasses the loop completely if the out_vars parameter string is the empty string. Note that the code where he noticed this problem uses large vectors of 1D grid arrays, and it turns out that Cactus counts each vector element as a distinct grid variables and the length of the loop over grid variables in my case was close to 100.000, which might explain why nobody has noticed this before.

Patch by Peter Diener

-----------------------------------------------------------------------

Summary of changes: Carpet/CarpetIOASCII/src/ioascii.cc | 13 ++++++++----- Carpet/CarpetIOHDF5/src/CarpetIOHDF5.cc | 14 ++++++++++---- Carpet/CarpetIOHDF5/src/OutputSlice.cc | 12 +++++++----- Carpet/CarpetIOScalar/src/ioscalar.cc | 11 ++++++----- 4 files changed, 31 insertions(+), 19 deletions(-)

hooks/post-receive -- Carpet — Adaptive Mesh Refinement for the Cactus Framework http://carpetcode.org/