Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

Linker errors
by Ian Hinder 10 Jan '12

10 Jan '12

Hi, I have recently been getting the following linker error on some builds of the ET: > /home/ianhin/Cactus/EinsteinToolkitTests/configs/einsteintoolkit_e055fb02a4c17556fd41c009e44c5f0671d21e6e/lib/libthorn_CactusBindings.a(ScheduleGRHydro_InitData.c.o): In function `CCTKi_BindingsSchedule_GRHydro_InitData': > /home/ianhin/Cactus/EinsteinToolkitTests/configs/einsteintoolkit_e055fb02a4c17556fd41c009e44c5f0671d21e6e/bindings/Schedule/ScheduleGRHydro_InitData.c:185: undefined reference to `grhydro_cylindricalexplosionm_' > make[1]: *** [/home/ianhin/Cactus/EinsteinToolkitTests/exe/cactus_einsteintoolkit_e055fb02a4c17556fd41c009e44c5f0671d21e6e] Error 1 > make: *** [einsteintoolkit_e055fb02a4c17556fd41c009e44c5f0671d21e6e] Error 2 It is reproducible, in the sense that I can run the build command again on the same configuration without cleaning it, and get the same error. But when a new configuration is built, the error goes away or changes. I first saw this a few days ago, and have never seen it before. The first time I saw it, the error was with one of the bindings files: > 16039 /home/ianhin/Cactus/EinsteinToolkitTests/configs/einsteintoolkit_63b457e6e6391de8061e1fd96b7cac0c1d8a775d/lib/libthorn_CactusBindings.a(BindingsSchedule.c.o): In function `CCTKi_BindingsScheduleInitialise': > 16040 /home/ianhin/Cactus/EinsteinToolkitTests/configs/einsteintoolkit_63b457e6e6391de8061e1fd96b7cac0c1d8a775d/bindings/Schedule/BindingsSchedule.c:440: undefined reference to `CCTKi_BindingsSchedule_Hydro_InitExcision' > 16041 /home/ianhin/Cactus/EinsteinToolkitTests/configs/einsteintoolkit_63b457e6e6391de8061e1fd96b7cac0c1d8a775d/lib/libthorn_CactusBindings.a(BindingsParameterRecovery.c.o): In function `CCTKi_BindingsParameterRecoveryInitialise': > 16042 /home/ianhin/Cactus/EinsteinToolkitTests/configs/einsteintoolkit_63b457e6e6391de8061e1fd96b7cac0c1d8a775d/bindings/Schedule/BindingsParameterRecovery.c:689: undefined reference to `CCTKi_BindingsParameterRecovery_Hydro_InitExcision' > 16043 make[1]: *** [/home/ianhin/Cactus/EinsteinToolkitTests/exe/cactus_einsteintoolkit_63b457e6e6391de8061e1fd96b7cac0c1d8a775d] Error 1 > 16044 make: *** [einsteintoolkit_63b457e6e6391de8061e1fd96b7cac0c1d8a775d] Error 2 The only thing in common is that the problem always seems to arise with GRHydro, but this might be a coincidence. Looking back in the build log for the first case, I see: 13013 COMPILING /home/ianhin/Cactus/EinsteinToolkitTests/arrangements/EinsteinInitialData/GRHydro_InitData/src/GRHydro_CylindricalExplosionM.F90 13014 : remark #5133: The input stream is empty If this file were in fact empty, the linker error is what I would expect. But the file does not seem to be empty, it does in fact contain the subroutine GRHydro_cylindricalexplosionM. The output files in the config directory seem to be OK: > [ianhin@io1 EinsteinToolkitTests]$ wc configs/einsteintoolkit_63b457e6e6391de8061e1fd96b7cac0c1d8a775d/build/GRHydro_InitData/GRHydro_CylindricalExplosionM.f90 > 2637 7513 64109 configs/einsteintoolkit_63b457e6e6391de8061e1fd96b7cac0c1d8a775d/build/GRHydro_InitData/GRHydro_CylindricalExplosionM.f90 > [ianhin@io1 EinsteinToolkitTests]$ nm configs/einsteintoolkit_63b457e6e6391de8061e1fd96b7cac0c1d8a775d/build/GRHydro_InitData/GRHydro_CylindricalExplosionM.F90.o > 0000000000000000 N .debug_info_seg > 0000000000000018 r STRLITPACK_0 > 0000000000000010 r STRLITPACK_1 > 0000000000000008 r STRLITPACK_2 > 0000000000000000 r STRLITPACK_3 > 0000000000000000 r _2il0floatpacket.324 > 0000000000000008 r _2il0floatpacket.325 > 0000000000000010 r _2il0floatpacket.326 > 0000000000000018 r _2il0floatpacket.327 > 0000000000000020 r _2il0floatpacket.328 > 0000000000000028 r _2il0floatpacket.329 > 0000000000000030 r _2il0floatpacket.330 > 0000000000000038 r _2il0floatpacket.331 > U _intel_fast_memset > 000000000000007c C admbaserest_ > U cctk_equals_ > 0000000000002d60 T cyl_fr_ > U exp > 0000000000000000 T grhydro_cylindricalexplosionm_ > 0000000000000078 C grhydro_initdatapriv_ > 0000000000000268 C grhydrorest_ > 0000000000000058 C hydrobaserest_ > U log > U prim2congenm_ > U prim2conpolym_ Does anyone have an idea of why this might have started happening? -- Ian Hinder http://numrel.aei.mpg.de/people/hinder

3 3

Einstein Toolkit Seminar
by Frank Loeffler 09 Jan '12

09 Jan '12

Hi Please consider joining the Einstein Toolkit Seminar next week Monday, January 16th, at 10 am US central time. We will use the Einstein Toolkit Meeting venue for this, in particular the EVO meeting. Details (and a link to the slides) can be found at http://einsteintoolkit.org/seminars/2012_01_16 Next weeks presenter will be Ian Hawke from the University of Southampton, talking about "A conservation law formulation of nonlinear elasticity in general relativity". Frank Loeffler

1 0

Meeting minutes
by Roland Haas 09 Jan '12

09 Jan '12

Hello all, present were: Frank, Roland, Bruno, Tanja, Erik, Steve, Yosef, Josh, Ian ET seminars: * Ian Hawke will talk about his paper on elasticity, Frank will prepare announcement * please add seminar proposals to the list, we'd rather have too many than not enough Spring workshop in Atlanta: * start on afternoon of last APS day * Dates: ** Tue April 3rd 4-6pm: setup and maybe technical stuff ** Wed morning - Fri noon: regular workshop dates * Tanja will reserve a room at GT * hotels to be announced * will send reminder email to relevant mailing lists (Cactus, ET, ...) Cactus issues: * Ian still has problems building GRHydro on AEI machines, he will investigate as the problems seems AEI-specific * Josh reports that the slope limiters used in TVD in GRHydro seem to be miss-labeled. Will continue discussion on mailing list to have more eyes look at the code. 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.

1 0

simfactory change allocation bug
by Petr Tsatsin 07 Jan '12

07 Jan '12

Hi, Recently my allocation on qb has been changed. So, I changed allocation in defs.local.ini to a new one. However when i tried to submit a job my old allocation has been used in a submitscript instead. How can I fix this? Petr

3 2

File ICs?
by Hal Finkel 06 Jan '12

06 Jan '12

Is there an existing thorn that allows you to read in initial grid data from a file? I see EinsteinInitialData/IDFileADM, but that does not actually implement any reading. Thanks again, Hal -- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory

3 3

Correction to McLachlan dot[A] advection terms
by Erik Schnetter 02 Jan '12

02 Jan '12

I found that the dot[A] advection terms in McLachlan were not implemented correctly. In particular, Kerr-Schild black holes were not manifestly stationary. I corrected this, and pushed the changes. Most BSSN evolutions don't use A as evolved variable (A is approximately equivalent to dot[alpha]), and are thus not affected. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/

1 0

Re: [Users] [Einstein Toolkit] #66: IOHDF5::out3D_ghosts and friends doesn't work and corrupts 2D data slices
by Ian Hinder 21 Dec '11

21 Dec '11

On 18 Oct 2011, at 15:51, Einstein Toolkit wrote: > #66: IOHDF5::out3D_ghosts and friends doesn't work and corrupts 2D data slices > -----------------------------------+---------------------------------------- > Reporter: bcmsma@… | Owner: eschnett > Type: defect | Status: new > Priority: minor | Milestone: > Component: Carpet | Version: > Resolution: | Keywords: > -----------------------------------+---------------------------------------- > > Comment (by rhaas): > > The output_XXX ones work for out3d_vars (the "sliced" 3d output), they do > not work for the legacy out_vars 3d output as you correclty point out. The > former should produce identical output for grid functions (and maybe > scalar and arrays though that is much less well tested). Its code cannot > be used for checkpointing though which is why the old legacy code is still > in (and I don't fully trust the new 3D code yet since it has not been > active for very long). I wasn't really aware of the new-style 3D output method. Does this method allow for parallel output (i.e. one file per process)? If not, then I worry that it might be quite slow. -- Ian Hinder http://numrel.aei.mpg.de/people/hinder

2 1

Re: [Users] [Einstein Toolkit] #659: vip.rzg.mpg.de: Internal Compiler Error: Insufficient storage
by alibeck 21 Dec '11

21 Dec '11

Einstein Toolkit schrieb: > #659: vip.rzg.mpg.de: Internal Compiler Error: Insufficient storage > -----------------------------------------------+---------------------------- > Reporter: alexander.beck-ratzka@… | Owner: eschnett > Type: defect | Status: review > Priority: major | Milestone: > Component: SimFactory | Version: > Resolution: | Keywords: Formaline > -----------------------------------------------+---------------------------- > Changes (by knarf): > > * cc: alexander.beck-ratzka@… (added) > > > Comment: > > Alex? > > I have just tried to add a comment, saying the big has been fixed. Unfortunately I am getting the following error message: [snip] Submission rejected as potential spam [snip] My comment was as follows: [snip] I have changed in the machine config file mdb/machines/vip.ini the make alias. The line make = gmake -j16 has been exchanged against make = env LDR_CNTRL='MAXDATA=0xB0000000@DSA' gmake -j16 The solution is also available now in the trunk version. Using this alias, the build is working now. [snip] Any ideas, what might have causes this error? Best wishes Alexander

4 4

Problem when checking out ET-dev
by Michael Pürrer 20 Dec '11

20 Dec '11

Hi all, I ran into the following problem when checking out the development version of ET: ----------------------------------------------------------------- Checking out module: Carpet/doc from repository: ssh://carpetmercurial@carpetcode.org/carpet into: Cactus/arrangements carpetmercurial(a)carpetcode.org's password: I had no problem checking out the development version of Carpet following http://www.carpetcode.org/get-carpet.html. Does anybody know a solution? Michael

5 9

Re: [Users] Restarting from a checkpoint with simfactory
by Barry Wardell 19 Dec '11

19 Dec '11

On Mon, Dec 19, 2011 at 10:08 PM, Erik Schnetter <schnetter(a)cct.lsu.edu>wrote: > > There was a discussion regarding where to place checkpoint files. I > originally intended them to reside within the corresponding output-NNNN > directories, and this required setting the checkpoint directory to > $parfile, same as the output directory. However, since then others made the > point that they rather wanted all checkpoint files of a simulation in the > same directory, because this enables Cactus to remove the checkpoint files > of previous restarts -- this makes restarts less independent, but can save > disk space. This requires setting the checkpoint directory to > "../checkpoints". > > I don't recall what changes were necessary in Simfactory to support this, > but there may have been some. > In the end, I don't think any changes were made in order to support this. The only changes were in the parfiles. > However, Simfactory always expected all output directories to be set to > $parfile, or to subdirectories of $parfile. It may be that things worked > without doing so, but I never used or tested this myself. > I guess it must have always been the case that this didn't work. It does seem somewhat counter-intuitive that by default Cactus outputs checpoints to a different location than where it looks for them. Barry

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users