Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

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

No Einstein Toolkit Meeting
by Frank Loeffler 24 May '15

24 May '15

Hi, There will not be an Einstein Toolkit meeting coming Monday. The next meeting will be in about one week on Monday, June 1st, at the usual time. Frank Löffler

1 0

Toward an Extensible Volume Integration Thorn
by Zach Etienne 24 May '15

24 May '15

Hi all, Back when I was at Illinois, I wrote a decent volume integration thorn, which was nicely extensible, but required a very messy schedule.ccl to perform all the ~40 integrations we used, with basically no options in [].par files to modify or reduce the list of volume integrals (because it would have made the schedule.ccl file *even* messier). I am now trying to write a new version, which I would like to contribute, open-sourced, to the ET. In this version, the schedule.ccl file is very simple, and by simply specifying desired volume integrals in the [].par file, the scheduling of these volume integrals is *supposed* to be done automatically. Easier said than done. Here's the output from the scheduling when the code is run: while (VolumeIntegrals::IntegralCounter) GROUP VolumeIntegralGroup: Evaluate all volume integrals GROUP VolumeIntegrandGroup: Evaluate all volume integrands VolumeIntegrals::ComputeIntegrand: [local] Compute Integrand GROUP VolumeIntegralSumGroup: Evaluate all volume integral sums VolumeIntegrals::DoSum: [global] Do Sum VolumeIntegrals::DecrementIntegralCounter: Decrement IntegralCounter variable end while Contrary to what is indicated above, the code in the loop actually evaluates only the function in the [local] context, ignoring my [global] requests, and giving a segfault (see full output from this loop below my sig). Is there any way I can make this work, or am I doomed to repeat the messy schedule.ccl of the past? -Zach * * * Zachariah Etienne Assistant Professor of Mathematics West Virginia University INFO (Carpet): [ml=0][rl=3][m=0][c=0,lc=0][tl=0] Local mode call at CCTK_ANALYSIS to VolumeIntegrals::InitializeIntegralCounter INFO (Carpet): [ml=0][rl=3][m=0][c=0,lc=0][tl=0] Leaving local mode INFO (Carpet): [ml=0][rl=3][m=0][tl=0] Leaving singlemap mode INFO (Carpet): [ml=0][rl=3][tl=0] Entering singlemap mode INFO (Carpet): [ml=0][rl=3][m=0][tl=0] Entering local mode INFO (Carpet): [ml=0][rl=3][m=0][c=0,lc=0][tl=0] Local mode call at VolumeIntegrandGroup to VolumeIntegrals::ComputeIntegrand INFO (Carpet): [ml=0][rl=3][m=0][c=0,lc=0][tl=0] Leaving local mode INFO (Carpet): [ml=0][rl=3][m=0][tl=0] Leaving singlemap mode INFO (Carpet): [ml=0][rl=3][tl=0] Leaving level mode INFO (Carpet): [ml=0][tl=0] Global mode call at VolumeIntegralSumGroup to VolumeIntegrals::DoSum INFO (Carpet): [ml=0][tl=0] Entering level mode INFO (Carpet): [ml=0][rl=0][tl=0] Entering singlemap mode INFO (Carpet): [ml=0][rl=0][m=0][tl=0] Entering local mode INFO (Carpet): [ml=0][rl=0][m=0][c=0,lc=0][tl=0] Leaving local mode INFO (Carpet): [ml=0][rl=0][m=0][tl=0] Leaving singlemap mode INFO (Carpet): [ml=0][rl=0][tl=0] Leaving level mode INFO (Carpet): [ml=0][tl=0] Entering level mode INFO (Carpet): [ml=0][rl=1][tl=0] Entering singlemap mode INFO (Carpet): [ml=0][rl=1][m=0][tl=0] Entering local mode INFO (Carpet): [ml=0][rl=1][m=0][c=0,lc=0][tl=0] Leaving local mode INFO (Carpet): [ml=0][rl=1][m=0][tl=0] Leaving singlemap mode INFO (Carpet): [ml=0][rl=1][tl=0] Leaving level mode INFO (Carpet): [ml=0][tl=0] Entering level mode INFO (Carpet): [ml=0][rl=2][tl=0] Entering singlemap mode INFO (Carpet): [ml=0][rl=2][m=0][tl=0] Entering local mode INFO (Carpet): [ml=0][rl=2][m=0][c=0,lc=0][tl=0] Leaving local mode INFO (Carpet): [ml=0][rl=2][m=0][tl=0] Leaving singlemap mode INFO (Carpet): [ml=0][rl=2][tl=0] Leaving level mode INFO (Carpet): [ml=0][tl=0] Entering level mode INFO (Carpet): [ml=0][rl=3][tl=0] Entering singlemap mode INFO (Carpet): [ml=0][rl=3][m=0][tl=0] Entering local mode INFO (Carpet): [ml=0][rl=3][m=0][c=0,lc=0][tl=0] Leaving local mode INFO (Carpet): [ml=0][rl=3][m=0][tl=0] Leaving singlemap mode INFO (Carpet): [ml=0][rl=3][tl=0] Leaving level mode APPLICATION TERMINATED WITH THE EXIT STRING: Segmentation fault (signal 11)

4 8

yt and the Einstein Toolkit
by Jonah Miller 22 May '15

22 May '15

Hello Einstein Toolkit Users, I am travelling to meet with Matt Turk, the head developer of the yt visualization toolkit (http://yt-project.org/). Among other things, we hope to make yt and the Einstein Toolkit work together. My understanding is that there was a push in this direction in the past. If possible, I'd like to look at the code that was written for this purpose in the past. Does anyone know where I could find it. Thanks in advance! Best, Jonah Miller

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users