From users at einsteintoolkit.org Mon Jan 5 15:18:02 2026 From: users at einsteintoolkit.org (users at einsteintoolkit.org) Date: Mon, 05 Jan 2026 15:18:02 -0600 Subject: [Users] Agenda for Thursday's Meeting Message-ID: <695c2a8a.fjrjfkH6+rd381BV%users@einsteintoolkit.org> Please update the Wiki with agenda items for Thursday's meeting. Thanks! https://docs.einsteintoolkit.org/et-docs/meeting_agenda --The Maintainers From timothy.edgin at gmail.com Mon Jan 5 21:05:39 2026 From: timothy.edgin at gmail.com (Timothy Edgin) Date: Mon, 5 Jan 2026 21:05:39 -0600 Subject: [Users] [New Thorn] PrimeResonance - A Discrete Kernel for Manifold Resonance Message-ID: Dear Einstein Toolkit Community, I am writing to announce the release of *PrimeResonance*, a new Thorn developed to explore the intersection of number theory and field resonance within the Cactus framework. Project Overview: The PrimeResonance Thorn implements a discrete computational kernel that maps primorial moduli (P4, P5, P6, etc.) to continuous manifold rotations. This work bridges discrete number theory and continuous field physics, demonstrating that specific discrete phase mappings remain bounded and structurally consistent with the Fine Structure Constant ($\alpha^{-1}$) and the Golden Angle. *Repositories:* - Thorn Source Code: https://github.com/timtiminhous/Prime-Resonance-Thorn (Contains the CCL definitions and source implementation compatible with the Einstein Toolkit) - Mathematical Proofs (LEAN4): https://github.com/timtiminhous/ContinuityEngine (Contains the formal verification of the bridge theorem and kernel stability) License: This work is released under the PolyForm Noncommercial License 1.0. It is free for academic research, education, and non-commercial open source use. Commercial applications require a separate license. I welcome feedback from the community regarding the integration of this kernel into broader relativistic simulations. Best regards, Timothy Edgin Former Cybersecurity Architect / Independent Researcher Timothy Edgin- Senior Cybersecurity Consultant Architect of Polyadmin Incorporated CISSP 832-206-3481 https://polyadmin.com/ *https://www.credly.com/users/timothyedgin/badges * *https://www.linkedin.com/in/timothyedgin/ * [image: ArcSight Logger v7.x Certified Expert] This email communication may contain CONFIDENTIAL INFORMATION WHICH ALSO MAY BE LEGALLY PRIVILEGED and is intended only for the use of the intended recipients identified above. If you are not the intended recipient of this communication, you are hereby notified that any unauthorized review, use, dissemination, distribution, downloading, or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply email, delete the communication and destroy all copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 14910 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Report.lean Type: application/octet-stream Size: 1510 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Prime_Energy_Comparison.png Type: image/png Size: 169274 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Prime_Resonance_Spectrum.png Type: image/png Size: 196840 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: prime_resonance_data.csv Type: text/csv Size: 269 bytes Desc: not available URL: From users at einsteintoolkit.org Wed Jan 7 17:15:01 2026 From: users at einsteintoolkit.org (users at einsteintoolkit.org) Date: Wed, 07 Jan 2026 17:15:01 -0600 Subject: [Users] Einstein Toolkit Meeting Reminder Message-ID: <695ee8f5.6FokXiUyKw8plBQc%users@einsteintoolkit.org> 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 zachetie at gmail.com Thu Jan 8 22:30:13 2026 From: zachetie at gmail.com (Zach Etienne) Date: Thu, 8 Jan 2026 20:30:13 -0800 Subject: [Users] Postdoctoral Position in Numerical Relativity (University of Idaho) Message-ID: Dear Einstein Toolkit Community, A postdoctoral position is available in the Department of Physics at the University of Idaho, focused on advancing numerical relativity methods for compact binary systems. *Apply here: https://uidaho.peopleadmin.com/postings/50495 * The successful candidate will extend efforts such as the Einstein Toolkit, BlackHoles at Home, and the superB project to perform state-of-the-art simulations of compact binaries (e.g., binary black holes, binary neutron stars, and black hole?neutron star binaries). Broader goals include generating accurate predictions for gravitational-wave and multimessenger signals and exploring challenging regions of parameter space. *Required qualifications* - Ph.D. in Physics, Astrophysics, Applied Mathematics, Computer Science/Engineering, or a closely related field by the start date - Demonstrated research in numerical relativity, computational general relativity, or closely related computational physics - Experience with PDE solvers (elliptic and/or hyperbolic), numerical methods, and scientific software development - Proficiency in C/C++ and Python, with experience in HPC environments (e.g., MPI/OpenMP; GPU experience a plus) - Record of peer-reviewed publications appropriate to career stage Preferred qualifications - Strong written and oral scientific communication skills; ability to work independently and collaboratively - Commitment to reproducible research (version control, testing, documentation) - Experience generating binary black hole initial data (conformally flat/curved) on curvilinear/multipatch/multidomain/AMR grids - Experience with Einstein Toolkit, NRPy / NRPyElliptic, GRHayL, IllinoisGRMHD, or comparable NR/GRMHD codes - Background implementing/benchmarking radiation transport (neutrino or photon) in GR - Supercomputer workflows (e.g., Slurm/PBS), CI/testing, and contributions to open-source scientific software - Familiarity with gravitational-wave modeling and catalog/campaign paper authorship Compensation and appointment details - Pay range: $60,000 annually or higher, commensurate with experience - Full-time (FTE 1.0), Exempt, fiscal-year appointment - Continuation is contingent on funding - Background check required for finalists Application materials Please submit the following via the posting: https://uidaho.peopleadmin.com/postings/50495 - CV/Resume - Cover Letter / Letter of Application - Statement of Research - List of References University of Idaho The University of Idaho is located in Moscow, Idaho, in the Palouse region near the Washington state border, with easy access to nearby Pullman, WA. EEO statement: The University of Idaho is an equal employment opportunity employer, including veterans and individuals with disabilities. -Zach ----- Zachariah Etienne Prof. of Physics, U. of Idaho Adjunct Prof. of Physics & Astronomy, West Virginia U. https://etienneresearch.com https://blackholesathome.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From hwitek at illinois.edu Fri Jan 9 09:45:57 2026 From: hwitek at illinois.edu (Helvi Witek) Date: Fri, 9 Jan 2026 09:45:57 -0600 Subject: [Users] Fwd: DCOMP Early Career Office Hours In-Reply-To: <525cb417-0d13-4c1c-b395-1a597764d774@dfw1s10mta161.xt.local> References: <525cb417-0d13-4c1c-b395-1a597764d774@dfw1s10mta161.xt.local> Message-ID: <0483c762-a804-5c14-c07d-aaa7ae646961@illinois.edu> Dear all, the event below may be interesting for some of you, showcasing different career opportunities in computational physics. One of the speakers is Gabriele Bozzola who was a numerical relativist and author of the python package kuibit for analyzing NR data. Best wishes Helvi --------------------------------------------- Dr. Helvi Witek Associate Professor Department of Physics University of Illinois at Urbana-Champaign 247 Loomis Lab 1110 W Green St Urbana, IL 61801 --------------------------------------------- -------- Forwarded Message -------- Subject: DCOMP Early Career Office Hours Date: Fri, 09 Jan 2026 09:22:43 -0600 From: APS DCOMP To: hwitek at illinois.edu DCOMP Early Career Office Hours Dear DCOMP member, Recent years have seen a growing investment in computational research fields such as artificial intelligence, high performance computing, data science, biotech, physics simulators, and many others. This rapid expansion created a demand for specialized experts capable of maintaining and developing the complex computational software infrastructure. In response, the role of *Research Software Engineer *(RSE) has emerged as a distinct and increasingly important career path. A research software engineer combines strong software engineering skills with an understanding of research workflows. RSEs build, maintain, and optimize software that enables scientific discovery, data analysis, simulations, machine learning workflows, and other computational research tasks. They often work in academia, national labs, research institutes, or R&D teams in industry. Join us in our latest *DCOMP Office hours* , where we explore the career prospects and opportunities associated with the RSE career path. *What to Expect:* This event takes form in a one-hour virtual ?office hour? two speakers who are actively involved in the RSE community. They will share their experience in the field, discuss their current roles, and offer practical advice for navigating this career path. The sessions will also include open Q&A segments, giving attendees the opportunity to ask questions and gain candid insights on this specific career path. The coming session is scheduled for *January 21, 2026 at 11 a.m. ET*, and will host: Sandra Gesing Executive Director of US-RSE and Senior Researcher at San Diego Supercomputing Center, where her work focuses on computational workflows as well as distributed and parallel computing which inherently leads to highly interdisciplinary projects. Sandra is also Director of the Center of Excellence for Science Gateways, where she aims at supporting users, developers and providers of science gateways, with keen interest in sustainability of research software, usability of computational methods and reproducibility of research results while advocating for open science initiatives. Gabriele Bozzola Applied Scientist at the Amazon Center for Quantum Computing, where his work focus on the development of tools and techniques for the design and simulation of quantum chips aimed at quantum computing. Prior to joining Amazon, Gabriele was Senior Scientific Software Engineer for the CliMa project at Caltech, where he contributed to the development of robust and accurate open-source models for climate modeling in Julia. *Event details:* * Participants can register to the event here * The initiative is free and open to everyone. However we warmly encourage participants to become members of the Division of Computational Physics of the APS (DCOMP) to further support our community and benefit from continued involvement in its activities (APS Student Members may select up to two divisions and/or topical groups free of charge. The fee for students with more than two divisions and/or topical groups and for early career members is $10. Please visit the Engage website for more information.) *Join the conversation! *Visit your unit's website and log in to your unit's APS Engage discussion community. Ask for career advice, support or mentor members, learn about or share opportunities (e.g. meetings and funding opportunities), and more. ? 2026 American Physical Society | All rights reserved 1 Physics Ellipse, College Park, MD?20740 You are receiving this message because you are a member of the APS Division of Computational Physics. Approved by Francesco Belli, DCOMP Early Career. Update Email Preferences | Contact Us | View Privacy Policy | View Online -------------- next part -------------- An HTML attachment was scrubbed... URL: From users at einsteintoolkit.org Mon Jan 12 15:18:02 2026 From: users at einsteintoolkit.org (users at einsteintoolkit.org) Date: Mon, 12 Jan 2026 15:18:02 -0600 Subject: [Users] Agenda for Thursday's Meeting Message-ID: <6965650a.WYMzSm/r7zZZZ0Hq%users@einsteintoolkit.org> 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 mail.ubc.ca Tue Jan 13 17:01:58 2026 From: rhaas at mail.ubc.ca (Roland Haas) Date: Tue, 13 Jan 2026 15:01:58 -0800 Subject: [Users] Safe check of variable Coordinates::volume_form_state In-Reply-To: <7d03f31719c5411c847624cb34e17430@ua.pt> References: <012372d5d50d4f21bd0900f3e365f943@ua.pt> <20251217100441.73500499@haengie2.phas.ubc.ca> <7d03f31719c5411c847624cb34e17430@ua.pt> Message-ID: <20260113150158.556c8893@haengie2.phas.ubc.ca> Hello Jordan, I took a quick look and Llama's schedule.ccl runs Coordinates_SetInverseJacobian which sets volume_form_state and also volume_form but only based on the Jacobian so does not take the grid spacing into account or overlapping cells. Thornburg04 then schedules its own routine afterwards which overwrites those results. volume_form_state = store_volume_form [...] if (store_volume_form /= 0) then call calc_det3 (Jac, detJ) ! TODO: The volume form d^3x is defined as ! d^3x = da db dc * det(dx / da) * M, ! where M is the mask storing the nominal cell volume volume_form(i,j,k) = detJ end if Yours, Roland > [CAUTION: Non-UBC Email] > > Hi Roland, > > > Thank you very much for your message! I had seen the shorter version > of your reply in the minutes indeed, but thank you for giving a more > detailed answer! > > > When I come back from the holiday season, I will gladly file the bug > report. I would also say that this should be straightforward to fix, > at least about initializing the variable to 0 by default. > > > The consistency between setting the parameter > Coordinates::store_volume_form=yes and having the code still set > Coordinates::volume_form_state = 0 depending on the actual > implementation of the volume form -- if it's even needed -- might be > a different question though. For instance, I think that technically > the system Thornburg04nc should have the volume form computed, but it > doesn't. I suppose that the consistency could be handled at > ParamCheck for example. Please tell me if that would require another > subsequent bug report or not. > > I would say that this renders the usage of CCTK_VarDataPtr on > Coordinates::volume_form still insufficient because its storage > relies on the parameter value, although I get your point about > abusing poisoning there. However (from the top of my head), I > remember that when I used poisoning with Llama (and MLBSSN), the > norm2 of the Hamiltonian constraint was NaN, so I had to turn it off. > > > Let me know if you'd like me to help on the implementation. I'm not > sure about how the process goes and what is the corresponding > involvement, so I don't want to make promises, but I'd happy to > contribute to these (hopefully easy) fixes, if it saves you more time > than it wastes. > > > Best wishes for the holiday season! > > > Jordan > > > > ________________________________ > From: Roland Haas > Sent: Wednesday, December 17, 2025 6:04:41 PM > To: Jordan Nicoules > Cc: users at einsteintoolkit.org > Subject: Re: [Users] Safe check of variable > Coordinates::volume_form_state > > > CUIDADO: Email de um sistema externo. Cuidado com links, anexos e > pedidos de dados/senhas. CAUTION: Email from an external system. Be > careful with links, attachments, and requests for data/passwords. > > Hello Jordan, > > Sorry for the delayed response. This dropped off my radar after > agreeing to try and respond during the last ET call. > > > I'm trying to extend our analysis thorn to tackle multipatch grids > > built with Llama. I want to use Coordinates::volume_form in the > > computation of volume integrals, by setting the corresponding > > parameter Coordinates::store_volume_form = yes. > > > > > > Our standard use case relies on Coordinates::coordinate_system = > > "Thornburg04", for which it works like a charm. However, except for > > this system and the analogous Thornburg13 (I have not tested it so > > far), it seems the variable Coordinates::volume_form_state is not > > modified nor initialized, whatever the value of the parameter > > Coordinates::store_volume_form. > > That would be a bug in the Llama coordinate systems. They should all > at least set up the variable correctly. Would you mind filing a bug > report using > > https://bitbucket.org/einsteintoolkit/tickets/issues/new > > > That makes the parameter insufficient > > by itself to perform checks. Moreover, since the flag is not > > initialized, we also can't simply check its value, which can be > > polluted. I have tried to use Carpet::poison_new_timelevels = yes > > and CarpetLib::poison_new_memory = yes, but it didn't seem to > > solve the issue. > > You can check if a variable has storage using the CCTK_VarDataPtr > function call > (https://einsteintoolkit.org/referencemanual/ReferenceManual.html#x1-217000doc) > but it won't tell you if the values found in there are sensible > (admittedly you could abuse poisoning or this). > > > Hence, I would like to ask if there's another way to check for > > uninitialized values, a safe way to use the variables I mentioned in > > a general case, or any information/subtlety I may have missed? > > I think you captured the intended behaviour and the bugs present. > Should be (one hopes) easy to fix at least in that all coordinate > systems should indicate correctly if the volume form is set up or now. > > > Ultimately, I can directly check Coordinates::coordinate_system, and > > output a warning/error if it's not of the types mentioned above. > > That feels a bit unsatisfactory, although I may default to it. > > Yes, looking at another thorns parameter is somewhat error prone, in > particular if it is a parameter that is private and thus could change > meaning at any moment. > > 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 . -- 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 . From users at einsteintoolkit.org Wed Jan 14 17:15:01 2026 From: users at einsteintoolkit.org (users at einsteintoolkit.org) Date: Wed, 14 Jan 2026 17:15:01 -0600 Subject: [Users] Einstein Toolkit Meeting Reminder Message-ID: <69682375.MmbNMcsrekuRoU3Y%users@einsteintoolkit.org> 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 lucas.t.s.carneiro at gmail.com Thu Jan 15 09:02:41 2026 From: lucas.t.s.carneiro at gmail.com (Lucas Timotheo Sanches) Date: Thu, 15 Jan 2026 09:02:41 -0600 Subject: [Users] Meeting Minutes for 2026-01-08 Message-ID: Present: Lucas (minutes), Steve (chair), Roland, Yosef, Zach, Beyhan, Maxwell, Johnny # Agenda items Release name has been decided: Hypatia https://en.wikipedia.org/wiki/Hypatia Steve says he will have the release timeline ready by the next call # Mailing list Safe check of variable Coordinates::volume_form_state: Roland says the issue is caused because not all coordinates in Llama provide and set volume forms for integration. # Tickets: -2904: Lucas will check if he can do what he wants with current mechanisms, if not we will revisit this. -2909: Steve asks for Roland to take a look at the PR. -2907: No one looked at that yet. -2908: Roland thinks that if this works, it may work for the reason that it's not actually passing a long string to the OS. He wants to find if the arguments are too long, so he passes that into the OS. He will update the ticket. -2903: There's no PR on this yet. From wernecklr at gmail.com Thu Jan 15 09:22:04 2026 From: wernecklr at gmail.com (Leo Rosa Werneck) Date: Thu, 15 Jan 2026 07:22:04 -0800 Subject: [Users] Meeting Minutes for 2026-01-15 Message-ID: Hi all, Here are the minutes for this morning?s meeting. Cheers, Leo ========== Present: Lucas (Chair), Leo (Minutes), Steve, Keith, Zach, Deborah, Johnny, Nikolai ** ET Release ET_2026_05 ** * Call for Proposed New Features: --- * Gallery Runners: Deborah, Lucas, Johnny, Leo. * Timeline: Steve has an initial draft (some dates below) - Mar 1: have new thorns compiling and ready for test. - Apr 1: release-critical testing begins. - Jun 1: release. ** Unanswered Question on Mailing List ** * APS: DCOMP Early Career Office Hours might be useful to some, featuring Gabriele Bozzola as a speaker. * Postdoc position open at University of Idaho (Zach). ** Open Tickets & Tickets for Review ** * #2904: `cctk_patch_is_cartesian` field added to cGH. Not strictly necessary, it is useful to have it an provides a performance optimization to Llama. * #2909: Removing "TAGS=..." to interface.ccl, PR was created. * #2910: Add option to exclude boundaries in 1D tsv output in CarpetX. ------ 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 jnicoules at ua.pt Fri Jan 16 11:11:46 2026 From: jnicoules at ua.pt (Jordan Nicoules) Date: Fri, 16 Jan 2026 17:11:46 +0000 Subject: [Users] Safe check of variable Coordinates::volume_form_state In-Reply-To: <20260113150158.556c8893@haengie2.phas.ubc.ca> References: <012372d5d50d4f21bd0900f3e365f943@ua.pt> <20251217100441.73500499@haengie2.phas.ubc.ca> <7d03f31719c5411c847624cb34e17430@ua.pt>, <20260113150158.556c8893@haengie2.phas.ubc.ca> Message-ID: <78e676778f274b6aa14c2e7576e3a6e1@ua.pt> Hi Roland, Thank you very much for your answer and for pointing that out. Somehow I think that at the time, I was aware of this part of the source code, but I probably missed the fact that it is actually scheduled, even when the inverse Jacobian is not computed. So I guess that this really fixes my problem with checks and simplifies my life in that regard, because the parameter and flags are both set correctly then. However, part of the reason why I thought this was not working properly, is because I was getting wrong numbers at the end of the day, but I attributed a wrong cause to it (bad memory access). Thanks to your comment about the spacing, and the piece of code you emphasized, I went back to doing some testing (with patch system Thornburg04nc), and I think that the problem lies in that the value assignment to the volume form is not consistent with what happens for Thornburg04 in the purely spherical part (with h the spacing): // set volume form to deterimant of Jacobian const CCTK_REAL det = fabs(( J11[ijk] * J22[ijk] * J33[ijk] + J12[ijk] * J23[ijk] * J31[ijk] + J13[ijk] * J21[ijk] * J32[ijk] - J11[ijk] * J23[ijk] * J32[ijk] - J12[ijk] * J21[ijk] * J33[ijk] - J13[ijk] * J22[ijk] * J31[ijk])); volume_form[ijk] = h[0]*h[1]*h[2]/det; If it makes sense (and I'm not misled this time), I will instead open a bug report to change, in inverse-jacobian.F90, volume_form(i,j,k) = detJ into [... definition and attribution to h...] volume_form(i,j,k) = h(1)*h(2)*h(3) / abs(detJ) which does indeed yield correct results for the volume integrals I'm computing. Also note the absolute value, because I've seen that detJ can be negative and it does impact the result at the end. Again, I've limited my tests to Thornburg04 and Thornburg04nc patch systems (and only at t=0 for the latter), for the type of simulations I'm doing. So I don't know if it breaks things somewhere outside, and if the loss of backwards compatibility on that quantity may be a problem. But I think this should improve consistency, and hopefully fit closer to the idea of the variable. This also prevents outsourcing that calculation with the spacing in any user thorn, hence limiting the information it needs to fetch from Coordinates. Best, Jordan ________________________________ From: Roland Haas Sent: Tuesday, January 13, 2026 23:01 To: Jordan Nicoules Cc: users at einsteintoolkit.org Subject: Re: [Users] Safe check of variable Coordinates::volume_form_state CUIDADO: Email de um sistema externo. Cuidado com links, anexos e pedidos de dados/senhas. CAUTION: Email from an external system. Be careful with links, attachments, and requests for data/passwords. Hello Jordan, I took a quick look and Llama's schedule.ccl runs Coordinates_SetInverseJacobian which sets volume_form_state and also volume_form but only based on the Jacobian so does not take the grid spacing into account or overlapping cells. Thornburg04 then schedules its own routine afterwards which overwrites those results. volume_form_state = store_volume_form [...] if (store_volume_form /= 0) then call calc_det3 (Jac, detJ) ! TODO: The volume form d^3x is defined as ! d^3x = da db dc * det(dx / da) * M, ! where M is the mask storing the nominal cell volume volume_form(i,j,k) = detJ end if Yours, Roland > [CAUTION: Non-UBC Email] > > Hi Roland, > > > Thank you very much for your message! I had seen the shorter version > of your reply in the minutes indeed, but thank you for giving a more > detailed answer! > > > When I come back from the holiday season, I will gladly file the bug > report. I would also say that this should be straightforward to fix, > at least about initializing the variable to 0 by default. > > > The consistency between setting the parameter > Coordinates::store_volume_form=yes and having the code still set > Coordinates::volume_form_state = 0 depending on the actual > implementation of the volume form -- if it's even needed -- might be > a different question though. For instance, I think that technically > the system Thornburg04nc should have the volume form computed, but it > doesn't. I suppose that the consistency could be handled at > ParamCheck for example. Please tell me if that would require another > subsequent bug report or not. > > I would say that this renders the usage of CCTK_VarDataPtr on > Coordinates::volume_form still insufficient because its storage > relies on the parameter value, although I get your point about > abusing poisoning there. However (from the top of my head), I > remember that when I used poisoning with Llama (and MLBSSN), the > norm2 of the Hamiltonian constraint was NaN, so I had to turn it off. > > > Let me know if you'd like me to help on the implementation. I'm not > sure about how the process goes and what is the corresponding > involvement, so I don't want to make promises, but I'd happy to > contribute to these (hopefully easy) fixes, if it saves you more time > than it wastes. > > > Best wishes for the holiday season! > > > Jordan > > > > ________________________________ > From: Roland Haas > Sent: Wednesday, December 17, 2025 6:04:41 PM > To: Jordan Nicoules > Cc: users at einsteintoolkit.org > Subject: Re: [Users] Safe check of variable > Coordinates::volume_form_state > > > CUIDADO: Email de um sistema externo. Cuidado com links, anexos e > pedidos de dados/senhas. CAUTION: Email from an external system. Be > careful with links, attachments, and requests for data/passwords. > > Hello Jordan, > > Sorry for the delayed response. This dropped off my radar after > agreeing to try and respond during the last ET call. > > > I'm trying to extend our analysis thorn to tackle multipatch grids > > built with Llama. I want to use Coordinates::volume_form in the > > computation of volume integrals, by setting the corresponding > > parameter Coordinates::store_volume_form = yes. > > > > > > Our standard use case relies on Coordinates::coordinate_system = > > "Thornburg04", for which it works like a charm. However, except for > > this system and the analogous Thornburg13 (I have not tested it so > > far), it seems the variable Coordinates::volume_form_state is not > > modified nor initialized, whatever the value of the parameter > > Coordinates::store_volume_form. > > That would be a bug in the Llama coordinate systems. They should all > at least set up the variable correctly. Would you mind filing a bug > report using > > https://bitbucket.org/einsteintoolkit/tickets/issues/new > > > That makes the parameter insufficient > > by itself to perform checks. Moreover, since the flag is not > > initialized, we also can't simply check its value, which can be > > polluted. I have tried to use Carpet::poison_new_timelevels = yes > > and CarpetLib::poison_new_memory = yes, but it didn't seem to > > solve the issue. > > You can check if a variable has storage using the CCTK_VarDataPtr > function call > (https://einsteintoolkit.org/referencemanual/ReferenceManual.html#x1-217000doc) > but it won't tell you if the values found in there are sensible > (admittedly you could abuse poisoning or this). > > > Hence, I would like to ask if there's another way to check for > > uninitialized values, a safe way to use the variables I mentioned in > > a general case, or any information/subtlety I may have missed? > > I think you captured the intended behaviour and the bugs present. > Should be (one hopes) easy to fix at least in that all coordinate > systems should indicate correctly if the volume form is set up or now. > > > Ultimately, I can directly check Coordinates::coordinate_system, and > > output a warning/error if it's not of the types mentioned above. > > That feels a bit unsatisfactory, although I may default to it. > > Yes, looking at another thorns parameter is somewhat error prone, in > particular if it is a parameter that is private and thus could change > meaning at any moment. > > 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 . -- 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 mail.ubc.ca Fri Jan 16 11:30:03 2026 From: rhaas at mail.ubc.ca (Roland Haas) Date: Fri, 16 Jan 2026 09:30:03 -0800 Subject: [Users] Safe check of variable Coordinates::volume_form_state In-Reply-To: <78e676778f274b6aa14c2e7576e3a6e1@ua.pt> References: <012372d5d50d4f21bd0900f3e365f943@ua.pt> <20251217100441.73500499@haengie2.phas.ubc.ca> <7d03f31719c5411c847624cb34e17430@ua.pt> <20260113150158.556c8893@haengie2.phas.ubc.ca> <78e676778f274b6aa14c2e7576e3a6e1@ua.pt> Message-ID: <20260116093003.6a0de176@haengie2.phas.ubc.ca> Hello Jordan, > However, part of the reason why I thought this was not working > properly, is because I was getting wrong numbers at the end of the > day, but I attributed a wrong cause to it (bad memory access). Thanks > to your comment about the spacing, and the piece of code you > emphasized, I went back to doing some testing (with patch system > Thornburg04nc), and I think that the problem lies in that the value > assignment to the volume form is not consistent with what happens for > Thornburg04 in the purely spherical part (with h the spacing): Correct. The volume_forrm computed by Thornburg04 (and also Thornburg04nc I would guess) differs from the generic one computed otherswise. This is something to be discussed with the Llama developers. > > If it makes sense (and I'm not misled this time), I will instead open > a bug report to change, in inverse-jacobian.F90, > > volume_form(i,j,k) = detJ > > into > > [... definition and attribution to h...] > > volume_form(i,j,k) = h(1)*h(2)*h(3) / abs(detJ) Yes, a bug report would be most welcome. > which does indeed yield correct results for the volume integrals I'm > computing. Also note the absolute value, because I've seen that detJ > can be negative and it does impact the result at the end. There is one remaining issue, namely that this will not take into account the case where there is overlap between coordinate patches. Thornburg04 handles this case by computing the overlap and reducing the volume_factor accordingly (0 for cells that are fully overlapped and a fraction of the volume if the overlap is not total). I don't know on top of my head which other (functioning) coordinate system have overlap between patches. > Again, I've limited my tests to Thornburg04 and Thornburg04nc patch > systems (and only at t=0 for the latter), for the type of simulations > I'm doing. So I don't know if it breaks things somewhere outside, and > if the loss of backwards compatibility on that quantity may be a > problem. Well it would be step forward already to see the improvements that your changes bring. > But I think this should improve consistency, and hopefully fit closer > to the idea of the variable. This also prevents outsourcing that > calculation with the spacing in any user thorn, hence limiting the > information it needs to fetch from Coordinates. Well ideally the results of using Llama should be the same as not using Llama. Eg for a Cartesian only grid we currently have that the "sum" reduction in Carpet computes: Sum(Grid_function) = integral(Grid_function)/(dx_coarse*dy_coarse*dz_coarse) that is the "sum" reduction computes the Riemann integral of a grid function as if the coarsest grid spaccing was 1.0 instead of dx/dy/dz (since Carpet does not actually know that spacing). So this should mean that for Llama the result for Cartesian coordinates should be the same and thus for non-Cartesian coordinates the result of the "sum" reduction should *also* be: integral(Grid_function*volume_form)/(dx_coarse*dy_coarse*dz_coarse) where now dx_coarse etc. are the grid spacing on some map, most conveniently a Cartesian map 0 if it exists (eg in Thornburg04 but not in Thornburg04nc). Which is not quite what Llama produces right now, which would be: Sum(Grid_function*volume_form) = int(Grid_function) if I am not mistaken. But that's a breaking change in Llama from its current behaviour, so will need some discussion. 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 . From users at einsteintoolkit.org Mon Jan 19 15:18:02 2026 From: users at einsteintoolkit.org (users at einsteintoolkit.org) Date: Mon, 19 Jan 2026 15:18:02 -0600 Subject: [Users] Agenda for Thursday's Meeting Message-ID: <696e9f8a.rbZo55NRkXxjAzWl%users@einsteintoolkit.org> Please update the Wiki with agenda items for Thursday's meeting. Thanks! https://docs.einsteintoolkit.org/et-docs/meeting_agenda --The Maintainers From keithdow at keithdow.net Mon Jan 19 22:08:25 2026 From: keithdow at keithdow.net (keithdow@keithdow.net keithdow@keithdow.net) Date: Mon, 19 Jan 2026 23:08:25 -0500 (EST) Subject: [Users] Z4c not found. Message-ID: <266222143.4276511.1768882105624@webmail-oxcs.register.com> ETK group, I am trying to run a binary black hole example on CarpetX and run into a simple error. Error: Thorn Z4c not found. I ran the radiative.par example of WavetoyX fine. I added Z4c to the thorn list and it says again. Error: Thorn Z4c not found. I reloaded and updated everything, but still get the issue. The machine is a DGX Spark running Ubuntu. I appreciate any suggestions. Thanks for your help. Keith -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhaas at mail.ubc.ca Tue Jan 20 09:10:20 2026 From: rhaas at mail.ubc.ca (Roland Haas) Date: Tue, 20 Jan 2026 07:10:20 -0800 Subject: [Users] Z4c not found. In-Reply-To: <266222143.4276511.1768882105624@webmail-oxcs.register.com> References: <266222143.4276511.1768882105624@webmail-oxcs.register.com> Message-ID: <20260120071020.6451b075@haengie2.phas.ubc.ca> Hello Keith, > I ran the radiative.par example of WavetoyX fine. I added Z4c to the > thorn list and it says again. > Error: Thorn Z4c not found. > > I reloaded and updated everything, but still get the issue. The > machine is a DGX Spark running Ubuntu. I appreciate any suggestions. One guess into the blue: when you added the thorn to your thornlist, assuming you had used GetComponents on a thornlist that did not list the thorn, did you at that point also set up a symbolic link from arrangements/SpacetimeX/Z4c to ../../repos/SpacetimeX/Z4c ? And is that link valid, ie does actually point to the correct location? Should look something like this: $ ls -l arrangements/SpacetimeX/ total 8 lrwxrwxrwx 1 rhaas rhaas 30 Apr 17 2025 NewRadX -> ../../repos/SpacetimeX/NewRadX lrwxrwxrwx 1 rhaas rhaas 27 Jan 20 07:09 Z4c -> ../../repos/SpacetimeX/Z4c 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 . From jnicoules at ua.pt Tue Jan 20 09:16:06 2026 From: jnicoules at ua.pt (Jordan Nicoules) Date: Tue, 20 Jan 2026 15:16:06 +0000 Subject: [Users] Safe check of variable Coordinates::volume_form_state In-Reply-To: <20260116093003.6a0de176@haengie2.phas.ubc.ca> References: <012372d5d50d4f21bd0900f3e365f943@ua.pt> <20251217100441.73500499@haengie2.phas.ubc.ca> <7d03f31719c5411c847624cb34e17430@ua.pt> <20260113150158.556c8893@haengie2.phas.ubc.ca> <78e676778f274b6aa14c2e7576e3a6e1@ua.pt>, <20260116093003.6a0de176@haengie2.phas.ubc.ca> Message-ID: <1db01fec5d6d4d469990ba38fe97999a@ua.pt> Hi Roland, > Correct. The volume_forrm computed by Thornburg04 (and also > Thornburg04nc I would guess) differs from the generic one computed > otherswise. > This is something to be discussed with the Llama developers. Thornburg04nc relies on the default behavior, which is why I find it a bit dangerous to have it inconsistent with Thornburg04. I think that Thornburg13 does it like Thornburg04. Maybe there are good reasons to have different behaviors for the volume form with different patch systems, but then again it forces outside code to check for the type of patch system. > Yes, a bug report would be most welcome. Following your advice, I opened one earlier today. > I don't know on top of my head which other (functioning) coordinate > system have overlap between patches. Shouldn't that be done by the concerned patch system anyway, and currently give wrong results if it is not done? > But that's a breaking change in Llama from its current behaviour, so > will need some discussion. Sure, I understand. On that point, I already need to differentiate between Llama and non-Llama runs to fetch or not the volume form, so having different treatments was less of an issue. Best, Jordan -------------- next part -------------- An HTML attachment was scrubbed... URL: From users at einsteintoolkit.org Wed Jan 21 17:15:01 2026 From: users at einsteintoolkit.org (users at einsteintoolkit.org) Date: Wed, 21 Jan 2026 17:15:01 -0600 Subject: [Users] Einstein Toolkit Meeting Reminder Message-ID: <69715df5./Vg4Ss/TJhPiciYJ%users@einsteintoolkit.org> 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 keithdow at keithdow.net Sat Jan 24 17:14:29 2026 From: keithdow at keithdow.net (keithdow@keithdow.net keithdow@keithdow.net) Date: Sat, 24 Jan 2026 18:14:29 -0500 (EST) Subject: [Users] meeting minutes for 2026-01-22 Message-ID: <1654886809.5175459.1769296469572@webmail-oxcs.register.com> [Users] meeting minutes for 2026-01-22 Present: Roland, Keith, Steve, Beyhan, Maxwell, Cheng-Hsin, Deborah, Lucas, Leo Nikolai, Jordan ET release: Dec 1: Step 1 *Release Coordinator: Steve *Coordinator Assistant: *Release Name: Hypatia *Test Runners: Jan 1: Step 2 *Release timeline *Gallery Runners: **Leo - **Deborah - GW15 **Johnny **Beyhan - TOV *Testers: **Roland ? Jan 22: Step 3 *Add call for new features to the website *These are the things to be included as of now **- LSU: Cottonmouth **- UIUC: CandudaX **- Idaho: Bhahaha Mar 1: Step 4 *Choose features, update master thornlist this wonth *Find reviewers for features *Decide on release-critical compute systems *Regenerate auto-generated thorns for the ?rst time Apr 1: Step 5: Start testing *Release-critical testing May 1: Step 6: Release Prep *Feature Freeze *Create Zenodo item *Draft Release Announcement *Conntact contributors and release team about inclusion Jun 1: Step 7: Release ** Unanswered Question on Mailing List ** *Safe check of variable Coordinates::volume_form_state **Volume form grid function depends on coordinates. (Thornburg 04) **Multipatch solution has issue in the overlap **lucas, to make things consistent ** Open Tickets & Tickers for Review ** * #2898 Needs review * #2908 Roland to comment on PR * #2909 Steve has a PR. Roland to take a look. -------------- next part -------------- An HTML attachment was scrubbed... URL: From users at einsteintoolkit.org Mon Jan 26 15:18:01 2026 From: users at einsteintoolkit.org (users at einsteintoolkit.org) Date: Mon, 26 Jan 2026 15:18:01 -0600 Subject: [Users] Agenda for Thursday's Meeting Message-ID: <6977da09.hucSet2I4EbkUIfl%users@einsteintoolkit.org> 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 Tue Jan 27 09:41:58 2026 From: hwitek at illinois.edu (Helvi Witek) Date: Tue, 27 Jan 2026 09:41:58 -0600 Subject: [Users] Fwd: [atpesc-references] ATPESC 2026 In-Reply-To: References: Message-ID: Dear all, please see below the announcement for the?Argonne Training Program on Extreme-Scale Computing, and opening for applications. It is open for PhD students and postdocs. Some of my group members attended the school in recent years and found it very useful. Best wishes, Helvi --------------------------------------------- Dr. Helvi Witek Associate Professor Department of Physics University of Illinois at Urbana-Champaign 247 Loomis Lab 1110 W Green St Urbana, IL 61801 --------------------------------------------- -------- Forwarded Message -------- Subject: [atpesc-references] ATPESC 2026 Date: Tue, 27 Jan 2026 03:03:37 +0000 From: Loy, Raymond M. To: atpesc-references at extremecomputingtraining.anl.gov Dear friends of ATPESC, I am reaching out to you because you have previously recommended students to attend ATPESC.? If you know of any suitable candidates for this year, please let them know?about the opportunity. Thank you! Ray ??? Apply now to learn the tools and techniques needed to carry out computational science on the world's most powerful supercomputers. *ALCF ANNOUNCEMENT* ATPESC?2026: Applications due February 25 ATPESC 2026 ------------------------------------------------------------------------ The annual Argonne Training Program on Extreme-Scale Computing is set to take place July 26 - August 7, 2026. Submit your application by February 25 for an opportunity to learn the tools and techniques needed to carry out computational science on the world's most powerful supercomputers. ATPESC?participants will have access to DOE?s leadership-class systems at the ALCF, OLCF, and NERSC. APPLY HERE *ATPESC**?Q&A WEBINAR* Join us on February 5, 2026, for a webinar that will provide a brief overview of ATPESC?and feature an open Q&A session about the application process. This is a great opportunity to ask any questions you have about the program. REGISTER FOR WEBINAR *PROGRAM CURRICULUM* Renowned scientists and leading HPC experts will serve as lecturers and guide the hands-on training sessions. The core curriculum will cover: * Computer architectures * Numerical algorithms and mathematical software * Software productivity and sustainability * Data analysis, visualization, I/O, and methodologies for?big data applications * Performance measurement and debugging tools * Machine learning and data science *ELIGIBILITY AND APPLICATION* Graduate students, postdocs, and computational scientists interested in attending ATPESC?can review eligibility and application details on the website . There are no fees to participate in ATPESC. Domestic airfare, meals, and lodging are also provided. *Application deadline: February 25, 2026*. /ATPESC//?is supported by the DOE Office of Science Advanced Scientific Computing Research Program./ ------------------------------------------------------------------------ linkedin facebook youtube Instagram US Department of Energy Office of Science Argonne Leadership Computing Facility *Argonne Leadership Computing Facility* 9700 South Cass Avenue, Lemont, IL 60439 www.alcf.anl.gov ??| media at alcf.anl.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- -- atpesc-references mailing list atpesc-references at lists.extremecomputingtraining.anl.gov To unsubscribe or set options, visit https://urldefense.com/v3/__https://lists.extremecomputingtraining.anl.gov/mailman/listinfo/atpesc-references__;!!DZ3fjg!6Tjrb57SJCddsJBa_MmqqzpoRkSkb9UZp-eCNSxUF9d9VafESKzjWWmpkjVEMtBN1mcyovYVJKE_QFjwOtg$ From abderrahimelkhou00 at gmail.com Tue Jan 27 12:39:31 2026 From: abderrahimelkhou00 at gmail.com (Abderrahim El Khou) Date: Tue, 27 Jan 2026 19:39:31 +0100 Subject: [Users] My problems with Thorn Message-ID: Good evening sir, I'm having trouble writing my own thorn; i might have overlooked something important. I'm working on a Linux Ubuntu system; I have Mathematica and i think the problem is with its related with the Kranc. I want to know where i missed the solution. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2026-01-27 19-39-12.png Type: image/png Size: 14452 bytes Desc: not available URL: From abderrahimelkhou00 at gmail.com Tue Jan 27 12:40:33 2026 From: abderrahimelkhou00 at gmail.com (Abderrahim El Khou) Date: Tue, 27 Jan 2026 19:40:33 +0100 Subject: [Users] My problems with Thorn In-Reply-To: References: Message-ID: if it possible i want a tutorial how to write my own thorn if it is thank you a lot On Tue, Jan 27, 2026 at 7:39?PM Abderrahim El Khou < abderrahimelkhou00 at gmail.com> wrote: > Good evening sir, I'm having trouble writing my own thorn; i might have > overlooked something important. I'm working on a Linux Ubuntu system; I > have Mathematica and i think the problem is with its related with the > Kranc. I want to know where i missed the solution. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhaas at mail.ubc.ca Tue Jan 27 13:36:34 2026 From: rhaas at mail.ubc.ca (Roland Haas) Date: Tue, 27 Jan 2026 11:36:34 -0800 Subject: [Users] My problems with Thorn In-Reply-To: References: Message-ID: <20260127113626.4205485a@haengie2.phas.ubc.ca> Hello Abderrahim El Khou, > if it possible i want a tutorial how to write my own thorn if it is > thank you a lot Kranc has an example (the SimpleWave.m one) in: http://kranccode.org/documentation.html though note that it uses the `Bin/kranc` wrapper so that all required Mathematica packages are being found. There are a number of recorded tutorials on how to write a new thorn that you can find in: https://www.youtube.com/playlist?list=PLRxi-yB7cTGc6_RtPA8g3qm2XOGfmvkoH for example: https://youtu.be/PcuPhODh34o?si=tAaM54bRT584N7Qo There's also the CreatingANewThorn-*.ipyb notebooks in: https://github.com/EinsteinToolkit/jupyter-et/tree/master/tutorial-server/notebooks which are actually used in the recording above. 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 . From rhaas at mail.ubc.ca Wed Jan 28 09:28:00 2026 From: rhaas at mail.ubc.ca (Roland Haas) Date: Wed, 28 Jan 2026 07:28:00 -0800 Subject: [Users] My problems with Thorn In-Reply-To: References: <20260127113626.4205485a@haengie2.phas.ubc.ca> Message-ID: <20260128072800.235a7113@haengie2.phas.ubc.ca> Hello Abderrahim El Khou, You do not really have to run the tutorial notebooks through jupyter, you can just use jupyter as a viewer for the information and follow along using the video recording. If you do not have Jupyter installed then github's online viewer also works. e.g.: https://github.com/EinsteinToolkit/jupyter-et/blob/master/tutorial-server/notebooks/CreatingANewThorn-HeatEqn.ipynb you can see the content that goes into the individual files in the cells that start with %writefile and the remainder of that cell is the content written to the file. SimpleWave.m is an example on how to use Kranc to generate a thorn. If you intent to use Kranc then it is a good first example to start with. Many more complex thorns are generated using Kranc eg the WeylScal4 thorn, the mclachlan thorns and the EinsteinExact thorns. If you would rather write a thorn using C/C++ or Fortran then Yosef's lecture on how to create a heat equation / wave equation may be your best starting point. Or you can use one of the very old examples of how to implement a wave equation, like the attached one. There's not video recording of it though. Yours, Roland > [CAUTION: Non-UBC Email] > > I found one problem here, i don't work with Juypter so the language is > confusing me a little bit so i start following the example that you give me > at the first "the SimpleWave.m" my question here is it necessarily to take > the same process for any create of other thorns or the is just for the > simple wave, if no what is the solution please. > Thank you a lot sir. > > On Tue, Jan 27, 2026 at 8:36?PM Roland Haas wrote: > > > Hello Abderrahim El Khou, > > > > > if it possible i want a tutorial how to write my own thorn if it is > > > thank you a lot > > > > Kranc has an example (the SimpleWave.m one) in: > > > > http://kranccode.org/documentation.html > > > > though note that it uses the `Bin/kranc` wrapper so that all required > > Mathematica packages are being found. > > > > There are a number of recorded tutorials on how to write a new thorn > > that you can find in: > > > > https://www.youtube.com/playlist?list=PLRxi-yB7cTGc6_RtPA8g3qm2XOGfmvkoH > > > > for example: > > > > https://youtu.be/PcuPhODh34o?si=tAaM54bRT584N7Qo > > > > There's also the CreatingANewThorn-*.ipyb notebooks in: > > > > > > https://github.com/EinsteinToolkit/jupyter-et/tree/master/tutorial-server/notebooks > > > > which are actually used in the recording above. > > > > 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 . > > 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: example_wavetoy.pdf Type: application/pdf Size: 401571 bytes Desc: not available URL: From users at einsteintoolkit.org Wed Jan 28 17:15:01 2026 From: users at einsteintoolkit.org (users at einsteintoolkit.org) Date: Wed, 28 Jan 2026 17:15:01 -0600 Subject: [Users] Einstein Toolkit Meeting Reminder Message-ID: <697a9875.6Cr06cJwz1ZdVOQA%users@einsteintoolkit.org> 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 mail.ubc.ca Thu Jan 29 09:51:30 2026 From: rhaas at mail.ubc.ca (Roland Haas) Date: Thu, 29 Jan 2026 07:51:30 -0800 Subject: [Users] meeting minutes for 2026-01-29 Message-ID: <20260129075130.131979ef@haengie2.phas.ubc.ca> Present: Roland, Peter, Deborah, Aryan Saju, Beyhan, Cheng-Hsin, Johnny, Maxwell, Nikolai, Noora, Steve Chair: Deborah Minutes: Roland ET release planning =================== * gallery examples is firming up * timeline: https://docs.einsteintoolkit.org/et-docs/Release_Details#Details_for_ET_2026_05 * currently ahead of schedule * Beyhan will handle BHNS merger * Johnny will run Poisson equation * Noora will run axi-dilaton example * tentatively starting examples April 1st once most changes are in * Johnny may be able to run testsuite on Frontera * Testsuite runner needed for expanse * will need reviewers. Peter will review Bhahaha (champion is Zach) Questions on mailing list ========================= * no questions found Open tickets ============ * Roland is collecting tar files, Frank created them in the past, but they are lost https://bitbucket.org/einsteintoolkit/tickets/issues/2673/provide-historical-tar-archives-for-each * Roland has started implementing STORAGE statements https://bitbucket.org/einsteintoolkit/tickets/issues/2913/support-enabling-disabling-storage-in * Roland commented on https://bitbucket.org/einsteintoolkit/tickets/issues/2908/cactus-fixed-arg-list-too-long-error Max (Morris) will update * Roland to take a look at https://bitbucket.org/einsteintoolkit/tickets/issues/2899/bhns-with-elliptica-assertion-all-offset on Marenostrum * Peter and Zach plan to get back to, wanted to compare results https://bitbucket.org/einsteintoolkit/tickets/issues/963/improve-mclachlan-accuracy * Roland and Steve will pick up again on https://bitbucket.org/einsteintoolkit/tickets/issues/2909/remove-tags-from-interfaceccl Roland to add comments to ticket * Steve and Roland discussed: https://bitbucket.org/einsteintoolkit/tickets/issues/2910/carpetx-add-option-to-exclude-boundaries Roland suggests that this was added to avoid outputting bad data in the physical boundary, asks whether it would not be better to have correct data there * Re-review is required https://bitbucket.org/einsteintoolkit/tickets/issues/2898/carpetx-interpolator-caches Poke Erik about review. * Roland will provide a reproducer for https://bitbucket.org/einsteintoolkit/tickets/issues/2888/race-condition-writing-propertiesini-in Tickets for review ================== * Roland to look into https://bitbucket.org/einsteintoolkit/tickets/issues/2862/update-spacetimex-z4c-robust-stability Any other business ================== * North American ET School and Workshop at UIUC planning is ongoing, no firm date set yet. Will pick up again in the coming weeks. 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 . From mzilhao at ua.pt Thu Jan 29 11:39:24 2026 From: mzilhao at ua.pt (=?UTF-8?Q?Miguel_Zilh=C3=A3o?=) Date: Thu, 29 Jan 2026 17:39:24 +0000 Subject: [Users] Loss of convergence with subcycling in time In-Reply-To: <497a5ac0-e300-4af2-ab8e-2fdfd96f0d8e@ua.pt> References: <9203DF72-3569-452E-AB07-B132722C62F3@gmail.com> <497a5ac0-e300-4af2-ab8e-2fdfd96f0d8e@ua.pt> Message-ID: hi all, i haven?t been able to join the weekly calls lately, but i wanted to bring this up again. i recall that the problem is that, unless i?m missing something, the electric constraint isn?t converging at all in a very simple setting of a static charged black hole setup. this could be a real issue, especially since referees often ask for convergence tests and plots (and thus this could affect potential publications). i?m happy to help dig into this further, but i?m not super familiar with Carpet's internals. should i file a bug report, or is someone already looking into it? thanks, Miguel On 19/11/2025 17:33, users-bounces at einsteintoolkit.org wrote: > hi Erik, all, > > thanks for your input. for this specific example the grid is not moving > at all, so i was expecting it to be a simpler setting than the case with > binary BHs... > > is it then expected to see all that noise propagating out of the buffer > region and contaminating the whole grid in such a short amount of time > (plot attached)? this is a bit uncomfortable, since the convergence on > the electric constraint violation is completely lost... if it were a > matter of dropping from 4th to 2nd order (as is the case in the L2 norm > of the Hamiltonian constraint) i'd be fine with it, but a complete lack > of convergence is difficult to justify... > > thanks, > Miguel > > > On 19/11/2025 16:23, Erik Schnetter wrote: >> On Nov 19, 2025, at 10:26, Steven Brandt via Users >> wrote: >>> >>> On 11/19/2025 8:24 AM, Erik Schnetter wrote: >>>> Miguel >>>> >>>> If I recall correctly, Ian Hinder studied convergence of black hole >>>> simulations with subcycling in time in great detail. The Einstein >>>> Toolkit gallery example for GW150914 contains the respective >>>> distilled knowledge. https://einsteintoolkit.org/gallery/bbh/index.html >>>> >>>> Some important details that I recall: >>>> - You can regrid only when the fine and coarse grids are aligned >>>> - You cannot use time interpolation at all. You need to use enough >>>> buffer zones for all the RK substeps for all the fine timesteps for >>>> each coarse time step. With 3 ghost zones and RK4 you need 21 buffer >>>> zones. >>> >>> Does no time interpolation mean no dense output? That didn't exist >>> when Ian did these tests, right? >>> >> Output doesn't affect time evolution, so it doesn't matter which way >> you output things. Of course, if you use second-order accurate >> interpolation to output a quantity you cannot expect 4th order >> convergence for these quantities. If you output time-interpolated >> values of e.g. the lapse then you should check convergence only for >> the fine grid values of the lapse there, not for the interpolated >> coarse grid values. >> >> -erik >> >> -- >> Erik Schnetter >> http://www.perimeterinstitute.ca/personal/eschnetter/ >> >> >> _______________________________________________ >> Users mailing list >> Users at einsteintoolkit.org >> http://lists.einsteintoolkit.org/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users at einsteintoolkit.org > http://lists.einsteintoolkit.org/mailman/listinfo/users