<div dir="ltr"><p><font face="arial, sans-serif"><b>Meeting Minutes – February 6, 2025<br></b><br>Present: Erik, Lucas, Roland, Liwei, Zach, Steve, Swapnil, Jay, Helvi, Allen</font></p><div><hr></div><h3><span style="font-family:arial,sans-serif;font-weight:normal;font-size:small">Liwei:</span></h3><ul><li><p><font face="arial, sans-serif">Comparing performance between Carpet and CarpetX.</font></p></li><li><p><font face="arial, sans-serif">Findings:</font></p><ul><li><p><font face="arial, sans-serif">One refinement level test shows similar speeds.</font></p></li><li><p><font face="arial, sans-serif">With six levels, CarpetX is about 20% slower (with and without subcycling).</font></p></li><li><p><font face="arial, sans-serif">Removing additional synchronization calls for interprocess boundaries (ghost-zones) and keeping sync calls only for prolongation during the substep makes the speed comparable to Carpet.</font></p></li><li><p><font face="arial, sans-serif">Further optimizations are in progress.</font></p></li></ul></li><li><p><font face="arial, sans-serif">Erik’s suggestion: Introduce a new grid point type to track prolongation boundaries and set a flag to check if they are synced.</font></p></li><li><p><font face="arial, sans-serif">Another potential issue: Using the <code>PointDesc</code> object (<code>p.I</code>) in CarpetX causes minor slowdowns compared to accessing indices in Carpet.</font></p></li><li><p><font face="arial, sans-serif">Erik’s input: The compiler should optimize this; Liwei will share an example <code>.o</code> file for Erik to analyze.</font></p></li></ul><h4><span style="font-weight:normal"><font face="arial, sans-serif">Roland:</font></span></h4><ul><li><p><font face="arial, sans-serif">Z4c requires a test case.</font></p></li><li><p><font face="arial, sans-serif">Currently working on it and may seek Steve’s review later.</font></p></li></ul><h4><span style="font-weight:normal"><font face="arial, sans-serif">Lucas:</font></span></h4><ul><li><p><font face="arial, sans-serif">Testing hybrid Runge-Kutta integrators with BBH simulations.</font></p></li><li><p><font face="arial, sans-serif">Successfully set up a multipatch system with two puncture data and extracted multipole data.</font></p></li><li><p><font face="arial, sans-serif">May need assistance with Z4c.</font></p></li><li><p><font face="arial, sans-serif">Updating the robust stability test parfile and will open a PR. Currently e</font><span style="font-family:arial,sans-serif">xperimenting with different boundary conditions.</span></p></li><li><p><font face="arial, sans-serif">Reviewing PRs for NewRadX in SpacetimeX and CarpetX repositories.</font></p></li><li><p><font face="arial, sans-serif">Zach’s question: Any tests beyond scalar wave for multipatch?</font></p><ul><li><p><font face="arial, sans-serif">Lucas is working on a BBH test case and aims for completion before the May release.</font></p></li></ul></li><li><p><font face="arial, sans-serif">Helvi’s question: Status of multipatch implementation in CanudaX?</font></p><ul><li><p><font face="arial, sans-serif">Lucas is still working on it.</font></p></li></ul></li><li><p><font face="arial, sans-serif">Liwei’s question: Can the multipatch code be used directly?</font></p><ul><li><p><font face="arial, sans-serif">Lucas explained that evolution codes must be modified to compute derivatives and project them onto the multipatch system.</font></p></li><li><p><font face="arial, sans-serif">Suggests adding an option to enable/disable multipatch rather than maintaining two code versions.</font></p></li></ul></li></ul><div><hr></div><h3><font size="2" style="font-weight:normal" face="arial, sans-serif">Next Meeting:</font></h3><p><font face="arial, sans-serif">Thursday, February 13, 2025 @ 10 AM CDT / 11 AM EST</font></p></div>