From jlhellmers at sdsu.edu Wed Nov 1 11:36:46 2023 From: jlhellmers at sdsu.edu (Joe Hellmers) Date: Wed, 1 Nov 2023 09:36:46 -0700 Subject: [Users] Trouble Building Cactus Thorns on Mac and on Expanse Message-ID: <2FC5C783-98A9-455B-8C4E-EA06F9797A60@sdsu.edu> Hello, I?d like to use Hyrdro_RNSID in order to generate a initial data for a rotating neutron star, but I?m having some difficulties building the Cactus thorns. Initially I?m just trying to build all of them. When I try to build on my Mac using the latest GNU compilers from Brew, I get a message that my compiler doesn?t support std c11. The version of gcc installed is Apple clang version 15.0.0 (clang-1500.0.40.1), whatever that gcc version that ends up being. If I use the gcc from the MESA SDK, (version 12.2.0) I get the same message. So, I switched to try it on the SDSC Expanse cluster, and at least I don?t get that problem, but I do end of having an issue that it is looking for some Slurm include files from a version that isn?t on expanse any more. Specifically it is looking under /cm/shared/apps/slurm/20.02.3/ but Expanse now has /cm/shared/apps/slurm/21.08.8. So I have a few questions 1) How can I just build what I need for Hydro_RNSID? 2) What can I do about building on my Mac? 3) Where can I change the configuration of my build so that it refers to the correct Slurm version when building on Expanse? Thanks! Joe Hellmers San Diego State University- Physics Dept. From rhaas at illinois.edu Wed Nov 1 17:15:01 2023 From: rhaas at illinois.edu (rhaas at illinois.edu) Date: Wed, 01 Nov 2023 17:15:01 -0500 Subject: [Users] Einstein Toolkit Meeting Reminder Message-ID: Hello, Please consider joining the weekly Einstein Toolkit phone call at 9:00 am US central time on Thursdays. For details on how to connect and what agenda items are to be discussed, use the link below. ** DAYLIGHT SAVING TIME WARNING ** Please note that the US / EU has already / not yet transitioned to / from daylight saving time. The phone call will be at 15:00 Central EU time. https://docs.einsteintoolkit.org/et-docs/Main_Page#Weekly_Users_Call --The Maintainers From wernecklr at gmail.com Thu Nov 2 09:53:17 2023 From: wernecklr at gmail.com (Leo Rosa Werneck) Date: Thu, 2 Nov 2023 07:53:17 -0700 Subject: [Users] Meeting minutes for 2023-11-02 Message-ID: Hi all, Here are the minutes for today?s meeting: Chair: Sam Minutes: Leo Present: Peter, Sam, Roland, Steve, Zach, Leo, Agnesh Pandey * ET release - Release name already decided - Gallery example runners o BNS: Steve o BBH: Debrah? Roland will ask o TOV: Peter o Scalar wave: pending - Sam will try to compile on Deep Bayou to make sure everything is working with GPUs (CarpetX) o Some of the GRHayL thorns are failing even on CPUs; Sam will look into it - Further compilations test are running at the moment * ET testing - Deep Bayou: Steve, SuperMIC - Sunrise: Peter - Frontera: Leo * Contributing to Springer book - Roland shared more information with those involved; no other news * Unanswered questions on the mailing list - Roland will respond to the user having issues on Macs and Expanse * Zach asked: was the toolkit compiled on arm64 CPUs? Yes, you should be able to compile it on Raspberry Pis. Zach is trying to compile on his phone. * A user had a question about the ET no longer working on his machine, but the issue could not be resolved. He will join the meeting again next week so we can further discuss the issues they are having. * Open tickets --- * Tickets ready for review - Only 4 remain! - Work has progressing on improving McLachlin - No more progress to report Next chair: Leo Next minutes: Roland Cheers, Leo ------ Leonardo R. Werneck, Ph.D. Postdoctoral researcher Office EP 314 | Department of Physics | University of Idaho 875 Perimeter Dr. MS 0903 Moscow, ID 83844-0903, USA leonardo at uidaho.edu https://leowerneck.github.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From scupp1 at my.apsu.edu Thu Nov 2 16:35:53 2023 From: scupp1 at my.apsu.edu (Cupp, Samuel D.) Date: Thu, 2 Nov 2023 21:35:53 +0000 Subject: [Users] meeting minutes for 2023-10-19 In-Reply-To: References: Message-ID: Hi Gabriele, I've been experimenting with this, and I've reproduced this issue on a different machine. In my case, it runs with 1 OMP thread but has the segfault with 2. Can you run that test parfile (repos/GRHayLET/GRHayLHDX/test/Balsara0.par) without OMP? If this is the source, it will help narrow down the problem. I can run the test with multiple threads on my local machine though, so I'm not sure why OMP only causes a segfault sometimes. Samuel Cupp Postdoctoral Researcher Department of Physics University of Idaho ________________________________ From: Gabriele Bozzola Sent: Sunday, October 29, 2023 6:16 PM To: Cupp, Samuel D. Cc: Steven R. Brandt ; users at einsteintoolkit.org Subject: Re: [Users] meeting minutes for 2023-10-19 Hi Sam, I verified that the testsuite passes if I remove the GRHayL thorns. Other than that, ET seems to work fine. Attached is the cfg file I used to compile ET on Anvil. Best, Gabriele On Thu, Oct 26, 2023 at 12:45?PM Cupp, Samuel D. > wrote: Hi Gabriele, We discussed this in the call this morning, and there's a few things we can try. First, it would be helpful if you created a ticket so we can track progress on the issue. This is especially true since the testsuite shouldn't hang if a test fails. The expected behavior would be for it to continue with testing, but for some reason it didn't. Also, it might help to remove GRHayLHDX from the thornlist, recompile, and see if that is the only test failing. Knowing if this is specific to the thorn or a broader issue would help diagnose the source of the problem. Samuel Cupp Postdoctoral Researcher Department of Physics University of Idaho ________________________________ From: Gabriele Bozzola > Sent: Tuesday, October 24, 2023 1:27 PM To: Cupp, Samuel D. > Cc: Steven R. Brandt >; users at einsteintoolkit.org > Subject: Re: [Users] meeting minutes for 2023-10-19 Hi Sam, This is just CPU. The .out for the entire testsuite was attached to my first email. Best, Gabriele On Tue, Oct 24, 2023 at 12:14?PM Cupp, Samuel D. > wrote: Do you know if any other CarpetX tests fail? Also, is this using gpus or cpus? Samuel Cupp Postdoctoral Researcher Department of Physics University of Idaho ________________________________ From: Gabriele Bozzola > Sent: Tuesday, October 24, 2023 10:07 AM To: Cupp, Samuel D. > Cc: Steven R. Brandt >; users at einsteintoolkit.org > Subject: Re: [Users] meeting minutes for 2023-10-19 Hi Sam, I pulled the latest version. Tests are not failing anymore, but looking at the .out, it seems that the Balsara0 test fails and stalls execution of the entire testsuite. I am attaching the .out for the test. Best, Gabriele On Fri, Oct 20, 2023 at 2:32?PM Cupp, Samuel D. > wrote: Hi Gabriele, It looks like some of the failures are in GRHayLHD. I've been having trouble getting consistent output with nproc>1. The data doesn't change, it just gets rearranged in the datafile. I made changes to the tests this week, so could you rerun the GRHayLHD tests and tell me if they fail? If they do, I'll change the tests so that they only run for nproc=1. I don't know why it would take that long to run, however. Nothing in the ET CI suggests it should take that long, best I can tell. Do you have an idea of which test is taking so long? Samuel Cupp Postdoctoral Researcher Department of Physics University of Idaho ________________________________ From: Users > on behalf of Gabriele Bozzola > Sent: Thursday, October 19, 2023 5:46 PM To: Steven R. Brandt > Cc: users at einsteintoolkit.org > Subject: Re: [Users] meeting minutes for 2023-10-19 Hello, Is there a tested configuration for anvil? I compiled it one last weekend and ran the tests with the master branch. I found a few failures in the MPI runs, and the test suite does not complete even with a walltime of 6 hours. I am attaching the output. Best, Gabriele On Thu, Oct 19, 2023 at 7:36?AM Steven R. Brandt > wrote: Present: Steve, Peter, Sam, Zach, Leo Release Gallery Examples - TOV is Peter - BBH is Steve - Roland might have students for the other three? Tests - Need to be run - Clusters: Stampede2 isn't listed, and Delta and Anvil are added. - Release name: Lise Meitner https://en.wikipedia.org/wiki/Lise_Meitner - Autogenerated codes need to be regenerated, Leo will do it Mailing list moderation - Remind Roland to send Peter the password Unanswered question on the mailing list - Need answer for Enzo. Roland was going to answer? - Ticket 2749: Leo says he fixed it. - Ticket 2647: One of Zach's students is looking at that in Grail (sp) - Ticket 2609: Steve thinks he approved PR for Roland _______________________________________________ Users mailing list Users at einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bozzola.gabriele at gmail.com Sun Nov 5 11:28:09 2023 From: bozzola.gabriele at gmail.com (Gabriele Bozzola) Date: Sun, 5 Nov 2023 09:28:09 -0800 Subject: [Users] meeting minutes for 2023-10-19 In-Reply-To: References: Message-ID: Hi Sam, I can confirm that if I set OMP_NUM_TRHEADS=1 the test passes. Best, Gabriele On Thu, Nov 2, 2023 at 2:35?PM Cupp, Samuel D. wrote: > Hi Gabriele, > I've been experimenting with this, and I've reproduced this issue on a > different machine. In my case, it runs with 1 OMP thread but has the > segfault with 2. Can you run that test parfile > (repos/GRHayLET/GRHayLHDX/test/Balsara0.par) without OMP? If this is the > source, it will help narrow down the problem. I can run the test with > multiple threads on my local machine though, so I'm not sure why OMP only > causes a segfault sometimes. > > Samuel Cupp > Postdoctoral Researcher > Department of Physics > University of Idaho > ------------------------------ > *From:* Gabriele Bozzola > *Sent:* Sunday, October 29, 2023 6:16 PM > *To:* Cupp, Samuel D. > *Cc:* Steven R. Brandt ; users at einsteintoolkit.org < > users at einsteintoolkit.org> > *Subject:* Re: [Users] meeting minutes for 2023-10-19 > > Hi Sam, > > I verified that the testsuite passes if I remove the GRHayL thorns. > Other than that, ET seems to work fine. > > Attached is the cfg file I used to compile ET on Anvil. > > Best, > Gabriele > > On Thu, Oct 26, 2023 at 12:45?PM Cupp, Samuel D. > wrote: > > Hi Gabriele, > We discussed this in the call this morning, and there's a few things we > can try. First, it would be helpful if you created a ticket so we can track > progress on the issue. This is especially true since the testsuite > shouldn't hang if a test fails. The expected behavior would be for it to > continue with testing, but for some reason it didn't. Also, it might help > to remove GRHayLHDX from the thornlist, recompile, and see if that is the > only test failing. Knowing if this is specific to the thorn or a broader > issue would help diagnose the source of the problem. > > Samuel Cupp > Postdoctoral Researcher > Department of Physics > University of Idaho > ------------------------------ > *From:* Gabriele Bozzola > *Sent:* Tuesday, October 24, 2023 1:27 PM > *To:* Cupp, Samuel D. > *Cc:* Steven R. Brandt ; users at einsteintoolkit.org < > users at einsteintoolkit.org> > *Subject:* Re: [Users] meeting minutes for 2023-10-19 > > Hi Sam, > > This is just CPU. The .out for the entire testsuite was attached to my > first email. > > Best, > Gabriele > > > > On Tue, Oct 24, 2023 at 12:14?PM Cupp, Samuel D. > wrote: > > Do you know if any other CarpetX tests fail? Also, is this using gpus or > cpus? > > Samuel Cupp > Postdoctoral Researcher > Department of Physics > University of Idaho > ------------------------------ > *From:* Gabriele Bozzola > *Sent:* Tuesday, October 24, 2023 10:07 AM > *To:* Cupp, Samuel D. > *Cc:* Steven R. Brandt ; users at einsteintoolkit.org < > users at einsteintoolkit.org> > *Subject:* Re: [Users] meeting minutes for 2023-10-19 > > Hi Sam, > > I pulled the latest version. Tests are not failing anymore, but looking at > the .out, it seems that the Balsara0 test fails and stalls execution of the > entire testsuite. > > I am attaching the .out for the test. > > Best, > Gabriele > > On Fri, Oct 20, 2023 at 2:32?PM Cupp, Samuel D. > wrote: > > Hi Gabriele, > It looks like some of the failures are in GRHayLHD. I've been having > trouble getting consistent output with nproc>1. The data doesn't change, it > just gets rearranged in the datafile. I made changes to the tests this > week, so could you rerun the GRHayLHD tests and tell me if they fail? If > they do, I'll change the tests so that they only run for nproc=1. > > I don't know why it would take that long to run, however. Nothing in the > ET CI suggests it should take that long, best I can tell. Do you have an > idea of which test is taking so long? > > Samuel Cupp > Postdoctoral Researcher > Department of Physics > University of Idaho > ------------------------------ > *From:* Users on behalf of Gabriele > Bozzola > *Sent:* Thursday, October 19, 2023 5:46 PM > *To:* Steven R. Brandt > *Cc:* users at einsteintoolkit.org > *Subject:* Re: [Users] meeting minutes for 2023-10-19 > > Hello, > > Is there a tested configuration for anvil? > > I compiled it one last weekend and ran the tests with the master branch. I > found a few failures in the > MPI runs, and the test suite does not complete even with a walltime of 6 > hours. > > I am attaching the output. > > Best, > Gabriele > > On Thu, Oct 19, 2023 at 7:36?AM Steven R. Brandt > wrote: > > Present: Steve, Peter, Sam, Zach, Leo > > Release > Gallery Examples > - TOV is Peter > - BBH is Steve > - Roland might have students for the other three? > Tests > - Need to be run > - Clusters: > Stampede2 isn't listed, and Delta and Anvil are added. > - Release name: Lise Meitner > https://en.wikipedia.org/wiki/Lise_Meitner > - Autogenerated codes need to be regenerated, Leo will do it > > Mailing list moderation > - Remind Roland to send Peter the password > > Unanswered question on the mailing list > - Need answer for Enzo. Roland was going to answer? > - Ticket 2749: Leo says he fixed it. > - Ticket 2647: One of Zach's students is looking at that in Grail (sp) > - Ticket 2609: Steve thinks he approved PR for Roland > > _______________________________________________ > Users mailing list > Users at einsteintoolkit.org > http://lists.einsteintoolkit.org/mailman/listinfo/users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbrandt at cct.lsu.edu Mon Nov 6 12:36:27 2023 From: sbrandt at cct.lsu.edu (Steven Brandt) Date: Mon, 6 Nov 2023 12:36:27 -0600 Subject: [Users] meeting minutes for 2023-10-19 In-Reply-To: References: Message-ID: <30c7f40d-c8af-4c8a-94fa-28518c2fb0c6@cct.lsu.edu> I think the gallery examples differs from previous weeks? I think I was trading BBH with some other test? --Steve On 10/19/2023 9:35 AM, Steven R. Brandt wrote: > Present: Steve, Peter, Sam, Zach, Leo > > Release > ??? Gallery Examples > ??? - TOV is Peter > ??? - BBH is Steve > ??? - Roland might have students for the other three? > ??? Tests > ??? - Need to be run > ??? - Clusters: > ??????? Stampede2 isn't listed, and Delta and Anvil are added. > ??? - Release name: Lise Meitner > https://en.wikipedia.org/wiki/Lise_Meitner > ??? - Autogenerated codes need to be regenerated, Leo will do it > > Mailing list moderation > ??? - Remind Roland to send Peter the password > > Unanswered question on the mailing list > ??? - Need answer for Enzo. Roland was going to answer? > ??? - Ticket 2749: Leo says he fixed it. > ??? - Ticket 2647: One of Zach's students is looking at that in Grail > (sp) > ??? - Ticket 2609: Steve thinks he approved PR for Roland > > _______________________________________________ > Users mailing list > Users at einsteintoolkit.org > http://lists.einsteintoolkit.org/mailman/listinfo/users From scupp1 at my.apsu.edu Mon Nov 6 12:50:05 2023 From: scupp1 at my.apsu.edu (Cupp, Samuel D.) Date: Mon, 6 Nov 2023 18:50:05 +0000 Subject: [Users] meeting minutes for 2023-10-19 In-Reply-To: <30c7f40d-c8af-4c8a-94fa-28518c2fb0c6@cct.lsu.edu> References: <30c7f40d-c8af-4c8a-94fa-28518c2fb0c6@cct.lsu.edu> Message-ID: Hi Steve, These are the minutes for an older meeting, so they hadn't switched yet. You are currently assigned the BNS gallery example. Samuel Cupp Postdoctoral Researcher Department of Physics University of Idaho ________________________________ From: Users on behalf of Steven Brandt Sent: Monday, November 6, 2023 10:36 AM To: users at einsteintoolkit.org Subject: Re: [Users] meeting minutes for 2023-10-19 I think the gallery examples differs from previous weeks? I think I was trading BBH with some other test? --Steve On 10/19/2023 9:35 AM, Steven R. Brandt wrote: > Present: Steve, Peter, Sam, Zach, Leo > > Release > Gallery Examples > - TOV is Peter > - BBH is Steve > - Roland might have students for the other three? > Tests > - Need to be run > - Clusters: > Stampede2 isn't listed, and Delta and Anvil are added. > - Release name: Lise Meitner > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FLise_Meitner&data=05%7C01%7Cscupp1%40my.apsu.edu%7C4b812167a1ed418733ee08dbdef75282%7Cfe42fdbd8df8483a9700ff2693323482%7C0%7C0%7C638348926065507796%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xVPy8NfSjg9SgjnY2wu6LigGsJuASOR5uEtVrHD5sa0%3D&reserved=0 > - Autogenerated codes need to be regenerated, Leo will do it > > Mailing list moderation > - Remind Roland to send Peter the password > > Unanswered question on the mailing list > - Need answer for Enzo. Roland was going to answer? > - Ticket 2749: Leo says he fixed it. > - Ticket 2647: One of Zach's students is looking at that in Grail > (sp) > - Ticket 2609: Steve thinks he approved PR for Roland > > _______________________________________________ > Users mailing list > Users at einsteintoolkit.org > https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.einsteintoolkit.org%2Fmailman%2Flistinfo%2Fusers&data=05%7C01%7Cscupp1%40my.apsu.edu%7C4b812167a1ed418733ee08dbdef75282%7Cfe42fdbd8df8483a9700ff2693323482%7C0%7C0%7C638348926065507796%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WsfyXWcVGjvXgQ8a4qsrdhDyGST0KKWPD5CUe3jxMak%3D&reserved=0 _______________________________________________ Users mailing list Users at einsteintoolkit.org https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.einsteintoolkit.org%2Fmailman%2Flistinfo%2Fusers&data=05%7C01%7Cscupp1%40my.apsu.edu%7C4b812167a1ed418733ee08dbdef75282%7Cfe42fdbd8df8483a9700ff2693323482%7C0%7C0%7C638348926065507796%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WsfyXWcVGjvXgQ8a4qsrdhDyGST0KKWPD5CUe3jxMak%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhaas at illinois.edu Mon Nov 6 15:18:02 2023 From: rhaas at illinois.edu (rhaas at illinois.edu) Date: Mon, 06 Nov 2023 15:18:02 -0600 Subject: [Users] Agenda for Thursday's Meeting Message-ID: Please update the Wiki with agenda items for Thursday's meeting. Thanks! https://docs.einsteintoolkit.org/et-docs/meeting_agenda --The Maintainers From rhaas at illinois.edu Tue Nov 7 09:24:24 2023 From: rhaas at illinois.edu (Roland Haas) Date: Tue, 7 Nov 2023 09:24:24 -0600 Subject: [Users] request for assistance In-Reply-To: <1697873245479.dn4h11cwqomorhpe0u2gfqux@android.mail.163.com> References: <1697873245479.dn4h11cwqomorhpe0u2gfqux@android.mail.163.com> Message-ID: <20231107092424.0829ab90@ekohaes8> Hello Liu, > Dear Einstein Toolkit developers,

My name is Liu and I am a > student from Nagoya University. I am now learning to use ET to do > some simulations. This time I am trying to reproduce this one:
href="https://urldefense.com/v3/__https://einsteintoolkit.org/gallery/bns/index.html__;!!DZ3fjg!4xB3fkj0qHuNguLbp8TtmbSsDXd63cjq97GxVyJkFL92UgArMlDH_mZCYfVtlCbZFKzUGFxqI4-G6nddxj30tsHMBrxNkUvXzg$">https://einsteintoolkit.org/gallery/bns/index.html
which > is a simulation of binary neutron stars.

During execution, I > noticed this segmentation fault here when creating the simulation > directory structure. (The screenshot file is attached to this email) > This seems to be caused by a mismatch in memory settings. I've tried > many debugging methods, but it still doesn't work.

Could you > please help me identify the issue? I am using Ubuntu 22.04.3 and I > have already built the Einstein Toolkit and run a sample simulation > successfully. Sorry for the long delay. Your email got held up on the mailing list server since you were not subscribed to the mailing list yourself. A SEGFAULT is often caused by running out of memory. If you are trying to run a BNS simulation on a workstation or laptop (unless it is very large) then I would expect this to be the case. You can try and monitor free memory using the "top" command while the simulation starts. If there is enough memory then the next thing would be to find out which function the code is in when it fails from the backtrace and error messages that should be present in the *.err file and the backtrac.*.txt files. They also contain information on how to turn the address of the failure location into a human readable function name. If you have never done that before then you may want to send the full stdout and stderr files (*.out and *.err when using simfactory) as well as the backtrace.*.txt files (in the bns and ouput-0000 directories respectively) to the list. Possibly compressed to avoid the email being rejected due to large attachments. Please avoid sending image screenshots as they do not let one copy and paste text out of them. 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://pgp.mit.edu . -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From rhaas at illinois.edu Tue Nov 7 09:27:23 2023 From: rhaas at illinois.edu (Roland Haas) Date: Tue, 7 Nov 2023 09:27:23 -0600 Subject: [Users] Help with Cactus Tutorial (updating fuka and building toolkit) In-Reply-To: References: Message-ID: <20231107092723.01dcaee6@ekohaes8> Hello Delaney, > Warning: Could not update fuka. Could not stash local changes. Error > message was 'error: open("codes/FUKAv1_Solvers/BBH/compile"): > Permission denied > fatal: Unable to process path codes/FUKAv1_Solvers/BBH/compile > Cannot save the current worktree state This is a git error that occurs if there are local changes tot the checked out fuka repository. If you did not yourseslf make changes then something corrupted the files. > From there, I'm unable to build the toolkit, resulting in errors like: > > CST error in /home/dfarrell/Cactus/lib/sbin/CST (at 319) > -> Missing thorn WVUThorns_Diagnostics/VolumeIntegrals_vacuum > > ------------------------------------------------------ > > make[1]: *** [/home/dfarrell/Cactus/lib/make/make.configuration:213: > /home/dfarrell/Cactus/configs/sim/config-data/make.thornlist] Error 1 > make: *** [Makefile:264: sim] Error 2 Since GetComponents failed there may well be some thorns missing. On the tutorial server your fasted way to recover this is is likely to wipe your Cactus tree and start from scratch. Namely running: %%bash rm -rf ~/Cactus ~/GetComponents ~/einsteintoolkit.th in a notebook cell should remove the full Cactus tree, GetComponents and the downloaded thornlist and let you start from scratch. 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://pgp.mit.edu . -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From rhaas at illinois.edu Wed Nov 8 17:15:01 2023 From: rhaas at illinois.edu (rhaas at illinois.edu) Date: Wed, 08 Nov 2023 17:15:01 -0600 Subject: [Users] Einstein Toolkit Meeting Reminder Message-ID: Hello, Please consider joining the weekly Einstein Toolkit phone call at 9:00 am US central time on Thursdays. For details on how to connect and what agenda items are to be discussed, use the link below. https://docs.einsteintoolkit.org/et-docs/Main_Page#Weekly_Users_Call --The Maintainers From rhaas at illinois.edu Thu Nov 9 09:56:42 2023 From: rhaas at illinois.edu (Roland Haas) Date: Thu, 9 Nov 2023 09:56:42 -0600 Subject: [Users] meeting minutes for 2023-11-09 Message-ID: <20231109095642.3b763e8f@ekohaes8> Present: Roland, Peter, Steven, Leo, Sam, Zach CarpetX failure due to non-threads safe flesh ============================================= * Cactus flesh is not thread save, but is called from multi-threaded context in CarpetX * this causes a SEGFAULT, but only during PreSyncOnly mode * ticket is https://bitbucket.org/einsteintoolkit/tickets/issues/2762 * this needs to be fixed before the release ET release ========== * SGRID test has been updated and passes on CI and local machine * Sam has drafted announcement email * Collecting authors for contributing * Peter is running tests on sunrise, most ACCESS-CI machines not yet tested * Debroah Ferguson will run BBH gallery example * Roland will poke local students * Peter ran into issues with ExternalLibraries/ADIOS and ExternalLibraries/MPI not picking up the mpicc wrapper. Roland says that ExternalLibraries/MPI is a measure or last resort, and he would avoid it unless no other option is possible Springer book ============= * Sam and Leo will look into it * Steve volunteers to contribute Running ET on Arm64 =================== * Roland reports he could successfully compile on his Arm64 box at home (TV Set-top box using Debian) * two failing tests: MemSpeed (aborts due to not recognising memory layout it seems, maybe hwloc), ML_BSSN_NewRad (numerical comparison fails) BitBucket account restrictions ============================== * resolved for einsteintoolkit and cactuscode * still in existence for Simfactory, needs action by Frank Loeffler Simfactory restructuring ======================== * Zach suggests that parts of simfactory may be split of and moved into the main build system of Cactus as a configure script or option list * currently we are lacking good directions on the website on how to compile, should be close to download page * would want to streamline download and build system for new users * Zach suggests to have requirements shown from simfactory like tool Open tickets ============ * https://bitbucket.org/einsteintoolkit/tickets/issues/2757 still needs to be fixed since it makes building fail unless Python's request is present * https://bitbucket.org/einsteintoolkit/tickets/issues/2755 Roland will accepts this bug fix Next chair: Zach Next minutes: Sam 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://pgp.mit.edu . -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From hayleyjmacpherson at gmail.com Thu Nov 9 17:28:09 2023 From: hayleyjmacpherson at gmail.com (Hayley Macpherson) Date: Thu, 9 Nov 2023 13:28:09 -1000 Subject: [Users] "Spikes" in density for FLRWSolver single-mode simulation Message-ID: <23B0E650-761C-4418-A314-8C4C474610EE@gmail.com> Hi all, I?ve noticed an issue with the single-mode setting of FLRWSolver (cosmological initial data thorn) when evolving with GRHydro. This set up is three intersecting sine-waves in 3D, see the attached 1D slice for the relative density perturbation (delta = rho / rho.mean - 1) on the initial slice (first plot attached). To do cosmological simulations which are dark-matter dominated we want something as close to P=0 as possible. GRHydro does not allow this so instead we choose a pressure such that P< -------------- next part -------------- A non-text attachment was scrubbed... Name: FLRW_32_1Gpc_SM_K1em29.par Type: application/octet-stream Size: 7697 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot 2023-11-09 at 13.11.29.png Type: image/png Size: 28991 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot 2023-11-09 at 13.11.52.png Type: image/png Size: 29324 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot 2023-11-09 at 13.17.32.png Type: image/png Size: 36297 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhaas at illinois.edu Mon Nov 13 15:18:01 2023 From: rhaas at illinois.edu (rhaas at illinois.edu) Date: Mon, 13 Nov 2023 15:18:01 -0600 Subject: [Users] Agenda for Thursday's Meeting Message-ID: Please update the Wiki with agenda items for Thursday's meeting. Thanks! https://docs.einsteintoolkit.org/et-docs/meeting_agenda --The Maintainers From rhaas at illinois.edu Wed Nov 15 17:15:01 2023 From: rhaas at illinois.edu (rhaas at illinois.edu) Date: Wed, 15 Nov 2023 17:15:01 -0600 Subject: [Users] Einstein Toolkit Meeting Reminder Message-ID: Hello, Please consider joining the weekly Einstein Toolkit phone call at 9:00 am US central time on Thursdays. For details on how to connect and what agenda items are to be discussed, use the link below. https://docs.einsteintoolkit.org/et-docs/Main_Page#Weekly_Users_Call --The Maintainers From scupp1 at my.apsu.edu Thu Nov 16 14:06:44 2023 From: scupp1 at my.apsu.edu (Cupp, Samuel D.) Date: Thu, 16 Nov 2023 20:06:44 +0000 Subject: [Users] meeting minutes for 2023-11-16 Message-ID: present: Sam Roland Zach Leo ET_2023_11 release ongoing NSIMD issue: downloading sleef fails on some clusters proposed solution: patch python code and include sleef file in tarball needs to be done before release Testing: Roland can also do testing on supermuc, summit, expanse Gallery examples: Deborah agreed BBH, hasn't started yet scalar wave, poisson equation examples aren't claimed yet; Roland will try to find students to run them draft release announcement done, needs to be sent to maintainers, contributors no update for springer book should look for more contributors hope to return to this topic once proposals are submitted and people have more time only remaining issue with the new bitbucket restriction on the number of users is with simfactory (owned by Frank Loffler) Roland will try to call him at his office to talk about this Unanswered emails: "Spikes" in density for FLRWSolver single-mode simulation seeing spikes in density with GRHydro; doesn't recall seeing this in 2017 ask if an older release version of the ET resolves the issue, since that would narrow the search for the problem Sam will send a response Tickets for review #2762 PR to fix issue; question about what is the best thing to do given the closeness to the release consensus to accept Steve's change; will be merged in this week #2763 want to be able to call CarpetX interpolator through standard Cactus Framework handles future-proofs this code against any changes involving the Cactus-CarpetX connective tissue Other topics larger token limits in chatgpt-4 could fix the issue we had with auto-generating minutes Next meeting in two weeks (2023-11-30) chair: Steve minute taker: Leo Samuel Cupp Postdoctoral Researcher Department of Physics University of Idaho -------------- next part -------------- An HTML attachment was scrubbed... URL: From scupp1 at my.apsu.edu Thu Nov 16 14:12:02 2023 From: scupp1 at my.apsu.edu (Cupp, Samuel D.) Date: Thu, 16 Nov 2023 20:12:02 +0000 Subject: [Users] "Spikes" in density for FLRWSolver single-mode simulation In-Reply-To: <23B0E650-761C-4418-A314-8C4C474610EE@gmail.com> References: <23B0E650-761C-4418-A314-8C4C474610EE@gmail.com> Message-ID: Hello Hayley, Thanks for letting us know about this issue. Since this was not a problem in earlier versions of the Einstein Toolkit, could you check out older ET versions and find when this change appears? It would be helpful if we knew that this was introduced in the changes from ET_2020_05 to RT_2020_11, for example. Then, we can focus on how the thorns changed between those two releases. Also, are you using the FRLWSolver in the Toolkit, or a newer in-house version? Samuel Cupp Postdoctoral Researcher Department of Physics University of Idaho ________________________________ From: Users on behalf of Hayley Macpherson Sent: Thursday, November 9, 2023 3:28 PM To: users at einsteintoolkit.org Subject: [Users] "Spikes" in density for FLRWSolver single-mode simulation Hi all, I?ve noticed an issue with the single-mode setting of FLRWSolver (cosmological initial data thorn) when evolving with GRHydro. This set up is three intersecting sine-waves in 3D, see the attached 1D slice for the relative density perturbation (delta = rho / rho.mean - 1) on the initial slice (first plot attached). To do cosmological simulations which are dark-matter dominated we want something as close to P=0 as possible. GRHydro does not allow this so instead we choose a pressure such that P< Pronouns: she/her/hers Office: ERC 479 Kavli Institute for Cosmological Physics Eckhardt Research Center 5640 South Ellis Avenue Chicago, IL, 60637 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot 2023-11-09 at 13.11.29.png Type: image/png Size: 28991 bytes Desc: Screenshot 2023-11-09 at 13.11.29.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot 2023-11-09 at 13.11.52.png Type: image/png Size: 29324 bytes Desc: Screenshot 2023-11-09 at 13.11.52.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot 2023-11-09 at 13.17.32.png Type: image/png Size: 36297 bytes Desc: Screenshot 2023-11-09 at 13.17.32.png URL: From physicsbeany at gmail.com Thu Nov 16 14:23:55 2023 From: physicsbeany at gmail.com (Bernard Kelly) Date: Thu, 16 Nov 2023 15:23:55 -0500 Subject: [Users] ETK config-stage failure with Macports gcc -- C+11 range-based for statments? Message-ID: Hi. I tried making a new configuration on my Macbook (MacOS Ventura, 13.6.2) after a gap of several months, and it's now failing the "make sim-config" step with a complaint about the C++ compiler not being C++11-compliant -- end of the make config step screen output is below. I'm using the latest available Macports-supplied GNU compilers (gcc-mp-13, g++-mp-13, etc.), with the following C & C++ options: ---------- compiler flags ----------- CPP = /opt/local/bin/cpp-mp-13 CC = /opt/local/bin/gcc-mp-13 CXX = /opt/local/bin/g++-mp-13 CPPFLAGS = CFLAGS = -std=c99 CXXFLAGS = -std=c++14 C_LINE_DIRECTIVES = yes OPTIMISE = yes CPP_OPTIMISE_FLAGS = # -DCARPET_OPTIMISE -DNDEBUG C_OPTIMISE_FLAGS = -O2 -march=native CXX_OPTIMISE_FLAGS = -O2 -march=native OPENMP = yes CPP_OPENMP_FLAGS = -fopenmp C_OPENMP_FLAGS = -fopenmp CXX_OPENMP_FLAGS = -fopenmp WARN = yes CPP_WARN_FLAGS = -Wall C_WARN_FLAGS = -Wall CXX_WARN_FLAGS = -Wall ---------- end of compiler flags ----------- Can anyone suggest what's up? The error says that the C++ compiler is failing to do range-based for statements, but I can compile & run a simple program with a range-based for statement, so this seems unlikely. I'm currently on ET_2023-05, but have this problem with ET_2022_11 as well, and with gcc-mp-12. Thanks, Bernard --------------- last bit of screen output --------- checking if compiler has broken omp collapse... no checking for getopt_long_only... yes checking for working const... yes checking for C inline... inline checking for C static inline... static inline checking for C restrict... restrict checking for C++ restrict... __restrict__ checking for C++ copysign... std::copysign checking for C++ fpclassify... std::fpclassify checking for C++ isfinite... std::isfinite checking for C++ isinf... std::isinf checking for C++ isnan... std::isnan checking for C++ isnormal... std::isnormal checking for C++ signbit... std::signbit checking for C _Pragma... yes checking for C function __attribute__((__const__))... yes checking for C++ function __attribute__((__const__))... yes checking for C++ member function __attribute__((__const__))... yes checking for C function __attribute__((__pure__))... yes checking for C++ function __attribute__((__pure__))... yes checking for C++ member function __attribute__((__pure__))... yes checking for C data __attribute__((__common__))... yes checking for C+ data __attribute__((__common__))... yes checking for C function __attribute__((__noinline__))... yes checking for C++ function __attribute__((__noinline__))... yes checking for C++ member function __attribute__((__noinline__))... yes checking for C function __attribute__((__always_inline__))... yes checking for C++ function __attribute__((__always_inline__))... yes checking for C++ member function __attribute__((__always_inline__))... yes checking for C __attribute__((__unused__))... yes checking for C++ __attribute__((__unused__))... yes checking for C __attribute__((__aligned__(...)))... yes checking for C++ __attribute__((__aligned__(...)))... yes checking for C __attribute__((__cold__))... yes checking for C++ __attribute__((__cold__))... yes checking for C __attribute__((__hot__))... yes checking for C++ __attribute__((__hot__))... yes checking for C __attribute__((__format__(printf, 1, 2)))... yes checking for C++ __attribute__((__format__(printf, 1, 2)))... yes checking for C __attribute__((__noreturn__))... yes checking for C++ __attribute__((__noreturn__))... yes checking for C __attribute__((__nonnull__))... yes checking for C++ __attribute__((__nonnull__))... yes checking for C __attribute__((__returns_nonnull__))... yes checking for C++ __attribute__((__returns_nonnull__))... yes checking for C __builtin_expect... yes checking for C++ __builtin_expect... yes checking for C __builtin_trap... yes checking for C++ __builtin_trap... yes checking for C __builtin_unreachable... no checking for C++ __builtin_unreachable... no checking for C __builtin_assume_aligned... yes checking for C++ __builtin_assume_aligned... yes checking for C++ static_assert... yes checking for C++ auto specifier... yes checking for C++ lambda expressions... yes checking for C++ range-based for statements... no Cactus requires a C++11 compiler -- check your C++ compiler and C++ compiler flags Error reconfiguring sim-config make: *** [sim-config] Error 2 -- ------------------------------------------------------------------ Bernard Kelly -- CRESST Assistant Research Scientist, NASA/GSFC Gravitational Astrophysics Laboratory --- Code 663 Phone: +1 (301) 286-7243 *** Fax: +1 (301) 286-2226 Web: http://science.gsfc.nasa.gov/sed/bio/bernard.j.kelly ORCID: orcid.org/0000-0002-3326-4454 ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhaas at illinois.edu Thu Nov 16 14:35:16 2023 From: rhaas at illinois.edu (Roland Haas) Date: Thu, 16 Nov 2023 14:35:16 -0600 Subject: [Users] ETK config-stage failure with Macports gcc -- C+11 range-based for statments? In-Reply-To: References: Message-ID: <20231116143516.432af74b@ekohaes8> Hello Bernard, Odd. You have the correct CXXFLAGS and the compiler seems new enough. Could you attach the config.log file that the run produced (should be mentioned near the end with full path). Since this has been an issue in the past: there are no environment variables CXX or CXXFLAGS defined in you shell (env | grep CXX finds nothing)? Yours, Roland > Hi. I tried making a new configuration on my Macbook (MacOS Ventura, > 13.6.2) after a gap of several months, and it's now failing the "make > sim-config" step with a complaint about the C++ compiler not being > C++11-compliant -- end of the make config step screen output is below. > > I'm using the latest available Macports-supplied GNU compilers > (gcc-mp-13, g++-mp-13, etc.), with the following C & C++ options: > > ---------- compiler flags ----------- > CPP = /opt/local/bin/cpp-mp-13 > CC = /opt/local/bin/gcc-mp-13 > CXX = /opt/local/bin/g++-mp-13 > CPPFLAGS = > CFLAGS = -std=c99 > CXXFLAGS = -std=c++14 > C_LINE_DIRECTIVES = yes > OPTIMISE = yes > CPP_OPTIMISE_FLAGS = # -DCARPET_OPTIMISE -DNDEBUG > C_OPTIMISE_FLAGS = -O2 -march=native > CXX_OPTIMISE_FLAGS = -O2 -march=native > OPENMP = yes > CPP_OPENMP_FLAGS = -fopenmp > C_OPENMP_FLAGS = -fopenmp > CXX_OPENMP_FLAGS = -fopenmp > WARN = yes > CPP_WARN_FLAGS = -Wall > C_WARN_FLAGS = -Wall > CXX_WARN_FLAGS = -Wall > ---------- end of compiler flags ----------- > > Can anyone suggest what's up? The error says that the C++ compiler is > failing to do range-based for statements, but I can compile & run a simple > program with a range-based for statement, so this seems unlikely. > > I'm currently on ET_2023-05, but have this problem with ET_2022_11 as well, > and with gcc-mp-12. > > Thanks, Bernard > > --------------- last bit of screen output --------- > checking if compiler has broken omp collapse... no > checking for getopt_long_only... yes > checking for working const... yes > checking for C inline... inline > checking for C static inline... static inline > checking for C restrict... restrict > checking for C++ restrict... __restrict__ > checking for C++ copysign... std::copysign > checking for C++ fpclassify... std::fpclassify > checking for C++ isfinite... std::isfinite > checking for C++ isinf... std::isinf > checking for C++ isnan... std::isnan > checking for C++ isnormal... std::isnormal > checking for C++ signbit... std::signbit > checking for C _Pragma... yes > checking for C function __attribute__((__const__))... yes > checking for C++ function __attribute__((__const__))... yes > checking for C++ member function __attribute__((__const__))... yes > checking for C function __attribute__((__pure__))... yes > checking for C++ function __attribute__((__pure__))... yes > checking for C++ member function __attribute__((__pure__))... yes > checking for C data __attribute__((__common__))... yes > checking for C+ data __attribute__((__common__))... yes > checking for C function __attribute__((__noinline__))... yes > checking for C++ function __attribute__((__noinline__))... yes > checking for C++ member function __attribute__((__noinline__))... yes > checking for C function __attribute__((__always_inline__))... yes > checking for C++ function __attribute__((__always_inline__))... yes > checking for C++ member function __attribute__((__always_inline__))... yes > checking for C __attribute__((__unused__))... yes > checking for C++ __attribute__((__unused__))... yes > checking for C __attribute__((__aligned__(...)))... yes > checking for C++ __attribute__((__aligned__(...)))... yes > checking for C __attribute__((__cold__))... yes > checking for C++ __attribute__((__cold__))... yes > checking for C __attribute__((__hot__))... yes > checking for C++ __attribute__((__hot__))... yes > checking for C __attribute__((__format__(printf, 1, 2)))... yes > checking for C++ __attribute__((__format__(printf, 1, 2)))... yes > checking for C __attribute__((__noreturn__))... yes > checking for C++ __attribute__((__noreturn__))... yes > checking for C __attribute__((__nonnull__))... yes > checking for C++ __attribute__((__nonnull__))... yes > checking for C __attribute__((__returns_nonnull__))... yes > checking for C++ __attribute__((__returns_nonnull__))... yes > checking for C __builtin_expect... yes > checking for C++ __builtin_expect... yes > checking for C __builtin_trap... yes > checking for C++ __builtin_trap... yes > checking for C __builtin_unreachable... no > checking for C++ __builtin_unreachable... no > checking for C __builtin_assume_aligned... yes > checking for C++ __builtin_assume_aligned... yes > checking for C++ static_assert... yes > checking for C++ auto specifier... yes > checking for C++ lambda expressions... yes > checking for C++ range-based for statements... no > Cactus requires a C++11 compiler -- check your C++ compiler and C++ > compiler flags > > Error reconfiguring sim-config > make: *** [sim-config] Error 2 > 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://pgp.mit.edu . -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From physicsbeany at gmail.com Thu Nov 16 14:49:11 2023 From: physicsbeany at gmail.com (Bernard Kelly) Date: Thu, 16 Nov 2023 15:49:11 -0500 Subject: [Users] ETK config-stage failure with Macports gcc -- C+11 range-based for statments? In-Reply-To: <20231116143516.432af74b@ekohaes8> References: <20231116143516.432af74b@ekohaes8> Message-ID: Hi Roland. I'm attaching the config.log file here (I had to hunt it down in configs/sim/config-data, since the configure step failed before it could point to anything). Since the logfile gives a small C++ program that failed to compile, I copied it to testGPP2.cpp, and tried compiling it myself; and yes, it failed. Errors from this are short enough to quote here: ------------ gs66-shannon:Cactus_ET_2023_05 bjkelly1$ /opt/local/bin/g++-mp-13 testGPP2.cpp ld: warning: ignoring duplicate libraries: '-lgcc' 0 0x1049cb648 __assert_rtn + 72 1 0x1048fffac ld::AtomPlacement::findAtom(unsigned char, unsigned long long, ld::AtomPlacement::AtomLoc const*&, long long&) const + 1204 2 0x104915924 ld::InputFiles::SliceParser::parseObjectFile(mach_o::Header const*) const + 15164 3 0x104922e30 ld::InputFiles::parseAllFiles(void (ld::AtomFile const*) block_pointer)::$_7::operator()(unsigned long, ld::FileInfo const&) const + 420 4 0x1a0274440 _dispatch_client_callout2 + 20 5 0x1a0289544 _dispatch_apply_invoke_and_wait + 224 6 0x1a028884c _dispatch_apply_with_attr_f + 1180 7 0x1a0288a38 dispatch_apply + 96 8 0x10499d3b8 ld::AtomFileConsolidator::parseFiles(bool) + 292 9 0x10493e170 main + 9048 ld: Assertion failed: (resultIndex < sectData.atoms.size()), function findAtom, file Relocations.cpp, line 1336. collect2: error: ld returned 1 exit status ------------ As for your other question, no, there's no environment variable set with a name containing CXX. Thanks, Bernard On Thu, Nov 16, 2023 at 3:35?PM Roland Haas wrote: > Hello Bernard, > > Odd. You have the correct CXXFLAGS and the compiler seems new enough. > > Could you attach the config.log file that the run produced (should be > mentioned near the end with full path). > > Since this has been an issue in the past: there are no environment > variables CXX or CXXFLAGS defined in you shell (env | grep CXX finds > nothing)? > > Yours, > Roland > > > Hi. I tried making a new configuration on my Macbook (MacOS Ventura, > > 13.6.2) after a gap of several months, and it's now failing the "make > > sim-config" step with a complaint about the C++ compiler not being > > C++11-compliant -- end of the make config step screen output is below. > > > > I'm using the latest available Macports-supplied GNU compilers > > (gcc-mp-13, g++-mp-13, etc.), with the following C & C++ options: > > > > ---------- compiler flags ----------- > > CPP = /opt/local/bin/cpp-mp-13 > > CC = /opt/local/bin/gcc-mp-13 > > CXX = /opt/local/bin/g++-mp-13 > > CPPFLAGS = > > CFLAGS = -std=c99 > > CXXFLAGS = -std=c++14 > > C_LINE_DIRECTIVES = yes > > OPTIMISE = yes > > CPP_OPTIMISE_FLAGS = # -DCARPET_OPTIMISE -DNDEBUG > > C_OPTIMISE_FLAGS = -O2 -march=native > > CXX_OPTIMISE_FLAGS = -O2 -march=native > > OPENMP = yes > > CPP_OPENMP_FLAGS = -fopenmp > > C_OPENMP_FLAGS = -fopenmp > > CXX_OPENMP_FLAGS = -fopenmp > > WARN = yes > > CPP_WARN_FLAGS = -Wall > > C_WARN_FLAGS = -Wall > > CXX_WARN_FLAGS = -Wall > > ---------- end of compiler flags ----------- > > > > Can anyone suggest what's up? The error says that the C++ compiler is > > failing to do range-based for statements, but I can compile & run a > simple > > program with a range-based for statement, so this seems unlikely. > > > > I'm currently on ET_2023-05, but have this problem with ET_2022_11 as > well, > > and with gcc-mp-12. > > > > Thanks, Bernard > > > > --------------- last bit of screen output --------- > > checking if compiler has broken omp collapse... no > > checking for getopt_long_only... yes > > checking for working const... yes > > checking for C inline... inline > > checking for C static inline... static inline > > checking for C restrict... restrict > > checking for C++ restrict... __restrict__ > > checking for C++ copysign... std::copysign > > checking for C++ fpclassify... std::fpclassify > > checking for C++ isfinite... std::isfinite > > checking for C++ isinf... std::isinf > > checking for C++ isnan... std::isnan > > checking for C++ isnormal... std::isnormal > > checking for C++ signbit... std::signbit > > checking for C _Pragma... yes > > checking for C function __attribute__((__const__))... yes > > checking for C++ function __attribute__((__const__))... yes > > checking for C++ member function __attribute__((__const__))... yes > > checking for C function __attribute__((__pure__))... yes > > checking for C++ function __attribute__((__pure__))... yes > > checking for C++ member function __attribute__((__pure__))... yes > > checking for C data __attribute__((__common__))... yes > > checking for C+ data __attribute__((__common__))... yes > > checking for C function __attribute__((__noinline__))... yes > > checking for C++ function __attribute__((__noinline__))... yes > > checking for C++ member function __attribute__((__noinline__))... yes > > checking for C function __attribute__((__always_inline__))... yes > > checking for C++ function __attribute__((__always_inline__))... yes > > checking for C++ member function __attribute__((__always_inline__))... > yes > > checking for C __attribute__((__unused__))... yes > > checking for C++ __attribute__((__unused__))... yes > > checking for C __attribute__((__aligned__(...)))... yes > > checking for C++ __attribute__((__aligned__(...)))... yes > > checking for C __attribute__((__cold__))... yes > > checking for C++ __attribute__((__cold__))... yes > > checking for C __attribute__((__hot__))... yes > > checking for C++ __attribute__((__hot__))... yes > > checking for C __attribute__((__format__(printf, 1, 2)))... yes > > checking for C++ __attribute__((__format__(printf, 1, 2)))... yes > > checking for C __attribute__((__noreturn__))... yes > > checking for C++ __attribute__((__noreturn__))... yes > > checking for C __attribute__((__nonnull__))... yes > > checking for C++ __attribute__((__nonnull__))... yes > > checking for C __attribute__((__returns_nonnull__))... yes > > checking for C++ __attribute__((__returns_nonnull__))... yes > > checking for C __builtin_expect... yes > > checking for C++ __builtin_expect... yes > > checking for C __builtin_trap... yes > > checking for C++ __builtin_trap... yes > > checking for C __builtin_unreachable... no > > checking for C++ __builtin_unreachable... no > > checking for C __builtin_assume_aligned... yes > > checking for C++ __builtin_assume_aligned... yes > > checking for C++ static_assert... yes > > checking for C++ auto specifier... yes > > checking for C++ lambda expressions... yes > > checking for C++ range-based for statements... no > > Cactus requires a C++11 compiler -- check your C++ compiler and C++ > > compiler flags > > > > Error reconfiguring sim-config > > make: *** [sim-config] Error 2 > > > > > 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://pgp.mit.edu . > -- ------------------------------------------------------------------ Bernard Kelly -- CRESST Assistant Research Scientist, NASA/GSFC Gravitational Astrophysics Laboratory --- Code 663 Phone: +1 (301) 286-7243 *** Fax: +1 (301) 286-2226 Web: http://science.gsfc.nasa.gov/sed/bio/bernard.j.kelly ORCID: orcid.org/0000-0002-3326-4454 ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: BJK_config.log Type: application/octet-stream Size: 40821 bytes Desc: not available URL: From schnetter at gmail.com Thu Nov 16 15:41:12 2023 From: schnetter at gmail.com (Erik Schnetter) Date: Thu, 16 Nov 2023 16:41:12 -0500 Subject: [Users] ETK config-stage failure with Macports gcc -- C+11 range-based for statments? In-Reply-To: References: <20231116143516.432af74b@ekohaes8> Message-ID: Bernard Your C++ compiler is probably fine, but your linker ("ld") is not, it cannot handle GCC's output. I have a MacPorts package "ld64" installed. Maybe that would help? -erik On Thu, Nov 16, 2023 at 3:49?PM Bernard Kelly wrote: > > Hi Roland. > > I'm attaching the config.log file here (I had to hunt it down in configs/sim/config-data, since the configure step failed before it could point to anything). > > Since the logfile gives a small C++ program that failed to compile, I copied it to testGPP2.cpp, and tried compiling it myself; and yes, it failed. Errors from this are short enough to quote here: > > ------------ > gs66-shannon:Cactus_ET_2023_05 bjkelly1$ /opt/local/bin/g++-mp-13 testGPP2.cpp > ld: warning: ignoring duplicate libraries: '-lgcc' > 0 0x1049cb648 __assert_rtn + 72 > 1 0x1048fffac ld::AtomPlacement::findAtom(unsigned char, unsigned long long, ld::AtomPlacement::AtomLoc const*&, long long&) const + 1204 > 2 0x104915924 ld::InputFiles::SliceParser::parseObjectFile(mach_o::Header const*) const + 15164 > 3 0x104922e30 ld::InputFiles::parseAllFiles(void (ld::AtomFile const*) block_pointer)::$_7::operator()(unsigned long, ld::FileInfo const&) const + 420 > 4 0x1a0274440 _dispatch_client_callout2 + 20 > 5 0x1a0289544 _dispatch_apply_invoke_and_wait + 224 > 6 0x1a028884c _dispatch_apply_with_attr_f + 1180 > 7 0x1a0288a38 dispatch_apply + 96 > 8 0x10499d3b8 ld::AtomFileConsolidator::parseFiles(bool) + 292 > 9 0x10493e170 main + 9048 > ld: Assertion failed: (resultIndex < sectData.atoms.size()), function findAtom, file Relocations.cpp, line 1336. > collect2: error: ld returned 1 exit status > ------------ > > As for your other question, no, there's no environment variable set with a name containing CXX. > > Thanks, Bernard > > > On Thu, Nov 16, 2023 at 3:35?PM Roland Haas wrote: >> >> Hello Bernard, >> >> Odd. You have the correct CXXFLAGS and the compiler seems new enough. >> >> Could you attach the config.log file that the run produced (should be >> mentioned near the end with full path). >> >> Since this has been an issue in the past: there are no environment >> variables CXX or CXXFLAGS defined in you shell (env | grep CXX finds >> nothing)? >> >> Yours, >> Roland >> >> > Hi. I tried making a new configuration on my Macbook (MacOS Ventura, >> > 13.6.2) after a gap of several months, and it's now failing the "make >> > sim-config" step with a complaint about the C++ compiler not being >> > C++11-compliant -- end of the make config step screen output is below. >> > >> > I'm using the latest available Macports-supplied GNU compilers >> > (gcc-mp-13, g++-mp-13, etc.), with the following C & C++ options: >> > >> > ---------- compiler flags ----------- >> > CPP = /opt/local/bin/cpp-mp-13 >> > CC = /opt/local/bin/gcc-mp-13 >> > CXX = /opt/local/bin/g++-mp-13 >> > CPPFLAGS = >> > CFLAGS = -std=c99 >> > CXXFLAGS = -std=c++14 >> > C_LINE_DIRECTIVES = yes >> > OPTIMISE = yes >> > CPP_OPTIMISE_FLAGS = # -DCARPET_OPTIMISE -DNDEBUG >> > C_OPTIMISE_FLAGS = -O2 -march=native >> > CXX_OPTIMISE_FLAGS = -O2 -march=native >> > OPENMP = yes >> > CPP_OPENMP_FLAGS = -fopenmp >> > C_OPENMP_FLAGS = -fopenmp >> > CXX_OPENMP_FLAGS = -fopenmp >> > WARN = yes >> > CPP_WARN_FLAGS = -Wall >> > C_WARN_FLAGS = -Wall >> > CXX_WARN_FLAGS = -Wall >> > ---------- end of compiler flags ----------- >> > >> > Can anyone suggest what's up? The error says that the C++ compiler is >> > failing to do range-based for statements, but I can compile & run a simple >> > program with a range-based for statement, so this seems unlikely. >> > >> > I'm currently on ET_2023-05, but have this problem with ET_2022_11 as well, >> > and with gcc-mp-12. >> > >> > Thanks, Bernard >> > >> > --------------- last bit of screen output --------- >> > checking if compiler has broken omp collapse... no >> > checking for getopt_long_only... yes >> > checking for working const... yes >> > checking for C inline... inline >> > checking for C static inline... static inline >> > checking for C restrict... restrict >> > checking for C++ restrict... __restrict__ >> > checking for C++ copysign... std::copysign >> > checking for C++ fpclassify... std::fpclassify >> > checking for C++ isfinite... std::isfinite >> > checking for C++ isinf... std::isinf >> > checking for C++ isnan... std::isnan >> > checking for C++ isnormal... std::isnormal >> > checking for C++ signbit... std::signbit >> > checking for C _Pragma... yes >> > checking for C function __attribute__((__const__))... yes >> > checking for C++ function __attribute__((__const__))... yes >> > checking for C++ member function __attribute__((__const__))... yes >> > checking for C function __attribute__((__pure__))... yes >> > checking for C++ function __attribute__((__pure__))... yes >> > checking for C++ member function __attribute__((__pure__))... yes >> > checking for C data __attribute__((__common__))... yes >> > checking for C+ data __attribute__((__common__))... yes >> > checking for C function __attribute__((__noinline__))... yes >> > checking for C++ function __attribute__((__noinline__))... yes >> > checking for C++ member function __attribute__((__noinline__))... yes >> > checking for C function __attribute__((__always_inline__))... yes >> > checking for C++ function __attribute__((__always_inline__))... yes >> > checking for C++ member function __attribute__((__always_inline__))... yes >> > checking for C __attribute__((__unused__))... yes >> > checking for C++ __attribute__((__unused__))... yes >> > checking for C __attribute__((__aligned__(...)))... yes >> > checking for C++ __attribute__((__aligned__(...)))... yes >> > checking for C __attribute__((__cold__))... yes >> > checking for C++ __attribute__((__cold__))... yes >> > checking for C __attribute__((__hot__))... yes >> > checking for C++ __attribute__((__hot__))... yes >> > checking for C __attribute__((__format__(printf, 1, 2)))... yes >> > checking for C++ __attribute__((__format__(printf, 1, 2)))... yes >> > checking for C __attribute__((__noreturn__))... yes >> > checking for C++ __attribute__((__noreturn__))... yes >> > checking for C __attribute__((__nonnull__))... yes >> > checking for C++ __attribute__((__nonnull__))... yes >> > checking for C __attribute__((__returns_nonnull__))... yes >> > checking for C++ __attribute__((__returns_nonnull__))... yes >> > checking for C __builtin_expect... yes >> > checking for C++ __builtin_expect... yes >> > checking for C __builtin_trap... yes >> > checking for C++ __builtin_trap... yes >> > checking for C __builtin_unreachable... no >> > checking for C++ __builtin_unreachable... no >> > checking for C __builtin_assume_aligned... yes >> > checking for C++ __builtin_assume_aligned... yes >> > checking for C++ static_assert... yes >> > checking for C++ auto specifier... yes >> > checking for C++ lambda expressions... yes >> > checking for C++ range-based for statements... no >> > Cactus requires a C++11 compiler -- check your C++ compiler and C++ >> > compiler flags >> > >> > Error reconfiguring sim-config >> > make: *** [sim-config] Error 2 >> > >> >> >> 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://pgp.mit.edu . > > > > -- > ------------------------------------------------------------------ > Bernard Kelly -- CRESST Assistant Research Scientist, NASA/GSFC > Gravitational Astrophysics Laboratory --- Code 663 > > Phone: +1 (301) 286-7243 *** Fax: +1 (301) 286-2226 > Web: http://science.gsfc.nasa.gov/sed/bio/bernard.j.kelly > ORCID: orcid.org/0000-0002-3326-4454 > ------------------------------------------------------------------ > _______________________________________________ > Users mailing list > Users at einsteintoolkit.org > http://lists.einsteintoolkit.org/mailman/listinfo/users -- Erik Schnetter http://www.perimeterinstitute.ca/personal/eschnetter/ From physicsbeany at gmail.com Thu Nov 16 16:29:36 2023 From: physicsbeany at gmail.com (Bernard Kelly) Date: Thu, 16 Nov 2023 17:29:36 -0500 Subject: [Users] ETK config-stage failure with Macports gcc -- C+11 range-based for statments? In-Reply-To: References: <20231116143516.432af74b@ekohaes8> Message-ID: Thanks, Erik. Hmm, OK. It turns out that I *have* ld64 installed via MacPorts, and I think that's what's being used here: gs66-shannon:~ bjkelly1$ L /opt/local/bin/ld* lrwxr-xr-x 1 root admin 8 Sep 28 19:42 /opt/local/bin/ld -> ld-xcode lrwxr-xr-x 1 root admin 16 Sep 28 19:42 /opt/local/bin/ld-classic -> ld-classic-xcode lrwxr-xr-x 1 root admin 32 Sep 28 19:41 /opt/local/bin/ld-classic-xcode -> ../libexec/ld64/ld-classic-xcode lrwxr-xr-x 1 root admin 24 Sep 28 19:41 /opt/local/bin/ld-xcode -> ../libexec/ld64/ld-xcode -rwxr-xr-x 1 root admin 176 Sep 28 20:06 /opt/local/bin/ld.lld-mp-14 -rwxr-xr-x 1 root admin 180 Sep 28 20:06 /opt/local/bin/ld64.lld-mp-14 I just tried setting LD = /opt/local/bin/ld-classic , but the failure is the same. I then tried using the pre-MacPorts system linker, LD = /usr/bin/ld, but the failure is unchanged. Perhaps there's a linker flag I should be setting? Right now I have nothing in LDFLAGS. Bernard On Thu, Nov 16, 2023 at 4:41?PM Erik Schnetter wrote: > Bernard > > Your C++ compiler is probably fine, but your linker ("ld") is not, it > cannot handle GCC's output. > > I have a MacPorts package "ld64" installed. Maybe that would help? > > -erik > > On Thu, Nov 16, 2023 at 3:49?PM Bernard Kelly > wrote: > > > > Hi Roland. > > > > I'm attaching the config.log file here (I had to hunt it down in > configs/sim/config-data, since the configure step failed before it could > point to anything). > > > > Since the logfile gives a small C++ program that failed to compile, I > copied it to testGPP2.cpp, and tried compiling it myself; and yes, it > failed. Errors from this are short enough to quote here: > > > > ------------ > > gs66-shannon:Cactus_ET_2023_05 bjkelly1$ /opt/local/bin/g++-mp-13 > testGPP2.cpp > > ld: warning: ignoring duplicate libraries: '-lgcc' > > 0 0x1049cb648 __assert_rtn + 72 > > 1 0x1048fffac ld::AtomPlacement::findAtom(unsigned char, unsigned long > long, ld::AtomPlacement::AtomLoc const*&, long long&) const + 1204 > > 2 0x104915924 > ld::InputFiles::SliceParser::parseObjectFile(mach_o::Header const*) const + > 15164 > > 3 0x104922e30 ld::InputFiles::parseAllFiles(void (ld::AtomFile const*) > block_pointer)::$_7::operator()(unsigned long, ld::FileInfo const&) const + > 420 > > 4 0x1a0274440 _dispatch_client_callout2 + 20 > > 5 0x1a0289544 _dispatch_apply_invoke_and_wait + 224 > > 6 0x1a028884c _dispatch_apply_with_attr_f + 1180 > > 7 0x1a0288a38 dispatch_apply + 96 > > 8 0x10499d3b8 ld::AtomFileConsolidator::parseFiles(bool) + 292 > > 9 0x10493e170 main + 9048 > > ld: Assertion failed: (resultIndex < sectData.atoms.size()), function > findAtom, file Relocations.cpp, line 1336. > > collect2: error: ld returned 1 exit status > > ------------ > > > > As for your other question, no, there's no environment variable set with > a name containing CXX. > > > > Thanks, Bernard > > > > > > On Thu, Nov 16, 2023 at 3:35?PM Roland Haas wrote: > >> > >> Hello Bernard, > >> > >> Odd. You have the correct CXXFLAGS and the compiler seems new enough. > >> > >> Could you attach the config.log file that the run produced (should be > >> mentioned near the end with full path). > >> > >> Since this has been an issue in the past: there are no environment > >> variables CXX or CXXFLAGS defined in you shell (env | grep CXX finds > >> nothing)? > >> > >> Yours, > >> Roland > >> > >> > Hi. I tried making a new configuration on my Macbook (MacOS Ventura, > >> > 13.6.2) after a gap of several months, and it's now failing the "make > >> > sim-config" step with a complaint about the C++ compiler not being > >> > C++11-compliant -- end of the make config step screen output is below. > >> > > >> > I'm using the latest available Macports-supplied GNU compilers > >> > (gcc-mp-13, g++-mp-13, etc.), with the following C & C++ options: > >> > > >> > ---------- compiler flags ----------- > >> > CPP = /opt/local/bin/cpp-mp-13 > >> > CC = /opt/local/bin/gcc-mp-13 > >> > CXX = /opt/local/bin/g++-mp-13 > >> > CPPFLAGS = > >> > CFLAGS = -std=c99 > >> > CXXFLAGS = -std=c++14 > >> > C_LINE_DIRECTIVES = yes > >> > OPTIMISE = yes > >> > CPP_OPTIMISE_FLAGS = # -DCARPET_OPTIMISE -DNDEBUG > >> > C_OPTIMISE_FLAGS = -O2 -march=native > >> > CXX_OPTIMISE_FLAGS = -O2 -march=native > >> > OPENMP = yes > >> > CPP_OPENMP_FLAGS = -fopenmp > >> > C_OPENMP_FLAGS = -fopenmp > >> > CXX_OPENMP_FLAGS = -fopenmp > >> > WARN = yes > >> > CPP_WARN_FLAGS = -Wall > >> > C_WARN_FLAGS = -Wall > >> > CXX_WARN_FLAGS = -Wall > >> > ---------- end of compiler flags ----------- > >> > > >> > Can anyone suggest what's up? The error says that the C++ compiler is > >> > failing to do range-based for statements, but I can compile & run a > simple > >> > program with a range-based for statement, so this seems unlikely. > >> > > >> > I'm currently on ET_2023-05, but have this problem with ET_2022_11 as > well, > >> > and with gcc-mp-12. > >> > > >> > Thanks, Bernard > >> > > >> > --------------- last bit of screen output --------- > >> > checking if compiler has broken omp collapse... no > >> > checking for getopt_long_only... yes > >> > checking for working const... yes > >> > checking for C inline... inline > >> > checking for C static inline... static inline > >> > checking for C restrict... restrict > >> > checking for C++ restrict... __restrict__ > >> > checking for C++ copysign... std::copysign > >> > checking for C++ fpclassify... std::fpclassify > >> > checking for C++ isfinite... std::isfinite > >> > checking for C++ isinf... std::isinf > >> > checking for C++ isnan... std::isnan > >> > checking for C++ isnormal... std::isnormal > >> > checking for C++ signbit... std::signbit > >> > checking for C _Pragma... yes > >> > checking for C function __attribute__((__const__))... yes > >> > checking for C++ function __attribute__((__const__))... yes > >> > checking for C++ member function __attribute__((__const__))... yes > >> > checking for C function __attribute__((__pure__))... yes > >> > checking for C++ function __attribute__((__pure__))... yes > >> > checking for C++ member function __attribute__((__pure__))... yes > >> > checking for C data __attribute__((__common__))... yes > >> > checking for C+ data __attribute__((__common__))... yes > >> > checking for C function __attribute__((__noinline__))... yes > >> > checking for C++ function __attribute__((__noinline__))... yes > >> > checking for C++ member function __attribute__((__noinline__))... yes > >> > checking for C function __attribute__((__always_inline__))... yes > >> > checking for C++ function __attribute__((__always_inline__))... yes > >> > checking for C++ member function > __attribute__((__always_inline__))... yes > >> > checking for C __attribute__((__unused__))... yes > >> > checking for C++ __attribute__((__unused__))... yes > >> > checking for C __attribute__((__aligned__(...)))... yes > >> > checking for C++ __attribute__((__aligned__(...)))... yes > >> > checking for C __attribute__((__cold__))... yes > >> > checking for C++ __attribute__((__cold__))... yes > >> > checking for C __attribute__((__hot__))... yes > >> > checking for C++ __attribute__((__hot__))... yes > >> > checking for C __attribute__((__format__(printf, 1, 2)))... yes > >> > checking for C++ __attribute__((__format__(printf, 1, 2)))... yes > >> > checking for C __attribute__((__noreturn__))... yes > >> > checking for C++ __attribute__((__noreturn__))... yes > >> > checking for C __attribute__((__nonnull__))... yes > >> > checking for C++ __attribute__((__nonnull__))... yes > >> > checking for C __attribute__((__returns_nonnull__))... yes > >> > checking for C++ __attribute__((__returns_nonnull__))... yes > >> > checking for C __builtin_expect... yes > >> > checking for C++ __builtin_expect... yes > >> > checking for C __builtin_trap... yes > >> > checking for C++ __builtin_trap... yes > >> > checking for C __builtin_unreachable... no > >> > checking for C++ __builtin_unreachable... no > >> > checking for C __builtin_assume_aligned... yes > >> > checking for C++ __builtin_assume_aligned... yes > >> > checking for C++ static_assert... yes > >> > checking for C++ auto specifier... yes > >> > checking for C++ lambda expressions... yes > >> > checking for C++ range-based for statements... no > >> > Cactus requires a C++11 compiler -- check your C++ compiler and C++ > >> > compiler flags > >> > > >> > Error reconfiguring sim-config > >> > make: *** [sim-config] Error 2 > >> > > >> > >> > >> 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://pgp.mit.edu . > > > > > > > > -- > > ------------------------------------------------------------------ > > Bernard Kelly -- CRESST Assistant Research Scientist, NASA/GSFC > > Gravitational Astrophysics Laboratory --- Code 663 > > > > Phone: +1 (301) 286-7243 *** Fax: +1 (301) 286-2226 > > Web: http://science.gsfc.nasa.gov/sed/bio/bernard.j.kelly > > ORCID: orcid.org/0000-0002-3326-4454 > > ------------------------------------------------------------------ > > _______________________________________________ > > Users mailing list > > Users at einsteintoolkit.org > > http://lists.einsteintoolkit.org/mailman/listinfo/users > > > > -- > Erik Schnetter > http://www.perimeterinstitute.ca/personal/eschnetter/ > -- ------------------------------------------------------------------ Bernard Kelly -- CRESST Assistant Research Scientist, NASA/GSFC Gravitational Astrophysics Laboratory --- Code 663 Phone: +1 (301) 286-7243 *** Fax: +1 (301) 286-2226 Web: http://science.gsfc.nasa.gov/sed/bio/bernard.j.kelly ORCID: orcid.org/0000-0002-3326-4454 ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From robyn.munoz at yahoo.fr Fri Nov 17 04:46:11 2023 From: robyn.munoz at yahoo.fr (Robyn Munoz) Date: Fri, 17 Nov 2023 10:46:11 +0000 (UTC) Subject: [Users] ML_BBSN shift evolution equation References: <1488684102.7474774.1700217971683.ref@mail.yahoo.com> Message-ID: <1488684102.7474774.1700217971683@mail.yahoo.com> Hello everyone, Could someone please clarify the shift evolution equation implemented in ML_BSSN? Just looking at the parameter file it seems like it is: ? ? ?d/dt beta^i = shiftGammaCoeff? Xt^i - betaDriver alpha^shiftAlphaPower beta^i looking at McLachlan_BSSN.m (for GammaDriver and without advection and dissipation), I think it is: ? ? ?d/dt beta^a =??shiftGammaCoeff?alpha^shiftAlphaPower B^awith? ? ?d/dt B^a = d/dt Xt^a -?betaDriver B^a Whereas looking at Alcubierre's book Eq 4.3.33 and 4.3.34 I would expect it to be? ? ? ?d/dt beta^i =? B^iwith? ? ?d/dt B^i = shiftGammaCoeff?alpha^shiftAlphaPower?d/dt Xt^a -?betaDriver B^a on the McLachlan webpage:?https://www.cct.lsu.edu/~eschnett/McLachlan/the link to describe the Gamma driver shift condition?http://grwiki.physics.ncsu.edu/wiki/Shift_Conditions?doesn't work but looking at the 2019 version on the wayback machine the evolution described is ? ? ?d/dt beta^a = (3/4) B^awith? ? ?d/dt B^a = d/dt?Xt^a -?betaDriver B^a where here (and in Alcubierre) d/dt = partial_t - beta^c partial_c. Does the McLachlan code have that second term beta^c partial_c?? This is confusing me, so what is actually implemented? Where are the parameters?shiftGammaCoeff, betaDriver and shiftAlphaPower in the evolution equation? And these are all constant positive reals right? In Alcubierre's book xi (that I think is shiftGammaCoeff) can be function of space and the lapse. Thank you,Robyn -------------- next part -------------- An HTML attachment was scrubbed... URL: From schnetter at gmail.com Fri Nov 17 08:24:00 2023 From: schnetter at gmail.com (Erik Schnetter) Date: Fri, 17 Nov 2023 09:24:00 -0500 Subject: [Users] ML_BBSN shift evolution equation In-Reply-To: <1488684102.7474774.1700217971683@mail.yahoo.com> References: <1488684102.7474774.1700217971683.ref@mail.yahoo.com> <1488684102.7474774.1700217971683@mail.yahoo.com> Message-ID: Robyn There are two choices to evolve the shift, either as first-order or as second-order equation. In the second case B^a is also evolved. In the first case B^a is just a dummy variable that remains unused. The other parameters have slightly different meanings in both cases. The "traditional" BSSN equation for the shift uses B^a. The "traditional" BSSN shift evolution also omits the Lie derivative terms for the shift. Some people find that these terms are useful, and so there are parameters to add them. Finally, the code is slightly more complicated because a certain term is identical to (part of) the RHS of the Gamma-tilde terms, and this term is reused. In the end we have unfortunately reached a state where the current meaning of the parameters cannot be changed any more because this would break existing parameter files. If in doubt the code is the ground truth. You might be able to choose some parameters (e.g. "B is evolved", "Lie derivative terms are omitted") and then manually simplify the code to see what happens. The story for the lapse alpha and its time derivative A is similar. -erik On Fri, Nov 17, 2023 at 5:47?AM Robyn Munoz wrote: > > Hello everyone, > > Could someone please clarify the shift evolution equation implemented in ML_BSSN? > > Just looking at the parameter file it seems like it is: > > d/dt beta^i = shiftGammaCoeff Xt^i - betaDriver alpha^shiftAlphaPower beta^i > > looking at McLachlan_BSSN.m (for GammaDriver and without advection and dissipation), I think it is: > > d/dt beta^a = shiftGammaCoeff alpha^shiftAlphaPower B^a > with > d/dt B^a = d/dt Xt^a - betaDriver B^a > > Whereas looking at Alcubierre's book Eq 4.3.33 and 4.3.34 I would expect it to be > > d/dt beta^i = B^i > with > d/dt B^i = shiftGammaCoeff alpha^shiftAlphaPower d/dt Xt^a - betaDriver B^a > > on the McLachlan webpage: https://www.cct.lsu.edu/~eschnett/McLachlan/ > the link to describe the Gamma driver shift condition http://grwiki.physics.ncsu.edu/wiki/Shift_Conditions doesn't work but looking at the 2019 version on the wayback machine the evolution described is > > d/dt beta^a = (3/4) B^a > with > d/dt B^a = d/dt Xt^a - betaDriver B^a > > where here (and in Alcubierre) d/dt = partial_t - beta^c partial_c. Does the McLachlan code have that second term beta^c partial_c ? > > This is confusing me, so what is actually implemented? Where are the parameters shiftGammaCoeff, betaDriver and shiftAlphaPower in the evolution equation? And these are all constant positive reals right? In Alcubierre's book xi (that I think is shiftGammaCoeff) can be function of space and the lapse. > > Thank you, > Robyn > _______________________________________________ > Users mailing list > Users at einsteintoolkit.org > http://lists.einsteintoolkit.org/mailman/listinfo/users -- Erik Schnetter http://www.perimeterinstitute.ca/personal/eschnetter/ From schnetter at gmail.com Fri Nov 17 08:26:13 2023 From: schnetter at gmail.com (Erik Schnetter) Date: Fri, 17 Nov 2023 09:26:13 -0500 Subject: [Users] ETK config-stage failure with Macports gcc -- C+11 range-based for statments? In-Reply-To: References: <20231116143516.432af74b@ekohaes8> Message-ID: In Cactus, "LD" needs to point to a compiler driver (e.g. "g++"), not to a linker. You should see a very different error message when you set "LD" to a linker. (Or maybe the configure script overwrites "LD".) Can you try installing a different "ld64" package, installing a different variant, or uninstalling it? -erik On Thu, Nov 16, 2023 at 5:29?PM Bernard Kelly wrote: > > Thanks, Erik. > > Hmm, OK. It turns out that I *have* ld64 installed via MacPorts, and I think that's what's being used here: > > gs66-shannon:~ bjkelly1$ L /opt/local/bin/ld* > lrwxr-xr-x 1 root admin 8 Sep 28 19:42 /opt/local/bin/ld -> ld-xcode > lrwxr-xr-x 1 root admin 16 Sep 28 19:42 /opt/local/bin/ld-classic -> ld-classic-xcode > lrwxr-xr-x 1 root admin 32 Sep 28 19:41 /opt/local/bin/ld-classic-xcode -> ../libexec/ld64/ld-classic-xcode > lrwxr-xr-x 1 root admin 24 Sep 28 19:41 /opt/local/bin/ld-xcode -> ../libexec/ld64/ld-xcode > -rwxr-xr-x 1 root admin 176 Sep 28 20:06 /opt/local/bin/ld.lld-mp-14 > -rwxr-xr-x 1 root admin 180 Sep 28 20:06 /opt/local/bin/ld64.lld-mp-14 > > I just tried setting LD = /opt/local/bin/ld-classic , but the failure is the same. > > I then tried using the pre-MacPorts system linker, LD = /usr/bin/ld, but the failure is unchanged. > > Perhaps there's a linker flag I should be setting? Right now I have nothing in LDFLAGS. > > Bernard > > On Thu, Nov 16, 2023 at 4:41?PM Erik Schnetter wrote: >> >> Bernard >> >> Your C++ compiler is probably fine, but your linker ("ld") is not, it >> cannot handle GCC's output. >> >> I have a MacPorts package "ld64" installed. Maybe that would help? >> >> -erik >> >> On Thu, Nov 16, 2023 at 3:49?PM Bernard Kelly wrote: >> > >> > Hi Roland. >> > >> > I'm attaching the config.log file here (I had to hunt it down in configs/sim/config-data, since the configure step failed before it could point to anything). >> > >> > Since the logfile gives a small C++ program that failed to compile, I copied it to testGPP2.cpp, and tried compiling it myself; and yes, it failed. Errors from this are short enough to quote here: >> > >> > ------------ >> > gs66-shannon:Cactus_ET_2023_05 bjkelly1$ /opt/local/bin/g++-mp-13 testGPP2.cpp >> > ld: warning: ignoring duplicate libraries: '-lgcc' >> > 0 0x1049cb648 __assert_rtn + 72 >> > 1 0x1048fffac ld::AtomPlacement::findAtom(unsigned char, unsigned long long, ld::AtomPlacement::AtomLoc const*&, long long&) const + 1204 >> > 2 0x104915924 ld::InputFiles::SliceParser::parseObjectFile(mach_o::Header const*) const + 15164 >> > 3 0x104922e30 ld::InputFiles::parseAllFiles(void (ld::AtomFile const*) block_pointer)::$_7::operator()(unsigned long, ld::FileInfo const&) const + 420 >> > 4 0x1a0274440 _dispatch_client_callout2 + 20 >> > 5 0x1a0289544 _dispatch_apply_invoke_and_wait + 224 >> > 6 0x1a028884c _dispatch_apply_with_attr_f + 1180 >> > 7 0x1a0288a38 dispatch_apply + 96 >> > 8 0x10499d3b8 ld::AtomFileConsolidator::parseFiles(bool) + 292 >> > 9 0x10493e170 main + 9048 >> > ld: Assertion failed: (resultIndex < sectData.atoms.size()), function findAtom, file Relocations.cpp, line 1336. >> > collect2: error: ld returned 1 exit status >> > ------------ >> > >> > As for your other question, no, there's no environment variable set with a name containing CXX. >> > >> > Thanks, Bernard >> > >> > >> > On Thu, Nov 16, 2023 at 3:35?PM Roland Haas wrote: >> >> >> >> Hello Bernard, >> >> >> >> Odd. You have the correct CXXFLAGS and the compiler seems new enough. >> >> >> >> Could you attach the config.log file that the run produced (should be >> >> mentioned near the end with full path). >> >> >> >> Since this has been an issue in the past: there are no environment >> >> variables CXX or CXXFLAGS defined in you shell (env | grep CXX finds >> >> nothing)? >> >> >> >> Yours, >> >> Roland >> >> >> >> > Hi. I tried making a new configuration on my Macbook (MacOS Ventura, >> >> > 13.6.2) after a gap of several months, and it's now failing the "make >> >> > sim-config" step with a complaint about the C++ compiler not being >> >> > C++11-compliant -- end of the make config step screen output is below. >> >> > >> >> > I'm using the latest available Macports-supplied GNU compilers >> >> > (gcc-mp-13, g++-mp-13, etc.), with the following C & C++ options: >> >> > >> >> > ---------- compiler flags ----------- >> >> > CPP = /opt/local/bin/cpp-mp-13 >> >> > CC = /opt/local/bin/gcc-mp-13 >> >> > CXX = /opt/local/bin/g++-mp-13 >> >> > CPPFLAGS = >> >> > CFLAGS = -std=c99 >> >> > CXXFLAGS = -std=c++14 >> >> > C_LINE_DIRECTIVES = yes >> >> > OPTIMISE = yes >> >> > CPP_OPTIMISE_FLAGS = # -DCARPET_OPTIMISE -DNDEBUG >> >> > C_OPTIMISE_FLAGS = -O2 -march=native >> >> > CXX_OPTIMISE_FLAGS = -O2 -march=native >> >> > OPENMP = yes >> >> > CPP_OPENMP_FLAGS = -fopenmp >> >> > C_OPENMP_FLAGS = -fopenmp >> >> > CXX_OPENMP_FLAGS = -fopenmp >> >> > WARN = yes >> >> > CPP_WARN_FLAGS = -Wall >> >> > C_WARN_FLAGS = -Wall >> >> > CXX_WARN_FLAGS = -Wall >> >> > ---------- end of compiler flags ----------- >> >> > >> >> > Can anyone suggest what's up? The error says that the C++ compiler is >> >> > failing to do range-based for statements, but I can compile & run a simple >> >> > program with a range-based for statement, so this seems unlikely. >> >> > >> >> > I'm currently on ET_2023-05, but have this problem with ET_2022_11 as well, >> >> > and with gcc-mp-12. >> >> > >> >> > Thanks, Bernard >> >> > >> >> > --------------- last bit of screen output --------- >> >> > checking if compiler has broken omp collapse... no >> >> > checking for getopt_long_only... yes >> >> > checking for working const... yes >> >> > checking for C inline... inline >> >> > checking for C static inline... static inline >> >> > checking for C restrict... restrict >> >> > checking for C++ restrict... __restrict__ >> >> > checking for C++ copysign... std::copysign >> >> > checking for C++ fpclassify... std::fpclassify >> >> > checking for C++ isfinite... std::isfinite >> >> > checking for C++ isinf... std::isinf >> >> > checking for C++ isnan... std::isnan >> >> > checking for C++ isnormal... std::isnormal >> >> > checking for C++ signbit... std::signbit >> >> > checking for C _Pragma... yes >> >> > checking for C function __attribute__((__const__))... yes >> >> > checking for C++ function __attribute__((__const__))... yes >> >> > checking for C++ member function __attribute__((__const__))... yes >> >> > checking for C function __attribute__((__pure__))... yes >> >> > checking for C++ function __attribute__((__pure__))... yes >> >> > checking for C++ member function __attribute__((__pure__))... yes >> >> > checking for C data __attribute__((__common__))... yes >> >> > checking for C+ data __attribute__((__common__))... yes >> >> > checking for C function __attribute__((__noinline__))... yes >> >> > checking for C++ function __attribute__((__noinline__))... yes >> >> > checking for C++ member function __attribute__((__noinline__))... yes >> >> > checking for C function __attribute__((__always_inline__))... yes >> >> > checking for C++ function __attribute__((__always_inline__))... yes >> >> > checking for C++ member function __attribute__((__always_inline__))... yes >> >> > checking for C __attribute__((__unused__))... yes >> >> > checking for C++ __attribute__((__unused__))... yes >> >> > checking for C __attribute__((__aligned__(...)))... yes >> >> > checking for C++ __attribute__((__aligned__(...)))... yes >> >> > checking for C __attribute__((__cold__))... yes >> >> > checking for C++ __attribute__((__cold__))... yes >> >> > checking for C __attribute__((__hot__))... yes >> >> > checking for C++ __attribute__((__hot__))... yes >> >> > checking for C __attribute__((__format__(printf, 1, 2)))... yes >> >> > checking for C++ __attribute__((__format__(printf, 1, 2)))... yes >> >> > checking for C __attribute__((__noreturn__))... yes >> >> > checking for C++ __attribute__((__noreturn__))... yes >> >> > checking for C __attribute__((__nonnull__))... yes >> >> > checking for C++ __attribute__((__nonnull__))... yes >> >> > checking for C __attribute__((__returns_nonnull__))... yes >> >> > checking for C++ __attribute__((__returns_nonnull__))... yes >> >> > checking for C __builtin_expect... yes >> >> > checking for C++ __builtin_expect... yes >> >> > checking for C __builtin_trap... yes >> >> > checking for C++ __builtin_trap... yes >> >> > checking for C __builtin_unreachable... no >> >> > checking for C++ __builtin_unreachable... no >> >> > checking for C __builtin_assume_aligned... yes >> >> > checking for C++ __builtin_assume_aligned... yes >> >> > checking for C++ static_assert... yes >> >> > checking for C++ auto specifier... yes >> >> > checking for C++ lambda expressions... yes >> >> > checking for C++ range-based for statements... no >> >> > Cactus requires a C++11 compiler -- check your C++ compiler and C++ >> >> > compiler flags >> >> > >> >> > Error reconfiguring sim-config >> >> > make: *** [sim-config] Error 2 >> >> > >> >> >> >> >> >> 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://pgp.mit.edu . >> > >> > >> > >> > -- >> > ------------------------------------------------------------------ >> > Bernard Kelly -- CRESST Assistant Research Scientist, NASA/GSFC >> > Gravitational Astrophysics Laboratory --- Code 663 >> > >> > Phone: +1 (301) 286-7243 *** Fax: +1 (301) 286-2226 >> > Web: http://science.gsfc.nasa.gov/sed/bio/bernard.j.kelly >> > ORCID: orcid.org/0000-0002-3326-4454 >> > ------------------------------------------------------------------ >> > _______________________________________________ >> > Users mailing list >> > Users at einsteintoolkit.org >> > http://lists.einsteintoolkit.org/mailman/listinfo/users >> >> >> >> -- >> Erik Schnetter >> http://www.perimeterinstitute.ca/personal/eschnetter/ > > > > -- > ------------------------------------------------------------------ > Bernard Kelly -- CRESST Assistant Research Scientist, NASA/GSFC > Gravitational Astrophysics Laboratory --- Code 663 > > Phone: +1 (301) 286-7243 *** Fax: +1 (301) 286-2226 > Web: http://science.gsfc.nasa.gov/sed/bio/bernard.j.kelly > ORCID: orcid.org/0000-0002-3326-4454 > ------------------------------------------------------------------ -- Erik Schnetter http://www.perimeterinstitute.ca/personal/eschnetter/ From physicsbeany at gmail.com Tue Nov 21 21:14:14 2023 From: physicsbeany at gmail.com (Bernard Kelly) Date: Tue, 21 Nov 2023 22:14:14 -0500 Subject: [Users] ETK config-stage failure with Macports gcc -- C+11 range-based for statments? In-Reply-To: References: <20231116143516.432af74b@ekohaes8> Message-ID: Hi Erik, Roland, et al. Problem resolved. It turns out the issue was with my local XCode installation. I was on a beta version of XCode 15.x, which needed to be upgraded (and I then had to reinstall Macports). One lingering issue: the linker that comes with XCode 15 has some different behavior that still messes up compilation. I have to add "-ld_classic" to my compiler flags to fix it. Thanks for the advice, Bernard On Fri, Nov 17, 2023 at 9:26?AM Erik Schnetter wrote: > In Cactus, "LD" needs to point to a compiler driver (e.g. "g++"), not > to a linker. You should see a very different error message when you > set "LD" to a linker. (Or maybe the configure script overwrites "LD".) > > Can you try installing a different "ld64" package, installing a > different variant, or uninstalling it? > > -erik > > On Thu, Nov 16, 2023 at 5:29?PM Bernard Kelly > wrote: > > > > Thanks, Erik. > > > > Hmm, OK. It turns out that I *have* ld64 installed via MacPorts, and I > think that's what's being used here: > > > > gs66-shannon:~ bjkelly1$ L /opt/local/bin/ld* > > lrwxr-xr-x 1 root admin 8 Sep 28 19:42 /opt/local/bin/ld -> ld-xcode > > lrwxr-xr-x 1 root admin 16 Sep 28 19:42 /opt/local/bin/ld-classic -> > ld-classic-xcode > > lrwxr-xr-x 1 root admin 32 Sep 28 19:41 > /opt/local/bin/ld-classic-xcode -> ../libexec/ld64/ld-classic-xcode > > lrwxr-xr-x 1 root admin 24 Sep 28 19:41 /opt/local/bin/ld-xcode -> > ../libexec/ld64/ld-xcode > > -rwxr-xr-x 1 root admin 176 Sep 28 20:06 /opt/local/bin/ld.lld-mp-14 > > -rwxr-xr-x 1 root admin 180 Sep 28 20:06 /opt/local/bin/ld64.lld-mp-14 > > > > I just tried setting LD = /opt/local/bin/ld-classic , but the failure is > the same. > > > > I then tried using the pre-MacPorts system linker, LD = /usr/bin/ld, but > the failure is unchanged. > > > > Perhaps there's a linker flag I should be setting? Right now I have > nothing in LDFLAGS. > > > > Bernard > > > > On Thu, Nov 16, 2023 at 4:41?PM Erik Schnetter > wrote: > >> > >> Bernard > >> > >> Your C++ compiler is probably fine, but your linker ("ld") is not, it > >> cannot handle GCC's output. > >> > >> I have a MacPorts package "ld64" installed. Maybe that would help? > >> > >> -erik > >> > >> On Thu, Nov 16, 2023 at 3:49?PM Bernard Kelly > wrote: > >> > > >> > Hi Roland. > >> > > >> > I'm attaching the config.log file here (I had to hunt it down in > configs/sim/config-data, since the configure step failed before it could > point to anything). > >> > > >> > Since the logfile gives a small C++ program that failed to compile, I > copied it to testGPP2.cpp, and tried compiling it myself; and yes, it > failed. Errors from this are short enough to quote here: > >> > > >> > ------------ > >> > gs66-shannon:Cactus_ET_2023_05 bjkelly1$ /opt/local/bin/g++-mp-13 > testGPP2.cpp > >> > ld: warning: ignoring duplicate libraries: '-lgcc' > >> > 0 0x1049cb648 __assert_rtn + 72 > >> > 1 0x1048fffac ld::AtomPlacement::findAtom(unsigned char, unsigned > long long, ld::AtomPlacement::AtomLoc const*&, long long&) const + 1204 > >> > 2 0x104915924 > ld::InputFiles::SliceParser::parseObjectFile(mach_o::Header const*) const + > 15164 > >> > 3 0x104922e30 ld::InputFiles::parseAllFiles(void (ld::AtomFile > const*) block_pointer)::$_7::operator()(unsigned long, ld::FileInfo const&) > const + 420 > >> > 4 0x1a0274440 _dispatch_client_callout2 + 20 > >> > 5 0x1a0289544 _dispatch_apply_invoke_and_wait + 224 > >> > 6 0x1a028884c _dispatch_apply_with_attr_f + 1180 > >> > 7 0x1a0288a38 dispatch_apply + 96 > >> > 8 0x10499d3b8 ld::AtomFileConsolidator::parseFiles(bool) + 292 > >> > 9 0x10493e170 main + 9048 > >> > ld: Assertion failed: (resultIndex < sectData.atoms.size()), function > findAtom, file Relocations.cpp, line 1336. > >> > collect2: error: ld returned 1 exit status > >> > ------------ > >> > > >> > As for your other question, no, there's no environment variable set > with a name containing CXX. > >> > > >> > Thanks, Bernard > >> > > >> > > >> > On Thu, Nov 16, 2023 at 3:35?PM Roland Haas > wrote: > >> >> > >> >> Hello Bernard, > >> >> > >> >> Odd. You have the correct CXXFLAGS and the compiler seems new enough. > >> >> > >> >> Could you attach the config.log file that the run produced (should be > >> >> mentioned near the end with full path). > >> >> > >> >> Since this has been an issue in the past: there are no environment > >> >> variables CXX or CXXFLAGS defined in you shell (env | grep CXX finds > >> >> nothing)? > >> >> > >> >> Yours, > >> >> Roland > >> >> > >> >> > Hi. I tried making a new configuration on my Macbook (MacOS > Ventura, > >> >> > 13.6.2) after a gap of several months, and it's now failing the > "make > >> >> > sim-config" step with a complaint about the C++ compiler not being > >> >> > C++11-compliant -- end of the make config step screen output is > below. > >> >> > > >> >> > I'm using the latest available Macports-supplied GNU compilers > >> >> > (gcc-mp-13, g++-mp-13, etc.), with the following C & C++ options: > >> >> > > >> >> > ---------- compiler flags ----------- > >> >> > CPP = /opt/local/bin/cpp-mp-13 > >> >> > CC = /opt/local/bin/gcc-mp-13 > >> >> > CXX = /opt/local/bin/g++-mp-13 > >> >> > CPPFLAGS = > >> >> > CFLAGS = -std=c99 > >> >> > CXXFLAGS = -std=c++14 > >> >> > C_LINE_DIRECTIVES = yes > >> >> > OPTIMISE = yes > >> >> > CPP_OPTIMISE_FLAGS = # -DCARPET_OPTIMISE -DNDEBUG > >> >> > C_OPTIMISE_FLAGS = -O2 -march=native > >> >> > CXX_OPTIMISE_FLAGS = -O2 -march=native > >> >> > OPENMP = yes > >> >> > CPP_OPENMP_FLAGS = -fopenmp > >> >> > C_OPENMP_FLAGS = -fopenmp > >> >> > CXX_OPENMP_FLAGS = -fopenmp > >> >> > WARN = yes > >> >> > CPP_WARN_FLAGS = -Wall > >> >> > C_WARN_FLAGS = -Wall > >> >> > CXX_WARN_FLAGS = -Wall > >> >> > ---------- end of compiler flags ----------- > >> >> > > >> >> > Can anyone suggest what's up? The error says that the C++ compiler > is > >> >> > failing to do range-based for statements, but I can compile & run > a simple > >> >> > program with a range-based for statement, so this seems unlikely. > >> >> > > >> >> > I'm currently on ET_2023-05, but have this problem with ET_2022_11 > as well, > >> >> > and with gcc-mp-12. > >> >> > > >> >> > Thanks, Bernard > >> >> > > >> >> > --------------- last bit of screen output --------- > >> >> > checking if compiler has broken omp collapse... no > >> >> > checking for getopt_long_only... yes > >> >> > checking for working const... yes > >> >> > checking for C inline... inline > >> >> > checking for C static inline... static inline > >> >> > checking for C restrict... restrict > >> >> > checking for C++ restrict... __restrict__ > >> >> > checking for C++ copysign... std::copysign > >> >> > checking for C++ fpclassify... std::fpclassify > >> >> > checking for C++ isfinite... std::isfinite > >> >> > checking for C++ isinf... std::isinf > >> >> > checking for C++ isnan... std::isnan > >> >> > checking for C++ isnormal... std::isnormal > >> >> > checking for C++ signbit... std::signbit > >> >> > checking for C _Pragma... yes > >> >> > checking for C function __attribute__((__const__))... yes > >> >> > checking for C++ function __attribute__((__const__))... yes > >> >> > checking for C++ member function __attribute__((__const__))... yes > >> >> > checking for C function __attribute__((__pure__))... yes > >> >> > checking for C++ function __attribute__((__pure__))... yes > >> >> > checking for C++ member function __attribute__((__pure__))... yes > >> >> > checking for C data __attribute__((__common__))... yes > >> >> > checking for C+ data __attribute__((__common__))... yes > >> >> > checking for C function __attribute__((__noinline__))... yes > >> >> > checking for C++ function __attribute__((__noinline__))... yes > >> >> > checking for C++ member function __attribute__((__noinline__))... > yes > >> >> > checking for C function __attribute__((__always_inline__))... yes > >> >> > checking for C++ function __attribute__((__always_inline__))... yes > >> >> > checking for C++ member function > __attribute__((__always_inline__))... yes > >> >> > checking for C __attribute__((__unused__))... yes > >> >> > checking for C++ __attribute__((__unused__))... yes > >> >> > checking for C __attribute__((__aligned__(...)))... yes > >> >> > checking for C++ __attribute__((__aligned__(...)))... yes > >> >> > checking for C __attribute__((__cold__))... yes > >> >> > checking for C++ __attribute__((__cold__))... yes > >> >> > checking for C __attribute__((__hot__))... yes > >> >> > checking for C++ __attribute__((__hot__))... yes > >> >> > checking for C __attribute__((__format__(printf, 1, 2)))... yes > >> >> > checking for C++ __attribute__((__format__(printf, 1, 2)))... yes > >> >> > checking for C __attribute__((__noreturn__))... yes > >> >> > checking for C++ __attribute__((__noreturn__))... yes > >> >> > checking for C __attribute__((__nonnull__))... yes > >> >> > checking for C++ __attribute__((__nonnull__))... yes > >> >> > checking for C __attribute__((__returns_nonnull__))... yes > >> >> > checking for C++ __attribute__((__returns_nonnull__))... yes > >> >> > checking for C __builtin_expect... yes > >> >> > checking for C++ __builtin_expect... yes > >> >> > checking for C __builtin_trap... yes > >> >> > checking for C++ __builtin_trap... yes > >> >> > checking for C __builtin_unreachable... no > >> >> > checking for C++ __builtin_unreachable... no > >> >> > checking for C __builtin_assume_aligned... yes > >> >> > checking for C++ __builtin_assume_aligned... yes > >> >> > checking for C++ static_assert... yes > >> >> > checking for C++ auto specifier... yes > >> >> > checking for C++ lambda expressions... yes > >> >> > checking for C++ range-based for statements... no > >> >> > Cactus requires a C++11 compiler -- check your C++ compiler and C++ > >> >> > compiler flags > >> >> > > >> >> > Error reconfiguring sim-config > >> >> > make: *** [sim-config] Error 2 > >> >> > > >> >> > >> >> > >> >> 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://pgp.mit.edu . > >> > > >> > > >> > > >> > -- > >> > ------------------------------------------------------------------ > >> > Bernard Kelly -- CRESST Assistant Research Scientist, NASA/GSFC > >> > Gravitational Astrophysics Laboratory --- Code 663 > >> > > >> > Phone: +1 (301) 286-7243 *** Fax: +1 (301) 286-2226 > >> > Web: http://science.gsfc.nasa.gov/sed/bio/bernard.j.kelly > >> > ORCID: orcid.org/0000-0002-3326-4454 > >> > ------------------------------------------------------------------ > >> > _______________________________________________ > >> > Users mailing list > >> > Users at einsteintoolkit.org > >> > http://lists.einsteintoolkit.org/mailman/listinfo/users > >> > >> > >> > >> -- > >> Erik Schnetter > >> http://www.perimeterinstitute.ca/personal/eschnetter/ > > > > > > > > -- > > ------------------------------------------------------------------ > > Bernard Kelly -- CRESST Assistant Research Scientist, NASA/GSFC > > Gravitational Astrophysics Laboratory --- Code 663 > > > > Phone: +1 (301) 286-7243 *** Fax: +1 (301) 286-2226 > > Web: http://science.gsfc.nasa.gov/sed/bio/bernard.j.kelly > > ORCID: orcid.org/0000-0002-3326-4454 > > ------------------------------------------------------------------ > > > > -- > Erik Schnetter > http://www.perimeterinstitute.ca/personal/eschnetter/ > -- ------------------------------------------------------------------ Bernard Kelly -- CRESST Assistant Research Scientist, NASA/GSFC Gravitational Astrophysics Laboratory --- Code 663 Phone: +1 (301) 286-7243 *** Fax: +1 (301) 286-2226 Web: http://science.gsfc.nasa.gov/sed/bio/bernard.j.kelly ORCID: orcid.org/0000-0002-3326-4454 ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhaas at illinois.edu Mon Nov 27 15:18:01 2023 From: rhaas at illinois.edu (rhaas at illinois.edu) Date: Mon, 27 Nov 2023 15:18:01 -0600 Subject: [Users] Agenda for Thursday's Meeting Message-ID: Please update the Wiki with agenda items for Thursday's meeting. Thanks! https://docs.einsteintoolkit.org/et-docs/meeting_agenda --The Maintainers From hwitek at illinois.edu Wed Nov 29 09:22:24 2023 From: hwitek at illinois.edu (Helvi Witek) Date: Wed, 29 Nov 2023 09:22:24 -0600 Subject: [Users] Fwd: Scientific software developer in computational astrophysics at the University of the Balearic Islands, SPAIN In-Reply-To: References: Message-ID: <5bd72917-b401-3427-d276-743d04e154ce@illinois.edu> Dear all, please find an announcement below for a position as scientific software developer at UIB to work with Carlos Palenzuela (in cc). Best wishes, Helvi --------------------------------------------- Dr. Helvi Witek Assistant Professor Department of Physics University of Illinois at Urbana-Champaign 247 Loomis Lab 1110 W Green St Urbana, IL 61801 --------------------------------------------- -------- Forwarded Message -------- Subject: Scientific software developer in computational astrophysics at the University of the Balearic Islands, SPAIN Date: Mon, 27 Nov 2023 11:26:56 +0000 From: Carlos Palenzuela Luque Reply-To: Carlos Palenzuela Luque To: consortium at lisamission.org Dear colleagues, We are looking to fill? a scientific software developer position in at UIB (Palma de Mallorca), Spain. The Relativity and Gravitation group at the University of the Balearic Islands (UIB) offers a 2-year position for a scientific software developer. The successful candidate will support our research in computational astrophysics and numerical relativity through the development of the scientific software Simflowny, a cloud-based open environment for scientific dynamical models, with a user-friendly Integrated Development Environment, which automatically generates parallel code for simulation frameworks (for more details see https://bitbucket.org/iac3/simflowny/wiki/Home ). He/she will work under the supervision of Dr. Carlos Palenzuela and Dr. Joan Masso?. The group also includes faculty members Prof. Carles Bona and Dr. Fernando Abalos. The starting date can be negotiated, but it should be somewhere between April and September 2024. The annual gross salary is ~ 30000 EUR. Minimal requirement will be a bachelor?s degree or equivalent in computer science, astronomy, physics or a related discipline, with software developing experience and knowledge in Java, C++, Python and Linux/Unix. Excellent oral and written communication skills either in English or Spanish. Applicants should send a curriculum vitae, including a brief description of previous experience and interests, to be sent to carlos.palenzuela[AT]uib.es. *The deadline for full consideration is January 30, 2024.* Best regards, Carlos Palenzuela -------------- next part -------------- An HTML attachment was scrubbed... URL: From hwitek at illinois.edu Wed Nov 29 16:59:54 2023 From: hwitek at illinois.edu (Helvi Witek) Date: Wed, 29 Nov 2023 16:59:54 -0600 Subject: [Users] Workshop "New frontiers in strong gravity III" in Benasque - 1st announcement Message-ID: <6edb2a2d-89ce-ebe4-5cc9-8c71a3a2f6c5@illinois.edu> Dear colleagues, The third installment of the two-week workshop ?New frontiers in strong gravity? will take place in Benasque, Spain from Jul 07?19, 2024. The registration will open in Spring 2024. Please see the website http://benasque.org/2024relativity/ for further information. Summary: The highly nonlinear, strong-field regime of gravity holds the key to address long-standing puzzles in modern physics. These range from theoretical questions concerning the nature of gravity, the quest for a consistent theory of quantum gravity and resulting modifications to general relativity, to new insights into nuclear matter under extreme conditions in the context of neutron star and multi-messenger astronomy. In this two-week workshop (Jul 07?19, 2024) we will bring together leading experts as well as junior scientists and PhD students in these diverse research areas, to encourage communication and training across the fields and to foster new research collaborations. Invited speakers include: Alessandra Buonanno - Chiara Caprini* -? Vitor Cardoso - Ramiro Cayuso - Pippa Cole - Isabel Cordero Carri?n - Maxence Corman - Alex Grant - Lavinia Heisenberg - Aaron Held - Leah Jenks - Andrea Mitridate - Jaki Noronha-Hostler*- Ornella Piccinni - Jocelyn Read - Harvey Reall* - Horng Sheng Chia - Banafshe Shiralilou - Justin Vines - Jordan Wilson-Gerow * To be confirmed We would appreciate it if you could forward the announcement to interested researchers in our field. We look forward to welcoming you in Benasque Helvi, On behalf of the organizers (D. Blas, P. Figueras, S. Nissanke, L. Stein, H. Witek) --------------------------------------------- Dr. Helvi Witek Assistant Professor Department of Physics University of Illinois at Urbana-Champaign 247 Loomis Lab 1110 W Green St Urbana, IL 61801 --------------------------------------------- From rhaas at illinois.edu Wed Nov 29 17:15:01 2023 From: rhaas at illinois.edu (rhaas at illinois.edu) Date: Wed, 29 Nov 2023 17:15:01 -0600 Subject: [Users] Einstein Toolkit Meeting Reminder Message-ID: Hello, Please consider joining the weekly Einstein Toolkit phone call at 9:00 am US central time on Thursdays. For details on how to connect and what agenda items are to be discussed, use the link below. https://docs.einsteintoolkit.org/et-docs/Main_Page#Weekly_Users_Call --The Maintainers From wernecklr at gmail.com Thu Nov 30 09:50:34 2023 From: wernecklr at gmail.com (Leo Rosa Werneck) Date: Thu, 30 Nov 2023 07:50:34 -0800 Subject: [Users] Meeting minutes for 2023-11-30 Message-ID: <3B717AFE-5A4E-4C5D-89FE-96255D72FA63@gmail.com> Present: Leo, Steve, Zach, Peter, Sam, Roland Chair: Steve Minutes: Leo * ET Release: = Blockers: - Locked simfactory repo was fixed - presync-only option in CarpetX was fixed - NSIMD compilation issues still present -> Any cluster which cannot access to the internet will fail -> Dependency on Python package 'requests' -> Dependency on OpenSSL -> Roland will try to fix today = ET gallery examples: - TOV started (Peter) - BBH started (Deborah) - BNS not started (Steve) - Scalar wave not started (TBD) - Poisson equation not started (TBD) = ET Testing: - Deep Bayou (Tests ran a couple of weeks ago with a couple of failures) - SuperMike (Tests ran a couple of weeks ago with a couple of failures) -> test_o11 (from CarpetProlongateTest) -> ML_BSSN_NewRad (from ML_BSSN_Test) -> ML_BSSN_O8_sgw3d (from ML_BSSN_Test) - SuperMUC (Compiled, can't run) - Delta (Compiled + Run) - Expanse (Compiled + Run) - Summit (Not done yet) - Sunrise (Tests ran and got a couple of failures) -> Balsara0 (from GRHayLHDX) -> sphere_pugh_ppm (from Hydro_InitExcision) -> rnsA2 (from Hydro_RNSID) -> ML_BSSN_NewRad (from ML_BSSN_Test) -> ML_BSSN_O8_sgw3d (from ML_BSSN_Test) - Frontera (Not done yet due to NSIMD compilation issues) - Gabriele Bozzola ran tests on Anvil and some failed: -> sphere_pugh_ppm (from Hydro_InitExcision) -> memspeed (from MemSpeed) -> checkpoint-openpmd (from TestOutput) -> output-openpmd (from TestOutput) -> recover-openpmd (from TestOutput) = Sam will push on getting the Zenodo and release announcement ready * ET contribution to springer book on GRMHD codes = Need more writers (currently only Leo, Sam, and Zach) = No progress to report * SPEC contribution = No update * Open questions on the mailing list = Roland will look into compilation issues on Mac OS * Open tickets = None discussed until release is done * Other stuff = Roland asked Steve to update the ET youtube channel = Discussion on creating a repository for numerical relativity gravitational waveforms, and the ET could offer this to the community - Hardware requirements include a few TB for data storage ------ Leonardo R. Werneck, Ph.D. Postdoctoral researcher Office EP 314 | Department of Physics | University of Idaho 875 Perimeter Dr. MS 0903 Moscow, ID 83844-0903, USA leonardo at uidaho.edu https://leowerneck.github.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruno.giacomazzo at unimib.it Mon Nov 20 08:22:13 2023 From: bruno.giacomazzo at unimib.it (Bruno Giacomazzo) Date: Mon, 20 Nov 2023 14:22:13 -0000 Subject: [Users] Fwd: [Associati] 2-year postdoc at INAF Padova (PRIN 2022 "EMERGE") In-Reply-To: References: Message-ID: FYI ---------- Forwarded message --------- Da: Ciolfi, Riccardo Date: ven 10 nov 2023 alle ore 15:20 Subject: [Associati] 2-year postdoc at INAF Padova (PRIN 2022 "EMERGE") To: , , < contrattisti at ced.inaf.it> Dear Colleagues, I would like to advertise the opening of a 2-year postdoc position (Assegno di Ricerca) at INAF-Osservatorio Astronomico di Padova funded via the PRIN MUR 2022 project "EMERGE - Neutron star mergers and the origin of short gamma-ray bursts" (PI: Riccardo Ciolfi) The selected candidate will study the formation of relativistic jets in binary neutron star mergers and their propagation across the surrounding post-merger environment via a combination of general and special relativistic magnetohydrodynamic simulations. For further details please find attached the official call, both in English and in Italian. I also encourage any interested candidates to contact me. The deadline for the application is *December 4th 2023*. Best, Riccardo Ciolfi -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pnrr emerge Det. D. 500.2023 post dott.pdf Type: application/pdf Size: 477468 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PNRR_bando det. d. 500.2023 ingl. emerge.pdf Type: application/pdf Size: 531825 bytes Desc: not available URL: