Trac August 2015

trac@lists.einsteintoolkit.org

1 participants
112 discussions

[Einstein Toolkit] #1795: PITTNullCode results depend on number of processors
by Einstein Toolkit 17 Aug '15

17 Aug '15

#1795: PITTNullCode results depend on number of processors -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: PITTNullCode | -----------------------------------+---------------------------------------- As part of trying to add SphericalHarmonicReconGen to the ET I noticed that PITTNullCode produces different results depending on the number of cores used. This already happens with the %%regression_test%% test if SphericalHarmonicRecon that is already in the ET. The issue is hidden right now since the test uses very lose tolerances of {{{ ABSTOL 1.5e-5 RELTOL 1.5e-4 }}} Changing them to the standard Cactus accuracies and regenerating the tests shows that the test that was generated using 2 processors fails when run with a single MPI process. Test data is in the branch rhaas/procdependency . This needs to be fixed or the arrangement must be marked as broken unless this is the intended behaviour in which case this needs to be documented prominently in the documenation. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1795> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #1800: suspicious use of reflevel and refinementlevel in CarpetIOHDF5's AddAttributes function
by Einstein Toolkit 14 Aug '15

14 Aug '15

#1800: suspicious use of reflevel and refinementlevel in CarpetIOHDF5's AddAttributes function --------------------+------------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- AddAttributes in CarpetIOHDF5 takes an explicit argument {{{refinementlevel}}} which is used to populate the "level" attribute of HDF5 datasets. However it also directly uses Carpet's global variable {{{reflevel}} to access some internal Carpet datastructures. Right now this seems to only be able to cause an issue for grid arrays (not grid functions) that have a coordinate system attached to them (since the code is behind an if statement that depends on the result of {{{Coord_GroupSystem (cctkGH, groupname)}}}). For such an array the {{{pos}}} ivect would be computed use the baseextents appropriate for a grid function (which is wrong) on the current refinement level (which is also wrong since grid arrays currently exits on reflevel 0 only). Output for grid arrays and scalar happens in global mode, which during the time output happens coincides with the finest refinement level. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1800> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac August 2015