Users December 2019

users@lists.einsteintoolkit.org

8 participants
12 discussions

ld error while linking simfactory on a HPC
by Schaffarczyk, Alois 02 Dec '19

02 Dec '19

Dear all, (1) I tried to compile simfactory on a German HPC (HLRN4) at Goettingen named "Emmy" - probably from Emmy Noether as she worked a long time there. (She is well-known from the Noether-theorem and abstract algebra) Unfortunately linking was not successful: ------------------------------------------------------------------------------------ /usr/bin/ld: warning: libgfortran.so.3, needed by /lib/../lib64/liblapack.so, may conflict with libgfortran.so.5 /usr/bin/ld: /home/shicfdfh/Einstein-toolkit/Cactus/configs/sim/scratch/external/hwloc/lib/libhwloc.a(topology-linux.o): undefined reference to symbol 'udev_device_unref@@LIBUDEV_183' /usr/lib64/libudev.so.1: error adding symbols: DSO missing from command line collect2: Fehler: ld gab 1 als Ende-Status zurück make[1]: *** [/home/shicfdfh/Einstein-toolkit/Cactus/exe/cactus_sim] Fehler 1 make: *** [sim] Fehler 2 ----------------------------------------------------------------------------------- Remark: "Fehler" is German and means ERROR. (2) meanwhile I received feedback from our HPC-support: He says: libudev.so.1 contains demanded ref to "183" and he asks if the order of options in the specific command-line is right: (from stackoverflow) "...Explanation: the linking is dependent on the order of modules. Symbols are first requested, and then linked in from a library that has them. So you have to specify modules that use libraries first, and libraries after them. " I must admit, that I'm not able to locate the line/file to which this might apply (3) Does anybody have an idea which may resolve the bug ? Many thanks in advance advance and best wishes Alois Peter from Kiel, Germany

2 1

Re: [Users] problem using McLachlan with a NS-BH system
by Erik Schnetter 02 Dec '19

02 Dec '19

Giulia Let me make a few more guesses: - How do the lapse gauge driver parameters look like? Did you rescale them as well? - How does the apparent horizon position / shape / coordinate radius behave before this happens? -erik On Fri, Nov 29, 2019 at 6:33 AM Giulia Crotti <g.crotti1(a)campus.unimib.it> wrote: > > Dear all, > thanks for the suggestions. Indeed the problem seems to be occurring > on the finest grid, because the lapse is wrong on the finest level. We > did try changing the ML_BSSN::BetaDriver parameter from 0.71 to 0.25 > (in order to make it ~1/M_BH), but the result was pretty much the > same. > > Cheers, > Giulia > > Il giorno mer 27 nov 2019 alle ore 16:27 Erik Schnetter > <schnetter(a)cct.lsu.edu> ha scritto: > > > > The issue with the time step size (see probably > > <https://arxiv.org/abs/1003.0859>) occurs on the coarsest levels only. > > If the error occurs near the puncture on the fine grid, then this is > > not the problem. > > > > Some of the gauge parameters have a dimension (e.g. 1/length). The > > "standard" settings are optimized for M=1. If your black hole mass is > > very different, then you might need to change them. If you have a > > total mass of M=4, then the gauge might try to act four times faster > > than usual, leading to an instability. The cure would then be > > increased resolution, or changing the respective parameters. > > > > -erik > > > > > > > > On Wed, Nov 27, 2019 at 8:52 AM Wolfgang Kastaun <physik(a)fangwolg.de> wrote: > > > > > > Hi Bruno, > > > > > > Not sure if related, but I vaguely recall that the gamma-driver shift > > > gauge condition can become unstable if the timestep exceeds a critical > > > value related to the damping constant eta in the driver. This might > > > happen with 9 levels if the timestep is also increasing by a factor 2 > > > with each level. The solution I remember was to use the same timestep > > > for the few coarsest levels. Do you know if the first occurrence of NANs > > > in the shift happens on the coarsest level? > > > > > > Cheers, > > > Wolfgang. > > > > > > On 11/27/19 12:36 PM, Bruno Giacomazzo wrote: > > > > Dear All, > > > > a student of mine (Giulia Crotti) is having issues running a NS-BH > > > > simulation with GRHydro and McLachlan (parfile attached). The problem we > > > > are having is with the metric evolution (see attached image for the > > > > lapse produced just before the crash) and I don't think I ever saw such > > > > a problem. Does any of you have any suggestio? > > > > > > > > Approximately around 2000 iterations the simulation crashes with the > > > > following error: > > > > > > > > ERROR from host r168c12s01.marconi.cineca.it > > > > <http://r168c12s01.marconi.cineca.it> process 0 > > > > > > > > while executing schedule bin CCTK_EVOL, routine > > > > PunctureTracker::PunctureTracker_Track > > > > > > > > in thorn PunctureTracker, file > > > > /marconi/home/userexternal/gcrotti0/EinsteinToolkit/ET_2018_09/Cactus/arrangements/EinsteinAnalysis/PunctureTracker/src/puncture_tracker.cc:204: > > > > > > > > -> Shift at puncture #0 is (-nan,-nan,-nan). This likely indicates an > > > > error in the simulation. > > > > > > > > > > > > Something is wrong with the metric; indeed the lapse function gets > > > > larger than 1. We have 9 refinement levels on the black hole, with a > > > > resolution of 0.045 on the finest grid. The initial data have been > > > > computed as to get a mass ratio = 3; so the black hole mass is ~4 solar > > > > masses. The black hole is non-spinning. > > > > > > > > > > > > Thanks, > > > > > > > > Bruno > > > > > > > > > > > > -- > > > > > > > > Prof. Bruno Giacomazzo > > > > Department of Physics > > > > University of Milano-Bicocca > > > > Piazza della Scienza 3 > > > > 20126 Milano > > > > Italy > > > > > > > > email: bruno.giacomazzo(a)unimib.it <mailto:bruno.giacomazzo@unimib.it> > > > > phone: (+39) 02 6448 2321 > > > > web: http://www.brunogiacomazzo.org <http://www.brunogiacomazzo.org/> > > > > > > > > ---------------------------------------------------------------------- > > > > There are only 10 types of people in the world: > > > > Those who understand binary, and those who don't > > > > ---------------------------------------------------------------------- > > > > > > > > > > > > _______________________________________________ > > > > Users mailing list > > > > Users(a)einsteintoolkit.org > > > > http://lists.einsteintoolkit.org/mailman/listinfo/users > > > > > > > _______________________________________________ > > > Users mailing list > > > Users(a)einsteintoolkit.org > > > http://lists.einsteintoolkit.org/mailman/listinfo/users > > > > > > > > -- > > Erik Schnetter <schnetter(a)cct.lsu.edu> > > http://www.perimeterinstitute.ca/personal/eschnetter/ > > _______________________________________________ > > Users mailing list > > Users(a)einsteintoolkit.org > > http://lists.einsteintoolkit.org/mailman/listinfo/users -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/

2 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users December 2019