Trac September 2014

trac@lists.einsteintoolkit.org

1 participants
133 discussions

[Einstein Toolkit] #1654: All accessible Cactus flesh functions should either be documented or deprecated
by Einstein Toolkit 09 Dec '14

09 Dec '14

#1654: All accessible Cactus flesh functions should either be documented or deprecated -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- There are some Cactus flesh functions which are not documented, and it is unclear the extent to which these are supported. The following command is one way to see the symbols provided to an executable by the Cactus flesh (there might be better or more accurate ways of doing this): {{{ find configs/sim/build/Cactus -name "*.o"|xargs nm -g | grep -v ' U '|less }}} After removing CCTKi symbols etc, this list of symbols should be cross- referenced with the documentation and a decision should be made for any undocumented functions. This is also a good way to find out about symbols which have been declared in the global namespace unintentionally. One could also imagine having a text file with a list of all the supported function symbols, and the automated test system checking that no additional functions are exported into the global namespace. This is not a high priority, but since I thought of it, I made the ticket anyway. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1654> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1662: Only ask once for auth info for bitbucket/github
by Einstein Toolkit 09 Dec '14

09 Dec '14

#1662: Only ask once for auth info for bitbucket/github ---------------------------+------------------------------------------------ Reporter: knarf | Owner: eric9 Type: enhancement | Status: new Priority: minor | Milestone: Component: GetComponents | Version: development version Keywords: | ---------------------------+------------------------------------------------ Maybe only for the special case of "big" services like bitbucket and github, only ask once for the auth info in GetComponents. While I can see that in theory somebody could use a different login for different projects, I think this would be highly unlikely in practice. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1662> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1039: Web-based documentation should be automatically updated
by Einstein Toolkit 09 Dec '14

09 Dec '14

#1039: Web-based documentation should be automatically updated -------------------------------------+-------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit website | Version: Keywords: Documentation | -------------------------------------+-------------------------------------- We have documentation for Cactus and the ET on their respective websites. This should be updated automatically when the source is changed, so it is never out of date. There should be documentation for the current release as well as the current development version. There is one technical problem standing in the way of this. The system should be automated, and it needs to have commit rights to a specific directory in the SVN repository hosting the files. SVN accounts for CCT machines tend to be the same as CCT login accounts, so we don't want to store the username and password. I think the best solution is to create an SVN account specifically for the documentation build system which is not tied to a CCT login account. This account would be given commit access to just the directories necessary. The "checkout, build doc, commit" script should be kept in version control somewhere, and a machine should be chosen on which to run it. It could be run regularly, or just in response to commits. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1039> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1487: Documentation build should be tested as part of the automated build and test
by Einstein Toolkit 08 Dec '14

08 Dec '14

#1487: Documentation build should be tested as part of the automated build and test --------------------+------------------------------------------------------- Reporter: hinder | Owner: hinder Type: defect | Status: new Priority: minor | Milestone: Component: Other | Version: development version Keywords: | --------------------+------------------------------------------------------- The build of the ET documentation should be tested as part of the automated build and test. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1487> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #791: Output timer tree as XML
by Einstein Toolkit 08 Dec '14

08 Dec '14

#791: Output timer tree as XML -------------------------+-------------------------------------------------- Reporter: hinder | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: | -------------------------+-------------------------------------------------- The attached patch to Carpet adds a parameter (off by default) which outputs the timer tree from each process to an XML file in the output directory at the end of the run. The output looks like this: {{{ <timer name = "main"> 7.7702 <timer name = "CallFunction"> 0.000241 <timer name = "thorns"> 0.000233 <timer name = "CaKernel_FreeDevMem"> 0.000221 <timer name = "PostCall"> 2e-06 </timer> <timer name = "PreCall"> 1e-06 </timer> </timer> </timer> </timer> <timer name = "CarpetStartup"> 0.00982 <timer name = "AllocateGridHierarchy"> 5e-06 </timer> }}} An alternative schema would be to have the name and timer value as subelements; i.e. {{{ <timer> <name>main</name> <value>7.7702</value> <children> <timer> <name>CallFunction</name> <value<0.000241</name> ... </timer> }}} The <children> tag might not be necessary, but might make it easier to parse. Having one file per process is not ideal; we would like to add reductions across processes to give min, max, average, standard deviation etc, also for the standard output display. OK to commit as a work-in-progress? We can change the schema later if it turns out to be easier to deal with. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/791> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 15

[Einstein Toolkit] #727: Test output changes every time some tests are run
by Einstein Toolkit 08 Dec '14

08 Dec '14

#727: Test output changes every time some tests are run -----------------------------------------------------------+---------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: testsuites QuasiLocalMeasures IDAxiOddBrillBH | -----------------------------------------------------------+---------------- Each time a new run of the test suites is performed, the test output of IDAxiOddBrillBH and QuasiLocalMeasures changes a little. These changes are below the tolerances set in the test.ccl files, so the tests pass, but there should be no change at all when the tests are run on the same machine. An example of the difference from one test run to the next is shown at http://git.barrywardell.net/EinsteinToolkitTestResults.git/blobdiff/95fe088…. Another example, from QuasiLocalMeasures, is at http://git.barrywardell.net/EinsteinToolkitTestResults.git/blobdiff/95fe088… /qlm-ks-shifted/admbase::metric.average.asc. The only thorns to exhibit this behaviour are IDAxiOddBrillBH and QuasiLocalMeasures. All other test data remains unchanged from one test run to the next. Note that the two test runs will be performed with different executables, since a new configuration is created for each run. I think I remember testing that simply re-running the same executable resulted in the same test output. Is it possible that there are a small number of points which access uninitialised memory which changes on each run for these thorns? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/727> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[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

← Newer
1
...
8
9
10
11
12
13
14
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac September 2014