Users November 2011

users@lists.einsteintoolkit.org

22 participants
34 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

support_old_CalcTmunu_mechanism
by Frank Loeffler 23 Sep '12

23 Sep '12

Hi, Are there objections to change the default of TmunuBase::support_old_CalcTmunu_mechanism from "yes" to "no"? Frank

1 1

Propose thorns for inclusion in the EinsteinToolkit
by Barry Wardell 26 Apr '12

26 Apr '12

Hi, Recently Ian Hinder and I have created an arrangement of thorns called EinsteinExact which provide some exact solutions for use in Cactus. The scope of these thorns is similar to that of the Exact thorn but with some notable improvements: * The extrinsic curvature is computed symbolically rather than using finite differencing so it should be accurate to within roundoff. This means that EinsteinExact is more exact than Exact. * The solutions used in EinsteinExact come from a database of metrics which have been correctness-tested, e.g., by checking symbolically that they are a solution of the Einstein equation. * EinsteinExact is written in Mathematica and uses Kranc, so the raw source is very small (~250 lines) and easy to understand. * Adding a spacetime is as simple as typing the components of the metric into Mathematica. So far, the spacetimes included are Minkowski, Kerr-Schild, gauge wave and shifted gauge wave, but the list can easily be extended in the future. There is also support for arbitrary rotations, using the same conventions as the Exact thorn uses. We have not yet included the other transformations supported by Exact, but they shouldn't be difficult to add. We have checked that for these spacetimes the Exact solutions converge to the EinsteinExact solutions at the correct finite differencing order used by Exact. We would like to propose the EinsteinExact arrangement for inclusion in the EinsteinToolkit. If you would like to try it out, you can get it using: git clone --recursive git://github.com/barrywardell/EinsteinExact Any comments or suggestions are welcome. Regards, Barry

4 6

changing CarpetRegrid2 parameters for ETK Maxwell + mercurial Carpet?
by Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY] 01 Mar '12

01 Mar '12

Hi all. At Erik's suggestion (off-list), I resolved some checkpoint recovery issues by moving from "Curie" to the new ETK release. However, my old grid specifications seem no longer to work. The parameters are for a 2:1 mass-ratio BHB evolution. I've used three "centres" -- one each for the punctures, and one centred at the origin. Below is what I used to have in CarpetRegrid2, which worked with the last "Curie" release of ETK (the full grid is [-2048,2048] in size). ------------------------------------------------------------------- # Parameters of thorn CarpetRegrid2 (implementing CarpetRegrid2) CarpetRegrid2::freeze_unaligned_levels = "yes" CarpetRegrid2::num_centres = 3 CarpetRegrid2::num_levels_1 = 12 CarpetRegrid2::position_x_1 = -3.3333333333333333333 CarpetRegrid2::movement_threshold_1 = 0.10 CarpetRegrid2::radius_1[5] = 40 CarpetRegrid2::radius_1[6] = 20 CarpetRegrid2::radius_1[7] = 10 CarpetRegrid2::radius_1[8] = 5 CarpetRegrid2::radius_1[9] = 2.5 CarpetRegrid2::radius_1[10] = 1.25 CarpetRegrid2::radius_1[11] = 0.625 CarpetRegrid2::num_levels_2 = 13 CarpetRegrid2::position_x_2 = 6.6666666666666666667 CarpetRegrid2::movement_threshold_2 = 0.05 CarpetRegrid2::radius_2[5] = 40 CarpetRegrid2::radius_2[6] = 20 CarpetRegrid2::radius_2[7] = 10 CarpetRegrid2::radius_2[8] = 5 CarpetRegrid2::radius_2[9] = 2.5 CarpetRegrid2::radius_2[10] = 1.25 CarpetRegrid2::radius_2[11] = 0.625 CarpetRegrid2::radius_2[12] = 0.3125 CarpetRegrid2::num_levels_3 = 6 CarpetRegrid2::radius_3[1] = 1024 CarpetRegrid2::radius_3[2] = 512 CarpetRegrid2::radius_3[3] = 256 CarpetRegrid2::radius_3[4] = 160 CarpetRegrid2::radius_3[5] = 96 CarpetRegrid2::regrid_every = 60 CarpetRegrid2::verbose = "yes" ------------------------------------------------------------------- This doesn't work now, however. Current ETK complains that some entries in radius_1 and radius_2 are unspecified, and it sets them to zero with catastrophic results. To resolve this, I am now explicitly setting the missing levels: CarpetRegrid2::radius_1[1] = 1024 CarpetRegrid2::radius_1[2] = 512 CarpetRegrid2::radius_1[3] = 256 CarpetRegrid2::radius_1[4] = 160 CarpetRegrid2::radius_2[1] = 1024 CarpetRegrid2::radius_2[2] = 512 CarpetRegrid2::radius_2[3] = 256 CarpetRegrid2::radius_2[4] = 160 This runs, but complains every time step about mismatched "simulated domain volume" and "reduction weight sum": ---------------------------------------------------------------------------------- INFO (CarpetReduce): Simulation domain volume: 442368 INFO (CarpetReduce): Reduction weight sum: 442367.999999072 WARNING level 1 in thorn CarpetReduce processor 0 host r186i2n12.p4.nas.nasa.gov (line 120 of /home1/bjkelly1/CODES/Cactus/configs/hahndol/build/CarpetReduce/mask_test.c): -> Simulation domain volume and reduction weight sum differ ---------------------------------------------------------------------------------- After a short evolution time (7.25 M, or more than 1700 time steps), the run crashes. First there are several messages of the form: ---------------------------------------------------------------------------------- INFO (CarpetReduce): Simulation domain volume: 442368 INFO (CarpetReduce): Reduction weight sum: 442367.999991311 INFO (CarpetRegrid2): Centre 1 is at position [-3.29831,-0.331478,7.81462e-15] with 12 levels INFO (CarpetRegrid2): Centre 2 is at position [6.58787,0.867484,8.98107e-15] with 13 levels INFO (CarpetRegrid2): Centre 3 is not active INFO (CarpetRegrid2): Regridding INFO (CarpetRegrid2): Regridding levels 10 and up WARNING level 1 in thorn CarpetLib processor 58 host r186i3n7.p4.nas.nasa.gov (line 182 of /home1/bjkelly1/CODES/Cactus/configs/hahndol/build/CarpetLib/dh.cc): [...] -> /home1/bjkelly1/CODES/Cactus/configs/hahndol/build/CarpetLib/dh.cc:948: [ml=0 rl=10 c=59] The following grid structure consistency check failed: Synchronisation and boundary prolongation: All points must have been received needrecv.empty() [...] WARNING level 0 in thorn CarpetLib processor 94 host r186i3n12.p4.nas.nasa.gov 12676 (line 1973 of /home1/bjkelly1/CODES/Cactus/configs/hahndol/build/CarpetLib/dh.cc): 12677 -> The grid structure is inconsistent. It is impossible to continue. -------------------------------------- I'm attaching my current parameter file in full. I'm reluctant to post the entire STDOUT/STDERR, since it's around a MB in size. Any ideas would be appreciated. I would turn to the copious documentation on CarpetRegrid2, but as noted before, there is none. Thanks, Bernard ----------------------------------------------------------------------------- Bernard Kelly -- CRESST Research Associate, NASA/GSFC Phone: +1 (301) 286-7243 E-Mail: bernard.j.kelly(a)nasa.gov<mailto:bernard.j.kelly@nasa.gov> Web: http://science.gsfc.nasa.gov/sed/index.cfm?fuseAction=people.jumpBio&iphone… -----------------------------------------------------------------------------

4 13

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

Contributing staggered prolongation/restriction operators to ET
by Zach Etienne 29 Nov '11

29 Nov '11

Dear ET folks, This email is to continue the discussion we started during our seminar earlier today. The main reason we could not comment about collaborating more closely with ET is because we had not discussed this previously and furthermore not all of us were present on the conference call. (We have agreed that all of us should give input before making big decisions, such as contributing our code.) Having now discussed the issue with everyone, we are all very keen to contribute to the ET project where we can, as its success will be useful for our own future work, much as the basic Cactus-Carpet infrastructure has proven helpful in the past. Here is our current thinking: * Background As you know, our latest GRMHD code evolves the vector potential A. The vector potential prescription we use carefully staggers all four components of the vector potential A, so that in unigrid the magnetic field B^i evolution is _equivalent_ to the standard, staggered constrained-transport scheme. A-field evolutions enable us to use any interpolation scheme we like at AMR refinement boundaries. However, there is a subtlety: Carpet does not have built-in prolongation/restriction operators for these staggered gridfunctions. * Prolongation/Restriction Modifications to Carpet To handle this problem, we modified some of the existing Carpet Lagrange prolongation/restriction code to instead interpolate the gridfunctions at the appropriate staggered gridpoints. Each of the four A-field components has its own staggering, so there are eight new pieces of code -- one for prolongating & restricting each component of A. We also have multiple interpolation schemes coded up, and each one may be switched on by a #define statement. In terms of infrastructure, the rest is pretty much bookkeeping; each A-field component is stored as any other gridfunction, but we must be careful when using A-field information because e.g., Ax[i,j,k] on the grid actually stores Ax[i,j+1/2,k+1/2]. * Contributing to ET Though it may not be compliant with the ET coding standards (e.g., we only handle the "double" data type), our changes to the Carpet infrastructure have been thoroughly tested, and we would be willing to contribute this code to the ET SVN. In return, we would like to work more closely with those of you who have access to the multipatch "cubed-spheres" code. Would you be willing to share this code with us? Sincerely, The Illinois Numerical Relativity Group -Zach Etienne -Yuk Tung Liu -Vasilis Paschalidis -Stu Shapiro

4 4

EinsteinExact/thorns
by Erik Schnetter 28 Nov '11

28 Nov '11

Barry I like your setup where EinsteinExact "contains" another repository "thorns". I assumes that makes it much simpler to regenerate code without needing to handle spurious conflicts. Can we copy this for McLachlan? Can you briefly describe how to set this up, and how we would have to extend GetComponents (if at all) to make this work? -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/

3 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users November 2011