Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #372: Accept comments in multi-line strings in parameter files
by Einstein Toolkit 02 Jul '11

02 Jul '11

#372: Accept comments in multi-line strings in parameter files -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- The attached patch modifies the parameter file parser to accept comments in multi-line strings. These comments extend from a "#" character to the end of the line. This makes it much easier to comment out variables in output strings. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/372> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #463: inlcude XXX_EARLY and XXX_LATE modes in schedule documentation, update "if" in schedule.ccl
by Einstein Toolkit 02 Jul '11

02 Jul '11

#463: inlcude XXX_EARLY and XXX_LATE modes in schedule documentation, update "if" in schedule.ccl -------------------+-------------------------------------------------------- Reporter: rhaas | Type: enhancement Status: new | Priority: optional Milestone: | Component: Cactus Version: | Keywords: documentation -------------------+-------------------------------------------------------- Two patches to the documentation. The first adds short one sentence descriptions of GLOBAL-EARLY, GLOBAL-LATE, META-EARLY and META-LATE. The second changes the documented allowed "if" statements in schedule files from {{{ if(CCTK_EQUALS(<parameter>, <value>)) { ... } }}} to {{{ if(<expression>) { ... } }}} which is what is actually allowed (and commonly used). Looking at the schedule parser it seems that in fact *everything* that is not a STORAGE/COMM or SCHEDULE block (or comment) is copied verbatim into the C function (tested this only very sporadically). Should this be documented? This affects the flesh so I cannot commit them myself. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/463> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #462: allow paramters in STORAGE statements
by Einstein Toolkit 02 Jul '11

02 Jul '11

#462: allow paramters in STORAGE statements -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- the attached patch allows constructs such as: STORAGE metric[timelevels] instead of the currently used and more cumbersome: if(timelevels == 1) { STORAGE metric[1] } else if(timelevels == 2) { ... } The full set of Curie test suites pass (on my workstation usin gcc 4.6, OpenMP and 2 processes) with just that patch and with the second patch to GRHydro that actually uses the new facilities -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/462> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #460: Abort if no Fortran compiler is available
by Einstein Toolkit 28 Jun '11

28 Jun '11

#460: Abort if no Fortran compiler is available -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- When building with an automatically setup simfactory 2 on my laptop, I got very strange error messages such as "none not found" because I had no fortran compiler configured. These came from LAPACK and BLAS. I attach patches which check whether the Fortran compiler is available, and if not, to abort with a sensible error message. It also seems to me that the Fortran thorn should abort if there is no Fortran compiler is available, so I also attach a patch to do this. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/460> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #453: Formaline deletes files if lib and src are symlinks
by Einstein Toolkit 27 Jun '11

27 Jun '11

#453: Formaline deletes files if lib and src are symlinks ---------------------------+------------------------------------------------ Reporter: barry.wardell | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | ---------------------------+------------------------------------------------ I have my Cactus tree set up so that the lib and src directories are actually symbolic links to flesh/lib and flesh/src. When compiling cactus in this tree, Formaline deletes all of the contents in these directories. This is because the find command in Formaline/src/make.configuration.deps only finds the symlink, not the contents. The attached patch is a proposed fix which forces find to look for the contents of lib and src. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/453> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #457: let user enable/disable C++ and Fortran support in ExternalLibraries/HDF5
by Einstein Toolkit 24 Jun '11

24 Jun '11

#457: let user enable/disable C++ and Fortran support in ExternalLibraries/HDF5 -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: rhaas Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- the attached patch exposes two new configuration variables (which default to yes): HDF5_ENABLE_CXX and HDF5_ENABLE_FORTRAN setting them to no allows users to avoid building/linking against the respective interfaces to hdf5. This is useful when eg. one does not need them and would like to link against a cluster supplied version of hdf5 (or if one cannot use the Fortran modules due to differing compiler versions). This kind of relates to Ian's original email: http://lists.einsteintoolkit.org/pipermail/users/2011-March/000928.html Although it does not provide any early warning. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/457> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #349: pyc files when syncing
by Einstein Toolkit 23 Jun '11

23 Jun '11

#349: pyc files when syncing ---------------------------+------------------------------------------------ Reporter: barry.wardell | Owner: mthomas Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ---------------------------+------------------------------------------------ When I use 'sim sync' to copy files to a machine, it often rsyncs several .pyc files in the SimFactory directory. This happens every time I sync after running a simfactory command on the remote machine. I think these files should probably be excluded from the sync process. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/349> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 16

[Einstein Toolkit] #454: Where To Get Chicken Coops
by Einstein Toolkit 21 Jun '11

21 Jun '11

#454: Where To Get Chicken Coops -----------------------+---------------------------------------------------- Reporter: anonymous | Type: defect Status: new | Priority: major Milestone: | Component: Other Version: | Keywords: -----------------------+---------------------------------------------------- Even though [http://www.chickencoopforsale.com chicken coops for sale] might not be on every one's weekly shopping list, they're needed by thousands of people internationally together with farmers and businesses. When you are serious about owning some chickens for domestic pets, egg laying or possibly meat then you'd probably like to know where one can acquire chicken coops from. There are several designs of coops and they're constructed from a variety of materials. There are open-air styles of coops plus the closed-house design. Almost all the fresh air kinds are produced from wood and chicken wire and newer varieties are now being constructed from plastic. Both designs ought to be very well ventilated for the safety of your flock. But, before you buy chicken coops or even chickens for that matter, remember to check out the local bylaws in your town. Various parts of the world have different legislation concerning the owning of chickens and also coops. Ensure that they're legal regionally. There are lots of different kinds of retailers specializing in chicken coops and these usually sell chicken coops as well. They may currently have a stock of cages and coops that are already built and they may also be able to custom design and put together one for your specific needs. The charge will most likely depend on the type of material used plus the size of the object. A lot of these sites may also sell the building plans to chicken coops together with kits. This means may buy them as well as some materials and accessories and then make it yourself. They're designed to maintain a specific number of chickens, so you need to have the plans for a hen house that's big enough. It is very important that you buy the right size and also have the space in your back garden.If you buy a brand new coop, make sure you get some sort of warrantee or guarantee with it. This is important as it really needs to be strong enough to guarantee the actual hens will not escape from it. Whilst it may be hard finding a store to buy chicken coops from in your area, you will have much better luck by looking for sellers on the web. There are several sites online that are specializing in chickens and their homes. You ought to be able to order kits and plans from their site and have them delivered to you if the outlets aren't local. You might also be thinking about purchasing a used coop. Many farmers and chicken owners will offer for sale theirs when they have to have brand new ones. You may want to check the classified ads in local papers and agriculture magazines to see if there are any available for purchase. If you do buy chicken coops that are used, you must inspect them first to make certain they're sturdy and in good condition. If you've never owned hens before, it's suggested that you do some research on the animals as well as their habits before purchasing a coop. It is very important for you to understand the requirements of the chickens and that the coop is suitable for them. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/454> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #442: Restructure grid hierarchy properties
by Einstein Toolkit 14 Jun '11

14 Jun '11

#442: Restructure grid hierarchy properties -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: | -------------------------+-------------------------------------------------- Some time ago, someone (can't find the email right now) reported problems with CarpetRegrid2, where the grid structure may be inconsistent. I have restructured the code, but since this is a fairly invasive change I would like this to be thoroughly tested before committing it. This change may lead to Carpet using a (slightly) different grid structure than before. The differences are not "important"; what potentially changes is the order in which consistency conditions are applied. I expect that, in most cases, there will be no differences. The list of consistency conditions is: - ensure proper nesting (level must be larger than next finer level) - add buffer zones (only once, not really a consistency condition) - combine regions into a single box (if this is efficient) - apply rotating 90/180 symmetry (if requested) - clip at outer boundary (so that boxes that are too large or are outside are cut off) I attach a patch and four new files that implement this restructuring. Give it a try if you are interested. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/442> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #452: Declare all private variables as private
by Einstein Toolkit 13 Jun '11

13 Jun '11

#452: Declare all private variables as private -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- In Fortran OpenMP, loop variables of parallel loops are implicitly private and do not need to be declared as private. I find this somewhat confusing, and I suggest to nevertheless declare them to be private. In particular, when tracking down OpenMP problems I am never sure whether it is a compiler problem, and I want to avoid as much ambiguity as possible. The attached patch does this. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/452> 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