Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

Re: [Users] [ET Trac] [Einstein Toolkit] #100: ExternalLibraries/HDF5/HDF5.sh fails to catch a missing library file in user implementation
by Roland Haas 13 Dec '10

13 Dec '10

Hello all, > following: > > make sim options=optionsfile VARIABLE=OVERRIDE > > and thus override the setting for VARIABLE that may exist in > "optionsfile". > > We may want to change this (and I think we should); however, there is Should this really be changed? I find myself doing make sim options=optionsfile SILENT=NO occasionally when the make process fails for some odd reason (actually I would sometimes prefer if I could do more with this mechanism, eg. also OPTIMISE=NO when debugging). So if the possibility of doing VARIABLE=OVERRIDE on the command line is related to preferring environment variables over options file options then (at least for me) the current behaviour is the more useful one. Yours, Roland -- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net.

2 1

Meeting Reminder
by Frank Loeffler 12 Dec '10

12 Dec '10

Hi, This is a reminder about our usual Monday Einstein Toolkit phone call. As usual, you can find instructions how to join on the following web site: http://einsteintoolkit.org/info/support/ Let's make this the last Einstein Toolkit call before Christmas, and thus within 2010. The next call after tomorrow will be January 10th, at 10am US central time. We should discuss what is foreseen to be happening within the toolkit over the holidays, especially for the development in GRHydro, but also on other aspects. Another issue I would discuss rather sooner than later is how we can keep track of publications which used the toolkit. This will be extremely important for the project reports. Waiting with this longer will only make it harder in the end. I would welcome ideas on how to keep a consistent and up-to-date database of publications. My personal expectation would be that this could be a bibtex file in some repository. But even then, a few more political/taste than technical issues remain, with the most often discussed being: how to choose keys for entries, how to (double?) cite arXiv and journal locations, as well as how to (or not to) include urls. It would be interesting to hear in this context how the different groups handle bibtex databases, especially when using multiple files from different sources. Frank

1 0

svn.(cactuscode|einsteintoolkit).org upgrade
by Frank Loeffler 10 Dec '10

10 Dec '10

Hi, The svn server for the Cactus and the Einstein Toolkit will be rebooted in about 15 minutes for a memory upgrade. It shouldn't take long to have it back up running after that. Frank Loeffler

1 1

HDF5 and C++
by John Baker 09 Dec '10

09 Dec '10

Hi, There was some discussion of HDF5 and c++ recently on this list (See: http://lists.einsteintoolkit.org/pipermail/users/2010-September/000515.html ). And also on the trac list in October. In relation to these, our group has been having several problems related to HDF5 and c++ recently. On many of the production environments where we run, there is no hdf5 build available which includes cpp support. In particular a build failed when searching for libhdf5_hl_cpp. We worked around this by removing these libraries from the list in ExternalLibraries/HDF5/HDF5.sh. This seemed to work, but required our hacking the repository version of the code and presumably could cause a failure with any thorns needing HDF5 C++ support. At the same time (actually going back to the first ETK release) I have had difficulty compiling on MacOS, (the macports hdf5-18 doesn't support fortran or c++ with openmpi). I don't generally need hdf5 when I'm doing development on my laptop, but it would be good to have it working. I recently tried using the HDF5=BUILD option on Mac, but this seemed to lead to the same problem in different form. The HDF5 configuration failed with a complaint that --enable-cxx was incompatible with MPI compilers. Getting to the point now, I have some questions: 1. Is there a good reason why HDF5 needs the C++ libraries in Cactus? 2. Does hdf5 1.8.5 even support the c++ interface? 3. What should we be doing differently to work around these issues? Thanks. John.

5 6

McLachlan updated
by Erik Schnetter 08 Dec '10

08 Dec '10

Recent improvements to Kranc slightly changed the way in which boundary conditions to non-evolved variables are applied. After updating the McLachlan source code, I have now pushed a newly generated McLachlan version to its repository. It passes the ML_BSSN_Test test suite. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/

2 2

parameters in TOVSolver
by Frank Loeffler 06 Dec '10

06 Dec '10

Hi, can we change the parameters TOV_Gamma and TOV_K in EinsteinInitial/TOVSolver to be simple scalars instead of arrays? At the moment this makes it possible to setup initial data of multiple stars with different EOSs. However, I don't know of a code which would then be able to evolve this and how that should look like. Is anyone using this ability to choose different EOSs for multiple stars? Frank

1 0

Re: [Users] [Einstein Toolkit] #131: Cactus produces way too much output with SILENT!=no
by Frank Loeffler 06 Dec '10

06 Dec '10

On Fri, Dec 03, 2010 at 04:49:07PM -0000, Einstein Toolkit wrote: > Instead of coming up with a different flag > or a new meaning for the "SILENT" option, why not just make the new > behaviour the default? I can't see any benefit in keeping the old > behaviour. Is there agreement that we should abandon the current compile time output and change to either a very condensed (SILENT!="no", new) or a very verbose (SILENT="no", no change here) version? Frank

1 0

trac components
by Frank Loeffler 06 Dec '10

06 Dec '10

Hi, This is a question about our bug tracking system. In this system we can define components against which people can then file issues. This helps to categorize the bug reports and to automatically assign bugs to people (component owners). At the moment only a few components are defined, e.g. simfactory, the ET websites, GetComponents, Carpet or trac itself. In the extreme case we could have one trac component for each ET component, e.g. each thorn or other utility. However, I think that this would not be so useful. This list would be really long and some issues would still not fit into that. I propose to group components within the Cactus framework mainly by arrangement, but not making that an absolute rule. We would assign maintainers to each of the arrangement. That would of course not mean that they would be (the only people) responsible to actually fix those problems, but merely taking care that the issues have proper owners and are not forgotten. What are the opinions about this? Frank

4 7

Meeting minutes
by Roland Haas 06 Dec '10

06 Dec '10

Meeting minutes: Present were: Tanja, Roland, Frank, Bruno, Ian, Peter - GRHydro coordination GT and RIT will work at merging the MHD routines with the HD routines and test them both for regression and performance - remove unused/obsolete code in GRHydro (this has to be discussed on the mailing list) * reconstruction of the conservatives * general unused code found when merging MHD (will have to come up with a list) * merge polytype and general evolution into one set of routines (have to measure performance impact). Should we include con2prim_polytype in this? - vote on including PunctureTracker in the toolkit - no one has tried OpenMP with the testsuites yet - no one (but Ian) has tried the python simfactory - Carpet/Hg needs testing to see if it works as expected with the testsuites Yours, Roland -- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net.

3 3

PunctureTracker.
by Peter Diener 06 Dec '10

06 Dec '10

Hi, before the Chandrasekhar release I contacted all the authors of the cactus thorn PunctureTracker about potentially include it in the Einstein Toolkit. For those who don't know, this thorn (as it's name implies) tracks the location of the punctures which can then be used to move the mesh refinement regions around. It does so simply by shift-advecting the puncture location. The main advantages of using this instead of tracking the black hole location using the apparent horizon centroid is 1) that it doesn't rely on being able to find the apparent horizon and 2) it converts the apparent horizon finder back to being a pure analysis function. I'm sending this e-mail now to gauge whether the rest of the Einstein Toolkit community is interested in this capability. We can discuss this on the mailing list and/or telecons. Cheers, Peter

6 5

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users