Trac July 2015

trac@lists.einsteintoolkit.org

1 participants
107 discussions

[Einstein Toolkit] #1627: Merge rewrite branch of McLachlan
by Einstein Toolkit 14 Aug '15

14 Aug '15

#1627: Merge rewrite branch of McLachlan -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- We should merge the "rewrite" branch of McLachlan. To do before this merge: - Remove helper thorn - Add backward compatibility layer for parameters -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1627> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #649: simfactory should create the "simulations" directory
by Einstein Toolkit 14 Aug '15

14 Aug '15

#649: simfactory should create the "simulations" directory ------------------------+--------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- when following the new users tutorial one gets: {{{ [rhaas@qb1 Cactus]$ ./simfactory/bin/sim submit static_tov --parfile=par/static_tov.par --procs=32 --walltime=8:0:0 Parameter file: /home/rhaas/Cactus/par/static_tov.par Error: could not access simulation base directory /scratch/rhaas/simulations for reading and writing Aborting Simfactory. [137450 refs] }}} This happens each time I set up a fresh simfactory on a machine. It might be useful if simfactory would create the simulation base directory if it does not exist. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/649> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1645: simfactory should create exe directory
by Einstein Toolkit 14 Aug '15

14 Aug '15

#1645: simfactory should create exe directory ------------------------+--------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: development version Keywords: | ------------------------+--------------------------------------------------- Using virtual (--virtual) configuration one can wrap a Cactus config (or at least the parts that simfactory cares about) around an existing executable. Simfactory then copies the executable to exe/cactus_sim (or whatever), however it assumes that exe already exists. Since exe is not part of the Cactus checkout, simfactory needs to itself ensure that it exists. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1645> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1615: TOVSolver shares parameters from GRHydro
by Einstein Toolkit 13 Aug '15

13 Aug '15

#1615: TOVSolver shares parameters from GRHydro -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: TOVSolver | -----------------------------------+---------------------------------------- Zach Etienne was looking at TOVSolver to use it for a test case in IllinoisGRMHD (and to compare to GRHydro). He found that it Turns out all but one of the parameters that are shared with GRHydro are unused in TOVSolver: These need to be removed: USES real rho_abs_min USES real rho_rel_min USES REAL initial_rho_abs_min USES REAL initial_rho_rel_min USES REAL initial_atmosphere_factor and that the one shared parameter that is actually used is GRHydro_rho_central. My suggestion would to remove these dependencies so that the initial data thorn can be used with other evolution thorns. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1615> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1059: simfactory silent error
by Einstein Toolkit 13 Aug '15

13 Aug '15

#1059: simfactory silent error --------------------------------------+------------------------------------- Reporter: anonymous | Owner: eschnett Type: enhancement | Status: new Priority: optional | Milestone: Component: SimFactory | Version: Keywords: simfactory error message | --------------------------------------+------------------------------------- When sim submit -remote ... fails to queue a job because the allocation has been overdrawn, simfactory does not print any error message to screen (it is only hidden in the log file). Could it be made to print an error message to screen? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1059> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #959: Move pthreads to ExternalLibraries
by Einstein Toolkit 13 Aug '15

13 Aug '15

#959: Move pthreads to ExternalLibraries -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- We should move pthreads support to ExternalLibraries (or to the flesh). I have asked CCT to create the respective repository. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/959> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 14

[Einstein Toolkit] #1579: GRHydro does not build on Blue Gene/Q
by Einstein Toolkit 09 Aug '15

09 Aug '15

#1579: GRHydro does not build on Blue Gene/Q ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Other | Version: development version Keywords: | ----------------------+----------------------------------------------------- Some of the C++ source files in GRHydro do not build on a Blue Gene/Q with IBM's compiler. The problem is that the compiler takes a very long time (>8h) even without (sic!) optimization. "The usual" playing with compiler options or changes to the source files had no effect. I consider this to be a bug in the compiler. A work-around may be to switch to Clang as C++ compiler. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1579> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1797: allow new timelevels to be created at runtime
by Einstein Toolkit 09 Aug '15

09 Aug '15

#1797: allow new timelevels to be created at runtime --------------------------------+------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Keywords: Cactus Carpet PUGH | --------------------------------+------------------------------------------- The set of patches in https://bitbucket.org/cactuscode/cactus/branch/rhaas%2FunlimitedTimelevels https://bitbucket.org/cactuscode/cactuspugh/branch/rhaas%2FunlimitedTimelev… https://bitbucket.org/eschnett/carpet/branch/rhaas%2FunlimitedTimelevels extend the flesh and the PUGH and Carpet drivers such that user thorns can enable more timelevels than the TIMELEVELS attribute in interface.ccl specifies. This separates the number of {{{_p}}} and {{{_p_p}}} etc. variables, which continues to be controlled by interface.ccl's TIMELEVELS attribute, from the number of timelevels that are accessible via {{{CCTK_VarDataPtr()}}}. This means that evolution thorns can ask for only ask many timelevels as they need for their own evolution algorithm (so 2 of MoL based thorns) and don't have to worry about how many timelevels Carpet may require for time interpolation. Similarly some MoL evolution methods (for example AB type methods) require multiple past timelevels of the RHS variables which MoL can enable by its own when using this functionality. Their should be very little user visible changes, mostly since few thorns actually needed to know the number of timelevels. The exisiting flesh functions {{{CCTK_MaxTimeLevels}}} continue to return the value set in TIMELEVELS while new functions {{{CCTK_MaxActiveTimeLevels}}} return the maximum number of timelevels that were ever activated or {{{CCTK_MaxTimeLevels}}}, whichever is larger. A possible improvement would be to make the existing {{{CCTK_MaxTimeLevels}}} return what {{{CCTK_MaxActiveTimeLevels}}}, yet no user code should ever need knowledge of {{{CCTK_MaxTimeLevels}}} anyway since it only ever returned the value set in {{{interface.ccl}}} so only drivers etc. should have used it to check for invalid timelevel parameters. The downside of that approach is that it changes the meaning of an existing flesh function rather than introducing a new one and deprecating the old one. This is fine if the meaning of {{{CCTK_MaxTimeLevels}}} really is "upper bound on {{{CCTK_ActiveTimeLevels}}} that could have been seen" rather than "the value of TIMELEVELS from interface.ccl". The patches pass all tests. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1797> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 11

[Einstein Toolkit] #816: include SphericalHarmonicReconASCII from incoming in PITTNULLCode
by Einstein Toolkit 04 Aug '15

04 Aug '15

#816: include SphericalHarmonicReconASCII from incoming in PITTNULLCode -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Christian Reisswig provided a copy of SphericalHarmonicReconASCII and alternative thorn that reads in CCE boundary data (similar SphericalHarmonicRecon) but supporting a wider variety of input file formats (HDF5 among them, irrespective of the name). Used by SpEC and Llama. There are no docs or test cases as of now. Test data would be welcome (SpEC, Llama or Cactus provided, I don't think it makes a difference). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/816> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 17

[Einstein Toolkit] #1798: add backtrace script to cactus utils
by Einstein Toolkit 28 Jul '15

28 Jul '15

#1798: add backtrace script to cactus utils -------------------------+-------------------------------------------------- Reporter: sbrandt | Owner: Type: enhancement | Status: new Priority: unset | Milestone: Component: Other | Version: development version Keywords: | -------------------------+-------------------------------------------------- The script converts backtraces generated by carpet to readable output with file and line number. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1798> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac July 2015