Users February 2014

users@lists.einsteintoolkit.org

11 participants
17 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

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 28 Feb '14

28 Feb '14

1 0

Re: [Users] Building on Mac OS
by David Radice 27 Feb '14

27 Feb '14

On Feb 10, 2014, at 8:51 AM, David Radice <david.e.pi.3.14(a)gmail.com> wrote: > Hi Ian, > > On Feb 10, 2014, at 3:42 AM, Ian Hinder <ian.hinder(a)aei.mpg.de> wrote: > >> Has anybody run into this before? If not, then I can attempt to dig into the configure script and find out why it's not detecting openmpi from macports anymore. > > yes I ran into this problem. > > The reason why the MPI thorn does not find the OpenMPI from MacPorts is that MacPorts recently changed the way in which MPI is installed. They wanted to support the simultaneous installation of multiple OpenMPI versions compiled with different compilers, so they decided to move all the header files and libraries of OpenMPI to some nonstandard locations where the MPI thorn does not find them. If I am not mistaken the new paths look like these: > > the headers in ${PREFIX}/include/${OMPI_VERSION} , > the libraries in ${PREFIX}/lib/${OMP_VERSION} . > > The default MPI wrappers have also been renamed as ${OMPI_VERSION}-${NAME}. The new port "mpi select" can create aliases for those, but since ET does not use the MPI wrappers to compile, this does not help very much. > > Possible solutions would be to either compile with the MPI wrappers, change to option list to explicitly set MPI_INC_DIR and MPI_LIB_DIRS, or manually compile OpenMPI and point the MPI thorn to it. I would recommend the last of these options, because I am not sure that OpenMPI is compiled correctly by MacPorts: it used to be the case that OpenMPI was compiled with a mix of clang (for the C part) and gcc (for the Fortran code), which resulted in some very weird behavior when running with OpenMPI and OpenMP, and I am not sure that the new "gcc versions" of OpenMPI are actually compiled with gcc or if they simply use gcc as the default target for the wrapper scripts. > > Cheers, > David

3 2

Einstein Toolkit Meeting Reminder
by Frank Loeffler 21 Feb '14

21 Feb '14

1 0

Updating MoL's LinearCombination to support AMR
by Erik Schnetter 18 Feb '14

18 Feb '14

I would like to support MoL's LinearCombination operator, which is also used to perform time integration on accelerators, to pass an additional argument "refinement level". This will help make it possible to run AMR simulations on accelerators (GPUs). This change is essentially a backport from the respective feature branch. If not using accelerators, this change affects only MoL. One of the main drivers for this change is to fold the CaKernel branch back into mainline. Do you agree with such experimental changes to MoL? -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://pgp.mit.edu/.

2 2

Meeting Minutes
by Roland Haas 17 Feb '14

17 Feb '14

Present: Frank, Roland, Josh, Matt, Philipp transition to git * use GRHydro and GRHydro_Init as test cases * Frank to create repository on bitbucket and move current trunk over there * Frank to create list of files with mappings of svn user names to email addresses * contributors can then enter their preferred email address * conversion will happen after this week * the goal is to have the GRHydro development to happen this branch * Frank will have a phone call with Philipp or Roland to walk him through the outstanding commit proposals (after repo has been created) MoL: * while rewriting MoL's scratch level handling, bugs were discovered in the RK87 and RK4-RK2 schemes (in both cases the bug was introduced after the initial implementation of the methods). Fixes have been proposed in ticket #1505 [1] Misc: * Frank will find replacement note takers for next week and the week after Yours, Roland [1] https://trac.einsteintoolkit.org/ticket/1505

1 1

Einstein Toolkit Meeting Reminder
by Frank Loeffler 14 Feb '14

14 Feb '14

1 0

Meeting Minutes
by Roland Haas 11 Feb '14

11 Feb '14

Present: Peter, Steve, Roland, Erik, Josh, Matt, Philipp * Erik, Ian and Barry are working on simfactory 3 which modularizes simfactory and includes facilities to build ExternalLibraries outside of Cactus ** downloads source code of external libraries only when required ** contact Ian Hinder for access to source code ** Steve asked if the modules in simfactory would be useful as a basis to replace the main Cactus make file with a script ** Erik said that so far simfactory 3 treats Cactus as a black box * Caltech would like to extend our EOS interface to handle more complex EOS that take an extra independent variable (describing the nuclear composition). ** it is suggested to leave the current EOS calls in place and to add a new set eg including Abar in the new function names ** possibly forward the "old" calls to the new ones, passing NULL for the extra argument ** Fortran callability may be sacrificed in the initial implementation * currently bluewaters shows a significant regression in run speed that even occurs when using an old executable. The seems possibly related to an update of the MPI stack. Philipp is working with Bluewaters support to fix this. Bluewaters is aware of the problem and Cactus is not the only code affected. Yours, Roland

3 2

Building on Mac OS
by Ian Hinder 10 Feb '14

10 Feb '14

Hi, I tried to compile the ET on my Mac OS 10.8.5 laptop this morning, and it failed while trying to compile MPI. I'm not sure why it wants to compile MPI, since I have openmpi installed via MacPorts. The error was > vt_pform_macos.c: In function 'vt_pform_wtime': > vt_pform_macos.c:210:7: error: 'asm' undeclared (first use in this function) > vt_pform_macos.c:210:7: note: each undeclared identifier is reported only once for each function it appears in > vt_pform_macos.c:210:11: error: expected ';' before 'volatile' > make[7]: *** [libvt_la-vt_pform_macos.lo] Error 1 > make[7]: *** Waiting for unfinished jobs.... > make[6]: *** [all-recursive] Error 1 > make[5]: *** [all] Error 2 > make[4]: *** [all-recursive] Error 1 > make[3]: *** [all-recursive] Error 1 > make[2]: *** [all-recursive] Error 1 > ERROR: Error while building MPI. Aborting. > > CST error 1: > -> Configuration script for thorn MPI returned exit code 1 > Error message: 'Error while building MPI. Aborting.' This may have been a problem all along, but in the past, the MPI thorn was able to detect my installation of MPI. But now, it says: > ******************************************************************************** > Running configuration script for thorn MPI: > MPI selected, but MPI_DIR not set. Checking some places... > MPI: Preparing directory structure... > MPI: Unpacking archive... > ~/Cactus/EinsteinToolkit/configs/sim/scratch/build/MPI ~/Cactus/EinsteinToolkit/configs/sim/scratch > MPI not found > Using bundled MPI... > Building MPI > [ian@Ians-MacBook-Pro EinsteinToolkit (proposed)]$ port list installed|grep mpi > mpi_select @0.0 sysutils/mpi_select > openmpi @1.7.3 science/openmpi > openmpi-default @1.7.3 science/openmpi Has anybody run into this before? If not, then I can attempt to dig into the configure script and find out why it's not detecting openmpi from macports anymore. -- Ian Hinder http://numrel.aei.mpg.de/people/hinder

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users February 2014