July 2021 - Ecp-aurora-sdk-discuss - mailman3.cels.anl.gov

Re: [Ecp-aurora-sdk-discuss] Undefined ze* symbols using oneapi's mpi with spack
by Wyatt Spear 30 Jul '21

30 Jul '21

Yes, that did the trick. I tried that last night but hadn't gotten around to giving an update here yet. Thanks, Wyatt On Fri, Jul 30, 2021 at 8:58 AM Willmore, Frank Ted <willmore(a)anl.gov> wrote: > Hi Wyatt-- > > > 26 /usr/bin/ld: warning: libze_loader.so.1, needed by > /soft/restricted/CNDA/mpich/drop41.1/mpich-ofi-sockets-icc-default-ats-drop41/lib/libmpi.so, > not found (try using -rpath or -rpath-link) > > >> 27 /usr/bin/ld: > /soft/restricted/CNDA/mpich/drop41.1/mpich-ofi-sockets-icc-default-ats-drop41/lib/libmpi.so: > undefined reference to `zeMemGetAllocProperties' > > ) > > I have the spack oneapi compiler definition set to load the oneapi > module, but no others. > > You might try adding the needed path to the 'environment' section of the > compiler stanza. > > > Outside of spack I get undefined ze symbols from nm on libmpi.so: > > nm > /soft/restricted/CNDA/mpich/drop41.1/mpich-ofi-sockets-icc-default-ats-drop41/lib/libmpi.so > | grep zeDeviceGet > > U zeDeviceGet > > U zeDeviceGetCommandQueueGroupProperties > > U zeDeviceGetProperties > > U zeDeviceGetSubDevices > > This is normal, it just means that these symbols are needed and expected > to be defined elsewhere, in this case, as part of level zero. > > > These are defined in: > /soft/libraries/intel-level-zero/api_+_loader/v1.2.3-Release-2021.06.01/lib64/libze_loader.so.1 > > But I'm not sure why the spack build environment would be unable to find > that. The directory seems > to be loaded into the LD_LIBRARY_PATH when the > oneapi module is loaded. > > Yes, this appears to be the case. You might verify that this path is > indeed present by examining the build environment (spack build-env) in > which case there may be something deeper going on. > > Adding explicitly to your LD_LIBRARY_PATH in the compiler stanza may be > your best bet. > > Cheers, > > --Frank > > Frank Willmore, Ph.D. > ALCF Operations > Argonne National Laboratory > willmore(a)anl.gov > > ------------------------------ > *From:* Ecp-aurora-sdk-discuss < > ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of Wyatt > Spear via Ecp-aurora-sdk-discuss < > ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> > *Sent:* Wednesday, July 28, 2021 3:29 PM > *To:* ecp-aurora-sdk-discuss(a)jlse.anl.gov < > ecp-aurora-sdk-discuss(a)jlse.anl.gov> > *Subject:* [Ecp-aurora-sdk-discuss] Undefined ze* symbols using oneapi's > mpi with spack > > Greetings, > > I am not sure how to access the archive for this list so please forgive me > if this is a known issue (or user error for that matter). > > I'm seeing this with the default oneapi module on yarrow/arcticus > (oneapi/2021.04.30.004), using spack to build upcxx (and similar errors for > a few other packages) for E4S environment testing. > > 576 /usr/bin/ld: warning: libze_loader.so.1, needed by > /soft/restricted/CNDA/mpich/drop41.1/mpich-ofi-sockets-icc-default-ats-drop41/lib/libmpicxx.so, > not found (try using -rpath or -rpath-link) > >> 577 /usr/bin/ld: > /soft/restricted/CNDA/mpich/drop41.1/mpich-ofi-sockets-icc-default-ats-drop41/lib/libmpi.so: > undefined reference to `zeMemGetAllocProperties' > ...numerous other symbols... > > (bonus example from hdf5: > > 26 /usr/bin/ld: warning: libze_loader.so.1, needed by > /soft/restricted/CNDA/mpich/drop41.1/mpich-ofi-sockets-icc-default-ats-drop41/lib/libmpi.so, > not found (try using -rpath or -rpath-link) > >> 27 /usr/bin/ld: > /soft/restricted/CNDA/mpich/drop41.1/mpich-ofi-sockets-icc-default-ats-drop41/lib/libmpi.so: > undefined reference to `zeMemGetAllocProperties' > ) > > I have the spack oneapi compiler definition set to load the oneapi module, > but no others. > > Outside of spack I get undefined ze symbols from nm on libmpi.so: > nm > /soft/restricted/CNDA/mpich/drop41.1/mpich-ofi-sockets-icc-default-ats-drop41/lib/libmpi.so > | grep zeDeviceGet > U zeDeviceGet > U zeDeviceGetCommandQueueGroupProperties > U zeDeviceGetProperties > U zeDeviceGetSubDevices > > But maybe that is expected? > > These are defined in: > /soft/libraries/intel-level-zero/api_+_loader/v1.2.3-Release-2021.06.01/lib64/libze_loader.so.1 > But I'm not sure why the spack build environment would be unable to find > that. The directory seems to be loaded into the LD_LIBRARY_PATH when the > oneapi module is loaded. > > Thanks for any advice. > > Wyatt Spear > > >

1 0

Re: [Ecp-aurora-sdk-discuss] Undefined ze* symbols using oneapi's mpi with spack
by Willmore, Frank Ted 30 Jul '21

30 Jul '21

Hi Wyatt-- > 26 /usr/bin/ld: warning: libze_loader.so.1, needed by /soft/restricted/CNDA/mpich/drop41.1/mpich-ofi-sockets-icc-default-ats-drop41/lib/libmpi.so, not found (try using -rpath or -rpath-link) > >> 27 /usr/bin/ld: /soft/restricted/CNDA/mpich/drop41.1/mpich-ofi-sockets-icc-default-ats-drop41/lib/libmpi.so: undefined reference to `zeMemGetAllocProperties' > ) > I have the spack oneapi compiler definition set to load the oneapi module, but no others. You might try adding the needed path to the 'environment' section of the compiler stanza. > Outside of spack I get undefined ze symbols from nm on libmpi.so: > nm /soft/restricted/CNDA/mpich/drop41.1/mpich-ofi-sockets-icc-default-ats-drop41/lib/libmpi.so | grep zeDeviceGet > U zeDeviceGet > U zeDeviceGetCommandQueueGroupProperties > U zeDeviceGetProperties > U zeDeviceGetSubDevices This is normal, it just means that these symbols are needed and expected to be defined elsewhere, in this case, as part of level zero. > These are defined in: /soft/libraries/intel-level-zero/api_+_loader/v1.2.3-Release-2021.06.01/lib64/libze_loader.so.1 > But I'm not sure why the spack build environment would be unable to find that. The directory seems > to be loaded into the LD_LIBRARY_PATH when the oneapi module is loaded. Yes, this appears to be the case. You might verify that this path is indeed present by examining the build environment (spack build-env) in which case there may be something deeper going on. Adding explicitly to your LD_LIBRARY_PATH in the compiler stanza may be your best bet. Cheers, --Frank Frank Willmore, Ph.D. ALCF Operations Argonne National Laboratory willmore(a)anl.gov<mailto:[email protected]> ________________________________ From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of Wyatt Spear via Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Sent: Wednesday, July 28, 2021 3:29 PM To: ecp-aurora-sdk-discuss(a)jlse.anl.gov <ecp-aurora-sdk-discuss(a)jlse.anl.gov> Subject: [Ecp-aurora-sdk-discuss] Undefined ze* symbols using oneapi's mpi with spack Greetings, I am not sure how to access the archive for this list so please forgive me if this is a known issue (or user error for that matter). I'm seeing this with the default oneapi module on yarrow/arcticus (oneapi/2021.04.30.004), using spack to build upcxx (and similar errors for a few other packages) for E4S environment testing. 576 /usr/bin/ld: warning: libze_loader.so.1, needed by /soft/restricted/CNDA/mpich/drop41.1/mpich-ofi-sockets-icc-default-ats-drop41/lib/libmpicxx.so, not found (try using -rpath or -rpath-link) >> 577 /usr/bin/ld: /soft/restricted/CNDA/mpich/drop41.1/mpich-ofi-sockets-icc-default-ats-drop41/lib/libmpi.so: undefined reference to `zeMemGetAllocProperties' ...numerous other symbols... (bonus example from hdf5: 26 /usr/bin/ld: warning: libze_loader.so.1, needed by /soft/restricted/CNDA/mpich/drop41.1/mpich-ofi-sockets-icc-default-ats-drop41/lib/libmpi.so, not found (try using -rpath or -rpath-link) >> 27 /usr/bin/ld: /soft/restricted/CNDA/mpich/drop41.1/mpich-ofi-sockets-icc-default-ats-drop41/lib/libmpi.so: undefined reference to `zeMemGetAllocProperties' ) I have the spack oneapi compiler definition set to load the oneapi module, but no others. Outside of spack I get undefined ze symbols from nm on libmpi.so: nm /soft/restricted/CNDA/mpich/drop41.1/mpich-ofi-sockets-icc-default-ats-drop41/lib/libmpi.so | grep zeDeviceGet U zeDeviceGet U zeDeviceGetCommandQueueGroupProperties U zeDeviceGetProperties U zeDeviceGetSubDevices But maybe that is expected? These are defined in: /soft/libraries/intel-level-zero/api_+_loader/v1.2.3-Release-2021.06.01/lib64/libze_loader.so.1 But I'm not sure why the spack build environment would be unable to find that. The directory seems to be loaded into the LD_LIBRARY_PATH when the oneapi module is loaded. Thanks for any advice. Wyatt Spear

1 0

Undefined ze* symbols using oneapi's mpi with spack
by Wyatt Spear 28 Jul '21

28 Jul '21

Greetings, I am not sure how to access the archive for this list so please forgive me if this is a known issue (or user error for that matter). I'm seeing this with the default oneapi module on yarrow/arcticus (oneapi/2021.04.30.004), using spack to build upcxx (and similar errors for a few other packages) for E4S environment testing. 576 /usr/bin/ld: warning: libze_loader.so.1, needed by /soft/restricted/CNDA/mpich/drop41.1/mpich-ofi-sockets-icc-default-ats-drop41/lib/libmpicxx.so, not found (try using -rpath or -rpath-link) >> 577 /usr/bin/ld: /soft/restricted/CNDA/mpich/drop41.1/mpich-ofi-sockets-icc-default-ats-drop41/lib/libmpi.so: undefined reference to `zeMemGetAllocProperties' ...numerous other symbols... (bonus example from hdf5: 26 /usr/bin/ld: warning: libze_loader.so.1, needed by /soft/restricted/CNDA/mpich/drop41.1/mpich-ofi-sockets-icc-default-ats-drop41/lib/libmpi.so, not found (try using -rpath or -rpath-link) >> 27 /usr/bin/ld: /soft/restricted/CNDA/mpich/drop41.1/mpich-ofi-sockets-icc-default-ats-drop41/lib/libmpi.so: undefined reference to `zeMemGetAllocProperties' ) I have the spack oneapi compiler definition set to load the oneapi module, but no others. Outside of spack I get undefined ze symbols from nm on libmpi.so: nm /soft/restricted/CNDA/mpich/drop41.1/mpich-ofi-sockets-icc-default-ats-drop41/lib/libmpi.so | grep zeDeviceGet U zeDeviceGet U zeDeviceGetCommandQueueGroupProperties U zeDeviceGetProperties U zeDeviceGetSubDevices But maybe that is expected? These are defined in: /soft/libraries/intel-level-zero/api_+_loader/v1.2.3-Release-2021.06.01/lib64/libze_loader.so.1 But I'm not sure why the spack build environment would be unable to find that. The directory seems to be loaded into the LD_LIBRARY_PATH when the oneapi module is loaded. Thanks for any advice. Wyatt Spear

1 0

Re: [Ecp-aurora-sdk-discuss] Synchronizing a Ze Command List
by Videau, Brice 15 Jul '21

15 Jul '21

Nicolas, You need to use the event system to synchronize within or at the end of the command list, there is unfortunately no convenient API to wait until a command list is done being used and can be deleted or reset. Best, Brice On 7/15/21 12:59 PM, Denoyelle, Nicolas via Ecp-aurora-sdk-discuss wrote: Greetings all, I'd like you have a tip for working with level zero. I am trying to synchronize a command list to wait on all commands that have been submitted. I was not able to find primitives or satisfying workaround to do so in the API documentation<https://spec.oneapi.io/level-zero/latest/core/api.html#cmdlist>. Any "ze" way to achieve this is welcome. AFAIK, command queues can be synchronized<https://spec.oneapi.io/level-zero/latest/core/api.html#zecommandqueuesynchr…>, however they are not the abstraction used to submit commands. The interface for queuing memcpys rely on the higher abstraction of command lists<https://spec.oneapi.io/level-zero/latest/core/api.html#copy>, from which one cannot retrieve the associated command queues even when the command list is an immediate command list. I am really working at the device granularity so ideally I would use command queues instead of command list, but the API is not designed to work with copies. One solution is to queue a memory barrier<https://spec.oneapi.io/level-zero/latest/core/api.html#barrier> and wait on it. I don't like this solution because waiting on all commands means paying the latency of sending and executing a new command which is suboptimal. Another workaround I know of is to associate an event with all memcpy commands and to wait on these events<https://spec.oneapi.io/level-zero/latest/core/api.html#zeeventhostsynchroni…>. This method requires to keep a container of events on which to wait. I would like to be able to natively wait on a whole command list instead. Thank you ahead for reading and suggestions, Nicolas

1 0

Synchronizing a Ze Command List
by Denoyelle, Nicolas 15 Jul '21

15 Jul '21

Greetings all, I'd like you have a tip for working with level zero. I am trying to synchronize a command list to wait on all commands that have been submitted. I was not able to find primitives or satisfying workaround to do so in the API documentation<https://spec.oneapi.io/level-zero/latest/core/api.html#cmdlist>. Any "ze" way to achieve this is welcome. AFAIK, command queues can be synchronized<https://spec.oneapi.io/level-zero/latest/core/api.html#zecommandqueuesynchr…>, however they are not the abstraction used to submit commands. The interface for queuing memcpys rely on the higher abstraction of command lists<https://spec.oneapi.io/level-zero/latest/core/api.html#copy>, from which one cannot retrieve the associated command queues even when the command list is an immediate command list. I am really working at the device granularity so ideally I would use command queues instead of command list, but the API is not designed to work with copies. One solution is to queue a memory barrier<https://spec.oneapi.io/level-zero/latest/core/api.html#barrier> and wait on it. I don't like this solution because waiting on all commands means paying the latency of sending and executing a new command which is suboptimal. Another workaround I know of is to associate an event with all memcpy commands and to wait on these events<https://spec.oneapi.io/level-zero/latest/core/api.html#zeeventhostsynchroni…>. This method requires to keep a container of events on which to wait. I would like to be able to natively wait on a whole command list instead. Thank you ahead for reading and suggestions, Nicolas

1 0

Re: [Ecp-aurora-sdk-discuss] [EXTERNAL] Re: segfault on yarrow
by Romero, Nichols A. 09 Jul '21

09 Jul '21

Rob, If you run with: OMP_TARGET_OFFLOAD=DISABLED Does the code still segfault? From: "Aulwes, Rob Tuan" <rta(a)lanl.gov> Date: Friday, July 9, 2021 at 4:40 PM To: Nichols Romero <naromero(a)anl.gov>, "ecp-aurora-sdk-discuss(a)jlse.anl.gov" <ecp-aurora-sdk-discuss(a)jlse.anl.gov> Subject: Re: [EXTERNAL] Re: [Ecp-aurora-sdk-discuss] segfault on yarrow Got same runtime segfault and no core dumps. Running interactively on articus. From: "Romero, Nichols A." <naromero(a)anl.gov> Date: Friday, July 9, 2021 at 3:39 PM To: "Aulwes, Rob Tuan" <rta(a)lanl.gov>, "ecp-aurora-sdk-discuss(a)jlse.anl.gov" <ecp-aurora-sdk-discuss(a)jlse.anl.gov> Subject: Re: [EXTERNAL] Re: [Ecp-aurora-sdk-discuss] segfault on yarrow No, just submit it to the articus queue. From: "Aulwes, Rob Tuan" <rta(a)lanl.gov> Date: Friday, July 9, 2021 at 4:16 PM To: Nichols Romero <naromero(a)anl.gov>, "ecp-aurora-sdk-discuss(a)jlse.anl.gov" <ecp-aurora-sdk-discuss(a)jlse.anl.gov> Subject: Re: [EXTERNAL] Re: [Ecp-aurora-sdk-discuss] segfault on yarrow Will I need to recompile for articus? From: "Romero, Nichols A." <naromero(a)anl.gov> Date: Friday, July 9, 2021 at 3:15 PM To: "Aulwes, Rob Tuan" <rta(a)lanl.gov>, "ecp-aurora-sdk-discuss(a)jlse.anl.gov" <ecp-aurora-sdk-discuss(a)jlse.anl.gov> Subject: [EXTERNAL] Re: [Ecp-aurora-sdk-discuss] segfault on yarrow Rob, Can you try it on Articus instead? Yarrow uses double-precision emulation and so I can imagine something easily going off the rails. Articus natively supports double-precision. From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of "Aulwes, Rob Tuan via Ecp-aurora-sdk-discuss" <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Reply-To: "Aulwes, Rob Tuan" <rta(a)lanl.gov> Date: Friday, July 9, 2021 at 4:10 PM To: "ecp-aurora-sdk-discuss(a)jlse.anl.gov" <ecp-aurora-sdk-discuss(a)jlse.anl.gov> Subject: [Ecp-aurora-sdk-discuss] segfault on yarrow Hi, Trying to run MPAS-Ocean on yarrow using OpenMP offloading. Getting a runtime segfault, but don’t get any core dumps. I’ve tried setting ‘ulimit unlimited’, but still no core dumps. How do I generate core dumps or is there an MPI-compatible debugger available on yarrow? I didn’t see totalview or ddt. Thanks,Rob

1 0

Re: [Ecp-aurora-sdk-discuss] [EXTERNAL] Re: segfault on yarrow
by Aulwes, Rob Tuan 09 Jul '21

09 Jul '21

Got same runtime segfault and no core dumps. Running interactively on articus. From: "Romero, Nichols A." <naromero(a)anl.gov> Date: Friday, July 9, 2021 at 3:39 PM To: "Aulwes, Rob Tuan" <rta(a)lanl.gov>, "ecp-aurora-sdk-discuss(a)jlse.anl.gov" <ecp-aurora-sdk-discuss(a)jlse.anl.gov> Subject: Re: [EXTERNAL] Re: [Ecp-aurora-sdk-discuss] segfault on yarrow No, just submit it to the articus queue. From: "Aulwes, Rob Tuan" <rta(a)lanl.gov> Date: Friday, July 9, 2021 at 4:16 PM To: Nichols Romero <naromero(a)anl.gov>, "ecp-aurora-sdk-discuss(a)jlse.anl.gov" <ecp-aurora-sdk-discuss(a)jlse.anl.gov> Subject: Re: [EXTERNAL] Re: [Ecp-aurora-sdk-discuss] segfault on yarrow Will I need to recompile for articus? From: "Romero, Nichols A." <naromero(a)anl.gov> Date: Friday, July 9, 2021 at 3:15 PM To: "Aulwes, Rob Tuan" <rta(a)lanl.gov>, "ecp-aurora-sdk-discuss(a)jlse.anl.gov" <ecp-aurora-sdk-discuss(a)jlse.anl.gov> Subject: [EXTERNAL] Re: [Ecp-aurora-sdk-discuss] segfault on yarrow Rob, Can you try it on Articus instead? Yarrow uses double-precision emulation and so I can imagine something easily going off the rails. Articus natively supports double-precision. From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of "Aulwes, Rob Tuan via Ecp-aurora-sdk-discuss" <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Reply-To: "Aulwes, Rob Tuan" <rta(a)lanl.gov> Date: Friday, July 9, 2021 at 4:10 PM To: "ecp-aurora-sdk-discuss(a)jlse.anl.gov" <ecp-aurora-sdk-discuss(a)jlse.anl.gov> Subject: [Ecp-aurora-sdk-discuss] segfault on yarrow Hi, Trying to run MPAS-Ocean on yarrow using OpenMP offloading. Getting a runtime segfault, but don’t get any core dumps. I’ve tried setting ‘ulimit unlimited’, but still no core dumps. How do I generate core dumps or is there an MPI-compatible debugger available on yarrow? I didn’t see totalview or ddt. Thanks,Rob

1 0

Re: [Ecp-aurora-sdk-discuss] [EXTERNAL] Re: segfault on yarrow
by Romero, Nichols A. 09 Jul '21

09 Jul '21

No, just submit it to the articus queue. From: "Aulwes, Rob Tuan" <rta(a)lanl.gov> Date: Friday, July 9, 2021 at 4:16 PM To: Nichols Romero <naromero(a)anl.gov>, "ecp-aurora-sdk-discuss(a)jlse.anl.gov" <ecp-aurora-sdk-discuss(a)jlse.anl.gov> Subject: Re: [EXTERNAL] Re: [Ecp-aurora-sdk-discuss] segfault on yarrow Will I need to recompile for articus? From: "Romero, Nichols A." <naromero(a)anl.gov> Date: Friday, July 9, 2021 at 3:15 PM To: "Aulwes, Rob Tuan" <rta(a)lanl.gov>, "ecp-aurora-sdk-discuss(a)jlse.anl.gov" <ecp-aurora-sdk-discuss(a)jlse.anl.gov> Subject: [EXTERNAL] Re: [Ecp-aurora-sdk-discuss] segfault on yarrow Rob, Can you try it on Articus instead? Yarrow uses double-precision emulation and so I can imagine something easily going off the rails. Articus natively supports double-precision. From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of "Aulwes, Rob Tuan via Ecp-aurora-sdk-discuss" <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Reply-To: "Aulwes, Rob Tuan" <rta(a)lanl.gov> Date: Friday, July 9, 2021 at 4:10 PM To: "ecp-aurora-sdk-discuss(a)jlse.anl.gov" <ecp-aurora-sdk-discuss(a)jlse.anl.gov> Subject: [Ecp-aurora-sdk-discuss] segfault on yarrow Hi, Trying to run MPAS-Ocean on yarrow using OpenMP offloading. Getting a runtime segfault, but don’t get any core dumps. I’ve tried setting ‘ulimit unlimited’, but still no core dumps. How do I generate core dumps or is there an MPI-compatible debugger available on yarrow? I didn’t see totalview or ddt. Thanks,Rob

1 0

Re: [Ecp-aurora-sdk-discuss] [EXTERNAL] Re: segfault on yarrow
by Aulwes, Rob Tuan 09 Jul '21

09 Jul '21

Will I need to recompile for articus? From: "Romero, Nichols A." <naromero(a)anl.gov> Date: Friday, July 9, 2021 at 3:15 PM To: "Aulwes, Rob Tuan" <rta(a)lanl.gov>, "ecp-aurora-sdk-discuss(a)jlse.anl.gov" <ecp-aurora-sdk-discuss(a)jlse.anl.gov> Subject: [EXTERNAL] Re: [Ecp-aurora-sdk-discuss] segfault on yarrow Rob, Can you try it on Articus instead? Yarrow uses double-precision emulation and so I can imagine something easily going off the rails. Articus natively supports double-precision. From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of "Aulwes, Rob Tuan via Ecp-aurora-sdk-discuss" <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Reply-To: "Aulwes, Rob Tuan" <rta(a)lanl.gov> Date: Friday, July 9, 2021 at 4:10 PM To: "ecp-aurora-sdk-discuss(a)jlse.anl.gov" <ecp-aurora-sdk-discuss(a)jlse.anl.gov> Subject: [Ecp-aurora-sdk-discuss] segfault on yarrow Hi, Trying to run MPAS-Ocean on yarrow using OpenMP offloading. Getting a runtime segfault, but don’t get any core dumps. I’ve tried setting ‘ulimit unlimited’, but still no core dumps. How do I generate core dumps or is there an MPI-compatible debugger available on yarrow? I didn’t see totalview or ddt. Thanks,Rob

1 0

Re: [Ecp-aurora-sdk-discuss] segfault on yarrow
by Romero, Nichols A. 09 Jul '21

09 Jul '21

Rob, Can you try it on Articus instead? Yarrow uses double-precision emulation and so I can imagine something easily going off the rails. Articus natively supports double-precision. From: Ecp-aurora-sdk-discuss <ecp-aurora-sdk-discuss-bounces(a)lists.jlse.anl.gov> on behalf of "Aulwes, Rob Tuan via Ecp-aurora-sdk-discuss" <ecp-aurora-sdk-discuss(a)lists.jlse.anl.gov> Reply-To: "Aulwes, Rob Tuan" <rta(a)lanl.gov> Date: Friday, July 9, 2021 at 4:10 PM To: "ecp-aurora-sdk-discuss(a)jlse.anl.gov" <ecp-aurora-sdk-discuss(a)jlse.anl.gov> Subject: [Ecp-aurora-sdk-discuss] segfault on yarrow Hi, Trying to run MPAS-Ocean on yarrow using OpenMP offloading. Getting a runtime segfault, but don’t get any core dumps. I’ve tried setting ‘ulimit unlimited’, but still no core dumps. How do I generate core dumps or is there an MPI-compatible debugger available on yarrow? I didn’t see totalview or ddt. Thanks,Rob

1 0