Users December 2010

users@lists.einsteintoolkit.org

18 participants
20 discussions

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

Re: [Users] Meeting Reminder
by Frank Loeffler 06 Dec '10

06 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/ We will talk about the progress on combining the MHD functions with the original hydro functions, experiences with EOS_Omni and Python Simfactory so far. Of course, as always, feel free to bring up any other topic you feel like we should discuss. Frank

1 0

Meeting minutes
by Roland Haas 06 Dec '10

06 Dec '10

Meeting minutes: Present were: Tanja, Roland, Frank, Erik, Bruno, Josh, Ian, Peter, Eloisa - GRHydro coordination (EOS/MHD) will merge "easy" MHD and HD functions (things other than con2prim/prim2con) - EOS_Omni and other EOS interfaces request users to update their thorns/parameter files to use EOS_Omni since EOS_Base support will go away - Define goals for next release and make them priority: - hg Carpet ? needs some work on the mask (weights) which is currently wrong in concave corners - Python Simfactory ? will be included - per-variable tolerances for Cactus testsuites ? * separate tests into regression tests (specific to each machine) and correctness tests * automate regression tests and run at set intervals rather then only before releases * (some minutes are missing since we had a fire alarm, please feel free to fill these in) - use OpenMP for testsuites will be used in the future - create testsuites using McLachlan from BSSN_MoL testsuites Peter will look into this (but it will take a while) 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

New thorn NoMPI
by Erik Schnetter 03 Dec '10

03 Dec '10

I have just committed a new thorn CactusUtils/NoMPI. This thorn contains a fake MPI implementation for much (but not everything) of MPI's functionality. It provides only a trivial implementation that runs on a single processor. NoMPI can be used to use an MPI code on systems where there is no MPI conveniently available, e.g. on laptops or workstations. To use this thorn, add #include <nompi.h> to your source code, and "uses include header: nompi.h" to the interface.ccl. Thorn NoMPI will automatically switch itself off if a real MPI implementation is found, so that it can be safely used all the time. My main goal was to make Carpet run on such systems, without having to add #ifdefs around each MPI call. Thorn NoMPI is not quite trivial, since certain functionality (e.g. MPI datatypes) still need to be supported. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/

3 3

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users December 2010