From rhaas at illinois.edu Thu Feb 1 10:04:01 2024 From: rhaas at illinois.edu (Roland Haas) Date: Thu, 1 Feb 2024 10:04:01 -0600 Subject: [Users] meeting minutes for 2024-02-01 Message-ID: <20240201100401.61219e00@ekohaes8> Present: Roland, Peter, Steve, Zach, Bing-Ran HE, Leo, Sam, Shenfei, Yosef ET release: * discussed possible modules for inclusion, updated release timeline https://docs.einsteintoolkit.org/et-docs/Release_Details#Schedule ** GRHayL enabled IL-GRMHD ** tabulated EOS in GRHayLlib ** update Baikal to NRPy 2.0 ** possible FUKA updates * reviewers for ID thorns needed * Gallery runners: ** ask Deborah about BBH ** ask Peter for TOV ** Steve will try local students for a gallery example (Max Morris) ET US Meeting: * proposed time June 3 - 7 * organizing committee members (desired): ** Steve, Peter (local) ** Yosef (prior US meeting) ** Roland (general?), Zach (LIGO) ** Philipp (EU ET meeting) Cactus build system: * Steve brought up state of Cactus build system * possibility of moving over to cmake which is a more modern system compared to autoconf, of which we use an old, essentially unsupported version * would still require CST code for auto-generated code * possibility cmake and IDEs may be able to better understand where code comes from and what is auto-generated * some prior discussion: https://lists.einsteintoolkit.org/pipermail/users/2023-April/008911.html Unanswered questions: https://lists.einsteintoolkit.org/pipermail/users/2024-January/009196.html * discussed attempts by Robyn to make things build on Sciama * Steve took at look no specific solution suggestion 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 samuel.gomez.1940 at student.uu.se Thu Feb 1 18:12:57 2024 From: samuel.gomez.1940 at student.uu.se (=?iso-8859-1?Q?Samuel_G=F3mez?=) Date: Fri, 2 Feb 2024 00:12:57 +0000 Subject: [Users] Parameter file for a binary BH merger immersed in a scalar field Message-ID: Hi! My name is Samuel G?mez, physics student doing his master in Uppsala university, Sweden. Currently I am doing my master thesis with Joshua Eby from Stockholm University about the phenomenology of Gravitational Atoms around Neutron Stars and Black Holes. I would like to perform numerical simulations for a BH binary merger around a scalar cloud with EinsteinToolkit. From now, I have been able to simulate the example of the TOV star given in the EinteinToolkit official page in my laptop and soon I will gain access to a computer cluster where I hopefully will be able to install the Toolkit and perform a simulation for the example of a binary merger. But my aim is to be able to perform, maybe in its simplest version, a simulation of a merger around a scalar field, extracting information about both the evolution of the BHs and the scalar field itself. The problem I face is that I am not sure at all if I will be able to do it without any parameter file. As far as I understood, my current version of the Toolkit already has installed thorns related with the implementation of a scalar field (if I am not mistaken, one example is ScalarBase). I thus send this email asking if it is possible to obtain a parameter file for simulating this scenario, or to provide me with any information about an existing tutorial on how to write one. Something like this would help me a lot. I would appreciate any answer. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhaas at illinois.edu Fri Feb 2 14:08:37 2024 From: rhaas at illinois.edu (Roland Haas) Date: Fri, 2 Feb 2024 14:08:37 -0600 Subject: [Users] Fw: [nr-community-call] Next NR community call: Monday, Feb 5 Message-ID: <20240202140837.2da57563@eduroamprvnat-172-16-47-169.near.illinois.edu> Begin forwarded message: Date: Fri, 2 Feb 2024 11:52:10 -0800 From: Nils Vu To: nr-community-call at black-holes.org Subject: [nr-community-call] Next NR community call: Monday, Feb 5 Dear Numerical Relativists, Our first NR community call of the year will be on Monday, Feb 5 (9am Pacific, noon NYC, 6pm Berlin). Our speakers will be Xiaoyi Xie (AEI Potsdam / JET) and William Cook (FSU Jena / GR-Athena++). You can find the schedule in the wiki: https://github.com/sxs-collaboration/nr-community-call/wiki As always: - Feel free to circulate this information within the NR community. - Please subscribe to our mailing list to receive info on the community calls in the future (or send a short message to nr-community-call+subscribe at black-holes.org to subscribe) and join our Slack for discussions (channel: #nr-community-call ). - Please sign up for a slot in the schedule to speak at one of the community calls: https://github.com/sxs-collaboration/nr-community-call/wiki Best, Nils ? Nils Vu, Ph.D. (he/him) Sherman Fairchild Postdoctoral Fellow in Theoretical Astrophysics California Institute of Technology -------------- next part -------------- An HTML attachment was scrubbed... URL: From lorenzo.cipriani at graduate.univaq.it Mon Feb 5 03:24:27 2024 From: lorenzo.cipriani at graduate.univaq.it (Lorenzo Cipriani) Date: Mon, 5 Feb 2024 09:24:27 +0000 Subject: [Users] Spatial refinement factors Message-ID: Dear all, I have a brief question. I am trying to initialize a run with two very small stars (radius of ~300m) whose centers are at 750m from the origin; since I need a very fine grid, I am trying to use a refinement factor different from 2. In particular I am setting the Carpet::space_refinement_factors variable equal to [ [1,1,1], [5,5,5], ...] but I get the following error message: CarpetLib::dh::regrid(bool): Assertion `all(reffact == 2)' failed. This also happens if I change the Carpet::refinement_factor. Am I missing some obvious setting? Thank you very much for your help! Best, Lorenzo Cipriani -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: parfile_small.par Type: application/octet-stream Size: 30166 bytes Desc: parfile_small.par URL: From emost at caltech.edu Mon Feb 5 08:47:56 2024 From: emost at caltech.edu (Most, Elias R.) Date: Mon, 5 Feb 2024 14:47:56 +0000 Subject: [Users] Today: NR community call at 9am Pacific / noon NYC / 5pm London / 6pm Berlin Message-ID: ???Dear Numerical Relativists, We?ll have our NR community call today, Monday Feb 5, 9am LA / noon NYC / 5pm London / 6pm Berlin in this Zoom room: https://caltech.zoom.us/j/87114806411 Our speakers today will be Xiaoyi Xie (AEI Potsdam / JET) and William Cook (FSU Jena / GR-Athena++). - Feel free to circulate this information within the NR community. - Please subscribe to our mailing list to receive info on the community calls in the future (or send a short message to nr-community-call+subscribe at black-holes.org to subscribe) and join our Slack for discussions (channel: #nr-community-call). - Please sign up for a slot in the schedule to speak at one of the community calls: https://github.com/sxs-collaboration/nr-community-call/wiki Looking forward to seeing you all later, Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhaas at illinois.edu Mon Feb 5 13:27:59 2024 From: rhaas at illinois.edu (Roland Haas) Date: Mon, 5 Feb 2024 13:27:59 -0600 Subject: [Users] Spatial refinement factors In-Reply-To: References: Message-ID: <20240205132759.681714ac@ekohaes8> Hello Lorenzo, > CarpetLib::dh::regrid(bool): Assertion `all(reffact == 2)' failed. > > This also happens if I change the Carpet::refinement_factor. > Am I missing some obvious setting? Only refinement factors of 2 are currently supported (coded up). Others could be added but you most likely will run into issues in other locations of the code as well (eg you need to then also code up time interpolation with the new factor, and GRHydro and other codes make assumptions about the refinement factor). 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 Mon Feb 5 15:18:01 2024 From: rhaas at illinois.edu (rhaas at illinois.edu) Date: Mon, 05 Feb 2024 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 Feb 7 17:15:01 2024 From: rhaas at illinois.edu (rhaas at illinois.edu) Date: Wed, 07 Feb 2024 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 sbrandt at cct.lsu.edu Thu Feb 8 09:42:32 2024 From: sbrandt at cct.lsu.edu (Steven Brandt) Date: Thu, 8 Feb 2024 09:42:32 -0600 Subject: [Users] meeting minutes for 2024-02-08 Message-ID: <2cf612e3-3a4e-4ecf-a091-e6a82d4bc525@cct.lsu.edu> - Present: Roland, Steve, Peter, Leo, Sam, Zach - Release: ? - Still in feature proposal phase ? - Sam brought up release deadline on the CarpetX call: ??? - LeanBSSN Molx ??? - NewRadX ??? - NPScalarsX - Summer Schools: ? - June 3-7 US ET Workshop ? - July 8-12 EU ET Workshop - Unanswered Questions: ? - Parameter file for BBH collision immersed in a scalar field. Helvi should respond. ? - Compiling on Frontera: Have to remove certain thorns to compile. We should be pushing the MakeThornList utility. ? - Compiling on Sciama: Bad compiler? - Our mailing list server seems unable to send out emails, Steve will fix. - We are running out of quota on Github, Roland will fix. - Open Tickets: ? - Tootle's request for more control of the link line, ordering of arguments. Maybe to use the ?_LIB_DIR to link and not use -L. From bruno.giacomazzo at unimib.it Fri Feb 9 08:34:50 2024 From: bruno.giacomazzo at unimib.it (Bruno Giacomazzo) Date: Fri, 9 Feb 2024 15:34:50 +0100 Subject: [Users] typo in GRHydro thorn guide? Message-ID: The GRHydro thorn guide ( https://einsteintoolkit.org/thornguide/EinsteinEvolve/GRHydro/documentation.html) contains the following sentence: "However, in the vacuum limit the continuity equations describing the fluid break down. *The speed of sound tends to the speed of light* and everything fails (especially the conversion from conserved to primitive variables)." A student of mine wrote that the sound speed tends to the speed of light if rho tends to zero citing this, but is this correct? For example, taking a polytropic EOS P=k*rho^\gamma, the sound speed squared is (assuming c=1) cs^2= \gamma * k * rho^\gamma / (rho*h) with rho*h=rho+rho*eps+P=rho+\gamma*P/(\gamma-1) So cs^2 goes like rho^\gamma/(rho+\rho^gamma) and if \gamma>1 then cs^2->0 for rho->0 (while it goes to 1 if rho-> infinity). Am I missing something? Cheers, Bruno -- Prof. Bruno Giacomazzo Department of Physics University of Milano-Bicocca Piazza della Scienza 3 20126 Milano Italy email: bruno.giacomazzo at unimib.it phone: (+39) 02 6448 2321 web: http://www.brunogiacomazzo.org --------------------------------------------------------------------- There are only 10 types of people in the world: Those who understand binary, and those who don't ---------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From schnetter at gmail.com Fri Feb 9 16:45:11 2024 From: schnetter at gmail.com (Erik Schnetter) Date: Fri, 9 Feb 2024 17:45:11 -0500 Subject: [Users] typo in GRHydro thorn guide? In-Reply-To: References: Message-ID: Bruno I find the statement itself weird ? the hydrodynamics equations break down, full stop. What happens to the speed of sound and whether it is even still defined depends on how to approach the vacuum limit. For example, one can argue that the temperature will increase if one goes to vacuum (it does in space), and thus the speed of sound would increase. I would remove any statement about the speed of sound, and maybe add the physical reason why the limit is not defined, with the mean free path length becoming too large (hence we don't have thermodynamics any more). Apart from this your calculation looks correct to me. If you take \rho -> 0 with k = const and \gamma = const then cs -> 0 . -erik On Fri, Feb 9, 2024 at 10:16?AM Bruno Giacomazzo wrote: > > The GRHydro thorn guide (https://einsteintoolkit.org/thornguide/EinsteinEvolve/GRHydro/documentation.html) contains the following sentence: "However, in the vacuum limit the continuity equations describing the fluid break down. The speed of sound tends to the speed of light and everything fails (especially the conversion from conserved to primitive variables)." > > A student of mine wrote that the sound speed tends to the speed of light if rho tends to zero citing this, but is this correct? > > For example, taking a polytropic EOS P=k*rho^\gamma, the sound speed squared is (assuming c=1) > > cs^2= \gamma * k * rho^\gamma / (rho*h) > > with > > rho*h=rho+rho*eps+P=rho+\gamma*P/(\gamma-1) > > So cs^2 goes like rho^\gamma/(rho+\rho^gamma) and if \gamma>1 then cs^2->0 for rho->0 (while it goes to 1 if rho-> infinity). > > Am I missing something? > > Cheers, > Bruno > > -- > > Prof. Bruno Giacomazzo > Department of Physics > University of Milano-Bicocca > Piazza della Scienza 3 > 20126 Milano > Italy > > email: bruno.giacomazzo at unimib.it > phone: (+39) 02 6448 2321 > web: http://www.brunogiacomazzo.org > > --------------------------------------------------------------------- > There are only 10 types of people in the world: > Those who understand binary, and those who don't > ---------------------------------------------------------------------- > > _______________________________________________ > Users mailing list > Users at einsteintoolkit.org > http://lists.einsteintoolkit.org/mailman/listinfo/users -- Erik Schnetter http://www.perimeterinstitute.ca/personal/eschnetter/ From rhaas at illinois.edu Mon Feb 12 15:18:01 2024 From: rhaas at illinois.edu (rhaas at illinois.edu) Date: Mon, 12 Feb 2024 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 Feb 14 17:15:01 2024 From: rhaas at illinois.edu (rhaas at illinois.edu) Date: Wed, 14 Feb 2024 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 Feb 15 09:41:33 2024 From: scupp1 at my.apsu.edu (Cupp, Samuel D.) Date: Thu, 15 Feb 2024 15:41:33 +0000 Subject: [Users] Meeting minutes 2024-02-15 Message-ID: Present: Sam Roland Steve Zach Peter Leo Spec benchmarks We made it to the second stage, so they should combine both and send the check to Steve. Proposed release contributions (and code champions): Multipole (Lucas) NewRadX (Cheng-Hsin) Z4c (Erik) Baikal/BaikalVacuum (Sam) generated from NRPy 2.0 Baikal/BaikalVacuumX (Sam) NRPyPN (Zach)generated from NRPy 2.0 FUKA? GRHayLHD update for tabulated EOS IllinoisGRMHD updated to use GRHayL Compilation on Mac homebrew: Roland has made some progress Might require backports of changes to external libraries Other issues with e.g. FLRWSolver due to difficulties in build system Tickets Issue #2770 fixed in master needs to be backported to previous release Issue #2774 Lots of details, reproducible examples given by Jose Next week's chair - Sam Next week's minute taker - Leo -------------- next part -------------- An HTML attachment was scrubbed... URL: From rolanhaas at web.de Thu Feb 15 09:51:50 2024 From: rolanhaas at web.de (Roland Haas) Date: Thu, 15 Feb 2024 09:51:50 -0600 Subject: [Users] test email 1 Message-ID: <20240215095150.57f5d021@ekohaes8> Hello all, This is a test of the Einstein Toolkit users mailing list. If this was a real email it would contain some actual text. Yours, Roland From rhaas at illinois.edu Fri Feb 16 10:27:36 2024 From: rhaas at illinois.edu (Roland Haas) Date: Fri, 16 Feb 2024 10:27:36 -0600 Subject: [Users] users@einsteintoolkit.org Message-ID: <20240216102716.7b832525@ekohaes8> Hello Samuel, Sorry for the long delay in responding. We are experiencing some issues with the mailing list making incoming emails not be correctly forwarded all the time. Thank you for your interest in the toolkit. The thorns in the Canuda repository (ScalarBase, ScalarEvolve, etc.) would indeed seem to be suitable for your application and somewhat similar research is being done in Helvi Witek's research group at UIUC, who is also one of the maintainers and authors of the Canuda code. I believe that e.g. initial data can be produces using eg the TwoPunctures_KerrProca thorn (or a slight modification of it if a scalar rather than a Proca field is required). I have put her and the other maintainers (as listed in the README file) in CC. They may most likely be able to provide more detailed comments (or redirect you to a colleague closer to your timezone that can help). Yours, Roland > Hi! > > My name is Samuel G?mez, physics student doing his master in Uppsala > university, Sweden. Currently I am doing my master thesis with Joshua > Eby from Stockholm University about the phenomenology of > Gravitational Atoms around Neutron Stars and Black Holes. > > I would like to perform numerical simulations for a BH binary merger > around a scalar cloud with EinsteinToolkit. From now, I have been > able to simulate the example of the TOV star given in the > EinteinToolkit official page in my laptop and soon I will gain access > to a computer cluster where I hopefully will be able to install the > Toolkit and perform a simulation for the example of a binary merger. > But my aim is to be able to perform, maybe in its simplest version, a > simulation of a merger around a scalar field, extracting information > about both the evolution of the BHs and the scalar field itself. > > The problem I face is that I am not sure at all if I will be able to > do it without any parameter file. As far as I understood, my current > version of the Toolkit already has installed thorns related with the > implementation of a scalar field (if I am not mistaken, one example > is ScalarBase). I thus send this email asking if it is possible to > obtain a parameter file for simulating this scenario, or to provide > me with any information about an existing tutorial on how to write > one. Something like this would help me a lot. I would appreciate any > answer. > > Thanks! -- 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 Fri Feb 16 10:31:12 2024 From: rhaas at illinois.edu (Roland Haas) Date: Fri, 16 Feb 2024 10:31:12 -0600 Subject: [Users] Parameter file for a binary BH merger immersed in a scalar field Message-ID: <20240216103112.77cc6304@ekohaes8> Hello Samuel, Sorry for the long delay in responding. We are experiencing some issues with the mailing list making incoming emails not be correctly forwarded all the time. Thank you for your interest in the toolkit. The thorns in the Canuda repository (ScalarBase, ScalarEvolve, etc.) would indeed seem to be suitable for your application and somewhat similar research is being done in Helvi Witek's research group at UIUC, who is also one of the maintainers and authors of the Canuda code. I believe that e.g. initial data can be produces using eg the TwoPunctures_KerrProca thorn (or a slight modification of it if a scalar rather than a Proca field is required). I have put her and the other maintainers (as listed in the README file) in CC. They may most likely be able to provide more detailed comments (or redirect you to a colleague closer to your timezone that can help). Yours, Roland > Hi! > > My name is Samuel G?mez, physics student doing his master in Uppsala > university, Sweden. Currently I am doing my master thesis with Joshua > Eby from Stockholm University about the phenomenology of > Gravitational Atoms around Neutron Stars and Black Holes. > > I would like to perform numerical simulations for a BH binary merger > around a scalar cloud with EinsteinToolkit. From now, I have been > able to simulate the example of the TOV star given in the > EinteinToolkit official page in my laptop and soon I will gain access > to a computer cluster where I hopefully will be able to install the > Toolkit and perform a simulation for the example of a binary merger. > But my aim is to be able to perform, maybe in its simplest version, a > simulation of a merger around a scalar field, extracting information > about both the evolution of the BHs and the scalar field itself. > > The problem I face is that I am not sure at all if I will be able to > do it without any parameter file. As far as I understood, my current > version of the Toolkit already has installed thorns related with the > implementation of a scalar field (if I am not mistaken, one example > is ScalarBase). I thus send this email asking if it is possible to > obtain a parameter file for simulating this scenario, or to provide > me with any information about an existing tutorial on how to write > one. Something like this would help me a lot. I would appreciate any > answer. > > Thanks! -- 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 gxfsma at rit.edu Fri Feb 16 10:46:24 2024 From: gxfsma at rit.edu (Giuseppe Ficarra) Date: Fri, 16 Feb 2024 16:46:24 +0000 Subject: [Users] Parameter file for a binary BH merger immersed in a scalar field In-Reply-To: <20240216103112.77cc6304@ekohaes8> References: <20240216103112.77cc6304@ekohaes8> Message-ID: Hi Samuel and Roland, I can suggest to start from the tutorial I gave at the RIT last summer that you can find on this repository: https://bitbucket.org/canuda/canuda_tutorial_scalar_rit_july2023/src/main/ Here you can find a complete tutorial and some example parameter files of a black hole binary coupled to a massive scalar field (with or without backreaction). All the parameter files here run with the ET_2023_05 release of the toolkit so I advise to use that version to run this parameter files. Let me know if you have any other question. Best, Giuseppe ________________________________ From: Roland Haas Sent: Friday, February 16, 2024 11:31 To: users at einsteintoolkit.org; samuel.gomez.1940 at student.uu.se Cc: Miguel Zilh?o; Witek, Helvi; Giuseppe Ficarra Subject: Re: [Users] Parameter file for a binary BH merger immersed in a scalar field Hello Samuel, Sorry for the long delay in responding. We are experiencing some issues with the mailing list making incoming emails not be correctly forwarded all the time. Thank you for your interest in the toolkit. The thorns in the Canuda repository (ScalarBase, ScalarEvolve, etc.) would indeed seem to be suitable for your application and somewhat similar research is being done in Helvi Witek's research group at UIUC, who is also one of the maintainers and authors of the Canuda code. I believe that e.g. initial data can be produces using eg the TwoPunctures_KerrProca thorn (or a slight modification of it if a scalar rather than a Proca field is required). I have put her and the other maintainers (as listed in the README file) in CC. They may most likely be able to provide more detailed comments (or redirect you to a colleague closer to your timezone that can help). Yours, Roland > Hi! > > My name is Samuel G?mez, physics student doing his master in Uppsala > university, Sweden. Currently I am doing my master thesis with Joshua > Eby from Stockholm University about the phenomenology of > Gravitational Atoms around Neutron Stars and Black Holes. > > I would like to perform numerical simulations for a BH binary merger > around a scalar cloud with EinsteinToolkit. From now, I have been > able to simulate the example of the TOV star given in the > EinteinToolkit official page in my laptop and soon I will gain access > to a computer cluster where I hopefully will be able to install the > Toolkit and perform a simulation for the example of a binary merger. > But my aim is to be able to perform, maybe in its simplest version, a > simulation of a merger around a scalar field, extracting information > about both the evolution of the BHs and the scalar field itself. > > The problem I face is that I am not sure at all if I will be able to > do it without any parameter file. As far as I understood, my current > version of the Toolkit already has installed thorns related with the > implementation of a scalar field (if I am not mistaken, one example > is ScalarBase). I thus send this email asking if it is possible to > obtain a parameter file for simulating this scenario, or to provide > me with any information about an existing tutorial on how to write > one. Something like this would help me a lot. I would appreciate any > answer. > > Thanks! -- 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 -------------- An HTML attachment was scrubbed... URL: From samuel.gomez.1940 at student.uu.se Fri Feb 16 11:44:34 2024 From: samuel.gomez.1940 at student.uu.se (=?iso-8859-1?Q?Samuel_G=F3mez?=) Date: Fri, 16 Feb 2024 17:44:34 +0000 Subject: [Users] Parameter file for a binary BH merger immersed in a scalar field In-Reply-To: References: <20240216103112.77cc6304@ekohaes8> Message-ID: Alright, thank you very much. This is very helpful. I will take a look at that tutorial and the parameter files. ________________________________ De: Giuseppe Ficarra Enviado: viernes, 16 de febrero de 2024 17:46 Para: users at einsteintoolkit.org ; Samuel G?mez Cc: Miguel Zilh?o ; Witek, Helvi Asunto: Re: [Users] Parameter file for a binary BH merger immersed in a scalar field Hi Samuel and Roland, I can suggest to start from the tutorial I gave at the RIT last summer that you can find on this repository: https://bitbucket.org/canuda/canuda_tutorial_scalar_rit_july2023/src/main/ Here you can find a complete tutorial and some example parameter files of a black hole binary coupled to a massive scalar field (with or without backreaction). All the parameter files here run with the ET_2023_05 release of the toolkit so I advise to use that version to run this parameter files. Let me know if you have any other question. Best, Giuseppe ________________________________ From: Roland Haas Sent: Friday, February 16, 2024 11:31 To: users at einsteintoolkit.org; samuel.gomez.1940 at student.uu.se Cc: Miguel Zilh?o; Witek, Helvi; Giuseppe Ficarra Subject: Re: [Users] Parameter file for a binary BH merger immersed in a scalar field Hello Samuel, Sorry for the long delay in responding. We are experiencing some issues with the mailing list making incoming emails not be correctly forwarded all the time. Thank you for your interest in the toolkit. The thorns in the Canuda repository (ScalarBase, ScalarEvolve, etc.) would indeed seem to be suitable for your application and somewhat similar research is being done in Helvi Witek's research group at UIUC, who is also one of the maintainers and authors of the Canuda code. I believe that e.g. initial data can be produces using eg the TwoPunctures_KerrProca thorn (or a slight modification of it if a scalar rather than a Proca field is required). I have put her and the other maintainers (as listed in the README file) in CC. They may most likely be able to provide more detailed comments (or redirect you to a colleague closer to your timezone that can help). Yours, Roland > Hi! > > My name is Samuel G?mez, physics student doing his master in Uppsala > university, Sweden. Currently I am doing my master thesis with Joshua > Eby from Stockholm University about the phenomenology of > Gravitational Atoms around Neutron Stars and Black Holes. > > I would like to perform numerical simulations for a BH binary merger > around a scalar cloud with EinsteinToolkit. From now, I have been > able to simulate the example of the TOV star given in the > EinteinToolkit official page in my laptop and soon I will gain access > to a computer cluster where I hopefully will be able to install the > Toolkit and perform a simulation for the example of a binary merger. > But my aim is to be able to perform, maybe in its simplest version, a > simulation of a merger around a scalar field, extracting information > about both the evolution of the BHs and the scalar field itself. > > The problem I face is that I am not sure at all if I will be able to > do it without any parameter file. As far as I understood, my current > version of the Toolkit already has installed thorns related with the > implementation of a scalar field (if I am not mistaken, one example > is ScalarBase). I thus send this email asking if it is possible to > obtain a parameter file for simulating this scenario, or to provide > me with any information about an existing tutorial on how to write > one. Something like this would help me a lot. I would appreciate any > answer. > > Thanks! -- 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 -------------- An HTML attachment was scrubbed... URL: From rhaas at illinois.edu Mon Feb 19 15:18:01 2024 From: rhaas at illinois.edu (rhaas at illinois.edu) Date: Mon, 19 Feb 2024 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 bruno.giacomazzo at unimib.it Wed Feb 21 12:56:22 2024 From: bruno.giacomazzo at unimib.it (Bruno Giacomazzo) Date: Wed, 21 Feb 2024 19:56:22 +0100 Subject: [Users] postdoc position between Milan, Jena and Warsaw In-Reply-To: References: <24651CB4-8D70-4868-B29F-718F4671055D@unifi.it> Message-ID: FYI ---------- Forwarded message --------- Da: Luca Del Zanna Date: mar 20 feb 2024 alle ore 19:17 Postdoc position on MHD simulations of magnetised neutron stars with prof Brynmor Haskell and prof Sebastiano Bernuzzi (part time in Milano, Jena, and Warsaw, to be arranged), deadline THIS FRIDAY 23: https://www.camk.edu.pl/en/archiwum/2024/01/22/postdoctoral-position-on-mhd-simulations-of-magnetised-neutron-stars/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhaas at illinois.edu Wed Feb 21 17:15:01 2024 From: rhaas at illinois.edu (rhaas at illinois.edu) Date: Wed, 21 Feb 2024 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 Feb 22 09:32:49 2024 From: rhaas at illinois.edu (Roland Haas) Date: Thu, 22 Feb 2024 09:32:49 -0600 Subject: [Users] Compiling ET_2023_11 on Sciama In-Reply-To: <280145465.2239788.1706291399012@mail.yahoo.com> References: <280145465.2239788.1706291399012.ref@mail.yahoo.com> <280145465.2239788.1706291399012@mail.yahoo.com> Message-ID: <20240222093249.2ed1f810@ekohaes8> Hello Robyn, all, Just responding here to "close" the conversation. Robyn and I have had an offline discussion and I was able to help with higher level issue that was what triggered to attempt at using the newer release. Yours, Roland > Hi everyone, > I've been unsuccessfully trying to run the latest version of Einstein > Toolkit on the Sciama HPC cluster where I have been using the 2020_05 > version so far.?Could someone please help? I have tried three > different approaches and put the terminal output and config.log files > of each in the folder here (too heavy for > email)Compiling_ET_2023_11_on_Sciama - Google Drive as well as the > Sciama config files I used in the B approach. > > A) Using the config files already included in Einstein Toolkit, using > intel_comp/2019.2 it gives the error Cactus requires a C++11 compiler > -- check your C++ compiler and C++ compiler flags > > If using g++ at least version 6 is required, if using icpc use > -gxx-name to use libstc++ from g++ at least version 6 I tried using > intel_comp/2020.1?(the latest available on Sciama) and got the same > error (and some module warnings). I found the path to g++ and so > tried to add -gxx-name = > /opt/apps/compilers/gnu_comp/cfg/9.1.0/intel64/bin/g++ to?CXXFLAGS in > sciama.cfg but this didn't change anything. B) Using gnu_comp/13.2.0 > instead, I changed modules and flags where you can see in the Google > Drive folder the .ini and .cfg files I use.?It compiles all the way > to the part "Creating cactus_sim" where it lists all the thorns then > I get lots?of errors of the type patch_system.cc:(.text+0xbe): > undefined reference to `H5open' > > /usr/bin/ld: Dwarf Error: found dwarf version '1', this reader only > handles version 2, 3 and 4 information. I have this message for lots > of files .cc, .c, .f90 undefined reference to lots of different H5 > functions (and also?dsytrf_?dgetrf_?dgesv_??dsysv_??dposv_??dgbsv_) > complaining about dwarf version 'any number'. The only other somewhat > similar example I found of this online is here > https://urldefense.com/v3/__https://github.com/tinygo-org/tinygo/issues/1415__;!!DZ3fjg!9mjP-VFecdeSB1L_ZQPEPFbDRHvM6zAk-eawkY7KzjykhzljCNXf7RKt-MwIZIuXct1A_TaOwfU6QxsJ5eDxq8I$ > ?but it's not that helpful. I'm guessing it's unhappy with hdf5, > unfortunately, the latest version on Sciama is 1.10.5. Do I just need > a later version of hdf5 or is this something else? C)?I tried with > the EinsteinToolkit hdf5 (that I see is version?1.12.0)? with > HDF5_DIR = BUILD and commented out HDF5_LIB_DIRS and HDF5_INC_DIRS, > as it compiles it doesn't get as far. In the output, I'm under the > impression it manages to build it properly, but later it seems to not > be unable to find it, but it should just be within Einstein Toolkit > right? Thank you for your help,Robyn > > -- 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 wernecklr at gmail.com Thu Feb 22 09:46:09 2024 From: wernecklr at gmail.com (Leo Rosa Werneck) Date: Thu, 22 Feb 2024 07:46:09 -0800 Subject: [Users] Meeting minutes for 2024-02-22 Message-ID: Hi all, Here are the minutes for today?s meeting. Chair: Sam Cupp Minutes: Leo Werneck Present: Sam Cupp, Leo Werneck, Peter Diener, Roland Haas, Samuel Tootle, Steve Brandt * ET Release - Champions/reviewers available in the minutes/agenda of previous meeting: https://docs.einsteintoolkit.org/et-docs/Meeting_agenda - FUKA: Champion Samuel Tootle, no reviewer needed since changes are small - FUKA Gallery Example: Samuel would like to provide a BHNS example. Roland suggested providing an example that can be compared against LORENE, so users can learn how to use FUKA if they know how to use LORENE. BHNS difficulty is related to tracking and refinement level adding/removing. Samuel will discuss with Leo how to use the volume integrals thorn. * Mailing List - Does Steve know why the mailing list stopped working in Feb? No. - There are a few messages regarding compilation problems. Roland will reply. * Open Tickets - #2772: Samuel and Roland figured out the compilation issues with Kadath - #2647: Needs reviewer * Tickets ready for review - No updates, tickets are not yet ready to be closed. Next Chair: Leo Next Minutes: Roland Best, 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 bozzola.gabriele at gmail.com Thu Feb 22 12:39:34 2024 From: bozzola.gabriele at gmail.com (Gabriele Bozzola) Date: Thu, 22 Feb 2024 10:39:34 -0800 Subject: [Users] Job ad: Software Engineer/Computational Physicist for climate modelling at CliMA Message-ID: Dear Einstein Toolkit community, CliMA is hiring a software engineer/computational physicist. Numerical relativists are an exceptional fit for the position. At CliMA, we are using Julia to build a brand new climate model for the 21st century (open source, with modern computational infrastructure, machine-learning ready, ...). It might be surprising to hear, but there is a large overlap between climate modelling and numerical relativity: we solve fluid dynamic equations, use differential geometry, run simulations on large clusters, and much more. Learn more about the position: https://clima.caltech.edu/join-our-team/ Feel free to reach out for more information. Best, Gabriele -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruno.giacomazzo at unimib.it Mon Feb 26 10:08:42 2024 From: bruno.giacomazzo at unimib.it (Bruno Giacomazzo) Date: Mon, 26 Feb 2024 17:08:42 +0100 Subject: [Users] DTP/TALENT School on Nuclear Theory for Astrophysics In-Reply-To: References: Message-ID: Dear All, Almudena Arcones (TU Darmstadt), Jorge Piekarewicz (Florida State University), and I have organized a 3-week long school on nuclear astrophysics that will be held at ECT* (Trento, Italy) from 15 July to 2 August. The school will cover: 1) the equation of state of neutron-rich matter and new constraints inferred from nuclear theory, experiment and observations; 2) core-collapse supernova as the birthplace of neutron stars; 3) neutron star mergers and gravitational waves to probe the neutron-star interior. More information about the school and the registration process can be found here: https://www.ectstar.eu/trainings/dtp-talent-2024-nuclear-theory-for-astrophysics/ Cheers, Bruno -- Prof. Bruno Giacomazzo Department of Physics University of Milano-Bicocca Piazza della Scienza 3 20126 Milano Italy email: bruno.giacomazzo at unimib.it phone: (+39) 02 6448 2321 web: http://www.brunogiacomazzo.org --------------------------------------------------------------------- There are only 10 types of people in the world: Those who understand binary, and those who don't ---------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhaas at illinois.edu Mon Feb 26 15:18:01 2024 From: rhaas at illinois.edu (rhaas at illinois.edu) Date: Mon, 26 Feb 2024 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 lorenzo.cipriani at graduate.univaq.it Wed Feb 28 10:52:39 2024 From: lorenzo.cipriani at graduate.univaq.it (Lorenzo Cipriani) Date: Wed, 28 Feb 2024 16:52:39 +0000 Subject: [Users] Residual eccentricity in BNS Message-ID: Hi everyone, I hope this message finds you well. I am running an equal mass BNS simulation and I find that the Newtonian distance from the origin of the center of mass of one star has strong oscillations that seem to be due to a residual eccentricity in the initial data (computed with Lorene). A modulation is also present in the GW strain and doesn't seem to disappear changing the omega_0 parameter in the fixed frequency integration to compute h (I use Kuibit by the way). I have a few questions: ??????1) Does the eccentricity in the ID grow only if the two stars are closer or are there other relevant parameters? ??????2) Given an initial eccentricity, do lower masses simply show the modulation more (since the modulus of the strain is smaller)? ??????3) Looking online I have found references to a routine to reduce eccentricity for BBH simulations. Is there anything similar for BNS? I know some residual eccentricity is to be expected, but this seems excessive. For reference I have uploaded the parameter file as well. Thank you very much, Lorenzo Cipriani -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gw.png Type: image/png Size: 114025 bytes Desc: gw.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: distance.png Type: image/png Size: 94801 bytes Desc: distance.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: parameters.par Type: application/octet-stream Size: 31358 bytes Desc: parameters.par URL: From tootle at itp.uni-frankfurt.de Wed Feb 28 11:31:43 2024 From: tootle at itp.uni-frankfurt.de (Samuel Tootle) Date: Wed, 28 Feb 2024 09:31:43 -0800 (PST) Subject: [Users] Residual eccentricity in BNS In-Reply-To: References: Message-ID: Hi Lorenzo, For closer separations the eccentricity can grow as the approximations of time symmetry and quasi-equilibrium become increasingly less accurate. The differences due to component masses would be negligible in comparison. Indeed eccentricity reduction is possible and we have implemented this in the FUKA codes, however, I am not aware of this capability currently existing in Lorene. Be default FUKA solutions utilize 3.5PN estimates to reduce residual eccentricity prior to an initial evolution. In most cases this is sufficient, but further reduction is also possible by fixing certain parameters (omega and adot, see https://arxiv.org/abs/2103.09911 for details). Though, for equal mass such methods are usually not necessary. Hopefully someone with more experience with Lorene can chime in, but I hope the above answers some of your inquiries. Warm regards, Samuel Tootle Postdoctoral Researcher Physics Department University of Idaho Feb 28, 2024 08:56:42 Lorenzo Cipriani : > Hi everyone, > > I hope this message finds you well. > > I am running an equal mass BNS simulation and I find that the Newtonian distance from the origin of the center of mass of one star has strong oscillations that seem to be due to a residual eccentricity in the initial data (computed with Lorene). A modulation is also present in the GW strain and doesn't seem to disappear changing the omega_0 parameter in the fixed frequency integration to compute h (I use Kuibit by the way). > > I have a few questions: > ??????1) Does the eccentricity in the ID grow only if the two stars are closer or are there other relevant parameters? > ??????2) Given an initial eccentricity, do lower masses simply show the modulation more (since the modulus of the strain is smaller)? > ??????3) Looking online I have found references to a routine to reduce eccentricity for BBH simulations. Is there anything similar for BNS? > > I know some residual eccentricity is to be expected, but this seems excessive. For reference I have uploaded the parameter file as well. > > Thank you very much, > Lorenzo Cipriani -------------- next part -------------- An HTML attachment was scrubbed... URL: From hwitek at illinois.edu Wed Feb 28 11:42:37 2024 From: hwitek at illinois.edu (Helvi Witek) Date: Wed, 28 Feb 2024 11:42:37 -0600 Subject: [Users] Workshop "New frontiers in Strong Gravity III" in Benasque, 7-19 July 2024 - 2nd announcement Message-ID: 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 is now open at the website https://benasque.org/2024relativity/ where you can find further information. Objective of the workshop: 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, 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 -? 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 - Justin Vines * 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 Feb 28 17:15:01 2024 From: rhaas at illinois.edu (rhaas at illinois.edu) Date: Wed, 28 Feb 2024 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 Feb 29 09:29:42 2024 From: rhaas at illinois.edu (Roland Haas) Date: Thu, 29 Feb 2024 09:29:42 -0600 Subject: [Users] meeting minutes for 2024-02-29 Message-ID: <20240229092942.7124a627@ekohaes8> Present: Sam, Leo, Peter, Roland, Zach * did no reach quota * discussed book chapter with Springer, Roland to solicit extra authors for GRhydro section * no new emails * no new tickets 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 Feb 29 13:58:25 2024 From: physicsbeany at gmail.com (Bernard Kelly) Date: Thu, 29 Feb 2024 14:58:25 -0500 Subject: [Users] WeylScal4 failing testsuites with ET_2023_11 Message-ID: Hi. I just tried running a parameter file with WeylScal4 using the ET_2023_11 release, and it fails during the pre-initial stage, with screen output like the following: ------------- NFO (CarpetIOHDF5): I/O Method 'IOHDF5_1D' registered: 1D AMR output of grid variables to HDF5 files INFO (CarpetIOHDF5): I/O Method 'IOHDF5_2D' registered: 2D AMR output of grid variables to HDF5 files INFO (CarpetIOHDF5): Periodic 2D AMR output requested for: ML_ADMCONSTRAINTS::H INFO (CarpetIOHDF5): I/O Method 'IOHDF5_3D' registered: 3D AMR output of grid variables to HDF5 files INFO (CarpetIOScalar): Periodic scalar output requested for: ML_BSSN::H ML_BSSN::M1 ML_BSSN::M2 ML_BSSN::M3 cactus_sim_ET_2023_11_WS4_ORIG: /nobackupp19/bjkelly1/codes/Cactus_ET_2023_11/configs/sim/build/Cactus/main/RDWR.cc:336: int cctki_RDWR::CCTK_HasAccess(const _cGH *, int): Assertion `current_function->RDWR' failed. Rank 3 with PID 73750 received signal 6 Writing backtrace to Kerr_LES_StandardSpin_VACUUM_dx032_WS4_ORIG/backtrace.3.txt ------------- I tried to run the WeylScal4 testsuites too (Teukolsky etc), with the same "Assertion `current_function->RDWR' failed" message. Just to check, I went back an ET release (ET_2023_05), and did the same test, and the tests ran & passed. So did something happen between releases to change the behavior of WeylScal4? And would it affect other Kranc-generated thorns too? Thanks, Bernard -- ------------------------------------------------------------------ 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 scupp1 at my.apsu.edu Thu Feb 29 14:23:19 2024 From: scupp1 at my.apsu.edu (Cupp, Samuel D.) Date: Thu, 29 Feb 2024 20:23:19 +0000 Subject: [Users] WeylScal4 failing testsuites with ET_2023_11 In-Reply-To: References: Message-ID: Hi Bernard, Is your parfile setting the parameter presync_mode? Alternatively, did you compile in debug mode? I ask this because that function has the following code static bool presync_only = CCTK_Equals(presync_mode, "presync-only"); #ifndef CCTK_DEBUG if(!presync_only) return true; #endif Unless I'm reading this section incorrectly, the code shouldn't reach that assertion unless its in debug mode or the mode is "presync-only". Samuel Cupp Postdoctoral Researcher Department of Physics University of Idaho ________________________________ From: Users on behalf of Bernard Kelly Sent: Thursday, February 29, 2024 11:58 AM To: Einstein Toolkit Users Subject: [Users] WeylScal4 failing testsuites with ET_2023_11 Hi. I just tried running a parameter file with WeylScal4 using the ET_2023_11 release, and it fails during the pre-initial stage, with screen output like the following: ------------- NFO (CarpetIOHDF5): I/O Method 'IOHDF5_1D' registered: 1D AMR output of grid variables to HDF5 files INFO (CarpetIOHDF5): I/O Method 'IOHDF5_2D' registered: 2D AMR output of grid variables to HDF5 files INFO (CarpetIOHDF5): Periodic 2D AMR output requested for: ML_ADMCONSTRAINTS::H INFO (CarpetIOHDF5): I/O Method 'IOHDF5_3D' registered: 3D AMR output of grid variables to HDF5 files INFO (CarpetIOScalar): Periodic scalar output requested for: ML_BSSN::H ML_BSSN::M1 ML_BSSN::M2 ML_BSSN::M3 cactus_sim_ET_2023_11_WS4_ORIG: /nobackupp19/bjkelly1/codes/Cactus_ET_2023_11/configs/sim/build/Cactus/main/RDWR.cc:336: int cctki_RDWR::CCTK_HasAccess(const _cGH *, int): Assertion `current_function->RDWR' failed. Rank 3 with PID 73750 received signal 6 Writing backtrace to Kerr_LES_StandardSpin_VACUUM_dx032_WS4_ORIG/backtrace.3.txt ------------- I tried to run the WeylScal4 testsuites too (Teukolsky etc), with the same "Assertion `current_function->RDWR' failed" message. Just to check, I went back an ET release (ET_2023_05), and did the same test, and the tests ran & passed. So did something happen between releases to change the behavior of WeylScal4? And would it affect other Kranc-generated thorns too? Thanks, Bernard -- ------------------------------------------------------------------ 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 physicsbeany at gmail.com Thu Feb 29 14:29:22 2024 From: physicsbeany at gmail.com (Bernard Kelly) Date: Thu, 29 Feb 2024 15:29:22 -0500 Subject: [Users] WeylScal4 failing testsuites with ET_2023_11 In-Reply-To: References: Message-ID: Hi Samuel. Thanks for the quick response. For both code releases (ET_2023_05 and ET_2023_11), I have DEBUG=yes in my config. Now that you've pointed it out, I *could* recompile from scratch with DEBUG=no ... but should I have to? And is this just covering up an actual bug (as the name implies)? Bernard On Thu, Feb 29, 2024 at 3:23?PM Cupp, Samuel D. wrote: > Hi Bernard, > Is your parfile setting the parameter presync_mode? Alternatively, did > you compile in debug mode? I ask this because that function has the > following code > > static bool presync_only = CCTK_Equals(presync_mode, "presync-only"); > #ifndef CCTK_DEBUG > if(!presync_only) > return true; > #endif > > Unless I'm reading this section incorrectly, the code shouldn't reach that > assertion unless its in debug mode or the mode is "presync-only". > > Samuel Cupp > Postdoctoral Researcher > Department of Physics > University of Idaho > ------------------------------ > *From:* Users on behalf of Bernard > Kelly > *Sent:* Thursday, February 29, 2024 11:58 AM > *To:* Einstein Toolkit Users > *Subject:* [Users] WeylScal4 failing testsuites with ET_2023_11 > > Hi. I just tried running a parameter file with WeylScal4 using the > ET_2023_11 release, and it fails during the pre-initial stage, with screen > output like the following: > > ------------- > NFO (CarpetIOHDF5): I/O Method 'IOHDF5_1D' registered: 1D AMR output of > grid variables to HDF5 files > INFO (CarpetIOHDF5): I/O Method 'IOHDF5_2D' registered: 2D AMR output of > grid variables to HDF5 files > INFO (CarpetIOHDF5): Periodic 2D AMR output requested for: > ML_ADMCONSTRAINTS::H > INFO (CarpetIOHDF5): I/O Method 'IOHDF5_3D' registered: 3D AMR output of > grid variables to HDF5 files > INFO (CarpetIOScalar): Periodic scalar output requested for: > ML_BSSN::H > ML_BSSN::M1 > ML_BSSN::M2 > ML_BSSN::M3 > cactus_sim_ET_2023_11_WS4_ORIG: > /nobackupp19/bjkelly1/codes/Cactus_ET_2023_11/configs/sim/build/Cactus/main/RDWR.cc:336: > int cctki_RDWR::CCTK_HasAccess(const _cGH *, int): Assertion > `current_function->RDWR' failed. > Rank 3 with PID 73750 received signal 6 > Writing backtrace to > Kerr_LES_StandardSpin_VACUUM_dx032_WS4_ORIG/backtrace.3.txt > ------------- > > I tried to run the WeylScal4 testsuites too (Teukolsky etc), with the same > "Assertion `current_function->RDWR' failed" message. > > Just to check, I went back an ET release (ET_2023_05), and did the same > test, and the tests ran & passed. > > So did something happen between releases to change the behavior of > WeylScal4? And would it affect other Kranc-generated thorns too? > > Thanks, Bernard > > -- > ------------------------------------------------------------------ > 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 > ------------------------------------------------------------------ > -- ------------------------------------------------------------------ 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 scupp1 at my.apsu.edu Thu Feb 29 14:45:54 2024 From: scupp1 at my.apsu.edu (Cupp, Samuel D.) Date: Thu, 29 Feb 2024 20:45:54 +0000 Subject: [Users] WeylScal4 failing testsuites with ET_2023_11 In-Reply-To: References: Message-ID: This should be a bug that only affects debug mode. Looking through the code, I think I've tracked back the issue. The RDWR attribute for functions (set in CCTKi_CreateRDWRData) is only defined if presync_mode is set to something other than "off" (the default). As such, this section of code should be bypassed for that parameter setting. As a quick fix, you could change line 324 of repos/flesh/src/main/RDWR.cc from if(cctkGH == nullptr)) to if(cctkGH == nullptr || CCTK_Equals(presync_mode, "off")) Let me know if that fixes the issue. Samuel Cupp Postdoctoral Researcher Department of Physics University of Idaho ________________________________ From: Bernard Kelly Sent: Thursday, February 29, 2024 12:29 PM To: Cupp, Samuel D. Cc: Einstein Toolkit Users Subject: Re: [Users] WeylScal4 failing testsuites with ET_2023_11 Hi Samuel. Thanks for the quick response. For both code releases (ET_2023_05 and ET_2023_11), I have DEBUG=yes in my config. Now that you've pointed it out, I *could* recompile from scratch with DEBUG=no ... but should I have to? And is this just covering up an actual bug (as the name implies)? Bernard On Thu, Feb 29, 2024 at 3:23?PM Cupp, Samuel D. > wrote: Hi Bernard, Is your parfile setting the parameter presync_mode? Alternatively, did you compile in debug mode? I ask this because that function has the following code static bool presync_only = CCTK_Equals(presync_mode, "presync-only"); #ifndef CCTK_DEBUG if(!presync_only) return true; #endif Unless I'm reading this section incorrectly, the code shouldn't reach that assertion unless its in debug mode or the mode is "presync-only". Samuel Cupp Postdoctoral Researcher Department of Physics University of Idaho ________________________________ From: Users > on behalf of Bernard Kelly > Sent: Thursday, February 29, 2024 11:58 AM To: Einstein Toolkit Users > Subject: [Users] WeylScal4 failing testsuites with ET_2023_11 Hi. I just tried running a parameter file with WeylScal4 using the ET_2023_11 release, and it fails during the pre-initial stage, with screen output like the following: ------------- NFO (CarpetIOHDF5): I/O Method 'IOHDF5_1D' registered: 1D AMR output of grid variables to HDF5 files INFO (CarpetIOHDF5): I/O Method 'IOHDF5_2D' registered: 2D AMR output of grid variables to HDF5 files INFO (CarpetIOHDF5): Periodic 2D AMR output requested for: ML_ADMCONSTRAINTS::H INFO (CarpetIOHDF5): I/O Method 'IOHDF5_3D' registered: 3D AMR output of grid variables to HDF5 files INFO (CarpetIOScalar): Periodic scalar output requested for: ML_BSSN::H ML_BSSN::M1 ML_BSSN::M2 ML_BSSN::M3 cactus_sim_ET_2023_11_WS4_ORIG: /nobackupp19/bjkelly1/codes/Cactus_ET_2023_11/configs/sim/build/Cactus/main/RDWR.cc:336: int cctki_RDWR::CCTK_HasAccess(const _cGH *, int): Assertion `current_function->RDWR' failed. Rank 3 with PID 73750 received signal 6 Writing backtrace to Kerr_LES_StandardSpin_VACUUM_dx032_WS4_ORIG/backtrace.3.txt ------------- I tried to run the WeylScal4 testsuites too (Teukolsky etc), with the same "Assertion `current_function->RDWR' failed" message. Just to check, I went back an ET release (ET_2023_05), and did the same test, and the tests ran & passed. So did something happen between releases to change the behavior of WeylScal4? And would it affect other Kranc-generated thorns too? Thanks, Bernard -- ------------------------------------------------------------------ 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 ------------------------------------------------------------------ -- ------------------------------------------------------------------ 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 Feb 29 15:16:10 2024 From: rhaas at illinois.edu (Roland Haas) Date: Thu, 29 Feb 2024 15:16:10 -0600 Subject: [Users] WeylScal4 failing testsuites with ET_2023_11 In-Reply-To: References: Message-ID: <20240229151610.480c5852@ekohaes8> Hello all, I suspect: hash 4d9935b1 https://bitbucket.org/cactuscode/cactus/commits/4d9935b11d807dc47e6e69478c039e1dd507222c "Cactus: fix problem with current_scheduled_function being a global." before which the if(!presync_only) return true; was always true. See Cactus pull request: https://bitbucket.org/cactuscode/cactus/pull-requests/158 Yours, Roland > This should be a bug that only affects debug mode. Looking through > the code, I think I've tracked back the issue. The RDWR attribute for > functions (set in CCTKi_CreateRDWRData) is only defined if > presync_mode is set to something other than "off" (the default). As > such, this section of code should be bypassed for that parameter > setting. As a quick fix, you could change line 324 of > repos/flesh/src/main/RDWR.cc > > from > > if(cctkGH == nullptr)) > > to > > if(cctkGH == nullptr || CCTK_Equals(presync_mode, "off")) > > Let me know if that fixes the issue. > > Samuel Cupp > Postdoctoral Researcher > Department of Physics > University of Idaho > ________________________________ > From: Bernard Kelly > Sent: Thursday, February 29, 2024 12:29 PM > To: Cupp, Samuel D. > Cc: Einstein Toolkit Users > Subject: Re: [Users] WeylScal4 failing testsuites with ET_2023_11 > > Hi Samuel. Thanks for the quick response. > > For both code releases (ET_2023_05 and ET_2023_11), I have DEBUG=yes > in my config. > > Now that you've pointed it out, I *could* recompile from scratch with > DEBUG=no ... but should I have to? And is this just covering up an > actual bug (as the name implies)? > > Bernard > > On Thu, Feb 29, 2024 at 3:23?PM Cupp, Samuel D. > > wrote: Hi Bernard, > Is your parfile setting the parameter presync_mode? Alternatively, > did you compile in debug mode? I ask this because that function has > the following code > > static bool presync_only = CCTK_Equals(presync_mode, > "presync-only"); #ifndef CCTK_DEBUG > if(!presync_only) > return true; > #endif > > Unless I'm reading this section incorrectly, the code shouldn't reach > that assertion unless its in debug mode or the mode is "presync-only". > > Samuel Cupp > Postdoctoral Researcher > Department of Physics > University of Idaho > ________________________________ > From: Users > > > on behalf of Bernard Kelly > > Sent: > Thursday, February 29, 2024 11:58 AM To: Einstein Toolkit Users > > > Subject: [Users] WeylScal4 failing testsuites with ET_2023_11 > > Hi. I just tried running a parameter file with WeylScal4 using the > ET_2023_11 release, and it fails during the pre-initial stage, with > screen output like the following: > > ------------- > NFO (CarpetIOHDF5): I/O Method 'IOHDF5_1D' registered: 1D AMR output > of grid variables to HDF5 files INFO (CarpetIOHDF5): I/O Method > 'IOHDF5_2D' registered: 2D AMR output of grid variables to HDF5 files > INFO (CarpetIOHDF5): Periodic 2D AMR output requested for: > ML_ADMCONSTRAINTS::H INFO (CarpetIOHDF5): I/O Method 'IOHDF5_3D' > registered: 3D AMR output of grid variables to HDF5 files INFO > (CarpetIOScalar): Periodic scalar output requested for: ML_BSSN::H > ML_BSSN::M1 > ML_BSSN::M2 > ML_BSSN::M3 > cactus_sim_ET_2023_11_WS4_ORIG: > /nobackupp19/bjkelly1/codes/Cactus_ET_2023_11/configs/sim/build/Cactus/main/RDWR.cc:336: > int cctki_RDWR::CCTK_HasAccess(const _cGH *, int): Assertion > `current_function->RDWR' failed. Rank 3 with PID 73750 received > signal 6 Writing backtrace to > Kerr_LES_StandardSpin_VACUUM_dx032_WS4_ORIG/backtrace.3.txt > ------------- > > I tried to run the WeylScal4 testsuites too (Teukolsky etc), with the > same "Assertion `current_function->RDWR' failed" message. > > Just to check, I went back an ET release (ET_2023_05), and did the > same test, and the tests ran & passed. > > So did something happen between releases to change the behavior of > WeylScal4? And would it affect other Kranc-generated thorns too? > > Thanks, Bernard > > -- > ------------------------------------------------------------------ > Bernard Kelly -- CRESST Assistant Research Scientist, NASA/GSFC > Gravitational Astrophysics Laboratory --- Code 663 > > Phone: +1 (301) 286-7243 *** Fax: +1 (301) 286-2226 > Web: > https://urldefense.com/v3/__http://science.gsfc.nasa.gov/sed/bio/bernard.j.kelly__;!!DZ3fjg!_GXFM4O-rtr0fpRH3Gd1uKbVS4goWPCK5mz5-a7mGoVXtTfJkxcgxKinS_SbQU5Ul635-8sg93xUPUi8-5c$ > ORCID: > orcid.org/0000-0002-3326-4454 > ------------------------------------------------------------------ > > > -- > ------------------------------------------------------------------ > Bernard Kelly -- CRESST Assistant Research Scientist, NASA/GSFC > Gravitational Astrophysics Laboratory --- Code 663 > > Phone: +1 (301) 286-7243 *** Fax: +1 (301) 286-2226 > Web: > https://urldefense.com/v3/__http://science.gsfc.nasa.gov/sed/bio/bernard.j.kelly__;!!DZ3fjg!_GXFM4O-rtr0fpRH3Gd1uKbVS4goWPCK5mz5-a7mGoVXtTfJkxcgxKinS_SbQU5Ul635-8sg93xUPUi8-5c$ > ORCID: > orcid.org/0000-0002-3326-4454 > ------------------------------------------------------------------ -- 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 Feb 29 15:18:08 2024 From: physicsbeany at gmail.com (Bernard Kelly) Date: Thu, 29 Feb 2024 16:18:08 -0500 Subject: [Users] WeylScal4 failing testsuites with ET_2023_11 In-Reply-To: References: Message-ID: Hi Samuel. Your code fix did indeed fix the problem (without having to compile from scratch with DEBUG=no) -- thanks! (I also compiled on a different machine with DEBUG=no from scratch, and that ran OK too) I don't really understand what's going on here, though. I assume/hope that WeylScal4 will be updated to avoid the need for this patch ... Thanks again, Bernard On Thu, Feb 29, 2024 at 3:45?PM Cupp, Samuel D. wrote: > This should be a bug that only affects debug mode. Looking through the > code, I think I've tracked back the issue. The RDWR attribute for functions (set > in CCTKi_CreateRDWRData) is only defined if presync_mode is set to > something other than "off" (the default). As such, this section of code > should be bypassed for that parameter setting. As a quick fix, you could > change line 324 of repos/flesh/src/main/RDWR.cc > > from > > if(cctkGH == nullptr)) > > to > > if(cctkGH == nullptr || CCTK_Equals(presync_mode, "off")) > > Let me know if that fixes the issue. > > Samuel Cupp > Postdoctoral Researcher > Department of Physics > University of Idaho > ------------------------------ > *From:* Bernard Kelly > *Sent:* Thursday, February 29, 2024 12:29 PM > *To:* Cupp, Samuel D. > *Cc:* Einstein Toolkit Users > *Subject:* Re: [Users] WeylScal4 failing testsuites with ET_2023_11 > > Hi Samuel. Thanks for the quick response. > > For both code releases (ET_2023_05 and ET_2023_11), I have DEBUG=yes in my > config. > > Now that you've pointed it out, I *could* recompile from scratch with > DEBUG=no ... but should I have to? And is this just covering up an actual > bug (as the name implies)? > > Bernard > > On Thu, Feb 29, 2024 at 3:23?PM Cupp, Samuel D. > wrote: > > Hi Bernard, > Is your parfile setting the parameter presync_mode? Alternatively, did > you compile in debug mode? I ask this because that function has the > following code > > static bool presync_only = CCTK_Equals(presync_mode, "presync-only"); > #ifndef CCTK_DEBUG > if(!presync_only) > return true; > #endif > > Unless I'm reading this section incorrectly, the code shouldn't reach that > assertion unless its in debug mode or the mode is "presync-only". > > Samuel Cupp > Postdoctoral Researcher > Department of Physics > University of Idaho > ------------------------------ > *From:* Users on behalf of Bernard > Kelly > *Sent:* Thursday, February 29, 2024 11:58 AM > *To:* Einstein Toolkit Users > *Subject:* [Users] WeylScal4 failing testsuites with ET_2023_11 > > Hi. I just tried running a parameter file with WeylScal4 using the > ET_2023_11 release, and it fails during the pre-initial stage, with screen > output like the following: > > ------------- > NFO (CarpetIOHDF5): I/O Method 'IOHDF5_1D' registered: 1D AMR output of > grid variables to HDF5 files > INFO (CarpetIOHDF5): I/O Method 'IOHDF5_2D' registered: 2D AMR output of > grid variables to HDF5 files > INFO (CarpetIOHDF5): Periodic 2D AMR output requested for: > ML_ADMCONSTRAINTS::H > INFO (CarpetIOHDF5): I/O Method 'IOHDF5_3D' registered: 3D AMR output of > grid variables to HDF5 files > INFO (CarpetIOScalar): Periodic scalar output requested for: > ML_BSSN::H > ML_BSSN::M1 > ML_BSSN::M2 > ML_BSSN::M3 > cactus_sim_ET_2023_11_WS4_ORIG: > /nobackupp19/bjkelly1/codes/Cactus_ET_2023_11/configs/sim/build/Cactus/main/RDWR.cc:336: > int cctki_RDWR::CCTK_HasAccess(const _cGH *, int): Assertion > `current_function->RDWR' failed. > Rank 3 with PID 73750 received signal 6 > Writing backtrace to > Kerr_LES_StandardSpin_VACUUM_dx032_WS4_ORIG/backtrace.3.txt > ------------- > > I tried to run the WeylScal4 testsuites too (Teukolsky etc), with the same > "Assertion `current_function->RDWR' failed" message. > > Just to check, I went back an ET release (ET_2023_05), and did the same > test, and the tests ran & passed. > > So did something happen between releases to change the behavior of > WeylScal4? And would it affect other Kranc-generated thorns too? > > Thanks, Bernard > > -- > ------------------------------------------------------------------ > 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 > ------------------------------------------------------------------ > > > > -- > ------------------------------------------------------------------ > 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 > ------------------------------------------------------------------ > -- ------------------------------------------------------------------ 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: