Trac

trac@lists.einsteintoolkit.org

8708 discussions

[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

[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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac