Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #2032: Piraha speed issues
by Einstein Toolkit 23 May '17

23 May '17

#2032: Piraha speed issues ---------------------+------------------------------------------------------ Reporter: sbrandt | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: Other | Version: development version Keywords: | ---------------------+------------------------------------------------------ Piraha slows down the CST phase of compilation. A cache system has been developed to speed it up. This feature should be added to the parse system. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2032> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #2043: new thorn for initial data (Hydro_RNS)
by Einstein Toolkit 21 May '17

21 May '17

#2043: new thorn for initial data (Hydro_RNS) -------------------------+-------------------------------------------------- Reporter: DePietri | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: Other | Version: development version Keywords: parma | -------------------------+-------------------------------------------------- The LSU and Parma groups used for publications and contributed to the development of the thorn the generate initial data for Rotating-Neutron- Star RNS based on Nik Stergioulas code (http://www.gravity.phys.uwm.edu/rns/) which constructs models of rapidly rotating, relativistic, compact stars using tabulated equations of state which are supplied by the user or polytqopic EOS. The code was widely used in conjunction with the Whisky code and more recently with GRHydro. The relevant code can be found here: [https://bitbucket.org/GravityPR/prthorns/src] I'd like another developer to have a look and give input. Once/If this is deemed ok to be included on technical grounds, we will add the necessary documentation. Test suites and example are already present. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2043> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #1875: SetMask_SphericalSurface: retain mask
by Einstein Toolkit 19 May '17

19 May '17

#1875: SetMask_SphericalSurface: retain mask ------------------------------------+--------------------------------------- Reporter: cott@… | Owner: Type: enhancement | Status: new Priority: unset | Milestone: Component: Other | Version: development version Keywords: | ------------------------------------+--------------------------------------- SetMask_SphericalSurface sets a mask based on SphericalSurface information. At every invocation, it wipes the mask, then resets it. Old behavior: mask is set from surface only if surface is active and valid. However, sometimes finding a horizon with AHFinderDirect may fail, but the mask info (i.e. the radius) may be perfectly valid. Mask is still not set in the old behavior, because AHFinderDirect makes the mask invalid (-1) if it does not find a horizon. New behavior: set mask from surface is surface is active and its minimum radius is > 0. Pull request: https://bitbucket.org/einsteintoolkit/einsteinutils/pull- requests/1/setmask_sphericalsurface-retain-mask/diff Pull request also adds verbose output (default: off). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1875> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #1390: parameter file parser aborts when findeing first error
by Einstein Toolkit 19 May '17

19 May '17

#1390: parameter file parser aborts when findeing first error --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- The attached parfile contains multiple errors (one per line). However the parameter file parser only reports the first one, then stops. This makes verifying parfiles for correctness hard. It might be good to defer aborting until the end of the file or until a larger number of parsing errors were encountered. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1390> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #2041: new thorns for hydro analysis
by Einstein Toolkit 19 May '17

19 May '17

#2041: new thorns for hydro analysis -------------------------+-------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: Other | Version: development version Keywords: | -------------------------+-------------------------------------------------- The LSU and Parma groups developed, and used for publications, a set of two thorns for analysis of hydro quantities, in particular for mode analysis. We would like to have those included in the Einstein Toolkit. We are aware that a few things are still missing for that (documentation, test suites), but before we go that extra step and create all of that, we want to be sure the following is seen as 'ok': The main thorn (GRHydro_Analysis, _not_ to be specific to GRHydro, it only inherits hydrobase - could and should probably be renames) does reductions of quire a few quantities. In practice, the memory required for this turned out to be a problem on some machines. These reductions are done at ANALYSIS, which means even telling Cactus to allocate/deallocate not once, globally, but instead doing that every time step does not help. Thus, there is a second thorn, a utility thorn called 'TempPool'. It's task is nothing else than to provide an array of grid functions that are always allocated, but which can be used by other thorns for, reductions - and, and this is the interesting part - can be re-used by other thorns, for other reductions after that; within the same time step in ANALYSIS. This is how TempPool is used by GRHydro_Analysis. TempPool is not tied to GRHydro_Analysis. Any other thorn can also request storage there, but there currently isn't another thorn. It just seemed to good idea to split this functionality. The book keeping already now makes sure that the number of allocated grid functions is only as large the maximum of any thorn using it. The relevant code can be found here: https://bitbucket.org/GravityPR/prthorns/src I'd like another developer to have a look and give input. Once/If this is deemed ok to be included, we will add the necessary documentation and test suites and make a proper proposal for inclusion. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2041> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1172: Remove unnecessary exp/log calls in EOS_Omni
by Einstein Toolkit 18 May '17

18 May '17

#1172: Remove unnecessary exp/log calls in EOS_Omni -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- EOS_Omni seems to call exp/log more often than necessary in the nuc_eos table lookup routines. Use algebraic identities to remove them. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1172> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #2003: piraha_everywhere Zelmani stress test
by Einstein Toolkit 10 May '17

10 May '17

#2003: piraha_everywhere Zelmani stress test --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: piraha | --------------------+------------------------------------------------------- Hello all, Zelmani contains a number of ccl files that make the perl based piraha parser abort with errors but that parsed fine with the old parrser. Some ccl files are clearly incorrect while others are correct and the parser should accept them. The major such issue is that the parser requires that that there is a private/public/protected setting at the beginning of a param.ccl which is not required by the docs since parameters are supposed to default to private. I attach all ccl files both in their original version as well as version that can be parsed without errors (hopefully). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2003> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 43

[Einstein Toolkit] #2037: HDF5's detect.sh searches for hdf5 in the "usual" directories even when HDF5_DIR is set
by Einstein Toolkit 29 Apr '17

29 Apr '17

#2037: HDF5's detect.sh searches for hdf5 in the "usual" directories even when HDF5_DIR is set --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: Cactus | Version: development version Keywords: HDF5 | --------------------+------------------------------------------------------- The code in detect.sh passes HDF5_DIR as the "GUESS" (7th) argument of find_lib and eventually that argument is *prepended* to the list of "usual" directories in bash_utils.sh {{{ local DIRS="$GUESS /usr /usr/local /usr/local/packages /usr/local/apps /opt /opt/local $HOME c:/packages" }}} This seems wrong. If a HDF5_DIR is given then the configure stage should fail if HDF5 is not found there. Otherwise the system would unexpectedly pick eg a system hdf5 instead of one from a module if the module was updated and its path changed. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2037> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #2035: NaNChecker should not use integer division
by Einstein Toolkit 27 Apr '17

27 Apr '17

#2035: NaNChecker should not use integer division -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Other | Version: development version Keywords: | -------------------------+-------------------------------------------------- I profiled the NaNChecker, and it seems as if it spent two thirds of its time performing integer division. I assume that these are the integer divisions where the code re-calculates the {{{(i,j,k)}}} triple from a linear index. This part of the code could easily be rewritten. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2035> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #2036: ML_ADMConstraints is not vectorized
by Einstein Toolkit 26 Apr '17

26 Apr '17

#2036: ML_ADMConstraints is not vectorized -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- I see that the thorn ML_ADMConstraints is not vectorized. Doing so should be straightforward, requiring only changing one or two lines in the Kranc script and regenerating the code. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2036> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac