WeylScal4 failing testsuites with ET_2023_11

List overview All Threads
Download

newer

older

Compiling ET_2023_11 on Frontera

US ET Workshop and Meeting 2024

Bernard Kelly

29 Feb 2024 29 Feb '24

11:58 a.m.

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 ------------------------------------------------------------------

Attachments:

attachment.html (text/html — 3.2 KB)

Show replies by date

Cupp, Samuel D.

29 Feb 29 Feb

12:23 p.m.

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@einsteintoolkit.org on behalf of Bernard Kelly physicsbeany@gmail.com Sent: Thursday, February 29, 2024 11:58 AM To: Einstein Toolkit Users Users@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:

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-4454http://orcid.org/0000-0002-3326-4454 ------------------------------------------------------------------

Bernard Kelly

12:29 p.m.

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@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@einsteintoolkit.org on behalf of Bernard Kelly physicsbeany@gmail.com *Sent:* Thursday, February 29, 2024 11:58 AM *To:* Einstein Toolkit Users Users@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: http://science.gsfc.nasa.gov/sed/bio/bernard.j.kelly ORCID: orcid.org/0000-0002-3326-4454

Cupp, Samuel D.

12:45 p.m.

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))

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@gmail.com Sent: Thursday, February 29, 2024 12:29 PM To: Cupp, Samuel D. scupp1@my.apsu.edu Cc: Einstein Toolkit Users Users@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@my.apsu.edumailto:scupp1@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@einsteintoolkit.orgmailto:users-bounces@einsteintoolkit.org> on behalf of Bernard Kelly <physicsbeany@gmail.commailto:physicsbeany@gmail.com> Sent: Thursday, February 29, 2024 11:58 AM To: Einstein Toolkit Users <Users@einsteintoolkit.orgmailto:Users@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:

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

Roland Haas

1:16 p.m.

Hello all,

I suspect:

hash 4d9935b1

https://bitbucket.org/cactuscode/cactus/commits/4d9935b11d807dc47e6e69478c03...

"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 physicsbeany@gmail.com Sent: Thursday, February 29, 2024 12:29 PM To: Cupp, Samuel D. scupp1@my.apsu.edu Cc: Einstein Toolkit Users Users@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@my.apsu.edumailto:scupp1@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@einsteintoolkit.orgmailto:users-bounces@einsteintoolkit.org> on behalf of Bernard Kelly <physicsbeany@gmail.commailto:physicsbeany@gmail.com> Sent: Thursday, February 29, 2024 11:58 AM To: Einstein Toolkit Users <Users@einsteintoolkit.orgmailto:Users@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.k... ORCID: orcid.org/0000-0002-3326-4454<https://urldefense.com/v3/__http://orcid.org/0000-0002-3326-4454__;!!DZ3fjg!...

...

--

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.k... ORCID: orcid.org/0000-0002-3326-4454<https://urldefense.com/v3/__http://orcid.org/0000-0002-3326-4454__;!!DZ3fjg!...

...

-- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://pgp.mit.edu .

Bernard Kelly

1:18 p.m.

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@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@gmail.com *Sent:* Thursday, February 29, 2024 12:29 PM *To:* Cupp, Samuel D. scupp1@my.apsu.edu *Cc:* Einstein Toolkit Users Users@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@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@einsteintoolkit.org on behalf of Bernard Kelly physicsbeany@gmail.com *Sent:* Thursday, February 29, 2024 11:58 AM *To:* Einstein Toolkit Users Users@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: 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

Roland Haas

29 Mar 29 Mar

10:59 a.m.

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/e185dc0c014d148908054ff34e6a...

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@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@gmail.com *Sent:* Thursday, February 29, 2024 12:29 PM *To:* Cupp, Samuel D. scupp1@my.apsu.edu *Cc:* Einstein Toolkit Users Users@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@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@einsteintoolkit.org on behalf of Bernard Kelly physicsbeany@gmail.com *Sent:* Thursday, February 29, 2024 11:58 AM *To:* Einstein Toolkit Users Users@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.k... 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.k... 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 .

923

Age (days ago)

952

Last active (days ago)

users@lists.einsteintoolkit.org

6 comments

3 participants

tags (0)

participants (3)

Bernard Kelly
Cupp, Samuel D.
Roland Haas