Trac March 2014

trac@lists.einsteintoolkit.org

1 participants
137 discussions

[Einstein Toolkit] #1550: Carpet Timer object gives 0 the first time it is read
by Einstein Toolkit 25 Apr '14

25 Apr '14

#1550: Carpet Timer object gives 0 the first time it is read --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: ET_2014_05 Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- The getTime method of the Carpet Timer object returns a value of 0 the first time it is read. The following test demonstrates the problem: {{{ SCHEDULE Timer_TestTimer at startup { LANG: C } "Test the timers" }}} {{{ #include <unistd.h> extern "C" int Timer_TestTimer() { Timer timer("Test"); timer.start(); unsigned int reason = sleep(1); double val = timer.getTime(); assert(reason != 0 || val > 0.5); timer.stop(); } }}} This is a regression since the original version of the Timer class, possibly introduced during the move of the class from Carpet to Timers. A symptom is that the evolution timer tree shows "inf" for the percentage of the total time the first time it is used, since the Evolve timer used to normalise the time values has been read as zero. The underlying Cactus timers do not suffer from this problem, so there is something wrong in the logic for the Timer class. The following test passes: {{{ SCHEDULE Timer_TestCactusTimers at startup { LANG: C } "Test the Cactus timers" }}} {{{ extern "C" int Timer_TestCactusTimers() { int handle = CCTK_TimerCreate("TestTimer"); cout << "handle == " << handle << endl; assert(handle >= 0); CCTK_TimerStartI (handle); unsigned int reason = sleep(1); CCTK_TimerStopI (handle); static cTimerData * timer = 0; if (not timer) timer = CCTK_TimerCreateData (); assert (timer); CCTK_TimerI (handle, timer); const cTimerVal* tv = CCTK_GetClockValue("gettimeofday", timer); assert(tv); double val = CCTK_TimerClockSeconds(tv); assert(reason != 0 || val > 0.5); return 0; } }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1550> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1359: add "read from file" option ot HydroBase's initial_data options
by Einstein Toolkit 25 Apr '14

25 Apr '14

#1359: add "read from file" option ot HydroBase's initial_data options -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: HydroBase | -----------------------------------+---------------------------------------- the attached patch adds a value "read from file" to HydroBase's initial_XXX options. This makes it possible to use IOUtils file reader with hydro data. This is somewhat similar to IDFileADM's extension of ADMBase's options, only we do not have to set any grid scalars. Needed to be able to reproduce the MHD paper's collapse test since Whisky_RNSID is not public. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1359> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 18

[Einstein Toolkit] #1215: Source browsing not working
by Einstein Toolkit 24 Apr '14

24 Apr '14

#1215: Source browsing not working ----------------------------------+----------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit trac | Version: Keywords: | ----------------------------------+----------------------------------------- The repositories in the "Browse source" TRAC interface (https://trac.einsteintoolkit.org/browser) are not being updated. The last Cactus flesh commit visible there is from 10 months ago. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1215> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1528: check that mainstream machines use correct thread binding
by Einstein Toolkit 23 Apr '14

23 Apr '14

#1528: check that mainstream machines use correct thread binding ------------------------+--------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: task | Status: new Priority: major | Milestone: Component: SimFactory | Version: development version Keywords: | ------------------------+--------------------------------------------------- it is possible that systems that initialize themselves before hwloc (eg MPI) bind to the wrong CPU core unless (the equivalent of) numactl is used. For an example on bluewaters see #1527. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1528> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1562: ExternalLibraries/hwloc unbuildable after a make clean.
by Einstein Toolkit 22 Apr '14

22 Apr '14

#1562: ExternalLibraries/hwloc unbuildable after a make clean. -----------------------+---------------------------------------------------- Reporter: anonymous | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Other | Version: development version Keywords: | -----------------------+---------------------------------------------------- ExternalLibraries/hwloc seems to get into an unbuildable state after doing a "make MY-CONFIG-clean". In other words, after executing the clean target a subsequent make encounters returns an error: arrangements/ExternalLibraries/hwloc/src/system_topology.cc:47:19: error: hwloc.h: No such file or directory -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1562> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1493: testsuite Carpet/outer-buffers fails
by Einstein Toolkit 21 Apr '14

21 Apr '14

#1493: testsuite Carpet/outer-buffers fails --------------------+------------------------------------------------------- Reporter: knarf | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: ET_2014_05 Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- The testsuite Carpet/outer-buffers fails because it sets the parameter Carpet::use_outer_buffer_zones which doesn't exist anymore. This testsuite was not usually run because a required thorn wasn't part of the toolkit. This now changed, triggering a failure in the regular builds and tests. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1493> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1558: trying to activate more thorns than compiled into Cactus leads to strange error message
by Einstein Toolkit 19 Apr '14

19 Apr '14

#1558: trying to activate more thorns than compiled into Cactus leads to strange error message --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- Right now if one tries to activate more thorns than the total number of thorns compiled into the executable, Cactus aborts with {{{ WARNING level 0 in thorn Cactus processor 0 host horizon.tapir.caltech.edu (line 951 of /mnt/data/rhaas/postdoc/gr/Zelmani/configs/null/build/Cactus/main/ActiveThorns.c): -> Internal error }}} this is utimately due to Cactus creating a list of maximum size number-of- compiled-in-thorns to record the number of thorns that are requested to be activated. The attached patches automatically grows this list whenever it would otherwise be too small (doubles the size). An alternative would be to implement stringlist using a std::map object, however the mapping of the std::map interface to what StringList provides is cumbersome. ok to apply? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1558> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #849: Drop explicit support for Fortran 77 in Cactus
by Einstein Toolkit 19 Apr '14

19 Apr '14

#849: Drop explicit support for Fortran 77 in Cactus -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- I suggest to drop explicit support for Fortran 77 in Cactus. Fortran 77 is, for all practical purposes, a subset of Fortran 90, and thus Fortran 77 code can be compiled by Fortran 90 compilers. There is currently no platform that has a Fortran 77 and no Fortran 90 compiler, and there is no Fortran source code in Cactus that cannot be compiled by a Fortran 90 compiler. In a way, supporting Fortran 77 as language is similar to supporting K&R C as a language. We don't do this either. I suggest to remove/ignore all configuration options regarding Fortran 77, and to compile .f77 and .F77 files with a Fortran 90 compiler. This change will simplify the configuration stage of Cactus. I don't expect any user to notice. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/849> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #1563: Provide always-working isnan etc.
by Einstein Toolkit 19 Apr '14

19 Apr '14

#1563: Provide always-working isnan etc. -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- Certain math optimization options (e.g. -ffast-math) tell the compiler that IEEE floating point numbers such as inf and nan do not need to be handled correctly (in the sense specified by the IEEE standard). This greatly improves floating-point speed and is commonly used in numerical HPC applications. For example, fmax() specifies: {{{ If exactly one argument is a NaN, fmax() returns the other argument. If both arguments are NaNs, fmax() returns a NaN. }}} Implementing this correctly requires checking whether each argument is a nan. To improve speed, one can omit this check, which means that fmax() may return NaN, even if one of its argument is not a NaN. This is fine in most cases, and people appreciate the added speed. However, since compilers then don't need to handle inf and nan correctly, they have begun to optimise isnan(x) to simply returning false all the time. This improves speed (since the check does not actually need to occur) and reduces code size (since the nan-handling if branches can be omitted). Of course, this makes it then impossible to actually check for nan by calling isnan. Currently, e.g. g++ performs this optimisation, whereas gcc does not. Things vary with other compilers. In the future, with link-time optimisations, I expect other compilers to follow g++. The enclosed patch provides functions CCTK_IEEE_isnan etc. that always check for nan, independent of the chosen optimisation flags. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1563> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1567: Lorene: compilation error when using -warn all
by Einstein Toolkit 18 Apr '14

18 Apr '14

#1567: Lorene: compilation error when using -warn all --------------------------------------+------------------------------------- Reporter: bmundim | Owner: Type: defect | Status: new Priority: major | Milestone: ET_2014_05 Component: EinsteinToolkit thorn | Version: ET_2013_11 Keywords: Lorene ExternalLibraries | --------------------------------------+------------------------------------- If I add the warning flag to fortran flags in my configuration option list, i.e.: F77_WARN_FLAGS = -warn all F90_WARN_FLAGS = -warn all Lorene's compilation abort with the following error messages: ... fcir2s.f(216): error #7983: The storage extent of the dummy argument exceeds that of the actual argument. [NDEG1] CALL CIRX2S(NDEG1,NDIMR,NN64,ITCH,IDR,IND,C64,CC,CS,DENT) -------------------^ fcir2s.f(240): error #7983: The storage extent of the dummy argument exceeds that of the actual argument. [NDEG1] CALL CIRX2S(NDEG1,NDIMR,NN64,ITCH,IDR,IND,C64,CC,CS,DENT) -------------------^ ... gr2p3s.f(719): error #8284: If the actual argument is scalar, the dummy argument shall be scalar unless the actual argument is of type character or is an element of an array that is not assumed shape, pointer, or polymorphic. [SOM] CALL EXRM1S(NR,NDR,1,1,0,IPP,CC,VA1) -------------^ gr2p3s.f(720): error #8284: If the actual argument is scalar, the dummy argument shall be scalar unless the actual argument is of type character or is an element of an array that is not assumed shape, pointer, or polymorphic. [SOM] CALL EXRM1S(NR,NDR,1,1,1,IPP,CC,DE1) -------------^ The first compilation error above indicates that NDEG1 is an array with dimension 2 in the calling subroutine FCIR2S while NDEG has dimension 3 in the called subroutine CIRX2S. A suggestion to work around this issue can be found at: http://software.intel.com/en-us/forums/topic/299025 and it boils down to make them both of the same dimension. Would you suggest a different workaround? Maybe make the dummy array dimension a (*)? Regarding the second type of error above, I am not sure yet which argument is actually causing trouble. My local version of Lorene indicates different line number than the error line above but essentially the difference between the calls that the compiler complaints and the ones it doesn't is the following: grep -i -n EXRM1S gr2p3s.f gr2p3s.f:694: CALL EXRM1S(NR,NDR,LF1,1,0,IPP,CC,C64) gr2p3s.f:695: CALL EXRM1S(NR,NDR,LF1,1,1,IPP,CC,UGRAV) gr2p3s.f:718: CALL EXRM1S(NR,NDR,1,1,0,IPP,CC,VA1) gr2p3s.f:719: CALL EXRM1S(NR,NDR,1,1,1,IPP,CC,DE1) On lines 694 and 695 there is no complaint from the compiler. While lines 718 and 719 do. So the dummy argument LF1 seems to prevent this compilation error in an earlier call. In any case, do you have any idea on how to fix this? Note that a workaround I found was to disable the compiler check for the subroutine interfaces by adding the following flag: F77_WARN_FLAGS = -warn all -warn nointerfaces F90_WARN_FLAGS = -warn all -warn nointerfaces However I would rather have this issue addressed than let it go silently. Besides it might affect other fortran codes in ET which I haven't had the opportunity to investigate yet. I have posted a message on Lorene mailing list about this issue. If I don't hear from them, maybe we should come up with a patch on our own. Could someone more familiar with Lorene inner workings come up with a suggestion for this patch? I could work on it and test it. Thanks, Bruno. PS: I found this article useful: http://software.intel.com/en-us/blogs/2009/03/31/doctor-fortran-in-ive- come-here-for-an-argument -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1567> 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 March 2014