Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #1644: create defs.local.ini when it does not exist
by Einstein Toolkit 09 Dec '14

09 Dec '14

#1644: create defs.local.ini when it does not exist -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: enhancement | Status: new Priority: major | Milestone: Component: SimFactory | Version: development version Keywords: | -------------------------+-------------------------------------------------- simfactory needs to be configured before it can be used even on a machine that is in the machine database. This can be done by copying and editing an existing defs.local.ini or by calling "sim setup". Since simfactory cannot function without this setup procedure (since not all of the machine.ini files set eg email and user keys), simfactory should detect if defs.local.ini is missing and offer to enter setup if this is the case. This would be closer to how most unix tools work, that create a functioning, default rc file when they are first started. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1644> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1647: simfactory default for <1 node jobs
by Einstein Toolkit 09 Dec '14

09 Dec '14

#1647: simfactory default for <1 node jobs ------------------------+--------------------------------------------------- Reporter: knarf | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: development version Keywords: | ------------------------+--------------------------------------------------- The following options {{{ --procs 2 --num-threads 2 }}} currently request a full node (ppn in the submitscript is higher than 2, if available). This is very surprising. By default, simfactory should not request more cores than a user asks for. I understand that on some clusters it is necessary to request full nodes, but then this should be implemented in the respective scripts for that cluster. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1647> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1648: MPI thorn should auto configure
by Einstein Toolkit 09 Dec '14

09 Dec '14

#1648: MPI thorn should auto configure -----------------------------------+---------------------------------------- Reporter: sbrandt | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Cactus_4.3.0 Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- The attached patch upgrades the MPI configuration thorn in a number of ways. First, and most importantly, it automatically configures mpi based on information obtained from mpicc when MPI_DIR isn't specified. Configuration is only disabled by setting MPI_DIR = NONE. In addition to MPI_INSTALL_DIR, it will look at CACTUS_EXT_INSTALL_DIR. Frank says that at one point a general external directory for applications was discussed. My feeling is that having the install land in configs is usually not what people want. This version emits an error message if you set MPI_DIR to BUILD, but don't set one of the above install dirs. If you really want MPI under configs, you can set MPI_INSTALL_DIR=CONFIGS. I anticipate pushback on my MPI_DIR=NONE, and MPI_INSTALL_DIR=CONFIGS suggestions, but I thought I'd suggest them regardless. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1648> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 21

[Einstein Toolkit] #1654: All accessible Cactus flesh functions should either be documented or deprecated
by Einstein Toolkit 09 Dec '14

09 Dec '14

#1654: All accessible Cactus flesh functions should either be documented or deprecated -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- There are some Cactus flesh functions which are not documented, and it is unclear the extent to which these are supported. The following command is one way to see the symbols provided to an executable by the Cactus flesh (there might be better or more accurate ways of doing this): {{{ find configs/sim/build/Cactus -name "*.o"|xargs nm -g | grep -v ' U '|less }}} After removing CCTKi symbols etc, this list of symbols should be cross- referenced with the documentation and a decision should be made for any undocumented functions. This is also a good way to find out about symbols which have been declared in the global namespace unintentionally. One could also imagine having a text file with a list of all the supported function symbols, and the automated test system checking that no additional functions are exported into the global namespace. This is not a high priority, but since I thought of it, I made the ticket anyway. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1654> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1662: Only ask once for auth info for bitbucket/github
by Einstein Toolkit 09 Dec '14

09 Dec '14

#1662: Only ask once for auth info for bitbucket/github ---------------------------+------------------------------------------------ Reporter: knarf | Owner: eric9 Type: enhancement | Status: new Priority: minor | Milestone: Component: GetComponents | Version: development version Keywords: | ---------------------------+------------------------------------------------ Maybe only for the special case of "big" services like bitbucket and github, only ask once for the auth info in GetComponents. While I can see that in theory somebody could use a different login for different projects, I think this would be highly unlikely in practice. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1662> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1664: CarpetIOHDF5 should not try to search for grid scalar s and DSITRIB=CONSTANT arrays in all hdf5 files
by Einstein Toolkit 09 Dec '14

09 Dec '14

#1664: CarpetIOHDF5 should not try to search for grid scalar s and DSITRIB=CONSTANT arrays in all hdf5 files --------------------------+------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: CarpetIOHDF5 | --------------------------+------------------------------------------------- Currently, if during a checkpoint recovery a grid scalar or DISTRIB=CONSTANT grid array is not found in the first file, then CarpetIOHDF5 will eventually open and parse all file looking for this dataset. This happens eg when one activates a new thorn with a checkpointed scalar or also when a new code version of a thorn that declares new checkpointed variables is used. Also, the current behaviour is that grid variables that are not found at all (as compared to grid variables for which only some but not all components are found) are silently ignored. Finally, the current checkpointing code will write a copy of grid scalars and DISTRIB=CONSTANT grid arrays in every single checkpoint file, which means that, for a valid set of checkpoint files, if the grid variable is not found in the first file it will also never be found in any of the other files. The ticket is thus an enhancement request to have CarpetIOHDF5 stop searching for the grid variable after the first file. This will not change the behaviour of any current checkpoint files but will speed up the case where a grid variable is missing. This will either speed up a final error report (if eg a thorn was using the missing data and reports poisoned data) or the restart with extra thorns significantly. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1664> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1665: move higher order restriction parameters from CarpetLib to Carpet
by Einstein Toolkit 09 Dec '14

09 Dec '14

#1665: move higher order restriction parameters from CarpetLib to Carpet ----------------------+----------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: optional | Milestone: Component: Carpet | Version: development version Keywords: | ----------------------+----------------------------------------------------- currently they are handled in an usual manner in that they are direct parameters of CarpetLib. The other similar parameters (eg prolongation_order_space) are parameters of Carpet which tells CarpetLib what to do. This will deprecate the parameters in CarpetLib and may also remove the {{{use_higher_order_parameter}}} altogether since it can be deduced from {{{restriction_order_space}}}. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1665> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1666: Consider using BitBucket "pull request" feature
by Einstein Toolkit 09 Dec '14

09 Dec '14

#1666: Consider using BitBucket "pull request" feature ----------------------------------+----------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit trac | Version: development version Keywords: | ----------------------------------+----------------------------------------- BitBucket allows a user to create a fork (or branch) of a repository and request that it be pulled into the master branch. Comments can be made on the pull request, and the discussion of the change will then be on the BitBucket website, rather than in TRAC. Pull requests are more convenient than patches, as there is no need to manually download and apply patch files, and there is a clear audit trail of what was reviewed and when. However, since not all the ET repositories are in BitBucket, this would lead to fragmentation of the review process, with some changes being discussed in TRAC and some in BitBucket. (See the discussion at http://lists.einsteintoolkit.org/pipermail/users/2014-October/003816.html regarding notifications of pull requests.) Discuss. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1666> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1719: Automatically run build and test on pull requests
by Einstein Toolkit 09 Dec '14

09 Dec '14

#1719: Automatically run build and test on pull requests -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Server Infrastructure | Version: development version Keywords: | -----------------------------------+---------------------------------------- It would be desirable to have the Jenkins build-and-test system automatically run for pull requests, so that it is clear that they can be merged without breaking anything. I don't know whether this is possible with Bitbucket, but Bitbucket does have Jenkins support and I've seen the "build-and-test of pull requests idea" work well with projects hosted on GitHub. See the Homebrew project for a good example. (imported from https://trac.einsteintoolkit.org/ticket/1666#comment:1) -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1719> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1669: No check for installed libraries in ExternalLibraries/pciutils
by Einstein Toolkit 09 Dec '14

09 Dec '14

#1669: No check for installed libraries in ExternalLibraries/pciutils -----------------------------------------+---------------------------------- Reporter: joachim.frieben@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: pciutils | -----------------------------------------+---------------------------------- It seems that the configure script in ExternalLibraries/pciutils does not look for an installed instance of pciutils. Therefore, the package is built from scratch even if as in my case both required packages pciutils and pciutils-devel are installed. It would be nice to have this check as it is usually the case for other external libraries. Thanks! -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1669> 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