Users April 2021

users@lists.einsteintoolkit.org

18 participants
33 discussions

AHFinderDirect error
by Hamilton, Maria 01 Apr '21

01 Apr '21

Hi, I'm trying to add by hand AHFinderDirect to the nsnstohmns.par i this way: ActiveThorns = "AHFinderDirect" AHFinderDirect::find_after_individual_time[1] = 100 AHFinderDirect::find_every = 64 AHFinderDirect::output_h_every = 128 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::initial_guess_method [1] = "coordinate sphere" AHFinderDirect::initial_guess__coord_sphere__radius[1] = 1.0 AHFinderDirect::initial_guess__coord_sphere__x_center[1] = 0.0 AHFinderDirect::N_horizons = 1 AHFinderDirect::origin_x[1] = 0 AHFinderDirect::max_allowable_horizon_radius[1] = 3 AHFinderDirect::which_surface_to_store_info[1] = 0 AHFinderDirect::move_origins = "yes" AHFinderDirect::predict_origin_movement = "yes" AHFinderDirect::reshape_while_moving = "yes" AHFinderDirect::reset_horizon_after_not_finding[1] = "no" AHFinderDirect::track_origin_from_grid_scalar[1] = "yes" AHFinderDirect::track_origin_from_grid_scalar[2] = "yes" I get this error when running: while executing schedule bin CCTK_POSTSTEP, routine AHFinderDirect::AHFinderDirect_find_horizons in thorn Cactus, file /home/babiuc/Cactus/configs/bns/build/Cactus/main/GroupsOnGH.c:290: -> Invalid variable name '' in CCTK_VarDataPtr cactus_bns: /home/babiuc/Cactus/configs/bns/build/AHFinderDirect/driver/Newton.cc:109: void AHFinderDirect::track_origin(const cGH*, AHFinderDirect::patch_system&, AHFinderDirect::AH_data*, int, bool): Assertion `ox' failed. Rank 0 with PID 68131 received signal 6 Writing backtrace to AHFg2nsnstohmns/backtrace.0.txt Aborted (core dumped) Can you please help me understand what I am doing wrong? Maria _______________________ Maria C. Babiuc Hamilton, Ph.D. Professor, Department of Physics College of Science, Marshall University, 1 John Marshall Drive, Huntington, WV, 25755 Room S 257, Phone: (304)696-2754

2 1

meeting minutes for 2021-04-01
by Roland Haas 01 Apr '21

01 Apr '21

Present: Roland, Peter D, Steve, David Bradley, Erik S, Ken, Miguel G, Zach, Maria SPEC benchmark contribution * Steve provided update on status * SPEC org is proceeding ahead * will have to check license given for code ** Cactus is LGPL (v2+) release planning * Roland provided an update on POWER status * needs documenation * will not include monitor for strain due to problems getting this to work with FFI due to ringing * Zach and Maria asked about computing radiated energy. Roland reported that this is not currently present to keep POWER doing one thing and do that well. Will add how to compute energy to documenation. * feature requests: ** energy and angular momentum ** reading in ASCII files in addition to HDF5 files * need to start testing on important systems since we are at the 2 months mark making LORENE2 the default ET LORENE * Zach reported on state from 2018 and that Josh had identified and issue with convergence in LORENE but that will not affect the parts the ET uses * Roland to contact Bruno G. about updates * would at that point also update included tarball simfactory Python3 transition * are using Python3 by default right now * no breakage observed tickets: * https://bitbucket.org/einsteintoolkit/tickets/issues/2516 Zach suggested to try perturbing initial data to roundoff and check what difference is observed and if that is larger than the differences seen here ** general agreement that there should be not difference baring con2prim issues and roundoff ** Roland would want to run a short test himself to see if any differences is observerd * https://bitbucket.org/einsteintoolkit/tickets/issues/963 Peter will take a look but has not had time yet * https://bitbucket.org/einsteintoolkit/tickets/issues/2407 Erik says he will pursue this after the next release. Roland reports that currently all simfactory clusters should support this but this will require a minimum version of gcc 6.X either to compile or as a libstc++ backend for the Intel compiler. Discussed how much speed benefit (if any) the Intel compiler provides compared to GNU compilers. Zach reports on benchmarks with Baikal benchmarks and found that GNU provided faster single core performance, but some other codes (eg LORENE) was much faster with Intel. Erik and Zach suggest a single node benchmark on a real physics setup. Peter mentioned extra options required to get best performance out of compilers in particular wrt to vectorization. ET as a library * Zach reported on efforts to use ET as analysis tool for black holes at home http://blackholesathome.net/ * meant as means to increase waveform generation throughput * Zach could reproduce the gallery example GW150914 using 2GB of memory with waveforms that looks as good or better * this will require a binary library of the ET for OSX, Linux and Windows * Roland has some initial work to compile ET using the MSYS Windows build system (package system for mingw a small footprint variant of Cygwin) * Erik reported on efforts at PI to provide material for high school students Minute taker next week: Steve Chair next weel: Peter D -- 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 1

Re: [Users] Compilation Error related to rdwr.pl script
by Michael Muller 01 Apr '21

01 Apr '21

Hello, Thank you for your quick reply and sorry for my late one. I was going through our code to see if I could find the source of the problem and I was able to locate it. The schedule.ccl file in one of our thorns created the problem. One of the functions that was declared in there was assigning "F90" to the "LANG" keyword, instead of the two options C and FORTRAN. And the function in rdwr.pl seems to check for those two keyword-options and generates an error message if neither is used, if I understood correctly. The latter was the case, where the scheduling declaration looked something like that: *** SCHEDULE function_name IN group_name AFTER other_function_name { LANG: F90 } "do some important stuff" *** I hope this helps. Thank you! Michael ________________________________ Date: Fri, 26 Mar 2021 14:49:02 -0500 From: Steven Brandt <sbrandt(a)cct.lsu.edu> Subject: Re: [Users] Compilation Error related to rdwr.pl script To: users(a)einsteintoolkit.org Message-ID: <6902d061-3fb8-5c8a-63ae-e9955323e2a3(a)cct.lsu.edu> Content-Type: text/plain; charset="windows-1252" Hello. Can you show me the source code which exposed this problem in rdwr.pl? Thanks. --Steve On 3/26/2021 2:46 PM, Michael Muller wrote: > Hello everyone, > > I am a new user of the Einstein Toolkit and I am currently trying to > build the ET deWitt-Morette release with some private thorns. The > private thorns were previously used with the ET Mayer release, so > there are some components that are not quite compatible with the new > release and at least one creates an error related to the new rdwr.pl > script. The problem is that the function in line 471 of rdwr.pl that > would create the error message seems to have a problem with the input > that it gets. Thus the actual error message pointing to the error in > the private thorn never gets printed. The exact error message is: > > "Can't call method "linenum" on unblessed reference at > /home/mmuller/ET_DeWittMorette_2020_11/Cactus/repos/flesh/lib/sbin/rdwr.pl > line 471. > /home/mmuller/ET_DeWittMorette_2020_11/Cactus/lib/make/make.configuration:212: > recipe for target > '/home/mmuller/ET_DeWittMorette_2020_11/Cactus/configs/ET_DeWitt_Morette_privGRHydro/config-data/make.thornlist' > failed > make[1]: *** > [/home/mmuller/ET_DeWittMorette_2020_11/Cactus/configs/ET_DeWitt_Morette_privGRHydro/config-data/make.thornlist] > Error 25 > Makefile:260: recipe for target 'ET_DeWitt_Morette_privGRHydro' failed > make: *** [ET_DeWitt_Morette_privGRHydro] Error 2" > > This error shows up just after the configuration scripts for the > thorns have run. I also included a copy of the full build output in > the attachments. > > It would be great if anyone could provide me with any pointers as to > what could be the source of this problem. > > Thank you and all the best, > Michael Müller > > _______________________________________________ > Users mailing list > Users(a)einsteintoolkit.org > http://lists.einsteintoolkit.org/mailman/listinfo/users

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users April 2021