Trac August 2015

trac@lists.einsteintoolkit.org

1 participants
112 discussions

[Einstein Toolkit] #1807: Download instructions do not let a new user compile
by Einstein Toolkit 31 Aug '15

31 Aug '15

#1807: Download instructions do not let a new user compile -------------------------------------+-------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit website | Version: development version Keywords: | -------------------------------------+-------------------------------------- The [http://einsteintoolkit.org/download/ Download section] of our website does not give any hint on how to compile the code after a (possibly) successful download. It should contain some additional sections 1. required installed software, in particular that svn from OSX does not work 1. a "How to compile" section that links to the [https://docs.einsteintoolkit.org/et- docs/Simplified_Tutorial_for_New_Users simplified tutorial] (preferred) or the regular tutorial (not preferred since this one requires them to get an account on Queenbee where they would have to download once more) 1. ideally a link to a "first steps" type document which could be part of an ET user guide described in #1804 -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1807> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1806: enovol operator in CarpetLib is broken
by Einstein Toolkit 29 Aug '15

29 Aug '15

#1806: enovol operator in CarpetLib is broken --------------------+------------------------------------------------------- Reporter: rhaas | Owner: rhaas Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- The implementation of {{{eno_interpolation_type = averages}}}, which is not used by default, is broken and cannot be used since it does not allow restriction. Even when adding restriction the computation of the required source region is done incorrectly and leads to segfaults since data outside of the source region is accessed. The check for regbbox + stencil width to be included in srcbbox in the prolongation operator source file seems to be broken as well since it does not take the difference between coarse and fine grid spacing into account. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1806> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1809: simplify CarpetLib's data.cc file
by Einstein Toolkit 24 Aug '15

24 Aug '15

#1809: simplify CarpetLib's data.cc file ----------------------+----------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: task | Status: new Priority: optional | Milestone: Component: Carpet | Version: development version Keywords: | ----------------------+----------------------------------------------------- CarpetLib's data.cc file contains a number of very large and complex switch statements inside of its {{{transfer_prolongate}}} and {{{transfer_restrict}}} routines (the prolongate one is about 500 lines long and is only one half of an {{{#if CAPRET_DIM}}} preprocessor if statement). The two switch statements also have to be kept in sync with each other whenever a new transport operator is added. It may be good to instead define some type of "operator package" object that contains the list of prolongation, restrict, time interpolation operators that correspond to a particular choice of transport operator and refinement centering as chosen in the parameter file and interface.ccl. This way the complex logic could be collected in only a single place. This would be useful since we seem to plan to add more new transport operators to Carpet. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1809> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1810: simplify CarpetLib's data.cc file
by Einstein Toolkit 24 Aug '15

24 Aug '15

#1810: simplify CarpetLib's data.cc file ----------------------+----------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: task | Status: new Priority: optional | Milestone: Component: Carpet | Version: development version Keywords: | ----------------------+----------------------------------------------------- CarpetLib's data.cc file contains a number of very large and complex switch statements inside of its {{{transfer_prolongate}}} and {{{transfer_restrict}}} routines (the prolongate one is about 500 lines long and is only one half of an {{{#if CAPRET_DIM}}} preprocessor if statement). The two switch statements also have to be kept in sync with each other whenever a new transport operator is added. It may be good to instead define some type of "operator package" object that contains the list of prolongation, restrict, time interpolation operators that correspond to a particular choice of transport operator and refinement centering as chosen in the parameter file and interface.ccl. This way the complex logic could be collected in only a single place. This would be useful since we seem to plan to add more new transport operators to Carpet. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1810> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1811: simplify CarpetLib's data.cc file
by Einstein Toolkit 24 Aug '15

24 Aug '15

#1811: simplify CarpetLib's data.cc file ----------------------+----------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: task | Status: new Priority: optional | Milestone: Component: Carpet | Version: development version Keywords: | ----------------------+----------------------------------------------------- CarpetLib's data.cc file contains a number of very large and complex switch statements inside of its {{{transfer_prolongate}}} and {{{transfer_restrict}}} routines (the prolongate one is about 500 lines long and is only one half of an {{{#if CAPRET_DIM}}} preprocessor if statement). The two switch statements also have to be kept in sync with each other whenever a new transport operator is added. It may be good to instead define some type of "operator package" object that contains the list of prolongation, restrict, time interpolation operators that correspond to a particular choice of transport operator and refinement centering as chosen in the parameter file and interface.ccl. This way the complex logic could be collected in only a single place. This would be useful since we seem to plan to add more new transport operators to Carpet. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1811> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1808: simplify CarpetLib's data.cc file
by Einstein Toolkit 24 Aug '15

24 Aug '15

#1808: simplify CarpetLib's data.cc file ----------------------+----------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: task | Status: new Priority: optional | Milestone: Component: Carpet | Version: development version Keywords: | ----------------------+----------------------------------------------------- CarpetLib's data.cc file contains a number of very large and complex switch statements inside of its {{{transfer_prolongate}}} and {{{transfer_restrict}}} routines (the prolongate one is about 500 lines long and is only one half of an {{{#if CAPRET_DIM}}} preprocessor if statement). The two switch statements also have to be kept in sync with each other whenever a new transport operator is added. It may be good to instead define some type of "operator package" object that contains the list of prolongation, restrict, time interpolation operators that correspond to a particular choice of transport operator and refinement centering as chosen in the parameter file and interface.ccl. This way the complex logic could be collected in only a single place. This would be useful since we seem to plan to add more new transport operators to Carpet. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1808> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #1749: avoid creating temporary links to files in Formaline
by Einstein Toolkit 18 Aug '15

18 Aug '15

#1749: avoid creating temporary links to files in Formaline -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: Formaline | -----------------------------------+---------------------------------------- the patch in https://bitbucket.org/cactuscode/cactusutils/branch/rhaas %2Fupdate-index changes the way Formaline populates the configjar git repository with changed files. Instead of making a hard linked copy of every file in the thorn, it used plumbing commands git-update-index to add them to the index. This deals gracefully with files in symbolically linked directories (but will dereference a symbolic link if the file *itself* is a symgolic link) and also works when CACTUS_CONFIGS_DIR is not on the same file system as the source tree (eg Cactus is in $HOME which has a small quota but is backed up and $CACTUS_CONFIGS_DIR is in $SCRATCH which is not backed up). Not being able to have $CACTUS_CONFIGS_DIR on a different file system than Cactus is a minor bug, in particular since this method is described in the UserGuide. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1749> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #334: unsuccessful qsub not recognized / submit succeeds for finished simulation
by Einstein Toolkit 18 Aug '15

18 Aug '15

#334: unsuccessful qsub not recognized / submit succeeds for finished simulation ------------------------+--------------------------------------------------- Reporter: knarf | Owner: mthomas Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- python version: I submitted a simulation 'sim submit' but the corresponding qsub failed due to wrong numbers of procs/node (philip cluster). I changed the number given on the command line and did a 'sim submit' again, this time successful. Several things happend which I think could be done better: - the unsuccessful qsub was not detected during the new submit - it attempted a restart and didn't simply clean the unsuccessful submit - when trying the restart, it went ahead and queued the job, but this later failed when run with "cannot rerun a restart that has been finished". This could have been caught earlier - without the wait time in the queue. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/334> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1790: ADMMass: Properly distinguish between int and CCTK_INT
by Einstein Toolkit 17 Aug '15

17 Aug '15

#1790: ADMMass: Properly distinguish between int and CCTK_INT -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- Patch attached. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1790> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1805: triggers statement does not include reductions output
by Einstein Toolkit 17 Aug '15

17 Aug '15

#1805: triggers statement does not include reductions output --------------------------------+------------------------------------------- Reporter: physik@… | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: Other | Version: ET_2014_05 Keywords: | --------------------------------+------------------------------------------- We were adding a grid function that is computed by a function scheduled only by the "triggers" mechanism. When adding the grid function to the reductions output (CarpetIOScalar::outScalar_vars), but not the regular output, we found the function computing the variable is not called. When adding the variable to regular 1d output, but with a lower output frequency than for the reductions, the function is only called before 1d output, but not reduction. This occured using the Wheeler release . -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1805> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac August 2015