Users May 2015

users@lists.einsteintoolkit.org

23 participants
38 discussions

Re: [Users] [ET Trac] [Einstein Toolkit] #1326: running loopcontrol on strange number of threads fails
by Erik Schnetter 11 Apr '19

11 Apr '19

Do you have a backtrace? -erik On Sunday, March 22, 2015, Einstein Toolkit < trac-noreply(a)einsteintoolkit.org> wrote: > #1326: running loopcontrol on strange number of threads fails > ------------------------------------+--------------------------------------- > Reporter: rhaas | Owner: > Type: defect | Status: new > Priority: minor | Milestone: > Component: EinsteinToolkit thorn | Version: > Resolution: | Keywords: LoopControl > ------------------------------------+--------------------------------------- > > Comment (by rhaas): > > This still happens even with current (Sun Mar 22 18:46:21 CET 2015) trunk, > though failure looks a bit different now: > {{{ > actus_sim: > /data/rhaas/postdoc/gr/ET_trunk/configs/sim/build/LoopControl/loopcontrol.cc:312: > T {anonymous}::divexact(T, T) [with T = int]: Assertion `i % j == 0' > failed > }}} > > -- > Ticket URL: <https://trac.einsteintoolkit.org/ticket/1326#comment:1> > Einstein Toolkit <http://einsteintoolkit.org> > The Einstein Toolkit > _______________________________________________ > Trac mailing list > Trac(a)einsteintoolkit.org > http://lists.einsteintoolkit.org/mailman/listinfo/trac > -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/

3 2

Cartoon2D and Carpet
by Luca Baiotti 08 Jun '15

08 Jun '15

Hello, I have a question about CactusNumerical/Cartoon2D. In the source file ApplyCartoon.c, there is a condition for the grid setup: if(cctk_gsh[1] != 2*cctk_nghostzones[1]+1) { CCTK_WARN(0, "Grid size in y direction inappropriate."); } As far as I could tell, this is generally violated in multilevel Carpet (CarpetRegrid2) runs, with standard settings that determine the minimum extension of the refined grids, like Carpet::use_buffer_zones = yes mol::ode_method = rk4 That condition for Cartoon2D can be achieved on the coarsest level by setting CoordBase::ymax equal to the spacing dy and CoordBase::ymin equal to -dy. But it cannot be set for refined levels, because CarpetRegrid2 adds as many points as required for the buffer zones. Indeed, Carpet adds enough buffer points for its own purposes that Cartoon2D seems to work fine. Should the above condition be changed to if(cctk_gsh[1] >= 2*cctk_nghostzones[1]+1) ? Yours, Luca

3 4

CAP - A Platform to Present Your Work to the World!
by 2015 International Conference on Advances in Physics (CAP 2015) 29 May '15

29 May '15

1 0

questions about working elliptic solver thorns
by Comer Duncan 29 May '15

29 May '15

Hi Erik, Frank suggested you might be an appropriate person to ask about elliptic solver thorns that work in the current release of ET. I have, as you know, built Hilbert and have built the development version. I am wanting to write a thorn which prepares a geon, approximated by initial data which has toroidal symmetry and is bounded. The desired distribution would be placed on the r axis in cylindrical coordinates and have a gaussian distribution. In the actual application, of course the initial data would be interpolated onto a Cartesian coordinate mesh or meshes. I just want to solve the Hamiltonian constraint and have the initial data be time-symmetric. This sounds like a pretty simple thing to do. I think I could start with Brill and put q to my purposes and pretty much get out what I want. However, the IDBrill does not seem to work. Also, I am wondering what kinds of elliptic solvers you know of that are fully supported in ET? Frank mentioned a petsc thorn. It does not get downloaded and built by default and looking at the einsteintoolkit.th file it is mentioned in: # CactusElliptic thorns !TARGET = $ARR !TYPE = git !URL = https://bitbucket.org/cactuscode/cactuselliptic.git !REPO_PATH= $2 !CHECKOUT = CactusElliptic/EllPETSc CactusElliptic/TATPETSc CactusElliptic/EllBase #DISABLED CactusElliptic/EllPETSc CactusElliptic/EllSOR CactusElliptic/TATelliptic #DISABLED CactusElliptic/TATPETSc However, what's with the DISABLED reference to EllPETSc is a bit concerning. So before I go though the exercise to look more into the EllPETSc, I thought I'd ask whether the EllPETSc thorn is fully compatible with Hilbert? Can you thus please bring me up to the current moment on just what elliptic solvers are in use for initial data construction in Hilbert? I know many people have been focussing on the multiple BH problem, so there's not much traffic anymore about Brill. I do want to run Brill though and also do the "geon" problem. Thanks for your advice and any pointers you can give. Comer

4 5

OALib Journal Helps Your Research Contribution Reached by the World.
by Open Access Library Journal 29 May '15

29 May '15

1 0

Gravitation, Astrophysics and Cosmology Research for Dear
by Journal of Modern Physics 28 May '15

28 May '15

1 0

Re: [Users] failed build on local mac osx yosemite
by Comer Duncan 28 May '15

28 May '15

Ok, I deactivated mpich and have run simfactory/bin/sim build --optionlist=osx-macports.cfg >build2.log 2>&1 and get similar errors. I have pasted the contents of build2.log to http://pastebin.com/kcua0vKQ. It does not seem that the deactivation of mpich had the desired effect. Thanks. Comer On Wed, May 20, 2015 at 12:24 PM, Comer Duncan <comer.duncan(a)gmail.com> wrote: > Erik, > > Thanks. I think I had mpich first and then added openmpi. I will > deactivate mpich-default. The question is do I need to > run simfactory/bin/sim build --optionlist=osx-macports.cfg >build.log 2>&1 > with build2.log instead of build.log so I get a new log file? Will it do > just what is necessary relative to openmpi libs or do the whole business > from scratch? > > Comer > > On Wed, May 20, 2015 at 12:13 PM, Erik Schnetter <schnetter(a)cct.lsu.edu> > wrote: > >> Comer >> >> I would have only one MPI implementation active. I assume you had mpich >> active, and then added openmpi when you followed our instructions. You can >> try to deactivate mpich: "sudo port deactivate mpich-default". >> Alternatively, you can deactivate openmpi. After this, you would need to >> configure and build from scratch. >> >> -erik >> >> On Wed, May 20, 2015 at 12:04 PM, Comer Duncan <comer.duncan(a)gmail.com> >> wrote: >> >>> Hi Erik, >>> >>> Here is what I find: >>> >>> ComerMacProRetina:Cactus comerduncan$ /opt/local/bin/mpiCC -showme >>> /usr/bin/clang -I/opt/local/include/openmpi-mp -Wl,-flat_namespace >>> -L/opt/local/lib/openmpi-mp -lmpi >>> ComerMacProRetina:Cactus comerduncan$ port installed | grep mpi >>> mpi-doc @3.1.3_0 >>> mpi-doc @3.1.4_0 (active) >>> mpi_select @0.0_3 (active) >>> mpich-default @3.1.3_0+gcc49 >>> mpich-default @3.1.4_0+gcc49 (active) >>> openmpi @1.7.5_3 (active) >>> openmpi-default @1.7.5_3+gcc47 (active) >>> petsc @3.5.3_1+accelerate+hwloc+mpich >>> petsc @3.5.3_1+accelerate+hwloc+openmpi (active) >>> >>> Any recommendations for changes? >>> >>> Thanks. >>> >>> Comer >>> >>> On Wed, May 20, 2015 at 9:26 AM, Erik Schnetter <schnetter(a)cct.lsu.edu> >>> wrote: >>> >>>> Comer >>>> >>>> Maybe you have two different MPI implementations installed. What is the >>>> output of "/opt/local/bin/mpiCC -showme"? What is the output of "port >>>> installed | grep mpi"? >>>> >>>> -erik >>>> >>>> On Wed, May 20, 2015 at 9:20 AM, Comer Duncan <comer.duncan(a)gmail.com> >>>> wrote: >>>> >>>>> Hi Ian, >>>>> >>>>> I did make sure that all ports mentioned in the osx-macports.cfg file >>>>> were done before attempting a build. I've followed your suggestion on >>>>> rebuilding and have pasted the build log to >>>>> http://pastebin.com/ka7c3QT5 >>>>> >>>>> Thanks for your help. >>>>> >>>>> Comer >>>>> >>>>> >>>>> On Tue, May 19, 2015 at 6:27 PM, Ian Hinder <ian.hinder(a)aei.mpg.de> >>>>> wrote: >>>>> >>>>>> >>>>>> On 19 May 2015, at 21:03, Comer Duncan <comer.duncan(a)gmail.com> >>>>>> wrote: >>>>>> >>>>>> I have tried to build the new release on my local macbook. I am >>>>>> running Yosemite and am using the optionlist for macports. Here is the >>>>>> part of the make which chokes: >>>>>> . >>>>>> . >>>>>> . >>>>>> Undefined symbols for architecture x86_64: >>>>>> "MPI::Win::Free()", referenced from: >>>>>> vtable for MPI::Win in libthorn_PeriodicCarpet.a(periodic.cc.o) >>>>>> vtable for MPI::Win in libthorn_Carpet.a(helpers.cc.o) >>>>>> vtable for MPI::Win in >>>>>> libthorn_CarpetEvolutionMask.a(evolution_mask.cc.o) >>>>>> vtable for MPI::Win in libthorn_CarpetIOASCII.a(ioascii.cc.o) >>>>>> vtable for MPI::Win in libthorn_CarpetIOBasic.a(iobasic.cc.o) >>>>>> vtable for MPI::Win in libthorn_CarpetIOHDF5.a(Input.cc.o) >>>>>> vtable for MPI::Win in >>>>>> libthorn_CarpetIOHDF5.a(CarpetIOHDF5.cc.o) >>>>>> ... >>>>>> "MPI::Comm::Comm()", referenced from: >>>>>> MPI::Intercomm::Merge(bool) const in >>>>>> libthorn_PeriodicCarpet.a(periodic.cc.o) >>>>>> MPI::Intracomm::Split(int, int) const in >>>>>> libthorn_PeriodicCarpet.a(periodic.cc.o) >>>>>> MPI::Intracomm::Create(MPI::Group const&) const in >>>>>> libthorn_PeriodicCarpet.a(periodic.cc.o) >>>>>> MPI::Graphcomm::Clone() const in >>>>>> libthorn_PeriodicCarpet.a(periodic.cc.o) >>>>>> MPI::Cartcomm::Clone() const in >>>>>> libthorn_PeriodicCarpet.a(periodic.cc.o) >>>>>> MPI::Intracomm::Clone() const in >>>>>> libthorn_PeriodicCarpet.a(periodic.cc.o) >>>>>> MPI::Intracomm::Create_graph(int, int const*, int const*, bool) >>>>>> const in libthorn_PeriodicCarpet.a(periodic.cc.o) >>>>>> ... >>>>>> "MPI::Datatype::Free()", referenced from: >>>>>> vtable for MPI::Datatype in >>>>>> libthorn_PeriodicCarpet.a(periodic.cc.o) >>>>>> vtable for MPI::Datatype in libthorn_Carpet.a(helpers.cc.o) >>>>>> vtable for MPI::Datatype in >>>>>> libthorn_CarpetEvolutionMask.a(evolution_mask.cc.o) >>>>>> vtable for MPI::Datatype in >>>>>> libthorn_CarpetIOASCII.a(ioascii.cc.o) >>>>>> vtable for MPI::Datatype in >>>>>> libthorn_CarpetIOBasic.a(iobasic.cc.o) >>>>>> vtable for MPI::Datatype in libthorn_CarpetIOHDF5.a(Input.cc.o) >>>>>> vtable for MPI::Datatype in >>>>>> libthorn_CarpetIOHDF5.a(CarpetIOHDF5.cc.o) >>>>>> ... >>>>>> "_ompi_mpi_cxx_op_intercept", referenced from: >>>>>> MPI::Op::Init(void (*)(void const*, void*, int, MPI::Datatype >>>>>> const&), bool) in libthorn_PeriodicCarpet.a(periodic.cc.o) >>>>>> MPI::Op::Init(void (*)(void const*, void*, int, MPI::Datatype >>>>>> const&), bool) in libthorn_Carpet.a(helpers.cc.o) >>>>>> MPI::Op::Init(void (*)(void const*, void*, int, MPI::Datatype >>>>>> const&), bool) in libthorn_CarpetEvolutionMask.a(evolution_mask.cc.o) >>>>>> MPI::Op::Init(void (*)(void const*, void*, int, MPI::Datatype >>>>>> const&), bool) in libthorn_CarpetIOASCII.a(ioascii.cc.o) >>>>>> MPI::Op::Init(void (*)(void const*, void*, int, MPI::Datatype >>>>>> const&), bool) in libthorn_CarpetIOBasic.a(iobasic.cc.o) >>>>>> MPI::Op::Init(void (*)(void const*, void*, int, MPI::Datatype >>>>>> const&), bool) in libthorn_CarpetIOHDF5.a(Input.cc.o) >>>>>> MPI::Op::Init(void (*)(void const*, void*, int, MPI::Datatype >>>>>> const&), bool) in libthorn_CarpetIOHDF5.a(CarpetIOHDF5.cc.o) >>>>>> ... >>>>>> ld: symbol(s) not found for architecture x86_64 >>>>>> collect2: error: ld returned 1 exit status >>>>>> make[1]: *** [/Users/comerduncan/Cactus/exe/cactus_sim] Error 1 >>>>>> make: *** [sim] Error 2 >>>>>> >>>>>> Here is the build I did: >>>>>> >>>>>> simfactory/bin/sim build >>>>>> --optionlist=/Users/comerduncan/Cactus/simfactory/mdb/optionlists/osx-macports.cfg >>>>>> >>>>>> Can you please help me figure out what went wrong? >>>>>> >>>>>> >>>>>> Hi Comer, >>>>>> >>>>>> My guess would be that there might be more than one version of MPI >>>>>> installed, or something in the MPI configuration script didn't work quite >>>>>> right. Did you install all the ports recommended in the comment in the >>>>>> os-macports.cfg optionlist? Can you post the output from the full build? >>>>>> I suggest to remove the configuration >>>>>> >>>>>> rm -rf configs/sim >>>>>> >>>>>> and then build, keeping all output: >>>>>> >>>>>> simfactory/bin/sim build --optionlist=osx-macports.cfg >build.log 2>&1 >>>>>> >>>>>> You could then copy and paste build.log into http://pastebin.com and >>>>>> include the link in your reply (to avoid having a large attachment on the >>>>>> mailing list). >>>>>> >>>>>> -- >>>>>> Ian Hinder >>>>>> http://members.aei.mpg.de/ianhin >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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/ >>>> >>> >>> >> >> >> -- >> Erik Schnetter <schnetter(a)cct.lsu.edu> >> http://www.perimeterinstitute.ca/personal/eschnetter/ >> > >

7 44

[yates@cct.lsu.edu: [Allcct] server maintenance]
by Frank Loeffler 27 May '15

27 May '15

Hi, This might also affect some of the ET servers, including web server, email lists and some code repositories. Frank ----- Forwarded message from Adam Yates <yates(a)cct.lsu.edu> ----- Date: Wed, 27 May 2015 17:31:43 -0500 From: Adam Yates <yates(a)cct.lsu.edu> To: allcct(a)cct.lsu.edu Subject: [Allcct] server maintenance User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 List-Id: ALLCCT Mailing List <allcct.cct.lsu.edu> Content-Type: text/plain; charset="us-ascii" Colleagues; We are experiencing some network problems on one of our virtualization hosts. The main CCT website along with a handful of other services will be temporarily interrupted as we address this problem. I will send out another notification as soon as maintenance has been completed. Thanks! Adam -- Adam Yates Manager of Information Technology Center for Computation and Technology (CCT) 1047 Digital Media Center (DMC) Baton Rouge, LA 70803 225.578.8235 _______________________________________________ Allcct mailing list Allcct(a)cct.lsu.edu https://mail.cct.lsu.edu/mailman/listinfo/allcct ----- End forwarded message -----

1 0

question about running brill test
by Comer Duncan 27 May '15

27 May '15

I know this is probably little used these days, but I am in the process of writing a small modification to create another test and wanted to make sure that the old brill initial data test will run. So I tried: ./simfactory/bin/sim submit brill_initialdata --parfile=par/test_brilldata_1.par --procs=1 --walltime=1:0:0 It did not get started really. Here is the output which indicates where it had trouble: Activating thorn Cactus...Success -> active implementation Cactus Activation requested for --->bam_elliptic LocalReduce admbase staticconformal ellbase boundary pugh pughslab pughreduce CartGrid3D CoordBase SymBase idbrilldata ioascii iobasic ioutil time <--- Thorn pugh requests automatic activation of MPI Thorn MPI requests automatic activation of hwloc Thorn hwloc requests automatic activation of zlib Error: Thorn bam_elliptic not found Is bam_elliptic existent and if so does it work with the current flavors of ET? Comer

2 3

ET tutorial says "stay tuned for QB2"
by Roland Haas 27 May '15

27 May '15

Hello all, looking at: https://docs.einsteintoolkit.org/et-docs/Tutorial_for_New_Users is QB2 still not yet up? 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.

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users May 2015