Trac July 2014

trac@lists.einsteintoolkit.org

1 participants
127 discussions

[Einstein Toolkit] #582: Semi-automatically split McLachlan's calculations
by Einstein Toolkit 08 Dec '14

08 Dec '14

#582: Semi-automatically split McLachlan's calculations -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Split McLachlan's calculations semi-automatically in two ways: (a) by variable, so that e.g. dot[g] and dot[K] are calculated separately, and (b) by pattern, so that advection terms, dissipation, and "everything else" are calculated separately. Also introduce parameters to choose which routines are called at run time. This is somewhat a work in progress, in that the patch is good, but the API defined to split kernels is more complex and less failsafe than it should be. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/582> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #1071: ensure atmosphere is properly set after ID
by Einstein Toolkit 08 Dec '14

08 Dec '14

#1071: ensure atmosphere is properly set after ID -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: major | Milestone: ET_2012_11 Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- At the moment GRHydro doesn't ensure properly that the atmosphere is set after initial data. This is no problem as long as the ID thorn takes care of this, the ID doesn't contain atmosphere or the EOS is sufficiently robust to 'recover'. However, this is not always the case. Thus, I propose to set the atmosphere mask in PostInitial, initializing it according to whatever was setup there by some other thorn. The patch to do that is attached. It is only a change to schedule.ccl as the corresponding function already exists. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1071> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 21

[Einstein Toolkit] #1152: Add option to compute center of mass to hydro_analysis and lots of smaller changes
by Einstein Toolkit 01 Dec '14

01 Dec '14

#1152: Add option to compute center of mass to hydro_analysis and lots of smaller changes -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: Hydro_Analysis | -----------------------------------+---------------------------------------- The attached set of patches adds the possibility to compute a center of mass location to hydro_analysis. It works by computing the center of mass (via x[idx]*rho[idx]) of the matter in a region of radius Hydro_Analysis_r_core around the point of maximum density. Only points whose density is above a fraction Hydro_Analysis_rho_core_rel_min of the maximum density are considered. I also include a number of bugfix patches and patches to make Hydro_Analysis more controllable by user input rather than hard-coded values. All patches contain a short description in the patch (ie. the git commit message). The ones adding extra control and/or warnings are: * Hydro_Analysis: add verbosity_level option to control how much data to output to stdout * Hydro_Analysis: use Fortran modules for prototypes if available * Hydro_Analysis: add parameters to control which interpolator is used * Hydro_Analysis: make parameters steerable * Hydro_Analysis: warn if grid point with maximum value cannot be found on grid * Hydro_Analysis: add parameter Hydro_Analysis_comp_rho_max_every * Hydro_Analysis: add option rho_max_loc_use_rotatingsymmetry180 * Hydro_Analysis: add option to average the location of multiple identical maxima * Hydro_Analysis: fiddle with when to warn about multiple identical maxima Bugfixes are: * Hydro_Analysis: checkpoint grid scalars * Hydro_Analysis: do reduction in global mode New feature: * Hydro_Analysis: add routine to compute center of mass in core region -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1152> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 19

[Einstein Toolkit] #1006: ExternalLibraries' configure.sh scripts handle /usr inconistently
by Einstein Toolkit 26 Nov '14

26 Nov '14

#1006: ExternalLibraries' configure.sh scripts handle /usr inconistently -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: ExternalLibraries | -----------------------------------+---------------------------------------- library path used for -L should not contain the system paths at least /lib, /lib64, /usr/lib, /usr/lib64, /usr/local/lib, /usr/local/lib64 (plus MacOS equivalents, and any other OS we support). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1006> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #1338: Rename Carpet output files
by Einstein Toolkit 25 Nov '14

25 Nov '14

#1338: Rename Carpet output files ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | ----------------------+----------------------------------------------------- Windows does not allow colons in file names. Output files produced by Carpet's should therefore not use colons. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1338> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 36

[Einstein Toolkit] #1537: Deprecate complex number functions
by Einstein Toolkit 25 Nov '14

25 Nov '14

#1537: Deprecate complex number functions -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: ET_2014_11 Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- The complex number functions in Cactus are not necessary any more since all languages (Fortran, C, C++) have built-in support that should rather be used. These functions should be marked "deprecated" in the documentation (but not removed). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1537> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1642: GRHydro should not depend on ADMMacros
by Einstein Toolkit 24 Nov '14

24 Nov '14

#1642: GRHydro should not depend on ADMMacros --------------------+------------------------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: major | Milestone: ET_2014_11 Component: Other | Version: development version Keywords: | --------------------+------------------------------------------------------- At the moment GRHydro uses ADMMacros::spatial_order to decide about how to calculate the source terms. ADMMacros is deprecated. There should be another mechanism to do this, and the dependence should be removed. Note that even the C++ code uses this parameter. The simplest solution would probably be a GRHydro parameter, and this is what I suggest (sources_spatial_order). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1642> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #1555: Simfactory: intel optionlists with rdynamic option
by Einstein Toolkit 10 Nov '14

10 Nov '14

#1555: Simfactory: intel optionlists with rdynamic option -------------------------+-------------------------------------------------- Reporter: bmundim | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: ET_2014_05 Component: SimFactory | Version: development version Keywords: | -------------------------+-------------------------------------------------- Hi, While reviewing some options in my config file I noticed that the -rdynamic gcc option for the linker is applied also to the intel compiler option lists in symfactory. However there seems to have no such an option when using icc or icpc. Wouldn't be better then to pass this option as --export-dynamic directly to the linker ld instead? Maybe as follows: LDFLAGS = -Wl,--export-dynamic -Wl,-rpath,/path/to/whatever instead of LDFLAGS = -rdynamic -Wl,-rpath,/path/to/whatever Thanks, Bruno. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1555> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1490: ExternalLibraries/PAPI contains testsuite, but no data
by Einstein Toolkit 10 Nov '14

10 Nov '14

#1490: ExternalLibraries/PAPI contains testsuite, but no data -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: minor | Milestone: ET_2014_05 Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- ExternalLibraries/PAPI contains testsuite, but no data. This means the testsuite mechanism (currently) will count it always as succeeding, which is not helpful. Also, it contains a README file which only says that this directory is empty - which is not only not helpful, but also wrong, given that there is this README inside.. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1490> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1481: Hidden hard-coded limits on max_l_modes and max_vars in Multipole
by Einstein Toolkit 10 Nov '14

10 Nov '14

#1481: Hidden hard-coded limits on max_l_modes and max_vars in Multipole --------------------------------------+------------------------------------- Reporter: bernard.j.kelly@… | Owner: Type: defect | Status: new Priority: major | Milestone: ET_2013_11 Component: EinsteinToolkit thorn | Version: ET_2013_05 Keywords: Multipole | --------------------------------------+------------------------------------- The EinsteinAnalysis/Multipole thorn has hard-coded limits (in src/multipole.cc) on the number of grid functions that can be decomposed (max_vars) and how high in polar quantum number this decomposition can go (max_l_modes). However, these are not reflected in the thorn's param.ccl. In fact, param.ccl contains a parameter "l_max", allowing it to be *any* positive value, and doesn't test this against max_l_modes until execution of this source. Wouldn't it make more sense to impose max_l_modes immediately at PARAMCHECK? To make the actual limit on interpolated functions explicit, a number of desired interpolants could be set in param.ccl (like "n_variables") --- limited if necessary to a hard-coded number that appears as a limit in the range. If the user tries to set n_variables too high, it gets caught at PARAMCHECK; if (s)he accidentally includes too many entries in the "variables" parameter, the extra ones would just be silently ignored. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1481> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac July 2014