[Users] WeylScal4 failing testsuites with ET_2023_11

Fri Mar 29 12:59:00 CDT 2024

Hello Bernard,

(closing the email thread by making sure it is marked as "responded")

This should be fixed as of commit  e185dc0c 

https://bitbucket.org/cactuscode/cactus/commits/e185dc0c014d148908054ff34e6a051988a87e59

of Cactus (see ticket
https://bitbucket.org/einsteintoolkit/tickets/issues/2781)

Thanks to Sam for following up on this and testing the fixes.

Yours,
Roland

> 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. <scupp1 at my.apsu.edu> 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 <physicsbeany at gmail.com>
> > *Sent:* Thursday, February 29, 2024 12:29 PM
> > *To:* Cupp, Samuel D. <scupp1 at my.apsu.edu>
> > *Cc:* Einstein Toolkit Users <Users at einsteintoolkit.org>
> > *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. <scupp1 at my.apsu.edu>
> > 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 <users-bounces at einsteintoolkit.org> on behalf of Bernard
> > Kelly <physicsbeany at gmail.com>
> > *Sent:* Thursday, February 29, 2024 11:58 AM
> > *To:* Einstein Toolkit Users <Users at einsteintoolkit.org>
> > *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!_7Ft2l2JqhrYGy11coIILkYNi7AYTZN6xnZ9cs3FweqCVlJskmz_IvivhLfdBofzsBal4aBH7wsRQWIuklnyJw$ 
> > 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!_7Ft2l2JqhrYGy11coIILkYNi7AYTZN6xnZ9cs3FweqCVlJskmz_IvivhLfdBofzsBal4aBH7wsRQWIuklnyJw$ 
> > 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: <http://lists.einsteintoolkit.org/pipermail/users/attachments/20240329/8e532c9f/attachment.sig>