Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #760: option --submitscript: unclear behaviour with wrong settings
by Einstein Toolkit 27 Mar '12

27 Mar '12

#760: option --submitscript: unclear behaviour with wrong settings ---------------------+------------------------------------------------------ Reporter: alibeck | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Other | Version: Keywords: | ---------------------+------------------------------------------------------ If one enter the name of a directory instead of a dataset after the option --submitscript, simfactory seems to use the default submitscript, without telling the user about that. The simulations sub-directory SIMFACTORY/run contains in this case the default submitscript of the configuration. However looking into the simulations sub-directory output-0000/SIMFACTORY one find an EMPTY submitscript, no runscript is available. In case of having a filename to a non existent file after ---submitscript, simfactory is really using the default submit script; the default submit script can be found in the simulations sub-directory output-0000/SIMFACTORY. Again the user is not informed about the usage of the default. Because of the behaviour with the directory name I am giving this error the priority major. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/760> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #753: prototype for CCTK_Barrier is wrong in reference manual
by Einstein Toolkit 26 Mar '12

26 Mar '12

#753: prototype for CCTK_Barrier is wrong in reference manual ---------------------------+------------------------------------------------ Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: documentation | ---------------------------+------------------------------------------------ the correct prototype is CCTK_Barrier(const cGH *cctkGH) (see rc/include/CommOverloadables.h) not CCTK_Barrier(int cGH, const cGH* cctkGH). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/753> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #765: NaNChecker should not reduce in local mode
by Einstein Toolkit 26 Mar '12

26 Mar '12

#765: NaNChecker should not reduce in local mode -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- The NaNChecker calls reduction operations in local mode. This does not quite work if a process has more than one component of the grid, and deadlocks if processes have different numbers of components. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/765> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #221: Simfactory should complain about unused arguments
by Einstein Toolkit 20 Mar '12

20 Mar '12

#221: Simfactory should complain about unused arguments ------------------------+--------------------------------------------------- Reporter: eschnett | Owner: mthomas Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- When more arguments are given to simfactory that it uses, it should complain with an error message. For example, "sim stop sim1 sim2" stops simulation sim1 and ignores the argument sim2. Instead, it should output an error message if the argument sim2 is ignored. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/221> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #777: remove header includes from IOJpeg/interface.ccl
by Einstein Toolkit 20 Mar '12

20 Mar '12

#777: remove header includes from IOJpeg/interface.ccl --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: IOJpeg | --------------------+------------------------------------------------------- Cactus's include mechanism creates empty files for jconfig.h and jpeglib.h in configs/<configname>/bindings/include since no thorn actually provides these include files (in particular ExternalLibraries/libjpeg does not). Instead these files are regular include files like hdf5.h so no special mechanism to include them is required. Right now the "USE include header" statements in interface.ccl prevent IOJpeg from finding the include files in /usr/include (which appears later in the include search path I assume). Ok, to be applied? Since this thorn lives in Cactuscode I cannot apply the patch myself. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/777> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #774: hack to unfix OpenMP threads from cores on Cray machines
by Einstein Toolkit 17 Mar '12

17 Mar '12

#774: hack to unfix OpenMP threads from cores on Cray machines ----------------------+----------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: task | Status: new Priority: optional | Milestone: Component: Carpet | Version: Keywords: hack | ----------------------+----------------------------------------------------- attached is a simple (and not terrible general) patch to have Carpet try and spread around the OpenMP threads if the parameter cray_thread_affinity_hack is set. Right now something like this is required to avoid a 50% slowdown on Kraken and Hopper. Do we want something like this in the official sources (eventually made a bit more general I'd hope) or is there a way to achieve this via say numactl or do we want to keep Carpet clean of hacks for individual machines? The patch was tried by me and Christian and does indeed unfix the threads. It is currently specific a particular arrangement of threads: for "n" threads and m MPI processes Kraken seems to affix all the threads from process 0 to core 0, all the threads from process 1 to core "n", those of process 2 to core "2*n" etc. The patch just makes threads from process "j" affine to cores j*n,...,(j-1)*n. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/774> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #775: Carpet: undefined CPU_COUNT identifier
by Einstein Toolkit 16 Mar '12

16 Mar '12

#775: Carpet: undefined CPU_COUNT identifier ---------------------+------------------------------------------------------ Reporter: bmundim | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | ---------------------+------------------------------------------------------ I just tried a fresh Cactus built today and it failed in my desktop machine with the following error: /home/bruno/tmp/einstein_dev_maxwell/Cactus/arrangements/Carpet/Carpet/src/SetupGH.cc(363): error: identifier "CPU_COUNT" is undefined int const num_cores = CPU_COUNT(&mask); This function was introduced in Carpet hg revision 3492 and it seems that it is causing trouble for me due to glib library version installed in my system, version 2.5.81. For versions greater than 2.6, it should be fine according to http://www.kernel.org/doc/man-pages/online/pages/man3/CPU_SET.3.html. I was wondering if a mechanism could be introduced in order to test the existence or not of CPU_COUNT (according to glib version?) and do not use it in case it is not defined. Thanks, Bruno. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/775> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #771: Carpet chooses non-ideal domain decompositions
by Einstein Toolkit 13 Mar '12

13 Mar '12

#771: Carpet chooses non-ideal domain decompositions ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | ----------------------+----------------------------------------------------- For a simple 100x100x1 domain, Carpet chooses the following decomposition: [0][0][0][0] exterior: proc 0 [0,0,0] : [24,49,3] ([25,50,4]) 5000 [0][0][0][1] exterior: proc 1 [0,50,0] : [24,99,3] ([25,50,4]) 5000 [0][0][0][2] exterior: proc 2 [25,0,0] : [49,49,3] ([25,50,4]) 5000 [0][0][0][3] exterior: proc 3 [25,50,0] : [49,99,3] ([25,50,4]) 5000 [0][0][0][4] exterior: proc 4 [50,0,0] : [62,99,3] ([13,100,4]) 5200 [0][0][0][5] exterior: proc 5 [63,0,0] : [74,99,3] ([12,100,4]) 4800 [0][0][0][6] exterior: proc 6 [75,0,0] : [87,99,3] ([13,100,4]) 5200 [0][0][0][7] exterior: proc 7 [88,0,0] : [99,99,3] ([12,100,4]) 4800 (a) Why are there elongated boxes? The grid should all have the same shape (50x25). (b) Why are there 25x50 grids? They should have a 50x25 shape. If this happens in 3D, performance will suffer. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/771> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #748: interface.ccl parser reports error for extra spaces after in function alias block
by Einstein Toolkit 12 Mar '12

12 Mar '12

#748: interface.ccl parser reports error for extra spaces after in function alias block ------------------------+--------------------------------------------------- Reporter: jtao | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: CST parser | ------------------------+--------------------------------------------------- E.g., if there are extra spaces after "LANGUAGE C" in the function alias block, the parser will report an missing "Language specification" error instead of discarding the extra spaces. PROVIDES FUNCTION MoLRegisterConstrainedGroup WITH \ MoL_RegisterConstrainedGroup \ LANGUAGE C -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/748> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #769: Execute remote commands in the background
by Einstein Toolkit 12 Mar '12

12 Mar '12

#769: Execute remote commands in the background -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- In response to a discussion on the mailing list, I replied: What we need here is an unsafe delayed-execution mechanism. So far, Simfactory provides the safe version of these mechanisms -- it is safe because all files are copied into the simulation directory, so that the resulting simulation is self-contained. Since this takes time, we are now looking for an unsafe mechanism that works much faster, but could fail. (For example, if one modified the source tree while Simfactory is still copying test results, the resulting simulation may be inconsistent.) I believe the standard Unix mechanism is "nohup". For example, after logging in, you would say "nohup sim create-submit mytests --testsuite --procs 2 &" (note the ampersand to make it run in the background). What we now want is the same thing, except without logging in manually. A current work-around may be something like: ./bin/sim --remote ranger execute 'nohup sleep 100 </dev/null >/dev/null 2>&1 & :' This executes a certain command on Ranger without waiting for the result. It is necessary to redirect I/O so that ssh finishes. The final ":" is a null command to obtain a legal shell syntax -- Simfactory expects the command to end without a terminator (such as "&" or ";"). If you replace the "sleep 100" with any other command (e.g. "sim submit"), things may work. In the long term, this should become an option to "--remote", e.g. "--remote-background". There should then also be a way to retrieve the output generated by this command (which necessarily remains on the remote system). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/769> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac