Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #756: SimFactory web site overwritten?
by Einstein Toolkit 07 Mar '12

07 Mar '12

#756: SimFactory web site overwritten? ------------------------+--------------------------------------------------- Reporter: tbode | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: www | ------------------------+--------------------------------------------------- I had reason to look at the SimFactory website today, but http://simfactory.org now contains information on an IEEE Cluster conference from 2009. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/756> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #766: Submitting a restart does not remember the queue
by Einstein Toolkit 03 Mar '12

03 Mar '12

#766: Submitting a restart does not remember the queue ------------------------+--------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- When I submit a new restart, Simfactory does not remember the queue I chose for the previous restart. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/766> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #763: LSUThorns/Vectors/src test.cc doesn't compile with "REAL_PRECISION = 4"
by Einstein Toolkit 02 Mar '12

02 Mar '12

#763: LSUThorns/Vectors/src test.cc doesn't compile with "REAL_PRECISION = 4" -----------------------------------+---------------------------------------- Reporter: jtao | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- COMPILING /home/jtao/workspace/CactusDev/Cactus/arrangements/LSUThorns/Vectors/src/test.cc /home/jtao/workspace/CactusDev/Cactus/configs/ml/build/Vectors/test.cc:154:39: error: macro "vec4_store_nta_partial" requires 5 arguments, but only 2 given /home/jtao/workspace/CactusDev/Cactus/configs/ml/build/Vectors/test.cc: In function ‘void Vectors_Test(cGH*)’: /home/jtao/workspace/CactusDev/Cactus/configs/ml/build/Vectors/test.cc:153:46: error: ‘vec4_store_partial_prepare’ was not declared in this scope In file included from /home/jtao/workspace/CactusDev/Cactus/configs/ml/build/Vectors/test.cc:1:0: /home/jtao/workspace/CactusDev/Cactus/arrangements/LSUThorns/Vectors/src/vectors.h:65:37: error: ‘vec4_store_nta_partial’ was not declared in this scope -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/763> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #758: support named spherical surfaces in NSTracker
by Einstein Toolkit 02 Mar '12

02 Mar '12

#758: support named spherical surfaces in NSTracker -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- the attached patch (fairly trivial) adds support for named spherical surfaces (see ticket #735) to NSTracker. If ok to apply someone will have to either commit to LSUThorns/NSTracker or grant me write permissions. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/758> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #761: Fold option list, submit script, and run script into mdb
by Einstein Toolkit 28 Feb '12

28 Feb '12

#761: Fold option list, submit script, and run script into mdb -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: enhancement | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- It would be nice to avoid having both an mdb, and three separate files (option list, submit script, run script) for each machine. These really belong together. The following may be possible: 1. An option list consists of a set of key-value pairs. It should be straightforward to put these into the mdb. 2. The submit script consists essentially of a single command, and various options that are set via comments. These options could also be set via command line options to qsub, and thus be stored in the mdb. In fact, Orca (Sharcnet) already requires this, and only has a trivial submit script. 3. All run scripts follow the same pattern: some commands to change the environment, some commands to mangle MPI node lists, and an mpirun command. Interspersed is a lot of boilerplate. These could be abstracted out into two or three MDB entries specifying these commands. The result would be that all information is stored in the mdb, and no additional files need to be tracked. To protect against mdb modifications while a job is waiting, we could/should store a copy of the mdb entry with each simulation. If the current mdb format is not convenient for storing this information (but why should it not?), then we could examine other options, e.g. based on XML or SqLite. (There are e.g. XML-like formats that have the same semantics as XML, but use a slightly different syntax that is friendlier for humans, but is as easy to parse for machines.) XML and friends would give us a hierarchy, which INI doesn't. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/761> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #757: rsync ignores .rsync.rules files in the Cactus ROOT directory
by Einstein Toolkit 22 Feb '12

22 Feb '12

#757: rsync ignores .rsync.rules files in the Cactus ROOT directory ------------------------+--------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- It seems that rsync, since simfactory never uses the Cactus root directory as a source, does not merge any .rsync.rules files in the root directory into filter.rules. .rysnc.rules files work fine in the sub-directories, eg. bin/ lib/ etc. Since I would like to have global .rsync.rules valid for all subdirectories, a workaround is to replicate the file .rsync.rules in all (top-level) subfolders via symbolic links. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/757> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #623: use GRHydro_polytrope_handle whenever prim2conpolytrope is called
by Einstein Toolkit 13 Feb '12

13 Feb '12

#623: use GRHydro_polytrope_handle whenever prim2conpolytrope is called --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: | --------------------+------------------------------------------------------- Currently GRHydro uses grhydro_eos_handle in both Primitive2Conservative and Primitive2ConservativePoly and relies on grhydro_eos_handle being an actual handle to the 2d polytype in the later. This means that calling Primitive2ConservativePoly from within a run with grhydro_eos_type == "General" uses the wrong handle (namely the general eos). This is not normally a problem since Primitive2ConservativePoly is only ever called if grhydro_eos_type == "polytype", with the exception of EoSChangeGammaK which always calls Primitive2ConservativePoly (and has to call a polytype routine). There are basically two ways to make this work in this case: * use GRHydro_polytrope_handle in Primitive2ConservativePoly * call prim2conPoly from within EoSChangeGammaK The first option has the disadvantage that this is not what Conservative2Primitive does. The second has the disadvantage that EoSChangeGammaK has to also recompute Yecons (and any other new conservatives we might define) on top of calling prim2conPoly. Any comments? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/623> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #722: SimFactory "Download" web page is out of date
by Einstein Toolkit 13 Feb '12

13 Feb '12

#722: SimFactory "Download" web page is out of date ------------------------+--------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: www | ------------------------+--------------------------------------------------- The SimFactory web page at http://simfactory.org/simfactory/download/ lists the old URL for the Python version of SimFactory. I suggest the following changes: 1. Make the Python version the first one mentioned, and make it clear that this is the recommended version. 2. Make it clear that the Perl version is unmaintained - maybe don't even mention this version. 3. Make the URLs clickable links so that it is easy to browse the repositories. 4. Update the ET release branch to the latest. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/722> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #754: Use different ssh options for interactive and non-interactive logins
by Einstein Toolkit 12 Feb '12

12 Feb '12

#754: Use different ssh options for interactive and non-interactive logins -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- Simfactory should use different ssh options for interactive and for non- interactive logins. For example, non-interactive logins should maybe not support X11 forwarding. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/754> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #694: Behavior of Slab_Transfer between components owned by the same process
by Einstein Toolkit 09 Feb '12

09 Feb '12

#694: Behavior of Slab_Transfer between components owned by the same process ------------------------+--------------------------------------------------- Reporter: bentivegna | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: Slab | ------------------------+--------------------------------------------------- Slab's documentation states that the Slab_Transfer only works when each process handles a single rectangular component. This affects small runs with periodic boundary conditions (imposed through Slab_Transfer), where two or more components on a single process are common because refinements that try to go past the symmetry boundary are carried over to the opposite side. Currently (attached parameter file), Slab_Transfer silently fails and the boundaries are simply never touched after initial data (except for the usual timelevel cycling). I'm not sure how easy it is to extend this functionality, but a check that Slab_Transfer is only used as intended should be inserted as soon as possible. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/694> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac