Users October 2011

users@lists.einsteintoolkit.org

14 participants
21 discussions

Einstein Toolkit Meeting Reminder
by Frank Loeffler 14 May '15

14 May '15

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/ I short: the number is (+1) 225-578-4942 or (+1) 866-573-0359 and the conference id is 118682#. My agenda contains: - Fall workshop - PLEASE let us know if you come [1]! - Hotel booking - Release planning - release date: Mon Oct 24 2011 - freeze date: Mon Sep 26 - the day of the call! - branch name: ET_2011_10 - List of release-concerning bugs [2] - ET paper: proposed "freeze" by Oct 3rd (Mon after this call) As always: feel free to add to this list. Frank Loeffler [1] https://docs.einsteintoolkit.org/et-docs/ET_Workshop_Fall_2011#Fall_Einstei… [2] https://trac.einsteintoolkit.org/query?status=!closed&milestone=ET_2011_11&…

10 31

Simulation domain volume and reduction weight sum differ
by Jakob Hansen 25 Sep '12

25 Sep '12

Hi, Using mercurial, I get this warning during simulations : INFO (CarpetReduce): Simulation domain volume: 170368000 INFO (CarpetReduce): Reduction weight sum: 170367999.880642 WARNING level 1 in thorn CarpetReduce processor 0 host tachyon2974 (line 120 of /home01/r632kgw/jakob/CactusP/arrangements/Carpet/CarpetReduce/src/mask_test.c): -> Simulation domain volume and reduction weight sum differ Simulations seem to run okay though. What is causing this warning and is it serious or can I just ignore it? Cheers, Jakob

3 3

Problems with mpich2
by jhar131＠cct.lsu.edu 18 Dec '11

18 Dec '11

When attempting to build a simulation (in fedora), I encounter an undefined reference error pertaining to MPI. I have installed mpich2 and mpich2-devel both automatically with yum -y as suggested in the notation; as well as manually after this error. Any suggestions? Creating cactus_Test in /home/joshua/Cactus/exe from CactusBase/Boundary CactusBase/CartGrid3D CactusBase/CoordBase CactusConnect/HTTPD CactusConnect/HTTPDExtra CactusWave/IDScalarWaveC CactusBase/IOASCII CactusBase/IOBasic CactusIO/IOJpeg CactusBase/IOUtil CactusPUGHIO/IsoSurfacer CactusBase/LocalReduce CactusPUGH/PUGH CactusPUGH/PUGHReduce CactusPUGH/PUGHSlab CactusConnect/Socket CactusBase/SymBase CactusBase/Time CactusWave/WaveBinarySource CactusWave/WaveToyC ExternalLibraries/libjpeg /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_trid' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_trvalid' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_env2int' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_trrealloc' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_trspace' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_trDebugLevel' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_TrSetMaxMem' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_trlevel' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_trmalloc' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_env2bool' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_env2range' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_trcalloc' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_trfree' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_env2str' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_trstrdup' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_trdump' /usr/lib64/mpich2/lib/libmpich.so: undefined reference to `MPL_trinit' collect2: ld returned 1 exit status

4 6

Problem with CarpetRegrid2/AMR
by Hal Finkel 15 Dec '11

15 Dec '11

I am trying to setup a simple simulation using CarpetRegrid2's AMR capability. As Erik has already pointed out to me (off list), the adaptive-refinement triggering code is still under development. Nevertheless, I would really like to get it working. In my current test case, I am using Kranc to solve a Klein-Gordon equation (with a non-linear potential). With the provided initial conditions, the system has an expanding bubble. This works well when refinement is turned off. To be clear, the evolution equation is: evolCalc = { Name -> "SFBubble_Evolve", Schedule -> {"in MoL_CalcRHS"}, Where -> Interior, Shorthands -> {}, Equations -> { dot[chi] -> chiM, dot[chiM] -> PD[chi,li,lj] Euc[ui,uj] - Vchi[chi] } }; where Vchi[chi_] := V'[chi] (V is the potential). The AMR level_mask is set by: lvlmskSet = { Name -> "SFBubble_SetLevelMask", Schedule -> {"AT preregrid"}, Where -> Interior, Shorthands -> { adchix, adchiy, adchiz }, Equations -> { adchix -> fabs[dx PD[chi,1]], adchiy -> fabs[dy PD[chi,2]], adchiz -> fabs[dz PD[chi,3]], "level_mask" -> ( Max[ adchix, adchiy, adchiz ]/dchimax ) /. Max[a_, b_, c_] -> fmax[a, fmax[b, c]] } }; (in words: the value of chi should not change by more than dchimax over the length of one grid cell) I am using the Periodic thorn to provide periodic boundary conditions. I've attached six pictures. They are at t = 0, the first level 1 intermediate time step, and the first coarse time step. The first three pictures are the value of chi on a slice through the middle of the box. The second three pictures are the value of level_mask. As can be seen in the second chi image, the interpolation into the refined region seems to be incorrect. The "boundary" seems to have appeared in the middle of the block. I have also attached the block descriptions. Is there something I could be doing incorrectly which would cause this? Otherwise, does anyone have any ideas on where to look for the problem? I am using the trunk version as of this morning. Thank you in advance, Hal -- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory

6 46

questions on CarpetIOASCII
by Luca Baiotti 12 Dec '11

12 Dec '11

Hello, I was looking into the param.ccl of CarpetIOASCII (hg version) and found some deprecated parameters: BOOLEAN out3D_ghosts "Output ghost zones (DEPRECATED)" { } "yes" BOOLEAN out3D_outer_ghosts "Output outer boundary zones (assuming that there are nghostzones boundary points (DEPRECATED)" { } "yes" In what sense are they deprecated? I don't do 3D ASCII output, but I think that setting the above parameters to "no" would be better (see also below). Furthermore, BOOLEAN out1D_d "Do output along the diagonal" STEERABLE = ALWAYS { } "yes" should also default to no, I suggest. Finally, I would also make the default of: BOOLEAN output_ghost_points "Output ghost points" { } "yes" to "no". This would also make the script CarpetIOASCII/src/util/Carpet2ygraph.pl work again (see other message about Carpet2ygraph.pl in this mailing list). Except for debugging, is there any advantage in outputting ghost zones? Cheers, Luca

3 3

*No* Einstein Toolkit Meeting Reminder
by Frank Loeffler 30 Oct '11

30 Oct '11

Hi Due to the Einstein Toolkit workshop there will be no Einstein Toolkit Meeting this week. Frank Loeffler

1 0

MoL and Arrays?
by Hal Finkel 28 Oct '11

28 Oct '11

In the MoL's interface file, MoLRegisterEvolvedArray, ArrayScratchSpace, etc. are commented out. Why is that? If I want to evolve arrays, should I just uncomment that stuff? Thanks in advance, Hal -- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory

2 1

Einstein Toolkit release "Maxwell"
by Frank Loeffler 25 Oct '11

25 Oct '11

We are pleased to announce the fourth release (code name "Maxwell") of the Einstein Toolkit, an open, community developed software infrastructure for relativistic astrophysics. This release includes substantial changes to the underlying AMR infrastructure Carpet and the simfactory tool. GRHydro is now officially released with support for magnetohydrodynamics. In addition, bug fixes accumulated since the previous release in April 2011 have been included. 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 hydrodynamics code GRHydro (an updated and extended version of the public release of the Whisky code). 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 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 five 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 0903973/0903782/0904015 (CIGR), and also by NSF 0701566/0855892 (XiRel), 0721915 (Alpaca), 0905046/0941653 (PetaCactus) and 0710874 (LONI Grid). The "Maxwell" Release Team on behalf of the Einstein Toolkit Consortium (2011-10-24)

1 1

GRMHD and the upcoming ET workshop
by Zach Etienne 25 Oct '11

25 Oct '11

Dear ET folks, We (the Illinois Relativity group) have been following the ET mailing list with great interest since its inception and were planning to send representatives to the upcoming ET workshop. Sadly, we will be too busy preparing for the Midwest Relativity Meeting, which we are hosting the following weekend. We noticed that there is some interest in implementing a vector potential-based GRMHD algorithm in ET. Were we able to attend the upcoming ET workshop to discuss this topic with you, we would have shared some recent improvements to our vector potential-based GRMHD algorithm, in the hope that the ET community might benefit. As many of you know, we currently evolve the vector potential to perform GRMHD simulations with divergence-free magnetic fields. We found some major problems with our original implementation when evolving magnetized binary inspirals, such as BHNS inspirals. We discovered that the problems were due to a zero-speed EM gauge mode, and after switching to another (Lorenz) EM gauge, we find huge improvements. We recently posted a paper summarizing our findings at: http://arxiv.org/abs/1110.4633 All the best, Zach Etienne Yuk Tung Liu Vasilis Paschalidis Stu Shapiro

2 2

Einstein Toolkit Meeting Reminder
by Frank Loeffler 24 Oct '11

24 Oct '11

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users October 2011