Trac February 2014

trac@lists.einsteintoolkit.org

1 participants
141 discussions

[Einstein Toolkit] #1045: URL field should be optional
by Einstein Toolkit 01 Sep '15

01 Sep '15

#1045: URL field should be optional ---------------------------+------------------------------------------------ Reporter: hinder | Owner: eric9 Type: defect | Status: new Priority: minor | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ In a CRL file, it should be possible to have only an AUTH_URL field and omit the URL field, since it might be that there is no unauthenticated way to access the repository (e.g. for private repositories). At the moment, when I omit the URL field for a Git repository, the error message is: {{{ Use of uninitialized value $git_repo in substitution (s///) at ./GetComponents line 589. Use of uninitialized value $git_repo in substitution (s///) at ./GetComponents line 590. Use of uninitialized value $rec{"GIT_REPO"} in substitution (s///) at ./GetComponents line 593. Use of uninitialized value $rec{"GIT_REPO"} in substitution (s///) at ./GetComponents line 594. ... }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1045> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #334: unsuccessful qsub not recognized / submit succeeds for finished simulation
by Einstein Toolkit 18 Aug '15

18 Aug '15

#334: unsuccessful qsub not recognized / submit succeeds for finished simulation ------------------------+--------------------------------------------------- Reporter: knarf | Owner: mthomas Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- python version: I submitted a simulation 'sim submit' but the corresponding qsub failed due to wrong numbers of procs/node (philip cluster). I changed the number given on the command line and did a 'sim submit' again, this time successful. Several things happend which I think could be done better: - the unsuccessful qsub was not detected during the new submit - it attempted a restart and didn't simply clean the unsuccessful submit - when trying the restart, it went ahead and queued the job, but this later failed when run with "cannot rerun a restart that has been finished". This could have been caught earlier - without the wait time in the queue. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/334> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #649: simfactory should create the "simulations" directory
by Einstein Toolkit 14 Aug '15

14 Aug '15

#649: simfactory should create the "simulations" directory ------------------------+--------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- when following the new users tutorial one gets: {{{ [rhaas@qb1 Cactus]$ ./simfactory/bin/sim submit static_tov --parfile=par/static_tov.par --procs=32 --walltime=8:0:0 Parameter file: /home/rhaas/Cactus/par/static_tov.par Error: could not access simulation base directory /scratch/rhaas/simulations for reading and writing Aborting Simfactory. [137450 refs] }}} This happens each time I set up a fresh simfactory on a machine. It might be useful if simfactory would create the simulation base directory if it does not exist. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/649> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1059: simfactory silent error
by Einstein Toolkit 13 Aug '15

13 Aug '15

#1059: simfactory silent error --------------------------------------+------------------------------------- Reporter: anonymous | Owner: eschnett Type: enhancement | Status: new Priority: optional | Milestone: Component: SimFactory | Version: Keywords: simfactory error message | --------------------------------------+------------------------------------- When sim submit -remote ... fails to queue a job because the allocation has been overdrawn, simfactory does not print any error message to screen (it is only hidden in the log file). Could it be made to print an error message to screen? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1059> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #959: Move pthreads to ExternalLibraries
by Einstein Toolkit 13 Aug '15

13 Aug '15

#959: Move pthreads to ExternalLibraries -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- We should move pthreads support to ExternalLibraries (or to the flesh). I have asked CCT to create the respective repository. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/959> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 14

[Einstein Toolkit] #816: include SphericalHarmonicReconASCII from incoming in PITTNULLCode
by Einstein Toolkit 04 Aug '15

04 Aug '15

#816: include SphericalHarmonicReconASCII from incoming in PITTNULLCode -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Christian Reisswig provided a copy of SphericalHarmonicReconASCII and alternative thorn that reads in CCE boundary data (similar SphericalHarmonicRecon) but supporting a wider variety of input file formats (HDF5 among them, irrespective of the name). Used by SpEC and Llama. There are no docs or test cases as of now. Test data would be welcome (SpEC, Llama or Cactus provided, I don't think it makes a difference). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/816> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 17

[Einstein Toolkit] #1377: GRHydro_Bondi.c and GRHydro_BondiM.c use M_PI
by Einstein Toolkit 16 Jun '15

16 Jun '15

#1377: GRHydro_Bondi.c and GRHydro_BondiM.c use M_PI -----------------------------------+---------------------------------------- Reporter: sbrandt | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: GRHydro M_PI | -----------------------------------+---------------------------------------- GRHydro_Bondi.c and GRHydro_BondiM.c use M_PI. This was a problem on Tianhe-1A. I'd suggest adding the following to both files: #ifndef M_PI #define M_PI 3.141592653589793 #endif -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1377> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 16

[Einstein Toolkit] #1252: Thorn configuration scripts should not be run if there are missing thorns
by Einstein Toolkit 09 Jun '15

09 Jun '15

#1252: Thorn configuration scripts should not be run if there are missing thorns -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- If there are thorns present in the thornlist which are not present in the source tree, Cactus currently displays the corresponding error message, and then runs the rest of the CST including thorn configuration scripts. Since these can build large external libraries (e.g. LORENE), it can be a long time before the user notices that the build has failed. I would prefer if Cactus aborted before running the CST scripts. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1252> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 16

[Einstein Toolkit] #796: Support https for einsteintoolkit.org
by Einstein Toolkit 22 May '15

22 May '15

#796: Support https for einsteintoolkit.org -------------------------------------+-------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit website | Version: Keywords: | -------------------------------------+-------------------------------------- To show our commitment to privacy and IT safety, we should enable https support for our web site. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/796> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #1506: compiling Cactus on Windows
by Einstein Toolkit 17 May '15

17 May '15

#1506: compiling Cactus on Windows --------------------------------+------------------------------------------- Reporter: jtao | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: compiling, windows | --------------------------------+------------------------------------------- Hi, In the process to create the cactusBSSN benchmark for SPEC, I worked with Mat from PGI(now NVIDIA) to help resolve some compilation issues on Windows. I don't have patches for each one of them, but attemptive solutions could be found in the email below. These are not critical issues but it would be good to be resolved to help future windows users if there is any. Regards, Jian Mathew COLGROVE wrote: > Hi Jian, > > I've been working on porting cactusBSSN to Windows. After working through some header file configuration, I encountered several undefined references. I've been able to work around some of them, but a few others I need some help with. > > 1) "STDOUT_FILENO" and "STDERR_FILENO" in Cactus/main/Warnlevel.c > These symbols are found in "unistd.h" which is not available on Windows. I just commented these lines out since I don't think this section is executed. Though, the proper fix would be to define then in > the cctk_Config.h file if not "HAVE_UNISTD_H" is not. The function isatty is defined in unistd.h. A conditional macro will be necessary for that function as well in this case. #if HAVE_UNISTD_H if (!isatty (STDOUT_FILENO)) val = ""; #endif > 2) "hypot" and "copysign" in Cactus/main/Complex.c > > Windows does support "hypot" and "copysign", however they spell them "_hypot" and "_copysign". To work around, I created two versions of each macro that use these symbols. I will probably do the same. > 3) "regexec", "regfree", and "regcomp" in Cactus/main/Parameters.c and Cactus/utils/misc.c > > Windows does not support these functions. We may be able to integrate a port from glibc into the benchmark but I would rather not. Since previous versions of Cactus did not used these symbols, can we use an older version other these files? As a matter of fact, Cactus includes files from the src of the GNU C library. You can find them under Your_Cactus/src/gnu. It is likely that you pre-configured Cactus on a linux box or other systems which provide the library. Cactus will then use the system default instead. To compiler regex.c getopt.c distributed with Cactus, you need to go to Your_Cactus/configs/spec/config-data/ and set both BUILD_GETOPT BUILD_REGEX to yes. # GNU stuff BUILD_GETOPT = yes BUILD_REGEX = yes This will solve #4 below as well. > 4) "getopt_long_only", "optarg", and "optind" in Cactus/main/ProcessCommandLine.c > > Again, there is no Windows equivalent for these symbols. We may be able to integrate something from http://gnuwin32.sourceforge.net/packages/libgw32c.htm, but I would rather not. Since previous versions of Cactus did not used these symbols, can we use an older version other this file? > > 5) "gethostname" and "gethostbyname" in Cactus/utils/Network.c > > Windows does have these functions but we'd need to link with a DLL which I'd rather not have to do (the user should have the option on how to link). Though, I think we'd be safe to remove these functions. Yes, the prototypes of gethostname and gethostbyname can be found in winsock2.h, and Cactus knows how to deal with them on Windows. --------------------------------------- Network.c : ... #elif defined HAVE_WINSOCK2_H #include <winsock2.h> #endif /* HAVE_WINSOCK2_H */ ... --------------------------------------- If linking DLL will be an issue, I would suggest you keep Util_GetHostName but make it a dummy function since Util_GetHostName serves as the interface to gethostname for Cactus. Regards, Jian -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1506> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

← Newer
1
2
3
4
5
6
7
8
9
...
15
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac February 2014