Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #837: valgrind error in Parameters.c
by Einstein Toolkit 30 Apr '12

30 Apr '12

#837: valgrind error in Parameters.c ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: blocker | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- These lines in Cactus/src/main/Parameters.c (line 2298 ff) are flagged by valgrind: {{{ inval = strtod (temp, &endptr); free(temp); if (*endptr) /* if we cannot parse as a number, try expression */ }}} Note that endptr is set to a location in the string temp that is freed before endptr is accessed. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/837> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #681: LSUThorns/Vectors: Update Kranc-specific code
by Einstein Toolkit 26 Apr '12

26 Apr '12

#681: LSUThorns/Vectors: Update Kranc-specific code -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/681> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #834: Provide access to CarpetLib timers
by Einstein Toolkit 26 Apr '12

26 Apr '12

#834: Provide access to CarpetLib timers -------------------------+-------------------------------------------------- Reporter: hinder | Owner: eschnett Type: enhancement | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | -------------------------+-------------------------------------------------- CarpetLib has several internal timers which contain useful information. I would like to make this more accessible to the user. Currently, these timers can be output by setting CarpetLib::print_timestats_every = 1 and the timer output is written to files called carpetlib-timing-statistics.NNNN.txt This file is in a nonstandard format, contains lots of information, and is difficult to interpret. It is also not realistic to have this output enabled routinely in production simulations because there is one file per process, which leads to large numbers of output files when running with large numbers of processes. There is also no way currently to reduce the information into a min/max/average, which is what we really care about most of the time. Cactus already has the ability to do the above if the timer values are stored in grid arrays. I propose that CarpetLib should define some grid arrays similar to those currently defined in Carpet for its timers. For example, {{{ CCTK_REAL timing TYPE=array DIM=1 SIZE=1 DISTRIB=constant TAGS='checkpoint="no"' { sent_bytes_count sent_bytes_per_second received_bytes_count received_bytes_per_second comm_time } "Per-processor timing information" }}} sent_bytes_count should come from commit_send_space::isend. received_bytes_count should come from commstate::sizes_irecv. comm_time should come from commstate::step. (Aside: Erik mentioned that the hierarchy of these timer names is incorrect; this should be fixed.) My aim is to be able to compare sent_bytes_per_second and received_bytes_per_second with the advertised bandwidth of the interconnect. For example, our own cluster has 5 GB/s full-duplex bandwidth. I would like to display reductions of these variables on standard output using CarpetIOBasic, and store these reductions in output files using CarpetIOScalar. This allows me to see very easily whether the communication is making efficient use of the hardware. The timers I mentioned above would tell us about the actual time to transmit data (or at least, as close as I can find), but does not include any overheads introduced by processing the data before giving it to MPI. We probably want to expose the overheads times as well. When should these variables be updated from the CarpetLib timers? At what point in the schedule, and how frequently? How should the rates (sent_bytes_per_second etc) be computed? Carpet uses a decaying average algorithm to compute its speeds. Does it make sense to do something similar here? Does it make sense to separate sent_bytes_per_second and received_bytes_per_second, given that we only have the combined communication time available? It would probably also be useful to measure latency. Would commstate::step:cnt be the correct number to measure, and if so, how should this be expressed? Does it make sense to provide these values in CarpetLib, or should Carpet provide the infrastructure itself and get the information from the CarpetLib timers? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/834> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #828: num-threads set in the machine files is never used as default value
by Einstein Toolkit 26 Apr '12

26 Apr '12

#828: num-threads set in the machine files is never used as default value ------------------------+--------------------------------------------------- Reporter: alibeck | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: ET_2011_05 Keywords: | ------------------------+--------------------------------------------------- If I set in a mdb/machine ini file num-threads = xx this value is never used e.g. as @NUM_THREADS@ in a SubmitScript or a RunScript, if --num-threads is not set on the command line. Instead of this, always a value of 1 is used as default. Of course this might make sense, if we want to set no OpenMP as default, but then is does ot make sense to set num-threads to a value different of 1 in the machines ini file, or even more, it does not make sense to set num-threads to anything in the machines ini files. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/828> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #822: Provide generic output routines
by Einstein Toolkit 26 Apr '12

26 Apr '12

#822: Provide generic output routines -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Cactus should provide generic output routines. These would output groups of arrays, not necessarily grid functions, in multiple columns per file. Such routines would be convenient in many cases, and would remove the need for specialized output routines that are currently found in many thorns (AH finders, spheres, multipoles, etc.). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/822> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #752: GetComponents hangs when "svn info" reports a certificate warning
by Einstein Toolkit 25 Apr '12

25 Apr '12

#752: GetComponents hangs when "svn info" reports a certificate warning ---------------------------+------------------------------------------------ Reporter: hinder | Owner: eric9 Type: defect | Status: new Priority: major | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ This is similar to, but not the same as, #135. The problem is that GetComponents runs "svn info" on a repository with https where SVN thinks the certificate is not valid: {{{ MacBook-2:manifest (master) $ svn info --username hinder https://svn.cactuscode.org/arrangements/CactusNumerical/MoL/device Error validating server certificate for 'https://svn.cactuscode.org:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! Certificate information: - Hostname: svn.cactuscode.org - Valid: from Thu, 05 Jan 2012 21:31:52 GMT until Fri, 04 Jan 2013 21:31:52 GMT - Issuer: lsu, edu - Fingerprint: d1:ea:8a:9a:a8:7d:a5:15:7a:56:22:27:99:30:96:d7:e4:38:0e:53 (R)eject, accept (t)emporarily or accept (p)ermanently? }}} This causes GetComponents to hang permanently with no indication of what is wrong. The solution to #135 was to add --non-interactive to the "svn update" command, and "svn info" also supports such an option. Should it be added here as well? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/752> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #830: problem connencting with svn.cct.lsu.edu
by Einstein Toolkit 25 Apr '12

25 Apr '12

#830: problem connencting with svn.cct.lsu.edu --------------------------------------+------------------------------------- Reporter: daniel.siegel@… | Type: defect Status: new | Priority: major Milestone: | Component: Other Version: | Keywords: server --------------------------------------+------------------------------------- Hello, we tried to download thorns like the ones listed below -- without success. We cannot connect from within the AEI network (login-damiana.aei.mpg.de). We have experienced the problem for a few days now. Regards, Daniel Siegel ----------------------------------------------------------------- Checking out module: LSUThorns/Vectors from repository: https://svn.cct.lsu.edu/repos/numrel/LSUThorns/Vectors/branches/ET_2011_10 into: Cactus/arrangements Warning: Could not checkout module LSUThorns/Vectors ----------------------------------------------------------------- -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/830> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #807: dependenct problem with standard hdf5 tools within HDF5 thorn
by Einstein Toolkit 24 Apr '12

24 Apr '12

#807: dependenct problem with standard hdf5 tools within HDF5 thorn --------------------+------------------------------------------------------- Reporter: knarf | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: ET_2012_05 Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- Currently the utils-build target depends on the standard hdf5 tools being build using the HDF5 thorn. However, when using an external library those tools are not present and 'make' presents the user with an unresolved build dependency error. We should probably remove binaries which are not always built from the make.configuration.defn file: ALL_UTILS += gif2h5 h52gif h5copy h5debug h5diff h5dump h5import h5jam h5ls h5mkgrp h5perf_serial h5redeploy h5repack h5repart h5stat h5unjam This would however, prevent binaries built by Cactus from being copied to the exe/NAME/ directory. Any ideas how to solve this? Copy them inside the build script maybe? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/807> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #826: cannot log into Wiki
by Einstein Toolkit 23 Apr '12

23 Apr '12

#826: cannot log into Wiki -------------------------------------+-------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit website | Version: Keywords: | -------------------------------------+-------------------------------------- I seem to be unable to log into the wiki (Trac works with the same usename/password). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/826> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #817: add function to flesh to query name of currently executing function
by Einstein Toolkit 23 Apr '12

23 Apr '12

#817: add function to flesh to query name of currently executing function -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- It would be nice if there was a function: {{{ #include <cctk.h> const cFunctionData * CCTK_QueryScheduledFunction(const cGH * cctkGH); const cFunctionData * func = QueryScheduledFunction(cctkGH); printf("Currently running: %s::%s\n", func->thorn, func->routine); }}} to find the function most recently called via CCTK_CallFunction. In the simplest implementation CCTK_CallFunction() (in main/ScheduleInterface.c) would simply store its {{{attribute}}} arguement in a global variable for later retrieval. A more complete implementation might have stack of called functions (in case CallFunction can be called recurively) or store the information in cctkGH (though CallFunction does not take cctkGH as an argument). I currently have a hacked version of the first option running to find out who is calling CarpetReduce in local mode. BUt it might be useful also in eg. the interpolator calls (as in "AEILocalInterpolator: point foo out of bounds"). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/817> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac