Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

Enabling CUDA/OpenCL thorns by default in Simfactory?
by Erik Schnetter 29 May '14

29 May '14

The Einstein Toolkit thorn list contains a set of thorns for CUDA or OpenCL. These are disabled by default, since many machines don't support this. These thorns are thus checked out by default, but are not built. I suggest to add these thorns to "enabled-thorns" in Simfactory for these machines. That means that these thorns would also be built by default. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/

5 14

Make "rewrite" branch of McLachlan the default
by Erik Schnetter 28 May '14

28 May '14

I believe the "rewrite" branch of McLachlan is sufficiently stable and accurate to become the master now. The code is significantly cleaner and easier to understand, and it has (since I've been using it myself for some time now) also some features and corrections that may be desirable to have. I suggest to make this the default now. I would give a brief presentation on one of the coming Mondays explaining the design choices and the differences, and after some brief testing we would switch over. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/

1 0

Meeting Minutes
by Frank Loeffler 26 May '14

26 May '14

Hi, Present were - Peter Diener - Erik Schnetter - Ian Hinder - Frank Löffler It was decided that the thorns HelloWorldCUDA and HelloWorldOpenCL will be included in the toolkit (not enabled by default, due to their nature). Also, Ian Hinder concluded that the possibilities Cactus provides for "variables" in parameter files are sufficient for him, so that he does not plan to look further into using a scripting language for parameter files. Developers interested in the inclusion of the Illinois hydro code should be looking at the code until next week, when we will likely discuss it's inclusion. Frank Löffler

1 0

Errors in build- non-existent include directories - latest release
by David Bradley 25 May '14

25 May '14

I have been trying to build the latest release, and run into many warnings such as: COMPILING arrangements/LSUThorns/SummationByParts/src/Derivatives_6_3.F90 Warning: Nonexistent include directory "/opt/Cactus/arrangements/LSUThorns/SummationByParts/src/include" Warning: Nonexistent include directory "/opt/Cactus/arrangements /LSUThorns/SummationByParts/src/includ" Any thoughts on the above fragment. The number is puzzling. Dave

2 1

Einstein Toolkit Meeting Reminder
by Frank Loeffler 23 May '14

23 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#. With the release "Wheeler" out of the door, this is now the right time to discuss and include even large changes. You held something back, or you wanted to clean something up, but it was too close to the release? Think about proposing and including is soon. Frank Loeffler

1 0

Re: [Users] [Einstein Toolkit] #1548: stdout redirection in multithreading scenario
by Gengbin Zheng 22 May '14

22 May '14

yes, that should work. But CCTK_stdout may also need to be thread private variable to avoid race condition by multiple SMP threads. So this will be similar to what I proposed to have a cctk_printf function. Gengbin On 5/22/2014 1:53 PM, Einstein Toolkit wrote: > #1548: stdout redirection in multithreading scenario > ----------------------------------+----------------------------------------- > Reporter: gzheng@… | Owner: > Type: defect | Status: reopened > Priority: major | Milestone: > Component: Cactus | Version: development version > Resolution: | Keywords: stdout redirection > ----------------------------------+----------------------------------------- > > Comment (by rhaas): > > After Gengbing's talk today and studying #1618, would it be possible to do > something as simple as this: > {{{ > static AMPI_TLS FILE *CCTK_stdout = NULL; > ... > CCTKi_CommandLineFinished(...) > { > ... > if(CCTK_MyProc(cctkGH) != 0) { > CCTK_stdout = fopen("CCTK_ProcX.out"); > } else { > // or just = stdout since we never close the file handle anyway > CCTK_stdout = freopen(stdout); > } > ... > } > }}} > ? > > We would then use CCTK_stdout in CCTK_VWarn etc. We'd still keep the > {{{dup()}}} code around for the benefit of Fortran code that does > {{{write(*,*)}}} etc. and requires redirecting the OS level file > descriptors (which may need some code to protect against multiple AMPI > ranks trying to redirect the same file descriptor). Such Fortran code > would not be compatible with AMPI (not much we can do about this I think > unless we want to change the file descriptors each time the thread > changes). > > This would make this ticket a sub-ticket of #1618 (supporting AMPI). >

2 1

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users