Trac February 2012

trac@lists.einsteintoolkit.org

1 participants
150 discussions

[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

[Einstein Toolkit] #558: Carpet with Periodic Boundary Conditions
by Einstein Toolkit 08 Feb '12

08 Feb '12

#558: Carpet with Periodic Boundary Conditions -----------------------------+---------------------------------------------- Reporter: hfinkel@… | Owner: eschnett Type: enhancement | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: carpet periodic | -----------------------------+---------------------------------------------- The current Carpet driver is not compatible with the periodic boundary conditions (as provided by the Periodic thorn or otherwise). Erik's comment on the User's list was: "It is straightforward to implement periodicity in the grid structure -- one needs to take the current grid structure, shift it in the 26 directions, and take the logical union of all 27 grid structures. This will then be automatically clipped. The most complex part is calculating by how much to shift." Please implement support for periodic BCs in Carpet. This will directly enable production science runs. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/558> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 25

[Einstein Toolkit] #120: Improve built-in help system
by Einstein Toolkit 08 Feb '12

08 Feb '12

#120: Improve built-in help system -------------------------+-------------------------------------------------- Reporter: hinder | Owner: mthomas Type: enhancement | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- SimFactory currently provides a single help screen when you type "sim help". I would like to be able to do "sim help <command>" and get help which is relevant for that command. This help should say briefly what the command does, and give a comprehensive list of the options specific to that command. The top-level "sim help" command should then give a list of the commands, and a list of the simfactory options which apply to all commands. This first help page should be kept as brief as possible so that it is easy to see at a glance what commands are available. The most common commands should be listed first, and maybe separated from the less common commands. I think this is important as it is the first port-of-call when someone wants to know how to use a particular feature, especially when the syntax is similar but not quite the same as in SimFactory 1. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/120> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #747: 9th order prolongation test fails with REAL_PRECISION=4
by Einstein Toolkit 06 Feb '12

06 Feb '12

#747: 9th order prolongation test fails with REAL_PRECISION=4 --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- If I set REAL_PRECISION=4 in my option list (single precision), Carpet will not run. This is because it performs self-tests on startup of the prolongation operators, and my guess is that single precision is insufficient for the 9th order operators. {{{ WARNING[L1,P0] (CarpetLib): Error in prolongate_3d_rf2::coeffs_3d_rf2 RT=CCTK_REAL4 ORDER=9 n=6 y0=0, res=9.53674e-07 WARNING[L1,P0] (CarpetLib): Error in prolongate_3d_rf2::coeffs_3d_rf2 RT=CCTK_REAL4 ORDER=9 n=6 y0=0, res=9.53674e-07 WARNING[L1,P0] (CarpetLib): Error in prolongate_3d_rf2::coeffs_3d_rf2 RT=CCTK_REAL4 ORDER=9 n=8 y0=0, res=1.52588e-05 WARNING[L1,P0] (CarpetLib): Error in prolongate_3d_rf2::coeffs_3d_rf2 RT=CCTK_REAL4 ORDER=9 n=8 y0=0, res=1.52588e-05 WARNING level 0 in thorn CarpetLib processor 0 host MacBook-2.local (line 98 of /Users/ian/Cactus/EinsteinToolkit/arrangements/Carpet/CarpetLib/src/prolongate_3d_rf2.cc): -> Aborting. WARNING level 0 in thorn CarpetLib processor 0 host MacBook-2.local (line 98 of /Users/ian/Cactus/EinsteinToolkit/arrangements/Carpet/CarpetLib/src/prolongate_3d_rf2.cc): -> Aborting. }}} I propose that the final warning should be changed to level 1 unless that order of prolongation has actually be requested for the run. In my case, I'm doing unigrid and don't care about prolongation. I don't know how to test the type (what type of object is "RT"?) in this template function. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/747> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 11

[Einstein Toolkit] #750: Unable to compile Vectors with REAL_PRECISION = 4
by Einstein Toolkit 06 Feb '12

06 Feb '12

#750: Unable to compile Vectors with REAL_PRECISION = 4 ---------------------------+------------------------------------------------ Reporter: barry.wardell | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Other | Version: Keywords: | ---------------------------+------------------------------------------------ When I try to compile the Vectors thorn with the REAL_PRECISION = 4 option, I get lots of errors when compiling test.cc: {{{ test.cc: In function 'void Vectors_Test(cGH*)': test.cc:130:28: error: 'vec4_store' was not declared in this scope test.cc:132:32: error: 'vec4_store_nta' was not declared in this scope test.cc:144:46: error: 'vec4_store_partial_prepare' was not declared in this scope test.cc:145:39: error: 'vec4_store_nta_partial' was not declared in this scope test.cc:158:14: error: assignment of read-only location '* & p' test.cc:158:14: error: '_mm_storel_ps' was not declared in this scope test.cc:158:14: error: assignment of read-only location '*((& p) + 8u)' test.cc:163:14: error: assignment of read-only location '*((& p) + 12u)' test.cc:163:14: error: '_mm_storeh_ps' was not declared in this scope test.cc:163:14: error: assignment of read-only location '*((& p) + 4u)' test.cc:169:58: error: 'vec4_store_nta_partial_mid' was not declared in this scope test.cc:188:3: error: 'k4cos' was not declared in this scope test.cc:196:3: error: 'k4sin' was not declared in this scope test.cc:198:3: error: 'k4tan' was not declared in this scope test.cc:200:3: error: cannot convert 'const __m128 {aka const __vector(4) float}' to '__m128i {aka __vector(2) long long int}' for argument '1' to '__m128i _mm_srai_epi32(__m128i, int)' test.cc:202:3: error: cannot convert 'const __m128 {aka const __vector(4) float}' to '__m128i {aka __vector(2) long long int}' for argument '1' to '__m128i _mm_srai_epi32(__m128i, int)' test.cc:204:3: error: cannot convert 'const __m128 {aka const __vector(4) float}' to '__m128i {aka __vector(2) long long int}' for argument '1' to '__m128i _mm_srai_epi32(__m128i, int)' test.cc:205:3: error: cannot convert 'const __m128 {aka const __vector(4) float}' to '__m128i {aka __vector(2) long long int}' for argument '1' to '__m128i _mm_srai_epi32(__m128i, int)' test.cc:207:3: error: cannot convert 'const __m128 {aka const __vector(4) float}' to '__m128i {aka __vector(2) long long int}' for argument '1' to '__m128i _mm_srai_epi32(__m128i, int)' test.cc:209:3: error: cannot convert 'const __m128 {aka const __vector(4) float}' to '__m128i {aka __vector(2) long long int}' for argument '1' to '__m128i _mm_srai_epi32(__m128i, int)' test.cc:211:3: error: cannot convert 'const __m128 {aka const __vector(4) float}' to '__m128i {aka __vector(2) long long int}' for argument '1' to '__m128i _mm_srai_epi32(__m128i, int)' test.cc:212:3: error: cannot convert 'const __m128 {aka const __vector(4) float}' to '__m128i {aka __vector(2) long long int}' for argument '1' to '__m128i _mm_srai_epi32(__m128i, int)' }}} These are mostly a result of missing definitions in vectors-4-SSE.h which should be added. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/750> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac February 2012