Users March 2014

users@lists.einsteintoolkit.org

10 participants
13 discussions

Start a nNew thread

Einstein Toolkit Meeting Reminder
by Frank Loeffler 14 May '15

14 May '15

10 31

Meeting Minutes
by Roland Haas 01 Apr '14

01 Apr '14

Present: Frank, Roland, Erik, Peter, Matt, Steve transition to git: * soften commit requirements, no longer require review for every change for thorns under heavy development * restrict commits just before release * when using git, no longer propose patches but instead use pull requests Yours, Roland

3 4

Einstein Toolkit Meeting Reminder
by Frank Loeffler 30 Mar '14

30 Mar '14

1 0

new evolution_methods "frozen-ID" and "regrid-only" for ADMBase
by Roland Haas 26 Mar '14

26 Mar '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all, this is related to ticket 1399 on trac (https://trac.einsteintoolkit.org/ticket/1399). There it is proposed to introduce new evolution methods to ADMBase that are intended to be used for simulations where the spacetime metric is either time independent (eg when using a fixed background spacetime for hydro simulations) or can be computed analytically at each step. Currently the "static" evolution method in ADMBase will apply boundary conditions as well as prolongation after each step which can be undesirable if the analytic spacetime is known since prolongation will change the values in the buffer zones. The two new methods would would do the following: regrid-only: * never apply boundary conditions, never do a SYNC * after a regrid (in the postregrid routine) re-apply the initial condition by scheduling ADMBase's initial data group apply-ID: * never apply boundary conditions, never do a SYNC * schedule ADMBase's initial data group before each timestep The later (apply-ID) is very similar to using Exact's "exact" evolution method while the first one is more economical in that it only re-computes the spacetime when required (assuming a time independent spacetime). The two changes would allow to use any ID thorn (as long as it only sets the current timelevel) as a source for a background spacetime. This email is to query for "nicer" names for the two methods. Currently proposed are "regrid-only" for the method that does "reapply-initial-condition-after-grid-structure-changes" and "apply-ID" for "reapply-initial-condition-at-every-time-step". I'll apply the patch sometime after next week with the then current winning name choice. 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/ iEYEARECAAYFAlMzOLsACgkQTiFSTN7SboUT7gCeNU/x42dpzOJ3GFelP29qmggB t/wAn2uLP1u2MZDPrisLQD1Yr0l5rqRi =/MUD -----END PGP SIGNATURE-----

2 1

Meeting Minutes
by Roland Haas 25 Mar '14

25 Mar '14

Present: Frank, Roland, Ian, Erik, Steve, Zach, Peter GRHydro update: * GRHydro is seeing a major rewrite with most F90 routines being re-implemented as C++ * in this process seldom (or completely) unused features are being removed * suggestion is to announce changes (rewrite and lost functionality) on mailing list then drop old code * Roland to make a list of changed/dropped functionality Git transition: * we will combine related thorns into common repositories * keep some thorns (ExternalLibraries that contain tarballs) in svn * Erik to create a proposed list of repositories and thorns in them on the wiki Timelevels: * changes to MoL to avoid having to count evolved variables * desire to have similar auto-counting in Carpet to determine number of timelevels required for interpolation in time * currently seems as if Carpet does not have enough information early enough to allocate those timelevels * suggestion (Erik): "register" grid functions with Carpet that same way they are registered with MoL if interpolation in time will be required. This will be a subset of the grid functions that do *not* state prolongation_type = None Yours, Roland

8 18

Meeting Minutes
by Roland Haas 24 Mar '14

24 Mar '14

Present: Frank, Roland, Ian, Erik, Zach, Peter, Barry, Matt, Matt Turk, Sam Skillman yt frontend to read Carpet HDF5 files: * Sam Skillman was visiting Caltech and started to work on adding a CarpetHDF5 reader to yt (http://yt-project.org/). On the Caltech side Sherwood Richers (did the actual work) and Roland Haas were involved. Sam's reader is making good progress and the hope is to have a beta version ready by the end of the (ongoing yt) workshop. An email asking for beta testing and including download instructions will be send to users(a)cactuscode.org once the beta is ready. * Erik described his efforts to define an API to write/read the datasets to allow changes to the on-desk dataset * this would be well suited to yt but is currently not the mainstream data format transition to git: * different proposals were made on how to best organize the thorns into git repositories * we will proceed with the "few repositories" option and use a layout where there is one repository per arrangement (except for exceptional cases like eg Kranc) with the ultimate goal of being able to check out directly into arrangements when possible (ie no more symbolic links) * this will include the uncontroversial arrangements CactusBase, CactusConnect as well as EinsteinEvolve * we will * we will also re-arrange some thorns that are currently (for historical reasons) in "unexpected" repositories. This includes some thorns in AEIThorns as well as eg TATPetsc * we will proceed with this right away without adapting GetComponents immediately * try to have all transitions (svn->git, single repo per arrangement) in a single release * Ian and Frank to work on conversion script from svn to git Yours, Roland

2 1

Re: [Users] CarpetReduce: Formerly working par file now yields 'Simulation domain volume and reduction weight sum differ'
by Scott Hawley 24 Mar '14

24 Mar '14

Hi Steve, Making that change didn't affect the error. You're off the hook. ;-) I'm happy to hear other suggestions. I've never seen this error before. Thanks, Scott From: "Steven R. Brandt" <sbrandt(a)cct.lsu.edu<mailto:sbrandt@cct.lsu.edu>> Date: Monday, January 27, 2014 10:32 AM To: Scott Hawley <scott.hawley(a)belmont.edu<mailto:scott.hawley@belmont.edu>> Subject: Re: [Users] CarpetReduce: Formerly working par file now yields 'Simulation domain volume and reduction weight sum differ' Let's just make sure it's not my fault somehow (I doubt that it is). Go to src/util/ParseFile.c and change line 134 to look like this: int piraha_active = 0; See if that makes any difference. If it doesn't, change the 0 back to 1. If it does, please let me know. Cheers, Steve On 01/23/2014 10:57 AM, Scott Hawley wrote: Hi. I never received any responses to this. Hoping it was just because that was a busy time of year. Trying again. Thanks, Scott From: Scott Hawley <scott.hawley(a)belmont.edu<mailto:scott.hawley@belmont.edu>> Date: Friday, December 20, 2013 1:19 PM To: "users(a)einsteintoolkit.org<mailto:users@einsteintoolkit.org>" <users(a)einsteintoolkit.org<mailto:users@einsteintoolkit.org>> Subject: [Users] CarpetReduce: Formerly working par file now yields 'Simulation domain volume and reduction weight sum differ' Hi, I'm pretty sure I haven't changed a par file which "used to work." Now I'm getting the 'Simulation domain volume and reduction weight sum differ' error. I've read a few previous posts about this... http://lists.einsteintoolkit.org/pipermail/users/2011-September/001457.html http://lists.einsteintoolkit.org/pipermail/users/2012-September/002540.html http://lists.einsteintoolkit.org/pipermail/trac/2011-October/002465.html ...but haven't understood how they apply to my case. I'm not using CarpetMask, and haven't changed anything about the boundary points or grid structure. Can anyone offer a suggestion? Thanks. Output log and par file follow. -Scott % /opt/local/bin/openmpirun -np 1 ./exe/cactus_bruiser -roe --logdir=log /Users/shawley/runs/cactus/bruiser/bruiser_test.par IN DIRECTORY: /Users/shawley/Cactus -------------------------------------------------------------------------------- 10 1 0101 ************************ 01 1010 10 The Cactus Code V4.0 1010 1101 011 www.cactuscode.org<http://www.cactuscode.org> 1001 100101 ************************ 00010101 100011 (c) Copyright The Authors 0100 GNU Licensed. No Warranty 0101 -------------------------------------------------------------------------------- Cactus version: 4.1.1 Compile date: Dec 20 2013 (12:34:14) Run date: Dec 20 2013 (13:02:27-0600) Run host: (pid=99492) WARNING level 1 in thorn CarpetReduce processor 0 host Working directory: /Users/shawley/Cactus (line 137 of /Users/shawley/.mojaveconfig/Cactus/bruiser/build/CarpetReduce/mask_test.c): Executable: ./exe/cactus_bruiser -> Simulation domain volume and reduction weight sum differ Parameter file: /Users/shawley/runs/cactus/bruiser/bruiser_test.par -------------------------------------------------------------------------------- % cat bruiser_test.par | grep -v '^#' Cactus::cctk_run_title = "BruiserSetBG, FMR BBH" Cactus::cctk_full_warnings = yes Cactus::cctk_itlast = 0 ActiveThorns = "AEILocalInterp Boundary CartGrid3D CoordBase SymBase Slab Carpet CarpetLib CarpetInterp CarpetReduce CarpetSlab CarpetRegrid IOUtil SphericalSurface NaNChecker ADMBase ADMCoupling ADMMacros CoordGauge SpaceMask StaticConformal BruiserSetBG BruiserConstraints AHFinderDirect ADMAnalysis ADMConstraints LoopControl InitBase CarpetIOBasic CarpetIOScalar CarpetIOASCII TimerReport TmunuBase GenericFD" ActiveThorns = "CarpetIOHDF5 CarpetIOASCII" SphericalSurface::nsurfaces = 3 SphericalSurface::maxntheta = 39 SphericalSurface::maxnphi = 76 SphericalSurface::ntheta [0] = 39 SphericalSurface::nphi [0] = 76 SphericalSurface::nghoststheta[0] = 2 SphericalSurface::nghostsphi [0] = 2 SphericalSurface::ntheta [1] = 39 SphericalSurface::nphi [1] = 76 SphericalSurface::nghoststheta[1] = 2 SphericalSurface::nghostsphi [1] = 2 SphericalSurface::ntheta [2] = 39 SphericalSurface::nphi [2] = 76 SphericalSurface::nghoststheta[2] = 2 SphericalSurface::nghostsphi [2] = 2 IO::out_dir = $parfile Carpet::domain_from_coordbase = yes driver::ghost_size = 4 InitBase::initial_data_setup_method="init_all_levels" Carpet::prolongation_order_time = 0 Carpet::prolongation_order_space = 1 Carpet::convergence_level = 0 ADMMacros::spatial_order = 4 ADMBase::initial_data = "BruiserSetBG, Kerr-Schild" ADMBase::lapse_timelevels = 2 ADMBase::shift_timelevels = 2 ADMConstraints::constraints_timelevels = 2 ADMBase::metric_timelevels = 2 CoordBase::domainsize = minmax CoordBase::spacing = numcells CoordBase::xmin = -36.0 CoordBase::ymin = -36.0 CoordBase::zmin = -36.0 CoordBase::xmax = 36.0 CoordBase::ymax = 36.0 CoordBase::zmax = 36.0 CoordBase::ncells_x = 12 CoordBase::ncells_y = 12 CoordBase::ncells_z = 12 CartGrid3D::type = coordbase CartGrid3D::avoid_origin = no NaNChecker::check_every = 524288 NaNChecker::action_if_found = terminate Carpet::max_refinement_levels = 7 CarpetRegrid::refinement_levels = 7 CarpetRegrid::refined_regions = "manual-coordinate-list" CarpetRegrid::smart_outer_boundaries = yes CarpetRegrid::coordinates = "[ [([-36,-36,-36]:[36,36,36]:[3,3,3])], [([-36,-36,-36]:[36,36,36]:[1.5,1.5,1.5])], [([-19.5,-19.5,-19.5]:[19.5,19.5,19.5]:[0.75,0.75,0.75])], [([-12,-9,-9]:[12,9,9]:[0.375,0.375,0.375])], [([-8.25,-4.125,-4.125]:[-1.875,4.125,4.125]:[0.1875,0.1875,0.1875]),([1.875,-4.125,-4.125]:[8.25,4.125,4.125]:[0.1875,0.1875,0.1875])], [([-6.375,-1.6875,-1.6875]:[-3.75,1.6875,1.6875]:[0.09375,0.09375,0.09375]), ([3.75,-1.6875,-1.6875]:[6.375,1.6875,1.6875]:[0.09375,0.09375,0.09375])] ]" Carpet::verbose = "no" Carpet::veryverbose = "no" BruiserSetBG::bh1_m = 1.0 BruiserSetBG::bh1_a = 0.5 BruiserSetBG::bh1_theta = 0.0 BruiserSetBG::bh1_phi = 1.57 BruiserSetBG::bh1_x = -5.00 BruiserSetBG::bh1_y = 0.0 BruiserSetBG::bh1_z = 0.0 BruiserSetBG::bh1_vx = 1.0e-33 BruiserSetBG::bh1_vy = 0.0 BruiserSetBG::bh1_vz = 0.0 BruiserSetBG::bh2_m = 1.0 BruiserSetBG::bh2_a = 0.5 BruiserSetBG::bh2_theta = 0.0 BruiserSetBG::bh2_phi = 0.0 BruiserSetBG::bh2_x = 5.00 BruiserSetBG::bh2_y = 0.0 BruiserSetBG::bh2_z = 0.0 BruiserSetBG::bh2_vx = 1.0e-33 BruiserSetBG::bh2_vy = 0.0 BruiserSetBG::bh2_vz = 0.0 BruiserSetBG::r_mask = 0.9 BruiserConstraints::skip_solver = "no" BruiserConstraints::use_fma = "no" BruiserConstraints::nlevels = 7 BruiserConstraints::nvcycle = 1 BruiserConstraints::preswp = 3 BruiserConstraints::bruiser_verbosity = 5 BruiserConstraints::sor_factor = 1.4 BruiserConstraints::cgtol = 1.0e-8 SpaceMask::use_mask = yes AHFinderDirect::find_every = 1 AHFinderDirect::geometry_interpolator_name = "Lagrange polynomial interpolation" AHFinderDirect::geometry_interpolator_pars = "order=4" AHFinderDirect::surface_interpolator_name = "Lagrange polynomial interpolation" AHFinderDirect::surface_interpolator_pars = "order=4" AHFinderDirect::N_horizons = 2 AHFinderDirect::origin_x [1] = -5.0 AHFinderDirect::initial_guess__coord_sphere__x_center [1] = -5.0 AHFinderDirect::initial_guess__coord_sphere__radius [1] = 2.0 AHFinderDirect::which_surface_to_store_info [1] = 0 AHFinderDirect::origin_x [2] = 5.0 AHFinderDirect::initial_guess__coord_sphere__x_center [2] = 5.0 AHFinderDirect::initial_guess__coord_sphere__radius [2] = 2.0 AHFinderDirect::which_surface_to_store_info [2] = 1 AHFinderDirect::set_mask_for_individual_horizon [2] = no TimerReport::output_all_timers = "yes" IOBasic::outInfo_every = 1 IOBasic::outInfo_reductions = "minimum maximum" IOBasic::outInfo_vars = " ADMBase::alp " IOScalar::outScalar_every = 1 IOScalar::outScalar_vars = " grid::coordinates ADMBase::metric ADMBase::curv " IOASCII::out2D_every = 1 IOASCII::out2D_vars = " BruiserConstraints::phi " IOHDF5::out_criterion = time IOHDF5::out_dt = 1.0 IOHDF5::out_vars = " ADMBase::metric ADMBase::curv BruiserSetBG::bruiser_mask BruiserConstraints::phi " BruiserConstraints::output_method = "IOHDF5" _______________________________________________ Users mailing list Users(a)einsteintoolkit.org<mailto:Users@einsteintoolkit.org>http://lists.einsteintoolkit.org/mailman/listinfo/users

2 2

Einstein Toolkit Meeting Reminder
by Frank Loeffler 24 Mar '14

24 Mar '14

1 0

Re: [Users] [Commits] [ianhinder/Kranc] 1fbc89: Use 4th order DG elements
by Frank Loeffler 19 Mar '14

19 Mar '14

On Tue, Mar 18, 2014 at 01:33:36PM -0700, Erik Schnetter wrote: > > Changed paths: > M Tools/CodeGen/DGFE.m > > Log Message: > ----------- > Use 4th order DG elements I am not sure how (didn't investigate), but this commit and the corresponding updates to McLachlan started to break the automated tests. See https://build.barrywardell.net/job/EinsteinToolkit/1144/ e.g.: In file included from /home/jenkins/workspace/EinsteinToolkit/arrangements/McLachlan/ML_ADMConstraints/src/Kranc.cc:33:0: /home/jenkins/workspace/EinsteinToolkit/arrangements/McLachlan/ML_ADMConstraints/src/Kranc.hh:10:29: error: ‘namespace ML_ADMConstraints { }’ redeclared as different kind of symbol Frank

3 4

Einstein Toolkit Meeting Reminder
by Frank Loeffler 17 Mar '14

17 Mar '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 mention changes to GRHydro that started to be moved from Zelmani to the main development repository, and will continue to be moved next week (see https://trac.einsteintoolkit.org/ticket/1531). We will *not* go over these patches one-by-one during the call though if not requested. Just see it as announcement of major code changes (although not a lot would change for a user). Also, more and more machine configurations move to the Intel 14 compiler, not so much because "it is the most recent", but mainly because version 13 has at least one serious bug which requires a workaround that affects performance negatively (disabling 'restrict'). Version 14 seems to have this fixed, and I would like to hear different stories if there are some. Thorn TestMoL was suggested to enter the ET (https://trac.einsteintoolkit.org/ticket/1557). Erik reviewed it as ok, but we should still give it its official 'ok'. Frank

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users March 2014