Users May 2014

users@lists.einsteintoolkit.org

15 participants
23 discussions

New Einstein Toolkit Release (Wheeler)
by Frank Loeffler 21 May '14

21 May '14

We are pleased to announce the ninth release (code name "Wheeler") of the Einstein Toolkit, an open, community developed software infrastructure for relativistic astrophysics. This release includes various improvements to the Cactus flesh, Carpet and GRHydro. In addition, bug fixes accumulated since the previous release in November 2013 have been included. For more detailed information about the "Wheeler" release please read the long release announcement on the Einstein Toolkit web pages: http://einsteintoolkit.org/about/releases/ET_2014_05_announcement.php. The Einstein Toolkit is a collection of software components and tools for simulating and analyzing general relativistic astrophysical systems that builds on numerous software efforts in the numerical relativity community including CactusEinstein, the Carpet AMR infrastructure and the relativistic magneto-hydrodynamics code GRHydro. The Cactus Framework is used as the underlying computational infrastructure providing large-scale parallelization, general computational components, and a model for collaborative, portable code development. The toolkit includes modules to build complete codes for simulating black hole spacetimes as well as systems governed by relativistic magneto-hydrodynamics. The Einstein Toolkit uses a distributed software model and its different modules are developed, distributed, and supported either by the core team of Einstein Toolkit Maintainers, or by individual groups. Where modules are provided by external groups, the Einstein Toolkit Maintainers provide quality control for modules for inclusion in the toolkit and help coordinate support. The Einstein Toolkit Maintainers currently involve postdocs and faculty from six different institutions, and host weekly meetings that are open for anyone to join in. Guiding principles for the design and implementation of the toolkit include: open, community-driven software development; well thought out and stable interfaces; separation of physics software from computational science infrastructure; provision of complete working production code; training and education for a new generation of researchers. For more information about using or contributing to the Einstein Toolkit, or to join the Einstein Toolkit Consortium, please visit our web pages at http://einsteintoolkit.org. The Einstein Toolkit is primarily supported by NSF 1212401/1212426/1212433/1212460 (Einstein Toolkit), and also by 0905046/0941653 (PetaCactus) and 0710874 (LONI Grid). All repositories participating in this release carry a branch ET_2014_05 marking this release. These release branches will be updated if severe errors are found. Again, for more information regarding the release, in particular for a list of larger changes, tested machines and remaining issues, go to http://einsteintoolkit.org/about/releases/ET_2014_05_announcement.php The "Wheeler" Release Team on behalf of the Einstein Toolkit Consortium (2014-05-21) Peter Diener Roland Haas Ian Hinder Frank Löffler Bruno C. Mundim Erik Schnetter May 21, 2014

1 0

Meeting Minutes
by Roland Haas 20 May '14

20 May '14

Present: Frank, Peter, Steve, Roland, Erik, Matt, Ian upcoming release: * tutorial currently refers to QueenBee which will go away in 2 weeks * will rewrite to tutorial to use Eric (also LONI) instead, once Eric is ready for use * will not hold release because of this complex parameter files: * apply patch #1554 [1] since it is only an incremental change of complexity compared to currently implemented functionality * including scripting language in Cactus is separate issue ** cannot call system() from within Cactus ** python is well known to users, but hard to include (Steve and Erik) ** lua is easy to include but not as well known to current user base * option for declarative style file rather than imperative style (ie setting parameters only once) * would like errors to be detected as close as possible to line introducing parameter error (so not first create parameter block then verify once the script finishes) * Ian to create ticket and implement code to have the Cactus flesh write fully parsed parameter file with all options by default (in addition to what is currently done). No objections to this feature. * decide on whether to also generate (rather than copy) parfile with only "set" parameter * interested parties to come up with "mock" complex parfiles so that we can then have a starting point for further discussion Ongoing issues: Gallery: * small examples of non-trivial code * BBH (qc0): Ian * BH: Peter: working version on Peter's laptop * NSNS to BH: currently fails * TOV collapse: Roland was volunteered, but suspects this will fail Yours, Roland [1] https://trac.einsteintoolkit.org/ticket/1554

3 3

Re: [Users] [ET Trac] [Einstein Toolkit] #1378: provide equivalent of fprintf(stderr, "%s\n", msg) in Fortran
by Peter Diener 19 May '14

19 May '14

I didn't get this in before the ticket was closed but thought the following might be useful. I believe most compilers (if not all) use unit 0 as stderr, but this is not guaranteed by the standard. However, a fortran 2003 compliant compiler provides an intrinsic module 'iso_fortran_env' that contains this information in the constant error_unit. It also provides input_unit (stdin) and output_unit (stdout). So for fortran 2003 (and later) compliant compilers, the portable way to write to stderr is to use the information in this module. Cheers, Peter On Mon, 19 May 2014, Einstein Toolkit wrote: > #1378: provide equivalent of fprintf(stderr, "%s\n", msg) in Fortran > --------------------------+------------------------------------------------- > Reporter: rhaas | Owner: > Type: enhancement | Status: closed > Priority: minor | Milestone: > Component: Cactus | Version: development version > Resolution: wontfix | Keywords: > --------------------------+------------------------------------------------- > Changes (by rhaas): > > * status: new => closed > * resolution: => wontfix > > > Comment: > > Ah, I did not now about unit 0 for stderr. Cactus redirects file > descriptor 0 (Unix parlance, stdout) to /dev/null on the non-root > processes, so writing to unit 6 (or *) did not work. > > -- > Ticket URL: <https://trac.einsteintoolkit.org/ticket/1378#comment:8> > Einstein Toolkit <http://einsteintoolkit.org> > The Einstein Toolkit > _______________________________________________ > Trac mailing list > Trac(a)einsteintoolkit.org > http://lists.einsteintoolkit.org/mailman/listinfo/trac >

1 0

Process memory growth
by Ian Hinder 19 May '14

19 May '14

Hi, I am seeing a growth in the memory usage of my BBH simulation. The attached plot shows the "maxrss" value reported by SystemStatistics compared with the value of Carpet::grid_functions, both converted to GB, as a function of simulation coordinate time. The plotted value is the maximum over all processes. The run eventually crashed with terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc while recomposing the grid hierarchy. This suggests that something is leaking memory. Does anyone else see problems like this? -- Ian Hinder http://numrel.aei.mpg.de/people/hinder

3 3

Einstein Toolkit Meeting Reminder
by Frank Loeffler 18 May '14

18 May '14

Hi Please consider joining the weekly Einstein Toolkit phone call at 10 am US central time on Mondays. As usual, you can find instructions how to join on the following web site: http://einsteintoolkit.org/community/support/ In short: the number is (+1) 225-578-4942 or (+1) 866-573-0359 and the conference id is 118682#. We will talk about issues concerning the next release, and anything else that might come up. One issue concerning the development version is: - discussion on complex parameter files. We have an open ticket [1] allowing variables to be defined in parameter files. It would be good to decide what level of complexity in parfiles we want to support. Suggestions range from "pure name value lists, no algebraic expressions" to "a lua/python/perl/tcl/... script". Frank [1] https://trac.einsteintoolkit.org/ticket/1554

1 0

Meeting Minutes
by Roland Haas 13 May '14

13 May '14

Present: Peter, Roland, Frank, Matt, Steve, Ian, Erik upcoming release: * release branches to be created today * Peter to commit fix to gaussian test data for ticket 1604 * Erik to regenerate all Kranc generated source code * list of release preparers for announcement: Peter, Roland, Ian, Frank, Bruno, Erik git transition: * Frank and Ian to get into contact next week to test svn to git transition scripts * will try using bitbucket Ongoing issues: Gallery: * small examples of non-trivial code * BBH (qc0): Ian * BH: Peter: working version on Peter's laptop * NSNS to BH: currently fails * TOV collapse: Roland was volunteered, but suspects this will fail Yours, Roland

4 7

Einstein Toolkit Meeting Reminder
by Frank Loeffler 11 May '14

11 May '14

Hi Please consider joining the weekly Einstein Toolkit phone call at 10 am US central time on Mondays. As usual, you can find instructions how to join on the following web site: http://einsteintoolkit.org/community/support/ In short: the number is (+1) 225-578-4942 or (+1) 866-573-0359 and the conference id is 118682#. We will talk about issues concerning the next release, and anything else that might come up. Peter Diener will host the meeting. The release branches will be created early next week (meaning shortly after the meeting). Anything that should go into the new release should be committed as soon as possible. Frank Loeffler

1 0

(possibly) inconsistent handling of ioffsetdenom in CarpetIOHDF5
by Roland Haas 10 May '14

10 May '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all, due to some issues we have with recovering checkpoints I find myself reading CarpetIOHDF5's Output.cc and Input.cc files. In particular lines 849--860 of Output.cc: 849 ivect const ioffsetdenom = bbox.stride(); 850 HDF5_ERROR (attr = H5Acreate (dataset, "ioffsetdenom", \ H5T_NATIVE_INT, 851 dataspace, H5P_DEFAULT)); 852 HDF5_ERROR (H5Awrite (attr, H5T_NATIVE_INT, &ioffsetdenom[0])); 853 HDF5_ERROR (H5Aclose (attr)); 854 ivect const ioffset = 855 ((bbox.lower() % bbox.stride()) + bbox.stride()) % \ bbox.stride(); 856 HDF5_ERROR (attr = H5Acreate (dataset, "ioffset", H5T_NATIVE_INT, 857 dataspace, H5P_DEFAULT)); 858 HDF5_ERROR (H5Awrite (attr, H5T_NATIVE_INT, &ioffset[0])); 859 HDF5_ERROR (H5Aclose (attr)); 860 ivect const iorigin = (bbox.lower() - ioffset) / bbox.stride(); which as far as I can tell always just sets ioffsetdenom to the stride. On the other hand, Input.cc in line 1399-1400: 1399 assert (all (stride % patch->ioffsetdenom == 0)); 1400 ivect lower = patch->iorigin * stride + patch->ioffset * stride / \ patch->ioffsetdenom; only requires stride to be a multiple of ioffsetdenom (rather than being identical). Finally if I read the code correctly then if actually stride != ioffsetdenom then the code produces incorrect results since Input.cc would compute lower as: lower = bbox.lower() - ioffset + patch->ioffset * stride / \ patch->ioffsetdenom (substituting for patch->iorigin) which only ever evaluates to the (presumably correct) bbox.lower() if stride == ioffsetdenom. Any thoughts? 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlNmpZMACgkQTiFSTN7SboXD/gCdGu62iL4LIlrpo2m3Lwv7pED+ 3f4AnR8KHQ91nNR/zzNJRcvOZbrn5oXO =5SNz -----END PGP SIGNATURE-----

3 2

Bin names
by Steven R. Brandt 08 May '14

08 May '14

Are bin names in schedule.ccl supposed to be case sensitive? It appears that they are. I tried to schedule something in mol_calcrhs, and Cactus says this is a nonexistent bin. Cheers, Steve

3 3

NaNChecker issue
by Hee Il Kim 07 May '14

07 May '14

Hi, I used to visualize the positions of NaNs simply by using contour plot of visit. But I failed to visualize the data of NaNmask.h5 generated by recent ET and GRHydro. The output says NaNChecker found NaNs and terminated the run. I tweaked the following parameters but got no difference: NaNChecker::ignore_restricted_points = "no" IOHDF5::output_symmetry_points = no IOHDF5::out3D_ghosts = no I tested even the logging level dependency. The crash time depends on it but no difference for NaN visualization. Actually the above hdf5 setup makes very weird Carpet grids but might do only on Visit. I'm using the latest version of stable ET. My visit has no problem in displaying NaNmask.h5 made by old ET. Thanks for your help in advance, Hee Il

3 4

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users May 2014