November 2017 - Trac - lists.einsteintoolkit.org

[Einstein Toolkit] #2072: Carpet: Disable OpenMP parallelization of transport operators
by Einstein Toolkit 22 Jan '18

22 Jan '18

#2072: Carpet: Disable OpenMP parallelization of transport operators -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: enhancement | Status: new Priority: major | Milestone: Component: Carpet | Version: development version Keywords: | -------------------------+-------------------------------------------------- This disables the OpenMP parallelization of Carpet's transport operators. I have observed that this leads to a significant speedup when many threads are used. The likely reason is that the regions which are parallelized are typically small. A typical reason would e.g. be the lower x-boundary of one component of one grid variable. The OpenMP thread startup overhead and the cache misses caused by parallelizing this are then larger than any benefit. See <https://bitbucket.org/eschnett/carpet/pull-requests/18/carpet- disable-openmp-parallelization-of/diff>. In a next step (not proposed here), we can parallelize transport operators again, but at a much higher level, e.g. at the level of the loop over all variables that need to be prolongated. However, Carpet currently (and quite unfortunately) uses static variables to hold pointers to timers, and these are not thread-safe. (Neither the static variables nor the timer implementation itself are.) This needs to be either corrected or disabled, which will be the topic of a further pull request. At this time, I ask some of those who are interested in performance in trying this pull request on a few iterations of a production simulation that uses many OpenMP threads and report back here. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2072> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #1784: osx-homebrew.cfg does not work out of the box on Yosemite
by Einstein Toolkit 22 Jan '18

22 Jan '18

#1784: osx-homebrew.cfg does not work out of the box on Yosemite ------------------------+--------------------------------------------------- Reporter: anonymous | Owner: Type: task | Status: new Priority: optional | Milestone: Component: SimFactory | Version: ET_2015_05 Keywords: | ------------------------+--------------------------------------------------- When installing ET anew on Yosemite with the instructions in osx-homebrew.cfg, the build fails because homebrew gets the latest version of gcc (5.1), which is currently not the one then specified in the cactus compilation options (4.9). This problem was encountered by a student who approached ET for the first time. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1784> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1757: Stampede needs to be updated
by Einstein Toolkit 22 Jan '18

22 Jan '18

#1757: Stampede needs to be updated ----------------------+----------------------------------------------------- Reporter: hinder | Owner: Type: task | Status: new Priority: critical | Milestone: Component: Other | Version: development version Keywords: backport | ----------------------+----------------------------------------------------- The SimFactory definition for Stampede currently uses the intel/13.1.1.163 compiler. This compiler will be removed next Tuesday (see https://portal.tacc.utexas.edu/user-guides/stampede/intel15). According to TACC, the current default is the older intel/13.0.2.146, and this is the recommended and default compiler, and will remain so. Both compilers have the "restrict" keyword blacklisted in Cactus (#1276). They will install intel/15.0.1 at the end of April. There is also intel/14.0.1.106 available, but it is labeled as "limited software stack". It is not clear why they are removing a newer compiler, or why they chose to do this a month before installing an even newer one. Our options are: 1. Upgrade to intel/14.0.1.106, which is labeled as "limited software stack" 2. Downgrade to intel/13.0.2.146, which is the default and will remain so for a while This should be done both for the trunk and the release branch. I suggest that option 2 is the most conservative, and probably the easiest, as there might be libraries which are not compiled for intel/14.0.1.106. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1757> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #2007: MoL fails to build with Intel compiler
by Einstein Toolkit 22 Jan '18

22 Jan '18

#2007: MoL fails to build with Intel compiler ---------------------+------------------------------------------------------ Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: blocker | Milestone: Component: Cactus | Version: development version Keywords: | ---------------------+------------------------------------------------------ Compiling MoL gives this error: {{{ /home/ianhin/Cactus/EinsteinToolkitGit/arrangements/CactusNumerical/MoL/src/RK4-RK2.c(60): error: unrecognized OpenMP #pragma #pragma omp /*parallel for*/ ^ compilation aborted for /home/ianhin/Cactus/EinsteinToolkitGit/configs/sim/build/MoL/RK4-RK2.c (code 2) }}} This code was introduced in https://bitbucket.org/cactuscode/cactusnumerical/commits/09a209266daa281a3e…. Removing the commented portion doesn't help. Replacing it with {{{ #pragma omp parallel }}} allows the code to compile. This is on Minerva, with icc (ICC) 16.0.1 20151021. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2007> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #1458: intel 13 2013.1.117 miss-compiles asserts in TwoPunctures tp_utils.c
by Einstein Toolkit 22 Jan '18

22 Jan '18

#1458: intel 13 2013.1.117 miss-compiles asserts in TwoPunctures tp_utils.c -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: TwoPunctures | -----------------------------------+---------------------------------------- this continues the thread in #1429 in particular https://trac.einsteintoolkit.org/ticket/1429#comment:14. Currently we need to determine which versions are affected. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1458> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1599: CarpetInterp/waveinterp_2p tests constant in time initial data
by Einstein Toolkit 27 Dec '17

27 Dec '17

#1599: CarpetInterp/waveinterp_2p tests constant in time initial data --------------------------+------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: CarpetInterp | --------------------------+------------------------------------------------- the test waveinterp_2p sets up initial data using IDWaveMoL (fom CactusExamples) using kx=ky=kz = 0. and slopet = 0.1. Ie the initial data is constant in space and has frequency 0.1. It then evolves this using WaveMoL and interpolates in space and time with CarpetInterp. Since the function is constant in space (exactly so, see eg the output in InterpToArray::array1d_vars[0]) the interpolation in space just tests roundoff errors. The second time derivative (array1d_vars[2]) should be zero and all we measure in the test is truncation errors on the level of 1e-9. This makes the test very sensitive to -Ofast, -O0, gcc vs. intel etc. and not a very good test. I would rather either use a Gausian wave for initial data so that there is some actual data in the result and not just numerical noise, or leave out the 2nd time derivative from the test data. The test fails due to significant errors in a virtual machine using ubuntu.cfg (which usies -ffast-math and -O2). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1599> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 11

[Einstein Toolkit] #2073: IO corruption on SDSC oasis file systems
by Einstein Toolkit 25 Dec '17

25 Dec '17

#2073: IO corruption on SDSC oasis file systems -------------------------------+-------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Other | Version: development version Keywords: Comet Gordon SDSC | -------------------------------+-------------------------------------------- I am experiencing file corruption in ASCII output produced by the Cactus code on Comet's (and Gordon's as far as I remember) scratch file systems. This manifests as lines of output being mashed together in the output file. I have added strace calls to my job script to capture all arguments to the OS's write() function and re-created the write() calls based on this. Those write calls, when replayed on a login node, do produce a correct (no mashed lines) file. All output to the file in question was from rank 0 only even though the code used MPI and ran on two MPI ranks. The same code and number of MPI ranks produces a correct output file when run on the $HOME file system. Thus it seems to me as if there may be an issue with the file system. I can try and reduce the test case to a more minimal example (right now it is a full simulation even though it runs only for <1minute) . You can find the job script (for account, SLURM options etc) here: /oasis/scratch/comet/rhaas/temp_project/simulations/OSTREAM_2_12/output-0000/SIMFACTORY/SubmitScript the script that launches the MPI executable here: /oasis/scratch/comet/rhaas/temp_project/simulations/OSTREAM_2_12/output-0000/SIMFACTORY/RunScript the strace output here: /home/rhaas/strace/strace.1882[67].log and the awk script to recreate the write calls is: gawk -vFS='"' '/write.*\/grid-coordinates.xy.asc/{print "printf \""$2"\""}' ~/strace.18826.log >recreate.sh The corrupted line is eg. line 161 of /oasis/scratch/comet/rhaas/temp_project/simulations/OSTREAM_2_12/output-0000/TEST/sim/CarpetIOASCII/newsep /grid-coordinates.xy.asc which reads 1 4 3 4 1 0.1666666666660.505076272276105285714 etc but should read 1 4 3 4 1 0.166666666666667 -0.0714285714285714 I can avoid the file corruption by flushing the output file after each line. I am wondering if there is anything known about this or if there is a workaround that does not boil to first writing all data to a file system local to the compute node and copying to /oasis/scratch after the job is finished (how much local space would be available since I would also have to do so for eg checkpoint files and 3d hdf5 output). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2073> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1919: have make newthorn create a functioning thorn
by Einstein Toolkit 23 Dec '17

23 Dec '17

#1919: have make newthorn create a functioning thorn -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- Currently the newthorn make target does not create a functioning thorn. It would be good if it produced a skeleton thorn that compiled. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1919> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #2022: thorn guide on et website links to pdf pages
by Einstein Toolkit 23 Dec '17

23 Dec '17

#2022: thorn guide on et website links to pdf pages -------------------------------------+-------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit website | Version: development version Keywords: | -------------------------------------+-------------------------------------- This is a continuation #2010 which was about the thorn guide being missing. This one is about the link behind "Thorn Guide" on http://einsteintoolkit.org/documentation.html, namely http://einsteintoolkit.org/thornguide/ points to an auto-generated index page of a directory of pdf files. Instead of the correct HTML page for a table of content pointing to html pages of documentation. Likely requires web server access to fix. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2022> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 16

[Einstein Toolkit] #2030: Multi-block boundaries leave uninitialized boundary points
by Einstein Toolkit 23 Dec '17

23 Dec '17

#2030: Multi-block boundaries leave uninitialized boundary points -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- Applying multi-block boundaries can leave uninitialized boundary points. This happens when multi-block boundaries are used in combination with another boundary condition that looks at the interior of the grid, such as e.g. a symmetry condition or radiative / extrapolating boundaries. There is another bug currently in McLachlan that applies its "scalar" boundary conditions to too few grid points (it uses "BoundaryNoSync" instead of "Boundary"), which means there are uninitialized boundary points for {{{initial_boundary_condition = "scalar"}}} as well in multi- block systems. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2030> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #2053: simfactory's hard-coded rsync options override a mdb entry's rsyncopts
by Einstein Toolkit 23 Dec '17

23 Dec '17

#2053: simfactory's hard-coded rsync options override a mdb entry's rsyncopts ------------------------+--------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: development version Keywords: | ------------------------+--------------------------------------------------- Right now, in line 165 of simfactory/lib/sim-sync.py {{{ cmd = "%s --rsh=%s --rsync-path=%s %s %s %s" % (rsynccmd, simlib.QuoteSafe(sshcmd), simlib.QuoteSafe(machineEntry.rsynccmd), rsyncopts, machineEntry.rsyncopts, arguments) cmd = "%s %s" % (cmd, " ".join(rsyncoptions)) }}} the hard-coded set of options in rsycnoptions {{{ rsyncoptions = [ '--checksum', '--compress', '--delete', '--hard-links', '--links', '--partial', '--perms', '--progress', '--recursive', '--sparse', '--stats', #'--times', '--verbose'] }}} overwrites the options passed in via the mdb (machineEntry.rsyncopts) since it appears later on the commmand line. This is (currently) an issue for minerva, whose file system does not support hard-links, since there is no way to pass in a {{{--no-hard-links}}} option for just minerva. Typically we don't have hard-links in our code trees, though it is certainly not something that is expected to never happen (eg I do have some hard links). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2053> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #2060: Parallel checkout fails on systems with threading missing from the perl installation
by Einstein Toolkit 13 Dec '17

13 Dec '17

#2060: Parallel checkout fails on systems with threading missing from the perl installation ---------------------------+------------------------------------------------ Reporter: diener | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: GetComponents | Version: development version Keywords: | ---------------------------+------------------------------------------------ One of the participants at the EinsteinToolkit workshop tried to checkout Cactus on a machine she had access to. Apparently threading was missing from the perl installation and checking out with --parallel failed with the error: Can't call method "enqueue" on an undefined value at ./GetComponents line 1025. Checking out serially works. This suggests that some check for the threading is missing or not taken into account properly. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2060> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #1753: hwloc: move pkg-config based detection into Search phase
by Einstein Toolkit 13 Dec '17

13 Dec '17

#1753: hwloc: move pkg-config based detection into Search phase -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: hwloc | -----------------------------------+---------------------------------------- the attacheched patch changes detect.sh such that pkg-config is treated on the same footing as the search at commonly known places. It also adds the option for the user to specify HWLOC_LIBS rather than hard-coding it to hwloc. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1753> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #2086: Perform only spatial prolongation when using a single timelevel and tag 'prolongation="copy"'
by Einstein Toolkit 22 Nov '17

22 Nov '17

#2086: Perform only spatial prolongation when using a single timelevel and tag 'prolongation="copy"' -------------------------------------------------------+-------------------- Reporter: miguel.zilhao.nogueira@… | Owner: eschnett Type: defect | Status: new Priority: unset | Milestone: Component: Carpet | Version: development version Keywords: | -------------------------------------------------------+-------------------- Sometimes it is useful to set a grid function that does not evolve at all. However, using a single timelevel and tag 'prolongation="copy"' results in a Carpet assertion failure. This is fixed in the following commit d13a6e245a3d7d2b575094fd0def540d510a166c, as discussed in the following thread: http://lists.einsteintoolkit.org/pipermail/users/2017-October/005835.html Could this be merged to master? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2086> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #2089: piraha uses Carp::confess() rather than CST_error
by Einstein Toolkit 21 Nov '17

21 Nov '17

#2089: piraha uses Carp::confess() rather than CST_error --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: piraha | --------------------+------------------------------------------------------- It really shouldn't. Instead it should use the CST provided CST_error function and continue parsing. Right now it stops at the first parsing error. I think this has been a point of contention of mine before and I do understand that recovering from a parse error is hard (and is why eg gcc does no longer use a auto-generated parser but instead a hand-written one apparently). However failing after the first parsing error is really annoying. At least it should continue with the next ccl file. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2089> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #2088: setting cctk_parser = "old" in sbin/CST does not completely disable piraha
by Einstein Toolkit 21 Nov '17

21 Nov '17

#2088: setting cctk_parser = "old" in sbin/CST does not completely disable piraha --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: piraha | --------------------+------------------------------------------------------- Namely it still attempts to parse the files with piraha but then throws away the result. The user visible side effect is that if piraha aborts (due to malformed ccl file that the old parser would have accepted) then one can no longer compile the code. This is a problem if one wants to do some bisection to find errors in a mixed old / new code basis. We should either remove the old parser completely or make it possible to completely skip any piraha parsing. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2088> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #1917: sim setup should automatically set up the machine for common OSes
by Einstein Toolkit 21 Nov '17

21 Nov '17

#1917: sim setup should automatically set up the machine for common OSes -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: SimFactory | Version: development version Keywords: | -------------------------+-------------------------------------------------- There are instructions at https://docs.einsteintoolkit.org/et- docs/Simplified_Tutorial_for_New_Users for users to configure simfactory for common operating systems when their machine is not recognised by SimFactory. This logic should be implemented in sim setup instead, so that users can use the ET out of the box on supported OSes. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1917> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #2004: example in New User Tutorial maybe wrong
by Einstein Toolkit 21 Nov '17

21 Nov '17

#2004: example in New User Tutorial maybe wrong --------------------------------------+------------------------------------- Reporter: b.gabella@… | Owner: Bill Gabella Type: defect | Status: new Priority: minor | Milestone: Component: Other | Version: development version Keywords: | --------------------------------------+------------------------------------- Running the static_tov.par that comes in the ETK_2016_11, I see different results for the two plots hydrobase-rho.maximum and admbase-lapse.minimum. See the mail list post Users Digest, Vol 83, Issue 3 on 1 Feb 2017 at 3:10pm. New User Tutorial https://docs.einsteintoolkit.org/et-docs/Tutorial_for_New_Users bill e.g. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2004> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #2087: Scheduling of GRHydro_SqrtSpatialDeterminant.
by Einstein Toolkit 21 Nov '17

21 Nov '17

#2087: Scheduling of GRHydro_SqrtSpatialDeterminant. -----------------------------------+---------------------------------------- Reporter: bentivegna | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- GRHydro calculates and stores the determinant of the spatial metric, among other places, in CCTK_INITIAL. However, there is currently no provision for this to happen after ADMBase_PostInitial, which can potentially change the spatial metric before the initial data is finalized. It can therefore happen that GRHydro uses old metric data. The attached patch solves this problem. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2087> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #2013: piraha breaks ThornDoc building
by Einstein Toolkit 19 Nov '17

19 Nov '17

#2013: piraha breaks ThornDoc building --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- Doing {{{make ThornDocHTML}}} I get an error message in eg in echo RELOADAGENT | gpg-connect-agent of {{{ Undefined subroutine &piraha::parse_peg_file called at /home/rhaas/postdoc/gr/cactus/ET_trunk/lib/sbin/ScheduleParser.pl line 83. }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2013> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 16

[Einstein Toolkit] #1396: Display prompts of executed commands
by Einstein Toolkit 19 Nov '17

19 Nov '17

#1396: Display prompts of executed commands ---------------------------+------------------------------------------------ Reporter: rhaas | Owner: eric9 Type: enhancement | Status: new Priority: optional | Milestone: Component: GetComponents | Version: development version Keywords: | ---------------------------+------------------------------------------------ the attached patch goes to some lengths to capture both stdout and stderr when executing commands and displays each line of output as it is generated by the command. This is useful for programs that output prompts to stdout and wait for user input afterwards. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1396> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #2015: thorn Vectors does not provide a sum() reduction
by Einstein Toolkit 19 Nov '17

19 Nov '17

#2015: thorn Vectors does not provide a sum() reduction -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: Vectors | -------------------------+-------------------------------------------------- It would be very useful for some applications (eg interpolation) if thorn Vectors provided a sum() function similar to the sum() member of vecmathlib https://bitbucket.org/eschnett/vecmathlib/src/477f9c85cf111e59a9042f230bb53… =file-view-default#vec_avx_double4.h-537 {{{ real_t sum() const { // return (*this)[0] + (*this)[1] + (*this)[2] + (*this)[3]; // __m256d x = _mm256_hadd_pd(v, v); // __m128d xlo = _mm256_extractf128_pd(x, 0); // __m128d xhi = _mm256_extractf128_pd(x, 1); realvec_t x = *this; x = _mm256_hadd_pd(x.v, x.v); return x[0] + x[2]; } }}} Most likely one can just copy and paste the code from vecmathlib. vecmathlib's license is not LGPL but permissive enough for inclusion and we can also ask Erik if one can use it and change the license of the affected code lines to LGPL in Cactus, the license is here: https://bitbucket.org/eschnett/vecmathlib/src/477f9c85cf111e59a9042f230bb53… =file-view-default {{{ Copyright (c) 2012, 2013 Erik Schnetter <eschnetter(a)gmail.com> Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2015> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #2026: param.ccl parser writes (debug?) files v1 and v2 into Cactus root
by Einstein Toolkit 19 Nov '17

19 Nov '17

#2026: param.ccl parser writes (debug?) files v1 and v2 into Cactus root --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- The file parametre_parser.pl contains {{{ open($fd,">v1") or die; print $fd $v1,"\n"; close($fd); open($fd,">v2") or die; print $fd $v2,"\n"; close($fd); }}} causing it to create files v1 and v2 in the main Cactus root. Without having looked into this in any more details, this smells like debug output that should be removed before the release. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2026> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #68: GetComponents hang due to certificate issues.
by Einstein Toolkit 19 Nov '17

19 Nov '17

#68: GetComponents hang due to certificate issues. --------------------------------+------------------------------------------- Reporter: diener@… | Owner: eric9 Type: defect | Status: new Priority: major | Milestone: Component: GetComponents | Version: ET_2010_06 Keywords: | --------------------------------+------------------------------------------- I did a complete new checkout of the EinsteinToolkit on numrel06 using the version of GetComponents available on the EinsteinToolkit web pages and had GetComponents hang with no errors or warnings when checking out AEIThorns/AEILocalInterp. Trying the checkout manually I got: Error validating server certificate for 'https://svn.aei.mpg.de:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! Certificate information: - Hostname: svn.aei.mpg.de - Valid: from Tue, 23 Feb 2010 16:02:12 GMT until Sun, 22 Feb 2015 16:02:12 GMT - Issuer: Max-Planck-Gesellschaft, DE - Fingerprint: 03:b4:e8:6e:d9:09:e9:93:72:e9:ff:fa:df:e4:2c:6d:1d:2a:e4:66 (R)eject, accept (t)emporarily or accept (p)ermanently? p After accepting the certificate and restarting the checkout proceeded without problems. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/68> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 29

[Einstein Toolkit] #2076: fix stripping of sourcedir path
by Einstein Toolkit 19 Nov '17

19 Nov '17

#2076: fix stripping of sourcedir path ------------------------+--------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: development version Keywords: backport | ------------------------+--------------------------------------------------- Commit d6e4f58 - sim-sync: handle symbolic links more gracefully (1 year, 6 months ago) <Roland Haas> introduced a bug that manifest in error messages of the form "mkdir: cannot create directory `/ET_Hack': Permission denied". Pull request is https://bitbucket.org/simfactory/simfactory2/pull- requests/21/simlib-correct-stripping-of-first-part/diff This should be backported to the release as it is very annoying to not even be able to use sim sync to transfer code. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2076> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac November 2017