Trac May 2014

trac@lists.einsteintoolkit.org

2 participants
138 discussions

[Einstein Toolkit] #1207: Einstein toolkit sites with invalid security certificates
by Einstein Toolkit 19 May '14

19 May '14

#1207: Einstein toolkit sites with invalid security certificates -------------------------------------+-------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit website | Version: Keywords: | -------------------------------------+-------------------------------------- https://einsteintoolkit.org exists but has an invalid security certificate (http://www.sslshopper.com/ssl-checker.html#hostname=einsteintoolkit.org). I don't think we need SSL/TLS on this server. It should either be disabled or a valid certificate used. The same applies to https://cactuscode.org (http://www.sslshopper.com/ssl- checker.html#hostname=cactuscode.org). Note that Frank's page (http://www.cct.lsu.edu/~knarf/cgi-bin/monitor.cgi) reports these certificates as self-signed; they are also expired. Self- signed certificates on public websites are bad: they encourage people to click through the warnings. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1207> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1607: TestMath: undefined reference in function TestMath_CC on loewe machine
by Einstein Toolkit 19 May '14

19 May '14

#1607: TestMath: undefined reference in function TestMath_CC on loewe machine -----------------------------------+---------------------------------------- Reporter: bmundim | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: TestMath | -----------------------------------+---------------------------------------- Trying to compile ET on loewe results in the following linking error: {{{ /home/astro/mundim/tmp/einstein_test/Cactus/configs/et/lib/libthorn_TestMath.a(math_cc.cc.o): In function `TestMath_CC': /home/astro/mundim/tmp/einstein_test/Cactus/arrangements/CactusTest/TestMath/src/math_cc.cc:178: undefined reference to `__builtin_fmaxf' /home/astro/mundim/tmp/einstein_test/Cactus/arrangements/CactusTest/TestMath/src/math_cc.cc:181: undefined reference to `__builtin_fmaxl' /home/astro/mundim/tmp/einstein_test/Cactus/arrangements/CactusTest/TestMath/src/math_cc.cc:190: undefined reference to `__builtin_fminf' /home/astro/mundim/tmp/einstein_test/Cactus/arrangements/CactusTest/TestMath/src/math_cc.cc:193: undefined reference to `__builtin_fminl' }}} loewe.cfg does set -std=c99 to CFLAGS. Any ideas on working around this error? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1607> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1546: LoopControl commit e0ddb732 contains Fortran 2003 code
by Einstein Toolkit 19 May '14

19 May '14

#1546: LoopControl commit e0ddb732 contains Fortran 2003 code --------------------+------------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- commit e0ddb732 "LoopControl: Rewrite" from Wed Jan 16 14:46:17 2013 -0500 introduces Fortran 2003 features (namely {{{bind(C)}}} in loopcontrol_types.F90. This fails to compile with gfortran 4.1.2 (the default gfortran on RH 5 machines, which are still around). David Radice stumbled oppon this. We had 2003 code in Carpet before, in ticket #670. At that point we modified the code to compile with gfortran 4.1.2 and removed the advanced features. Since gfortran 4.1.2 is by now 4 years old and none of our production option lists show the problem, I think we are finally ready to use some F2003 features in the code. We should then document this in the release notes, either for Cactus if we want to make this choice system wide or only for the ET/Carpet if we want to support running eg PUGH with only F90 around. We already require C99 in the Cactus flesh. Possibly we should take this discussion to cactus-devel. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1546> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1373: GRHydro::tov_slowsector test fails in ET_2013_05
by Einstein Toolkit 19 May '14

19 May '14

#1373: GRHydro::tov_slowsector test fails in ET_2013_05 -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: GRHydro | -----------------------------------+---------------------------------------- Most likely due to intel vs. gcc compiler issues. This ticket to serve as a reminder to fix this and to collect information known about this issue. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1373> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1378: provide equivalent of fprintf(stderr, "%s\n", msg) in Fortran
by Einstein Toolkit 19 May '14

19 May '14

#1378: provide equivalent of fprintf(stderr, "%s\n", msg) in Fortran -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- Currently to write out multi-line error messages in Fortran we use multiple calls to CCTK_WARN(1, warnline) followed possibly by a CCTK_ERROR(errline). Each of the level 1 warnings (given certain settings of the Cactus parameters) prints the source file location and other information to screen, thus cluttering the error output. A typical error message might look like this: {{{ WARNING level 1 in thorn GRHydro processor 179 host nid03278 (line 386 of GRHydro_Prim2Con.F90): -> EOS error in prim2con_hot: WARNING level 1 in thorn GRHydro processor 179 host nid03278 (line 388 of GRHydro_Prim2Con.F90): -> 64897 22 37 31 -1.440000E+00 -8.496000E+01 -1.296000E+01 8.595485E+01 WARNING level 1 in thorn GRHydro processor 179 host nid03278 (line 390 of GRHydro_Prim2Con.F90): -> 1.228064E-09 -8.644951E-03 -5.842300E-01 4.789413E-01 WARNING level 1 in thorn GRHydro processor 179 host nid03278 (line 392 of GRHydro_Prim2Con.F90): -> code: 106 WARNING level 1 in thorn GRHydro processor 179 host nid03278 (line 394 of GRHydro_Prim2Con.F90): -> reflevel: 0 WARNING level 1 in thorn GRHydro processor 179 host nid03278 (line 386 of GRHydro_Prim2Con.F90): -> EOS error in prim2con_hot: WARNING level 1 in thorn GRHydro processor 179 host nid03278 (line 388 of GRHydro_Prim2Con.F90): -> 64897 23 37 31 1.440000E+00 -8.496000E+01 -1.296000E+01 8.595485E+01 WARNING level 1 in thorn GRHydro processor 179 host nid03278 (line 390 of GRHydro_Prim2Con.F90): -> 1.227982E-09 -8.644755E-03 -5.798389E-01 4.789407E-01 WARNING level 1 in thorn GRHydro processor 179 host nid03278 (line 392 of GRHydro_Prim2Con.F90): -> code: 106 WARNING level 1 in thorn GRHydro processor 179 host nid03278 (line 394 of GRHydro_Prim2Con.F90): -> reflevel: 0 WARNING level 1 in thorn GRHydro processor 179 host nid03278 (line 166 of GRHydro_Eigenproblem.F90): -> EOS ERROR in eigenvalues_hot WARNING level 1 in thorn GRHydro processor 179 host nid03278 (line 168 of GRHydro_Eigenproblem.F90): -> keyerr: 668 keytemp: 0 WARNING level 0 in thorn GRHydro processor 179 host nid03278 (line 170 of GRHydro_Eigenproblem.F90): -> 1.228064E-09 -8.644951E-03 -5.842300E-01 4.789413E-01 5.668696E-04 cactus_sim: Cactus/arrangements/Carpet/Carpet/src/helpers.cc:314: int Carpet::Abort(const cGH*, int): Assertion `0' failed. Rank 179 with PID 13388 received signal 6 }}} with errors from multiple MPI processes possibly intersecting each other. It would be useful to provide a subroutine equivalent to {{{ subroutine CCTK_WARN_SHORT(msg) character*(*) :: msg write (stderr,'(a)') msg end subroutine }}} (name is up for discussion) that outputs only "msg" to stderr (and the warning listener registered in the flesh) without prepending the file information output. A similar routine might be offered for C (in WARN and VWarn flavors) both for symmetry reasons and to have the message pass the warning listeners, though in C one can usually get away with a single CCTK_VWarn and a very long format string. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1378> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

2 9

[Einstein Toolkit] #1551: Strange warnings at startup
by Einstein Toolkit 19 May '14

19 May '14

#1551: Strange warnings at startup ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | ----------------------+----------------------------------------------------- I see this warning multiple times at startup on Blue Waters: {{{ ^[[1mWARNING[L1,P0] (Flesh):^[[0m Invalid end }}} This is apparently output by the routine Util_IntInRange or Util_DoubleInRange. This happens for the parameter file simfactory/etc/parfiles/submit.par. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1551> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1473: Carpet segfaults in Shutdown
by Einstein Toolkit 16 May '14

16 May '14

#1473: Carpet segfaults in Shutdown --------------------+------------------------------------------------------- Reporter: knarf | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- For high numbers of threads, Carpet segfaults in Shutdown for the testsuite CarpetWaveToyNewRecover_test_1proc. I tried this with gcc and intel on a Debian system. The machine I run this on (spine, with the default simfactory configurations) has 2 processors with 8 cores, and ht enabled. When I run this testsuite with 1 mpi process but certain numbers of threads (e.g. 9, 11, 16) I see this segfault. Which number triggers the bug seems to depend on the compiler, but seems to be consistent within tries. The backtrace I see is, e.g.,: {{{ 1. CarpetLib::signal_handler(int) [/home/knarf/ET_2013_11/exe/cactus_sim(_ZN9CarpetLib14signal_handlerEi+0xeb) [/home/knarf/ET_2013_11/configs/sim/build/CarpetLib/backtrace.cc:542] 2. /lib/x86_64-linux-gnu/libc.so.6(+0x324f0) [??:0] 3. /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [??:0] 4. /lib/x86_64-linux-gnu/libc.so.6(abort+0x180) [??:0] 5. /lib/x86_64-linux-gnu/libc.so.6(+0x6d52b) [??:0] 6. /lib/x86_64-linux-gnu/libc.so.6(+0x76d76) [??:0] 7. /lib/x86_64-linux-gnu/libc.so.6(cfree+0x6c) [??:0] 8. mem<double>::~mem() [/home/knarf/ET_2013_11/exe/cactus_sim(_ZN3memIdED1Ev+0x80) [/home/knarf/ET_2013_11/configs/sim/build/CarpetLib/mem.cc:185] 9. data<double>::free() [/home/knarf/ET_2013_11/exe/cactus_sim(_ZN4dataIdE4freeEv+0x4b) [/home/knarf/ET_2013_11/configs/sim/build/CarpetLib/data.cc:549] a. data<double>::~data() [/home/knarf/ET_2013_11/exe/cactus_sim(_ZN4dataIdED1Ev+0x27) [/home/knarf/ET_2013_11/configs/sim/build/CarpetLib/data.cc:487] b. data<double>::~data() [/home/knarf/ET_2013_11/exe/cactus_sim(_ZN4dataIdED0Ev+0x9) [/home/knarf/ET_2013_11/configs/sim/build/CarpetLib/data.cc:487] c. ggf::recompose_free(int) [/home/knarf/ET_2013_11/exe/cactus_sim(_ZN3ggf14recompose_freeEi+0x1ae) [/home/knarf/ET_2013_11/configs/sim/build/CarpetLib/ggf.cc:257] d. ggf::~ggf() [/home/knarf/ET_2013_11/exe/cactus_sim(_ZN3ggfD1Ev+0xde) [/home/knarf/ET_2013_11/configs/sim/build/CarpetLib/ggf.cc:70] e. gf<double>::~gf() [/home/knarf/ET_2013_11/exe/cactus_sim(_ZN2gfIdED0Ev+0x9) [/home/knarf/ET_2013_11/configs/sim/build/CarpetLib/gf.cc:30] f. Carpet::Shutdown(tFleshConfig*) [/home/knarf/ET_2013_11/exe/cactus_sim(_ZN6Carpet8ShutdownEP12tFleshConfig+0x3ad) [/home/knarf/ET_2013_11/configs/sim/build/Carpet/Shutdown.cc:102] 10. /home/knarf/ET_2013_11/exe/cactus_sim(main+0x49) [/home/knarf/ET_2013_11/configs/sim/build/Cactus/main/flesh.cc:92] 11. /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [??:0] 12. /home/knarf/ET_2013_11/exe/cactus_sim() [??:0] }}} Marking as minor because this is in Shutdown, however if something would actually check for this it might break workflows. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1473> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 14

[Einstein Toolkit] #1576: use https as URL for repositories where available
by Einstein Toolkit 13 May '14

13 May '14

#1576: use https as URL for repositories where available -------------------------+-------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: ET_2014_11 Component: Other | Version: development version Keywords: | -------------------------+-------------------------------------------------- It would be nice to not have different access URLs for repositories depending on whether a user has write access or not. This too often leads to problems when checking something out as "read only" and trying to commit/push later. I propose to have only one URL for repositories where this is possible. For most svn repositories this would mean not using plain http, and for git it would mean combining git@ and git:// into https:// (where possible, carpetcode-hosted repositories do not provide this right now). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1576> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1604: Uninitialised data in tests using PUGH
by Einstein Toolkit 12 May '14

12 May '14

#1604: Uninitialised data in tests using PUGH -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: ET_2014_05 Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- PUGH has a poisoning parameter which can initialise grid variables to NaN. The default is "none" which leaves grid variables uninitialised. If the default is changed to NaN, several tests fail, indicating that they are failing to initialise their data correctly. The tests which fail are: tov_slowsector (from GRHydro) TestComplex (from TestComplex) gaussian (from WaveMoL) The tests fail on both 1 and 2 processes. All report differences related to NaNs apart from tov_slowsector. Possibly there is some NaN-filtering going on there. The test passes without PUGH poisoning. Tests were performed on Datura. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1604> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #1609: CarpetIOHDF5 incorrectly recovers grid scalars and arrays with DISTRIB=CONSTANT
by Einstein Toolkit 08 May '14

08 May '14

#1609: CarpetIOHDF5 incorrectly recovers grid scalars and arrays with DISTRIB=CONSTANT ---------------------+------------------------------------------------------ Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: blocker | Milestone: ET_2014_05 Component: Carpet | Version: development version Keywords: | ---------------------+------------------------------------------------------ Due to the way that grid variables with DISTRIB=constant are handled, a recent change to Carpet (which is required to run on larger core counts) caused these variables to not be correctly recovered (the change was to add a new dimension rather than extend an existing one). There were two things missing: grid scalars are handled as zero dimensional arrays in the flesh but as 1d arrays with 1 element in the driver, restoring variables (arrays or scalars) did not take the new way of handling DISTRIB=constant into account. Since I have already committed fixes before and now have fixes for the fixes (sorry), it would be good if someone was to review them. The typical failure mode is that grid scalars/arrays are not fully recovered which in the case of grid scalars is silent (since the whole variable is missing which we silently ignore) leaving them with undefined values. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1609> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac May 2014