From lawrence_edmond at brown.edu  Sat Jun  1 17:22:07 2024
From: lawrence_edmond at brown.edu (Edmond, Lawrence)
Date: Sat, 1 Jun 2024 18:22:07 -0400
Subject: [Users] Compiling Einstein Toolkit
Message-ID: <CAPoufhJNWp4j96eGDiNfes0DNK=VQ2myxrNJnX8GKjRY96-Ccw@mail.gmail.com>

Hello,

I am Lawrence Edmond, IV, a rising third-year PhD student at Brown
University in the physics department. I am interested in using
EinsteinToolkit to simulate black holes with accretion disks for cosmo/dark
matter research.

I am following along with the Wiki
<https://einsteintoolkit.org/download.html> and the JupyterNotebook
<https://github.com/einsteintoolkit/jupyter-et/blob/master/tutorial-server/notebooks/CactusTutorial.ipynb>
on
git to compile and run the first "HelloWorld" Thorn before attempting to
write my own. Following along with the notebook. I am able to compile
EinsteinToolkit via the following bash command:

./simfactory/bin/sim build -j4 --thornlist ../einsteintoolkit.th

which differs from the notebook by the location of the "einsteintoolkit.th"
thorn. This is able to compile without errors however, when I try to run
the following command to create and execute the "HelloWorld" thorn,

./simfactory/bin/sim create-run helloworld \    --parfile
arrangements/CactusExamples/HelloWorld/par/HelloWorld.par

I get an error message saying that the executable cannot be found or was
not created (see below for a copy of the output).

[ledmond at login010 Cactus]$ ./simfactory/bin/sim create-run helloworld \
    --parfile arrangements/CactusExamples/HelloWorld/par/HelloWorld.par
Warning: Current Working directory does not match Cactus sourcetree,
changing to /users/ledmond/EinsteinToolkit/Cactus
Parameter file:
/oscar/home/ledmond/EinsteinToolkit/Cactus/arrangements/CactusExamples/HelloWorld/par/HelloWorld.par
Error: Executable /users/ledmond/EinsteinToolkit/Cactus/exe/cactus_sim for
configuration sim does not exist or is not readable
Aborting Simfactory.

I believe the issue is that the procedure is looking for the executable
file, and the associated folder to hold all created executables is being
created using a path that cannot be accessed on my cluster. That being
said, is there a way to manually change the path for the exe/ directory
that is created by Simfactory?

Thank you in advance for any help you may offer. Please do not hesitate to
contact me if you need any more information or further clarification to
address this compilation issue.

-- 
*Best Regards, *

*Lawrence Edmond, IV*

*Class of 2026*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.einsteintoolkit.org/pipermail/users/attachments/20240601/2dc9401a/attachment.htm>

From p.moesta at uva.nl  Tue Jun  4 05:16:16 2024
From: p.moesta at uva.nl (Philipp Moesta)
Date: Tue, 4 Jun 2024 10:16:16 +0000
Subject: [Users] Reminder: European Einstein Toolkit Meeting 2024 Jul 8-12 @
 UvA
In-Reply-To: <AS2PR10MB77774ECAB117CC320F481978EBE62@AS2PR10MB7777.EURPRD10.PROD.OUTLOOK.COM>
References: <AS2PR10MB77773B96201BF014E466963FEBE62@AS2PR10MB7777.EURPRD10.PROD.OUTLOOK.COM>
 <AS2PR10MB77774ECAB117CC320F481978EBE62@AS2PR10MB7777.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <AS2PR10MB7777EA628A31C10BCE20A89EEBF82@AS2PR10MB7777.EURPRD10.PROD.OUTLOOK.COM>

Dear Einstein Toolkit Community,

Just a kind reminder for the European Meeting Jul 8-12 at the University of Amsterdam. We still have plenty of room for registrations and contributed talks. The deadline for both is Jun 20. You can register and find more info here European Einstein Toolkit Meeting<https://indico.nikhef.nl/event/5531/>.

Best,
Philipp on behalf of the SOC/LOC

From: Philipp Moesta <p.moesta at uva.nl>
Date: Thursday, May 9, 2024 at 14:25
To: users at einsteintoolkit.org <users at einsteintoolkit.org>
Subject: Re: European Einstein Toolkit Meeting 2024
The meeting will take place Jul 8-12, 2024.

Best,
Philipp

From: Philipp Moesta <p.moesta at uva.nl>
Date: Thursday, May 9, 2024 at 14:20
To: users at einsteintoolkit.org <users at einsteintoolkit.org>
Subject: European Einstein Toolkit Meeting 2024
European Einstein Toolkit Workshop and Meeting 2024

We are pleased to announce the 2024 edition of the European Einstein Toolkit Meeting<https://indico.nikhef.nl/event/5531/>. The in-person workshop will be held at the Gravitation & Astroparticle Physics Amsterdam (https://www.grappa.amsterdam/) center of the University of Amsterdam and will provide an opportunity for researchers and students to learn about the Einstein Toolkit (https://einsteintoolkit.org/), a community-driven software platform of core computational tools to advance and support research in relativistic astrophysics and gravitational physics.

The workshop will offer a mixture of talks and tutorials, with the tutorials including basic tutorials for new users and more advanced topics. The talks will, likewise, provide information for new users and will highlight exciting science cases and the latest developments in numerical relativity.

Please register via the website no later than Jun 14, 2024.

Looking forward to seeing you there!
Philipp
on behalf of the SOC/LOC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.einsteintoolkit.org/pipermail/users/attachments/20240604/13f62f4a/attachment.htm>

From sbrandt at cct.lsu.edu  Tue Jun  4 15:25:05 2024
From: sbrandt at cct.lsu.edu (Steven Brandt)
Date: Tue, 4 Jun 2024 15:25:05 -0500
Subject: [Users] Compiling Einstein Toolkit
In-Reply-To: <CAPoufhJNWp4j96eGDiNfes0DNK=VQ2myxrNJnX8GKjRY96-Ccw@mail.gmail.com>
References: <CAPoufhJNWp4j96eGDiNfes0DNK=VQ2myxrNJnX8GKjRY96-Ccw@mail.gmail.com>
Message-ID: <f699d2e4-6491-4065-8517-5a14a6915e97@cct.lsu.edu>

Lawrence,

Does ./exe/cactus_sim exist? If not, then something went wrong with your 
build.

--Steve

On 6/1/2024 5:22 PM, Edmond, Lawrence wrote:
> Hello,
>
> I am Lawrence Edmond, IV, a rising third-year PhD student at Brown 
> University in the physics department. I am interested in using 
> EinsteinToolkit to simulate black holes with accretion disks for 
> cosmo/dark matter research.
>
> I am following along with the Wiki 
> <https://einsteintoolkit.org/download.html>?and the JupyterNotebook 
> <https://github.com/einsteintoolkit/jupyter-et/blob/master/tutorial-server/notebooks/CactusTutorial.ipynb>?on 
> git to compile and run the first "HelloWorld" Thorn before attempting 
> to write my own. Following along with the notebook. I am able to 
> compile EinsteinToolkit via the following bash command:
> ./simfactory/bin/simbuild-j4--thornlist../einsteintoolkit.th  <http://einsteintoolkit.th>
> which differs from the notebook by the location of the 
> "einsteintoolkit.th <http://einsteintoolkit.th>" thorn. This is able 
> to compile without errors however, when I try to run the following 
> command to create and execute?the "HelloWorld" thorn,
> ./simfactory/bin/simcreate-runhelloworld\
> --parfilearrangements/CactusExamples/HelloWorld/par/HelloWorld.par
> I get an error message saying that the executable cannot be found or 
> was not created (see below for a copy of the output).
>
> [ledmond at login010 Cactus]$ ./simfactory/bin/sim create-run helloworld \
> ? ? --parfile arrangements/CactusExamples/HelloWorld/par/HelloWorld.par
> Warning: Current Working directory does not match Cactus sourcetree, 
> changing to /users/ledmond/EinsteinToolkit/Cactus
> Parameter file: 
> /oscar/home/ledmond/EinsteinToolkit/Cactus/arrangements/CactusExamples/HelloWorld/par/HelloWorld.par
> Error: Executable /users/ledmond/EinsteinToolkit/Cactus/exe/cactus_sim 
> for configuration sim does not exist or is not readable
> Aborting Simfactory.
>
> I believe the issue is that the procedure is looking for the 
> executable file, and the associated folder to hold all created 
> executables is being created using a path that cannot be accessed on 
> my cluster. That being said, is there a way to manually change the 
> path for the exe/ directory that is created by Simfactory?
>
> Thank you in advance for any help you may offer. Please do not 
> hesitate to contact me?if you need any more information or further 
> clarification to address this compilation issue.
>
> -- 
> /Best Regards, /
> /Lawrence Edmond, IV
> /
> /Class of 2026
> /
> /
> /
>
> _______________________________________________
> Users mailing list
> Users at einsteintoolkit.org
> http://lists.einsteintoolkit.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.einsteintoolkit.org/pipermail/users/attachments/20240604/3feba3d1/attachment.htm>

From rhaas at illinois.edu  Mon Jun 10 15:18:01 2024
From: rhaas at illinois.edu (rhaas at illinois.edu)
Date: Mon, 10 Jun 2024 15:18:01 -0500
Subject: [Users] Agenda for Thursday's Meeting
Message-ID: <E1sGlSr-00000000MyT-2szN@ekohaes8.ncsa.illinois.edu>

Please update the Wiki with agenda items for Thursday's meeting. Thanks!

https://docs.einsteintoolkit.org/et-docs/meeting_agenda

--The Maintainers

From jpmferreira at ua.pt  Wed Jun 12 09:51:13 2024
From: jpmferreira at ua.pt (=?UTF-8?Q?Jos=C3=A9_Ferreira?=)
Date: Wed, 12 Jun 2024 15:51:13 +0100
Subject: [Users] Error on the linking phase on compilation in a virtual
 environment
Message-ID: <8fc1a59e-2eba-44e4-bd12-7c35cb9798ff@ua.pt>

Dear toolkit users and developers,


With the latest update of GCC to version 14, there is a known error that 
prevents the compilation from taking place, preventing me from compiling 
the toolkit.

I?ve been trying to do something which I probably should have some time 
ago to avoid this kind of issues, while also granting some portability 
between machines, which is to setup a virtual environment using Conda to 
compile the toolkit.


I am sending you this e-mail because I?ve failed to compile the toolkit 
in a virtual environment, where I am currently stuck with an error 
during the linking phase. Before the update to GCC 14, and without the 
virtual environment, I was able of compiling the toolkit without any issue.

Here are the steps that I have performed:

 1.

    Activate an empty virtual environment managed by a conda (or a
    drop-in replacement) with the conda-forge repository configured

 2.

    |conda install gcc gxx gfortran openmpi openmpi-mpicc openmpi-mpicxx
    openmpi-mpifort binutils|

 3.

    Compile the toolkit with an empty thornlist, attached in |empty.th|,
    and an option file that points towards the virtual environment that
    is activated, attached in |venv.cfg|

 4.

    Get the following error from |ld| (the full log for making the
    config and the binary are attached in |cactus_empty.log|)

|Creating cactus_empty in /home/undercover/projects/cactus/exe from 
/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-ld: 
unrecognised emulation mode: arch=native Supported emulations: 
elf_x86_64 elf32_x86_64 elf_i386 elf_iamcu make[1]: *** 
[/home/undercover/projects/cactus/lib/make/make.configuration:150: 
/home/undercover/projects/cactus/exe/cactus_empty] Error 1 make: *** 
[Makefile:265: empty] Error 2 |


To me, the previous error indicates that something is passing the wrong 
flags to |ld|, because even if the emulation mode was not recognized it 
should give the error |ld: unrecognised emulation mode: <something>| 
instead of |ld: unrecognised emulation mode: arch=<something>|.

Removing the flag |-march=native| from the compilers confirms my guess 
by revealing a different error at the same stage

|Creating cactus_empty in /home/undercover/projects/cactus/exe from 
/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-ld: 
unrecognized option '-DMPICH_IGNORE_CXX_SEEK' 
/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-ld: use 
the --help option for usage information make[1]: *** 
[/home/undercover/projects/cactus/lib/make/make.configuration:150: 
/home/undercover/projects/cactus/exe/cactus_empty] Error 1 make: *** 
[Makefile:265: empty] Error 2 |

and if I were to remove the corresponding flag in the config file, |ld| 
will complain about something else.

It really seems like something is passing the flags onto |ld| where it 
shouldn?t, but I cannot tell who and where.


I should note that compiling very basic programs in C in the virtual 
environment doesn?t raise any issues, although I haven?t tested it very 
thoroughly.

Please do let me know if you have any issues in rendering this e-mail!


Best regards,

Jos? Ferreira


?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.einsteintoolkit.org/pipermail/users/attachments/20240612/a89105e6/attachment-0001.htm>
-------------- next part --------------
!CRL_VERSION = 1.0

!DEFINE ROOT = Cactus
!DEFINE ARR  = $ROOT/arrangements
!DEFINE COMPONENTLIST_TARGET = $ROOT/thornlists/

!DEFINE ET_RELEASE = ET_2023_05
-------------- next part --------------
# Cactus configuration for virtual environments managed by conda
# change libraries location to match your virtual environment below!

# list of conda packages installed from conda-forge:
# - binutils
# - libjpeg-turbo
# - gsl
# - hdf5
# - openmpi openmpi-mpicc openmpi-mpicxx openmpi-mpifort
# - gcc gxx gfortran

## Decide which flags will be used at compile-time
OPTIMISE = yes
WARN     = yes
DEBUG    = no
PROFILE  = no
OPENMP   = yes

## Preprocessors and Compilers
CPP = cpp
FPP = cpp
CC  = gcc
CXX = g++
F77 = gfortran
F90 = gfortran

## Default flags
CPPFLAGS = -DMPICH_IGNORE_CXX_SEEK
FPPFLAGS = -traditional
CFLAGS   = -g3 -march=native -std=gnu99
CXXFLAGS = -g3 -march=native -std=gnu++0x
F77FLAGS = -g3 -march=native -fcray-pointer -m128bit-long-double -ffixed-line-length-none -fno-range-check
F90FLAGS = -g3 -march=native -fcray-pointer -m128bit-long-double -ffixed-line-length-none -fno-range-check
LDFLAGS  = -rdynamic

## Optimization flags
CPP_OPTIMISE_FLAGS = -DKRANC_VECTORS # -DCARPET_OPTIMISE -DNDEBUG
FPP_OPTIMISE_FLAGS =                 # -DCARPET_OPTIMISE -DNDEBUG
C_OPTIMISE_FLAGS   = -Ofast
CXX_OPTIMISE_FLAGS = -Ofast
F77_OPTIMISE_FLAGS = -Ofast
F90_OPTIMISE_FLAGS = -Ofast

## Warning flags
CPP_WARN_FLAGS = -Wall
FPP_WARN_FLAGS = -Wall
C_WARN_FLAGS   = -Wall
CXX_WARN_FLAGS = -Wall
F77_WARN_FLAGS = -Wall
F90_WARN_FLAGS = -Wall

## Debug flags
CPP_DEBUG_FLAGS = -DCARPET_DEBUG -fsanitize=undefined -fsanitize=thread
FPP_DEBUG_FLAGS = -DCARPET_DEBUG -fsanitize=undefined -fsanitize=thread
C_DEBUG_FLAGS   = -O0            -fsanitize=undefined -fsanitize=thread
CXX_DEBUG_FLAGS = -O0            -fsanitize=undefined -fsanitize=thread
F77_DEBUG_FLAGS = -O0            -fsanitize=undefined -fsanitize=thread
F90_DEBUG_FLAGS = -O0            -fsanitize=undefined -fsanitize=thread

## Code profiling flags
CPP_PROFILE_FLAGS =
FPP_PROFILE_FLAGS =
C_PROFILE_FLAGS   = -pg
CXX_PROFILE_FLAGS = -pg
F77_PROFILE_FLAGS = -pg
F90_PROFILE_FLAGS = -pg

## OpenMP
CPP_OPENMP_FLAGS = -fopenmp
FPP_OPENMP_FLAGS = -fopenmp
C_OPENMP_FLAGS   = -fopenmp
CXX_OPENMP_FLAGS = -fopenmp
F77_OPENMP_FLAGS = -fopenmp
F90_OPENMP_FLAGS = -fopenmp

## Libraries location
LIBDIRS      =   # ?
MPI_DIR      = /home/undercover/.micromamba/envs/phd/
HDF5_DIR     = /home/undercover/.micromamba/envs/phd/
GSL_DIR      = /home/undercover/.micromamba/envs/phd/
HWLOC_DIR    = /home/undercover/.micromamba/envs/phd/
PTHREADS_DIR = /home/undercover/.micromamba/envs/phd/
LIBJPEG_DIR  = /home/undercover/.micromamba/envs/phd/
LIBS              = gfortran open-pal z # ?
C_LINE_DIRECTIVES = yes                 # ?
F_LINE_DIRECTIVES = yes                 # ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cactus_empty.log
Type: text/x-log
Size: 10633 bytes
Desc: not available
URL: <http://lists.einsteintoolkit.org/pipermail/users/attachments/20240612/a89105e6/attachment-0001.bin>

From rhaas at illinois.edu  Wed Jun 12 09:59:05 2024
From: rhaas at illinois.edu (Roland Haas)
Date: Wed, 12 Jun 2024 09:59:05 -0500
Subject: [Users] Error on the linking phase on compilation in a virtual
 environment
In-Reply-To: <8fc1a59e-2eba-44e4-bd12-7c35cb9798ff@ua.pt>
References: <8fc1a59e-2eba-44e4-bd12-7c35cb9798ff@ua.pt>
Message-ID: <20240612095905.05d45393@ekohaes8.ncsa.illinois.edu>

Hello Jose,

Cactus uses the C++ compiler to link things. 

This is controlled by the LD option list option.

In your option list (thank you for including it) you do not set it, so
it should default to the value of CXX.

However if there is an environment variable LD set, then this will
override the option list default (you'd see eg LD in the output of the
env command).

So as a first try, I'd add 

LD = g++

to your option list and recompile from scratch.

If that does not help, then more information will be required. Please
see:

http://einsteintoolkit.org/support.html#general-guidelines-for-questions

for what to include.

Yours,
Roland

On Wed, 12 Jun 2024 15:51:13 +0100, Jos? Ferreira wrote:
> Dear toolkit users and developers,
> 
> 
> With the latest update of GCC to version 14, there is a known error
> that prevents the compilation from taking place, preventing me from
> compiling the toolkit.
> 
> I?ve been trying to do something which I probably should have some
> time ago to avoid this kind of issues, while also granting some
> portability between machines, which is to setup a virtual environment
> using Conda to compile the toolkit.
> 
> 
> I am sending you this e-mail because I?ve failed to compile the
> toolkit in a virtual environment, where I am currently stuck with an
> error during the linking phase. Before the update to GCC 14, and
> without the virtual environment, I was able of compiling the toolkit
> without any issue.
> 
> Here are the steps that I have performed:
> 
>  1.
> 
>     Activate an empty virtual environment managed by a conda (or a
>     drop-in replacement) with the conda-forge repository configured
> 
>  2.
> 
>     |conda install gcc gxx gfortran openmpi openmpi-mpicc
> openmpi-mpicxx openmpi-mpifort binutils|
> 
>  3.
> 
>     Compile the toolkit with an empty thornlist, attached in
> |empty.th|, and an option file that points towards the virtual
> environment that is activated, attached in |venv.cfg|
> 
>  4.
> 
>     Get the following error from |ld| (the full log for making the
>     config and the binary are attached in |cactus_empty.log|)
> 
> |Creating cactus_empty in /home/undercover/projects/cactus/exe from
> /home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-ld:
> unrecognised emulation mode: arch=native Supported emulations:
> elf_x86_64 elf32_x86_64 elf_i386 elf_iamcu make[1]: ***
> [/home/undercover/projects/cactus/lib/make/make.configuration:150:
> /home/undercover/projects/cactus/exe/cactus_empty] Error 1 make: ***
> [Makefile:265: empty] Error 2 |
> 
> 
> To me, the previous error indicates that something is passing the
> wrong flags to |ld|, because even if the emulation mode was not
> recognized it should give the error |ld: unrecognised emulation mode:
> <something>| instead of |ld: unrecognised emulation mode:
> arch=<something>|.
> 
> Removing the flag |-march=native| from the compilers confirms my
> guess by revealing a different error at the same stage
> 
> |Creating cactus_empty in /home/undercover/projects/cactus/exe from
> /home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-ld:
> unrecognized option '-DMPICH_IGNORE_CXX_SEEK'
> /home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-ld:
> use the --help option for usage information make[1]: ***
> [/home/undercover/projects/cactus/lib/make/make.configuration:150:
> /home/undercover/projects/cactus/exe/cactus_empty] Error 1 make: ***
> [Makefile:265: empty] Error 2 |
> 
> and if I were to remove the corresponding flag in the config file,
> |ld| will complain about something else.
> 
> It really seems like something is passing the flags onto |ld| where
> it shouldn?t, but I cannot tell who and where.
> 
> 
> I should note that compiling very basic programs in C in the virtual
> environment doesn?t raise any issues, although I haven?t tested it
> very thoroughly.
> 
> Please do let me know if you have any issues in rendering this e-mail!
> 
> 
> Best regards,
> 
> Jos? Ferreira
> 
> 
> ?


-- 
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/20240612/353cc062/attachment.sig>

From jpmferreira at ua.pt  Wed Jun 12 13:04:49 2024
From: jpmferreira at ua.pt (=?UTF-8?Q?Jos=C3=A9_Ferreira?=)
Date: Wed, 12 Jun 2024 19:04:49 +0100
Subject: [Users] Error on the linking phase on compilation in a virtual
 environment
In-Reply-To: <20240612095905.05d45393@ekohaes8.ncsa.illinois.edu>
References: <8fc1a59e-2eba-44e4-bd12-7c35cb9798ff@ua.pt>
 <20240612095905.05d45393@ekohaes8.ncsa.illinois.edu>
Message-ID: <d10cb677-718e-4c62-8e18-fdd540717881@ua.pt>

Hello Roland,


Thanks for the reply, and apologies for not including all relevant 
information.

One of the things is that I forgot to mention that conda (in this case, 
micromamba, a drop-in alternative that is fully compatible) sets some 
environmental variables by itself. Obviously, some of them are are the 
overwritten with whatever is on the |.cfg| file.

It turns out that micromamba sets |$LD| to point towards the |ld| binary 
provided by the virtual environment

Adding |LD = g++| as you suggested resulted in a slightly different error

|Creating cactus_empty in /home/undercover/projects/cactus/exe from 
/home/undercover/.micromamba/envs/phd/bin/../lib/gcc/x86_64-conda-linux-gnu/11.4.0/../../../../x86_64-conda-linux-gnu/bin/ld: 
cannot find -lz: No such file or directory collect2: error: ld returned 
1 exit status make[1]: *** 
[/home/undercover/projects/cactus/lib/make/make.configuration:150: 
/home/undercover/projects/cactus/exe/cactus_empty] Error 1 make: *** 
[Makefile:265: empty] Error 2 |


To avoid back and forth between e-mails, and to add some information 
that was previously missing, here are the steps that I take to reproduce 
the error

 1.

    Create a new conda environment and activate it (in my machine it?s
    called ?phd?)

 2.

    |conda install gcc gxx gfortran openmpi openmpi-mpicc openmpi-mpicxx
    openmpi-mpifort binutils|

 3.

    Compile the toolkit with the thornlist |empty.th| and the options
    file |venv.cfg|, both attached again to this e-mail

 4.

    Configuration is created without any issues, with the terminal
    output attached to |empty.log| (this file was missing in the
    previous e-mail), and get the error making the binary, with the
    terminal output attached in |cactus_empty.log|


Further relevant information about the running status of the machine:

  *

    Environmental variables: see file |env.txt| which includes a
    stripped down version of the environmental variables. For instance,
    you can see that |$LD| is set and carries on with its value during
    compilation, but |$LDFLAGS|, |$CFLAGS| and |$CXXFLAGS| are
    overwritten by whatever is in the |venv.cfg|. Even if I concatenate
    the environmental variables from the shell with the ones from the
    options file, it still doesn?t work.

  *

    OS: Manjaro

  *

    Kernel: Linux legion 5.10.218-1-MANJARO #1 SMP PREEMPT Mon May 27
    02:19:19 UTC 2024 x86_64 GNU/Linux

  *

    CPU: Intel(R) Core(TM) i5-7300HQ CPU @ 2.50GHz (quad core)

  *

    Package Manager: Micromamba
    <https://mamba.readthedocs.io/en/latest/user_guide/micromamba.html>
    using the conda-forge <https://conda-forge.org/packages/> repositories


It should be noted that I am able of replicating this bug on my laptop 
(this machine) and two different desktops that are both running Arch Linux.

This is not totally unexpected considering they are very similar OS?s 
with the same versions of the software that is being used.


I hope that I could make it as clear as possible.

Best regards,

Jos? Ferreira


On 12/06/24 15:59, Roland Haas wrote:

> Hello Jose,
>
> Cactus uses the C++ compiler to link things.
>
> This is controlled by the LD option list option.
>
> In your option list (thank you for including it) you do not set it, so
> it should default to the value of CXX.
>
> However if there is an environment variable LD set, then this will
> override the option list default (you'd see eg LD in the output of the
> env command).
>
> So as a first try, I'd add
>
> LD = g++
>
> to your option list and recompile from scratch.
>
> If that does not help, then more information will be required. Please
> see:
>
> http://einsteintoolkit.org/support.html#general-guidelines-for-questions
>
> for what to include.
>
> Yours,
> Roland
>
> On Wed, 12 Jun 2024 15:51:13 +0100, Jos? Ferreira wrote:
>> Dear toolkit users and developers,
>>
>>
>> With the latest update of GCC to version 14, there is a known error
>> that prevents the compilation from taking place, preventing me from
>> compiling the toolkit.
>>
>> I?ve been trying to do something which I probably should have some
>> time ago to avoid this kind of issues, while also granting some
>> portability between machines, which is to setup a virtual environment
>> using Conda to compile the toolkit.
>>
>>
>> I am sending you this e-mail because I?ve failed to compile the
>> toolkit in a virtual environment, where I am currently stuck with an
>> error during the linking phase. Before the update to GCC 14, and
>> without the virtual environment, I was able of compiling the toolkit
>> without any issue.
>>
>> Here are the steps that I have performed:
>>
>> 1.
>>
>> Activate an empty virtual environment managed by a conda (or a
>> drop-in replacement) with the conda-forge repository configured
>>
>> 2.
>>
>> |conda install gcc gxx gfortran openmpi openmpi-mpicc
>> openmpi-mpicxx openmpi-mpifort binutils|
>>
>> 3.
>>
>> Compile the toolkit with an empty thornlist, attached in
>> |empty.th|, and an option file that points towards the virtual
>> environment that is activated, attached in |venv.cfg|
>>
>> 4.
>>
>> Get the following error from |ld| (the full log for making the
>> config and the binary are attached in |cactus_empty.log|)
>>
>> |Creating cactus_empty in /home/undercover/projects/cactus/exe from
>> /home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-ld:
>> unrecognised emulation mode: arch=native Supported emulations:
>> elf_x86_64 elf32_x86_64 elf_i386 elf_iamcu make[1]: ***
>> [/home/undercover/projects/cactus/lib/make/make.configuration:150:
>> /home/undercover/projects/cactus/exe/cactus_empty] Error 1 make: ***
>> [Makefile:265: empty] Error 2 |
>>
>>
>> To me, the previous error indicates that something is passing the
>> wrong flags to |ld|, because even if the emulation mode was not
>> recognized it should give the error |ld: unrecognised emulation mode:
>> <something>| instead of |ld: unrecognised emulation mode:
>> arch=<something>|.
>>
>> Removing the flag |-march=native| from the compilers confirms my
>> guess by revealing a different error at the same stage
>>
>> |Creating cactus_empty in /home/undercover/projects/cactus/exe from
>> /home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-ld:
>> unrecognized option '-DMPICH_IGNORE_CXX_SEEK'
>> /home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-ld:
>> use the --help option for usage information make[1]: ***
>> [/home/undercover/projects/cactus/lib/make/make.configuration:150:
>> /home/undercover/projects/cactus/exe/cactus_empty] Error 1 make: ***
>> [Makefile:265: empty] Error 2 |
>>
>> and if I were to remove the corresponding flag in the config file,
>> |ld| will complain about something else.
>>
>> It really seems like something is passing the flags onto |ld| where
>> it shouldn?t, but I cannot tell who and where.
>>
>>
>> I should note that compiling very basic programs in C in the virtual
>> environment doesn?t raise any issues, although I haven?t tested it
>> very thoroughly.
>>
>> Please do let me know if you have any issues in rendering this e-mail!
>>
>>
>> Best regards,
>>
>> Jos? Ferreira
>>
>>
>> ?

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.einsteintoolkit.org/pipermail/users/attachments/20240612/4cc0d185/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cactus_empty.log
Type: text/x-log
Size: 10633 bytes
Desc: not available
URL: <http://lists.einsteintoolkit.org/pipermail/users/attachments/20240612/4cc0d185/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: empty.log
Type: text/x-log
Size: 11594 bytes
Desc: not available
URL: <http://lists.einsteintoolkit.org/pipermail/users/attachments/20240612/4cc0d185/attachment-0003.bin>
-------------- next part --------------
# Cactus configuration for virtual environments managed by conda
# change libraries location to match your virtual environment below!

# list of conda packages installed from conda-forge:
# - binutils
# - libjpeg-turbo
# - gsl
# - hdf5
# - openmpi openmpi-mpicc openmpi-mpicxx openmpi-mpifort
# - gcc gxx gfortran

## Decide which flags will be used at compile-time
OPTIMISE = yes
WARN     = yes
DEBUG    = no
PROFILE  = no
OPENMP   = yes

## Preprocessors and Compilers
CPP = cpp
FPP = cpp
CC  = gcc
CXX = g++
F77 = gfortran
F90 = gfortran

## Default flags
CPPFLAGS = -DMPICH_IGNORE_CXX_SEEK
FPPFLAGS = -traditional
CFLAGS   = -g3 -march=native -std=gnu99
CXXFLAGS = -g3 -march=native -std=gnu++0x
F77FLAGS = -g3 -march=native -fcray-pointer -m128bit-long-double -ffixed-line-length-none -fno-range-check
F90FLAGS = -g3 -march=native -fcray-pointer -m128bit-long-double -ffixed-line-length-none -fno-range-check
LDFLAGS  = -rdynamic

## Optimization flags
CPP_OPTIMISE_FLAGS = -DKRANC_VECTORS # -DCARPET_OPTIMISE -DNDEBUG
FPP_OPTIMISE_FLAGS =                 # -DCARPET_OPTIMISE -DNDEBUG
C_OPTIMISE_FLAGS   = -Ofast
CXX_OPTIMISE_FLAGS = -Ofast
F77_OPTIMISE_FLAGS = -Ofast
F90_OPTIMISE_FLAGS = -Ofast

## Warning flags
CPP_WARN_FLAGS = -Wall
FPP_WARN_FLAGS = -Wall
C_WARN_FLAGS   = -Wall
CXX_WARN_FLAGS = -Wall
F77_WARN_FLAGS = -Wall
F90_WARN_FLAGS = -Wall

## Debug flags
CPP_DEBUG_FLAGS = -DCARPET_DEBUG -fsanitize=undefined -fsanitize=thread
FPP_DEBUG_FLAGS = -DCARPET_DEBUG -fsanitize=undefined -fsanitize=thread
C_DEBUG_FLAGS   = -O0            -fsanitize=undefined -fsanitize=thread
CXX_DEBUG_FLAGS = -O0            -fsanitize=undefined -fsanitize=thread
F77_DEBUG_FLAGS = -O0            -fsanitize=undefined -fsanitize=thread
F90_DEBUG_FLAGS = -O0            -fsanitize=undefined -fsanitize=thread

## Code profiling flags
CPP_PROFILE_FLAGS =
FPP_PROFILE_FLAGS =
C_PROFILE_FLAGS   = -pg
CXX_PROFILE_FLAGS = -pg
F77_PROFILE_FLAGS = -pg
F90_PROFILE_FLAGS = -pg

## OpenMP
CPP_OPENMP_FLAGS = -fopenmp
FPP_OPENMP_FLAGS = -fopenmp
C_OPENMP_FLAGS   = -fopenmp
CXX_OPENMP_FLAGS = -fopenmp
F77_OPENMP_FLAGS = -fopenmp
F90_OPENMP_FLAGS = -fopenmp

## Libraries location
LIBDIRS      =   # ?
MPI_DIR      = /home/undercover/.micromamba/envs/phd/
HDF5_DIR     = /home/undercover/.micromamba/envs/phd/
GSL_DIR      = /home/undercover/.micromamba/envs/phd/
HWLOC_DIR    = /home/undercover/.micromamba/envs/phd/
PTHREADS_DIR = /home/undercover/.micromamba/envs/phd/
LIBJPEG_DIR  = /home/undercover/.micromamba/envs/phd/
LIBS              = gfortran open-pal z # ?
C_LINE_DIRECTIVES = yes                 # ?
F_LINE_DIRECTIVES = yes                 # ?
-------------- next part --------------
!CRL_VERSION = 1.0

!DEFINE ROOT = Cactus
!DEFINE ARR  = $ROOT/arrangements
!DEFINE COMPONENTLIST_TARGET = $ROOT/thornlists/

!DEFINE ET_RELEASE = ET_2023_05
-------------- next part --------------
LOGNAME=undercover
HOME=/home/undercover
USER=undercover
CACTUS_ROOT=/home/undercover/projects/cactus
MAMBA_EXE=/usr/bin/micromamba
MAMBA_ROOT_PREFIX=/home/undercover/.micromamba
CONDA_SHLVL=1
CONDA_BACKUP_HOST=legion
HOST=x86_64-conda-linux-gnu
CONDA_PREFIX=/home/undercover/.micromamba/envs/phd
CONDA_DEFAULT_ENV=phd
CONDA_PROMPT_MODIFIER=(phd)
ADDR2LINE=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-addr2line
AR=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-ar
AS=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-as
CXXFILT=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-c++filt
ELFEDIT=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-elfedit
GPROF=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-gprof
LD=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-ld
LD_GOLD=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-ld.gold
NM=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-nm
OBJCOPY=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-objcopy
OBJDUMP=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-objdump
RANLIB=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-ranlib
READELF=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-readelf
SIZE=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-size
STRINGS=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-strings
STRIP=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-strip
BUILD=x86_64-conda-linux-gnu
CONDA_TOOLCHAIN_HOST=x86_64-conda-linux-gnu
CONDA_TOOLCHAIN_BUILD=x86_64-conda-linux-gnu
CC=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-cc
CPP=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-cpp
GCC=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-gcc
GCC_AR=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-gcc-ar
GCC_NM=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-gcc-nm
GCC_RANLIB=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-gcc-ranlib
CPPFLAGS=-DNDEBUG -D_FORTIFY_SOURCE=2 -O2 -isystem /home/undercover/.micromamba/envs/phd/include
CFLAGS=-march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -ffunction-sections -pipe -isystem /home/undercover/.micromamba/envs/phd/include
LDFLAGS=-Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,--disable-new-dtags -Wl,--gc-sections -Wl,--allow-shlib-undefined -Wl,-rpath,/home/undercover/.micromamba/envs/phd/lib -Wl,-rpath-link,/home/undercover/.micromamba/envs/phd/lib -L/home/undercover/.micromamba/envs/phd/lib
DEBUG_CPPFLAGS=-D_DEBUG -D_FORTIFY_SOURCE=2 -Og -isystem /home/undercover/.micromamba/envs/phd/include
DEBUG_CFLAGS=-march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-all -fno-plt -Og -g -Wall -Wextra -fvar-tracking-assignments -ffunction-sections -pipe -isystem /home/undercover/.micromamba/envs/phd/include
CMAKE_PREFIX_PATH=/home/undercover/.micromamba/envs/phd:/home/undercover/.micromamba/envs/phd/x86_64-conda-linux-gnu/sysroot/usr
_CONDA_PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_x86_64_conda_cos6_linux_gnu
CONDA_BUILD_SYSROOT=/home/undercover/.micromamba/envs/phd/x86_64-conda-linux-gnu/sysroot
CC_FOR_BUILD=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-cc
build_alias=x86_64-conda-linux-gnu
host_alias=x86_64-conda-linux-gnu
MESON_ARGS=--buildtype release
CMAKE_ARGS=-DCMAKE_AR=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-ar -DCMAKE_CXX_COMPILER_AR=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-gcc-ar -DCMAKE_C_COMPILER_AR=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-gcc-ar -DCMAKE_RANLIB=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-ranlib -DCMAKE_CXX_COMPILER_RANLIB=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-gcc-ranlib -DCMAKE_C_COMPILER_RANLIB=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-gcc-ranlib -DCMAKE_LINKER=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-ld -DCMAKE_STRIP=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-strip -DCMAKE_BUILD_TYPE=Release
GFORTRAN=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-gfortran
F95=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-f95
FC_FOR_BUILD=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-gfortran
FFLAGS=-march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -ffunction-sections -pipe -isystem /home/undercover/.micromamba/envs/phd/include
FORTRANFLAGS=-march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -ffunction-sections -pipe -isystem /home/undercover/.micromamba/envs/phd/include
DEBUG_FFLAGS=-march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -ffunction-sections -pipe -isystem /home/undercover/.micromamba/envs/phd/include -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-all -fno-plt -Og -g -Wall -Wextra -fcheck=all -fbacktrace -fimplicit-none -fvar-tracking-assignments -ffunction-sections -pipe
DEBUG_FORTRANFLAGS=-march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -ffunction-sections -pipe -isystem /home/undercover/.micromamba/envs/phd/include -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-all -fno-plt -Og -g -Wall -Wextra -fcheck=all -fbacktrace -fimplicit-none -fvar-tracking-assignments -ffunction-sections -pipe
FC=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-gfortran
F77=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-gfortran
F90=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-gfortran
CXX=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-c++
GXX=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-g++
CXXFLAGS=-fvisibility-inlines-hidden -fmessage-length=0 -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -ffunction-sections -pipe -isystem /home/undercover/.micromamba/envs/phd/include
DEBUG_CXXFLAGS=-fvisibility-inlines-hidden -fmessage-length=0 -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-all -fno-plt -Og -g -Wall -Wextra -fvar-tracking-assignments -ffunction-sections -pipe -isystem /home/undercover/.micromamba/envs/phd/include
CXX_FOR_BUILD=/home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-c++
XML_CATALOG_FILES=file:///home/undercover/.micromamba/envs/phd/etc/xml/catalog file:///etc/xml/catalog
_=/usr/bin/env

From rhaas at illinois.edu  Wed Jun 12 13:29:11 2024
From: rhaas at illinois.edu (Roland Haas)
Date: Wed, 12 Jun 2024 13:29:11 -0500
Subject: [Users] Error on the linking phase on compilation in a virtual
 environment
In-Reply-To: <d10cb677-718e-4c62-8e18-fdd540717881@ua.pt>
References: <8fc1a59e-2eba-44e4-bd12-7c35cb9798ff@ua.pt>
 <20240612095905.05d45393@ekohaes8.ncsa.illinois.edu>
 <d10cb677-718e-4c62-8e18-fdd540717881@ua.pt>
Message-ID: <20240612132911.7d1008e4@ekohaes8.ncsa.illinois.edu>

Hello Jos?,

Thanks for the detailed report.

I do not really use conda myself unfortunately, so will not be able to
directly test it though (unless things really go sideways).

The error you are encountering now is that the linker cannot find the
libz.so (or libz.a or libz.la) linker file. This is the zlib library
used for compression by eg HDF5. 

This can have multiple reasons. During configuration Cactus (really the
ExternalLibraries/zlib thorn) tries to determine where zlib is located
and set up linker options accordingly. It does so by (among other
things) searching "well known" locations for the file (among them /usr
and others). If found in one of those "well known" locations, which are
normally included in the compiler's default search path, it will not
add an explicit linker option so as to not move a location from the
"default" priority to "high" priority via an -L option (since this
causes no end of issues, and is eg also what cmake does).

Long story short, the anaconda provided linker may not look at those
"well known" locations since it wants to keep everything contained in
the anaconda environment (which mostly works for Python but not really
for anything else). 

To fix this you'd do like you already do for eg GSL and add a

ZLIB_DIR = /home/undercover/.micromamba/envs/phd/

setting to your option list (assuming that say libz.so is in /home/undercover/.micromamba/envs/phd/lib/libz.so).

Similarly for other errors of the same sort.

The automated search and build functionality in Cactus is mostly geared
towards vanilla Linux installations using one of the distributions
listed in
https://github.com/einsteintoolkit/jupyter-et/blob/master/tutorial-server/notebooks/CactusTutorial.ipynb
in the "Prerequisites" sections or macOS (using HomeBrew or MacPorts).

When used in other circumstances (on clusters, or, apparently, with
[mini]conda) failures are unfortunately common and one has to provide much
more information manually. Hopefully the suggestion above helps a bit.

Coincidentally I presented a talk on the Cactus build system (and some
ways of verifying what is going on) at the ET summer school and
workshop last week at LSU, which may help you find out exactly what is
going on. You can find the slides for this here (and soon also on the
summer school web-page):

https://github.com/rhaas80/2024_LSU/blob/main/CactusBuildSytemTour.ipynb

Yours,
Roland

On Wed, 12 Jun 2024 19:04:49 +0100, Jos? Ferreira wrote:
> Hello Roland,
> 
> 
> Thanks for the reply, and apologies for not including all relevant
> information.
> 
> One of the things is that I forgot to mention that conda (in this
> case, micromamba, a drop-in alternative that is fully compatible)
> sets some environmental variables by itself. Obviously, some of them
> are are the overwritten with whatever is on the |.cfg| file.
> 
> It turns out that micromamba sets |$LD| to point towards the |ld|
> binary provided by the virtual environment
> 
> Adding |LD = g++| as you suggested resulted in a slightly different
> error
> 
> |Creating cactus_empty in /home/undercover/projects/cactus/exe from
> /home/undercover/.micromamba/envs/phd/bin/../lib/gcc/x86_64-conda-linux-gnu
> /11.4.0/../../../../x86_64-conda-linux-gnu/bin/ld: cannot find -lz:
> No such file or directory collect2: error: ld returned 1 exit status
> make[1]: ***
> [/home/undercover/projects/cactus/lib/make/make.configuration:150:
> /home/undercover/projects/cactus/exe/cactus_empty] Error 1 make: ***
> [Makefile:265: empty] Error 2 |
> 
> 
> To avoid back and forth between e-mails, and to add some information
> that was previously missing, here are the steps that I take to
> reproduce the error
> 
>  1.
> 
>     Create a new conda environment and activate it (in my machine it__
> _s
>     called ?phd?)
> 
>  2.
> 
>     |conda install gcc gxx gfortran openmpi openmpi-mpicc
> openmpi-mpicxx openmpi-mpifort binutils|
> 
>  3.
> 
>     Compile the toolkit with the thornlist |empty.th| and the options
>     file |venv.cfg|, both attached again to this e-mail
> 
>  4.
> 
>     Configuration is created without any issues, with the terminal
>     output attached to |empty.log| (this file was missing in the
>     previous e-mail), and get the error making the binary, with the
>     terminal output attached in |cactus_empty.log|
> 
> 
> Further relevant information about the running status of the machine:
> 
>   *
> 
>     Environmental variables: see file |env.txt| which includes a
>     stripped down version of the environmental variables. For
> instance, you can see that |$LD| is set and carries on with its value
> during compilation, but |$LDFLAGS|, |$CFLAGS| and |$CXXFLAGS| are
>     overwritten by whatever is in the |venv.cfg|. Even if I
> concatenate the environmental variables from the shell with the ones
> from the options file, it still doesn?t work.
> 
>   *
> 
>     OS: Manjaro
> 
>   *
> 
>     Kernel: Linux legion 5.10.218-1-MANJARO #1 SMP PREEMPT Mon May 27
>     02:19:19 UTC 2024 x86_64 GNU/Linux
> 
>   *
> 
>     CPU: Intel(R) Core(TM) i5-7300HQ CPU @ 2.50GHz (quad core)
> 
>   *
> 
>     Package Manager: Micromamba
>     <https://urldefense.com/v3/__https://mamba.readthedocs.io/en/latest/use
> r_guide/micromamba.html__;!!DZ3fjg!4JUhc_Pyghv7QqhhZMN_0qShBOabzxJWmOQed8oS
> me19pKFVPvO_FgbMz2l69QVIuUf2kUS14LoJ0DHZJOeg$ >
>     using the conda-forge
> <https://urldefense.com/v3/__https://conda-forge.
> org/packages/__;!!DZ3fjg!4JUhc_Pyghv7QqhhZMN_0qShBOabzxJWmOQed8oSme19pKFVPv
> O_FgbMz2l69QVIuUf2kUS14LoJ0BBzkfxl$ > repositories
> 
> 
> It should be noted that I am able of replicating this bug on my
> laptop (this machine) and two different desktops that are both
> running Arch Linux.
> 
> This is not totally unexpected considering they are very similar OS__
> _s with the same versions of the software that is being used.
> 
> 
> I hope that I could make it as clear as possible.
> 
> Best regards,
> 
> Jos? Ferreira
> 
> 
> On 12/06/24 15:59, Roland Haas wrote:
> 
> > Hello Jose,
> >
> > Cactus uses the C++ compiler to link things.
> >
> > This is controlled by the LD option list option.
> >
> > In your option list (thank you for including it) you do not set it,
> > so it should default to the value of CXX.
> >
> > However if there is an environment variable LD set, then this will
> > override the option list default (you'd see eg LD in the output of
> > the env command).
> >
> > So as a first try, I'd add
> >
> > LD = g++
> >
> > to your option list and recompile from scratch.
> >
> > If that does not help, then more information will be required.
> > Please see:
> >
> > https://urldefense.com/v3/__http://einsteintoolkit.org/support.html*gener
> >  
> al-guidelines-for-questions__;Iw!!DZ3fjg!4JUhc_Pyghv7QqhhZMN_0qShBOabzxJWmO
> Qed8oSme19pKFVPvO_FgbMz2l69QVIuUf2kUS14LoJ0A8OitkU$ >
> > for what to include.
> >
> > Yours,
> > Roland
> >
> > On Wed, 12 Jun 2024 15:51:13 +0100, Jos? Ferreira wrote:  
> >> Dear toolkit users and developers,
> >>
> >>
> >> With the latest update of GCC to version 14, there is a known error
> >> that prevents the compilation from taking place, preventing me from
> >> compiling the toolkit.
> >>
> >> I?ve been trying to do something which I probably should have so  
> me
> >> time ago to avoid this kind of issues, while also granting some
> >> portability between machines, which is to setup a virtual
> >> environment using Conda to compile the toolkit.
> >>
> >>
> >> I am sending you this e-mail because I?ve failed to compile the
> >> toolkit in a virtual environment, where I am currently stuck with
> >> an error during the linking phase. Before the update to GCC 14, and
> >> without the virtual environment, I was able of compiling the
> >> toolkit without any issue.
> >>
> >> Here are the steps that I have performed:
> >>
> >> 1.
> >>
> >> Activate an empty virtual environment managed by a conda (or a
> >> drop-in replacement) with the conda-forge repository configured
> >>
> >> 2.
> >>
> >> |conda install gcc gxx gfortran openmpi openmpi-mpicc
> >> openmpi-mpicxx openmpi-mpifort binutils|
> >>
> >> 3.
> >>
> >> Compile the toolkit with an empty thornlist, attached in
> >> |empty.th|, and an option file that points towards the virtual
> >> environment that is activated, attached in |venv.cfg|
> >>
> >> 4.
> >>
> >> Get the following error from |ld| (the full log for making the
> >> config and the binary are attached in |cactus_empty.log|)
> >>
> >> |Creating cactus_empty in /home/undercover/projects/cactus/exe from
> >> /home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-ld:
> >> unrecognised emulation mode: arch=native Supported emulations:
> >> elf_x86_64 elf32_x86_64 elf_i386 elf_iamcu make[1]: ***
> >> [/home/undercover/projects/cactus/lib/make/make.configuration:150:
> >> /home/undercover/projects/cactus/exe/cactus_empty] Error 1 make:
> >> *** [Makefile:265: empty] Error 2 |
> >>
> >>
> >> To me, the previous error indicates that something is passing the
> >> wrong flags to |ld|, because even if the emulation mode was not
> >> recognized it should give the error |ld: unrecognised emulation
> >> mode: <something>| instead of |ld: unrecognised emulation mode:
> >> arch=<something>|.
> >>
> >> Removing the flag |-march=native| from the compilers confirms my
> >> guess by revealing a different error at the same stage
> >>
> >> |Creating cactus_empty in /home/undercover/projects/cactus/exe from
> >> /home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-ld:
> >> unrecognized option '-DMPICH_IGNORE_CXX_SEEK'
> >> /home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-ld:
> >> use the --help option for usage information make[1]: ***
> >> [/home/undercover/projects/cactus/lib/make/make.configuration:150:
> >> /home/undercover/projects/cactus/exe/cactus_empty] Error 1 make:
> >> *** [Makefile:265: empty] Error 2 |
> >>
> >> and if I were to remove the corresponding flag in the config file,
> >> |ld| will complain about something else.
> >>
> >> It really seems like something is passing the flags onto |ld| where
> >> it shouldn?t, but I cannot tell who and where.
> >>
> >>
> >> I should note that compiling very basic programs in C in the
> >> virtual environment doesn?t raise any issues, although I haven?t  
>  tested it
> >> very thoroughly.
> >>
> >> Please do let me know if you have any issues in rendering this
> >> e-mail!
> >>
> >>
> >> Best regards,
> >>
> >> Jos? Ferreira
> >>
> >>
> >> ?  
> 
> ?


-- 
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/20240612/930fc4dd/attachment.sig>

From jpmferreira at ua.pt  Wed Jun 12 14:43:10 2024
From: jpmferreira at ua.pt (=?UTF-8?Q?Jos=C3=A9_Ferreira?=)
Date: Wed, 12 Jun 2024 20:43:10 +0100
Subject: [Users] Error on the linking phase on compilation in a virtual
 environment
In-Reply-To: <20240612132911.7d1008e4@ekohaes8.ncsa.illinois.edu>
References: <8fc1a59e-2eba-44e4-bd12-7c35cb9798ff@ua.pt>
 <20240612095905.05d45393@ekohaes8.ncsa.illinois.edu>
 <d10cb677-718e-4c62-8e18-fdd540717881@ua.pt>
 <20240612132911.7d1008e4@ekohaes8.ncsa.illinois.edu>
Message-ID: <2663d74e-fa78-4ac2-8601-62c82c351be2@ua.pt>

Dear Roland,


Thanks for the prompt response.

You solution got rid of the error, so it does seem to be a path issues 
after all.


However, right after that, I got another error

|/home/undercover/.micromamba/envs/phd/bin/../lib/gcc/x86_64-conda-linux-gnu/11.4.0/../../../../x86_64-conda-linux-gnu/bin/ld: 
/home/undercover/.micromamba/envs/phd/bin/../lib/gcc/x86_64-conda-linux-gnu/11.4.0/../../../../lib/libopen-pal.so: 
undefined reference to `memcpy at GLIBC_2.14' 
/home/undercover/.micromamba/envs/phd/bin/../lib/gcc/x86_64-conda-linux-gnu/11.4.0/../../../../x86_64-conda-linux-gnu/bin/ld: 
/home/undercover/.micromamba/envs/phd/bin/../lib/gcc/x86_64-conda-linux-gnu/11.4.0/../../../../lib/./libpmix.so.2: 
undefined reference to `clock_gettime at GLIBC_2.17' 
/home/undercover/.micromamba/envs/phd/bin/../lib/gcc/x86_64-conda-linux-gnu/11.4.0/../../../../x86_64-conda-linux-gnu/bin/ld: 
/home/undercover/.micromamba/envs/phd/bin/../lib/gcc/x86_64-conda-linux-gnu/11.4.0/../../../../lib/./././libicuuc.so.73: 
undefined reference to 
`std::condition_variable::wait(std::unique_lock<std::mutex>&)@GLIBCXX_3.4.30' 
collect2: error: ld returned 1 exit status |

which seems to be related to GLIBC.


 From a quick search online, it seems that conda does not allow from a 
custom version of glibc, and the packages available in conda-forge use 
the system glibc, as can be seen when inside the virtual environment

|$ ldd $(which gcc) linux-vdso.so.1 (0x00007ffd03a67000) libm.so.6 => 
/usr/lib/libm.so.6 (0x00007f134b3a3000) libc.so.6 => /usr/lib/libc.so.6 
(0x00007f134b1b7000) /lib64/ld-linux-x86-64.so.2 => 
/usr/lib64/ld-linux-x86-64.so.2 (0x00007f134b4ca000) |

My guess would be that GCC expects a given version of GLIBC (more than 
one, apparently, which feels weird to me) and is unable to find them on 
my system, because I cannot provide them.

My understanding on these topics is sparse at best, so I'm just going to 
believe that there is no way to insert a custom glibc here somehow.


To be clear, I?m not longer asking for your support on this, I?m merely 
just reporting it for you and those that happen to be following this thread.


Thank you for your assistance,

All the best,

Jos? Ferreira


*P.S.:* Is there any workaround on 
https://bitbucket.org/einsteintoolkit/tickets/issues/2802/compilation-faiulres-in-twopunctures_bbhsf, 
for instance, by inserting some flag on GCC 14 and recover the warning 
where now there is an error?


On 12/06/24 19:29, Roland Haas wrote:

> Hello Jos?,
>
> Thanks for the detailed report.
>
> I do not really use conda myself unfortunately, so will not be able to
> directly test it though (unless things really go sideways).
>
> The error you are encountering now is that the linker cannot find the
> libz.so (or libz.a or libz.la) linker file. This is the zlib library
> used for compression by eg HDF5.
>
> This can have multiple reasons. During configuration Cactus (really the
> ExternalLibraries/zlib thorn) tries to determine where zlib is located
> and set up linker options accordingly. It does so by (among other
> things) searching "well known" locations for the file (among them /usr
> and others). If found in one of those "well known" locations, which are
> normally included in the compiler's default search path, it will not
> add an explicit linker option so as to not move a location from the
> "default" priority to "high" priority via an -L option (since this
> causes no end of issues, and is eg also what cmake does).
>
> Long story short, the anaconda provided linker may not look at those
> "well known" locations since it wants to keep everything contained in
> the anaconda environment (which mostly works for Python but not really
> for anything else).
>
> To fix this you'd do like you already do for eg GSL and add a
>
> ZLIB_DIR = /home/undercover/.micromamba/envs/phd/
>
> setting to your option list (assuming that say libz.so is in /home/undercover/.micromamba/envs/phd/lib/libz.so).
>
> Similarly for other errors of the same sort.
>
> The automated search and build functionality in Cactus is mostly geared
> towards vanilla Linux installations using one of the distributions
> listed in
> https://github.com/einsteintoolkit/jupyter-et/blob/master/tutorial-server/notebooks/CactusTutorial.ipynb
> in the "Prerequisites" sections or macOS (using HomeBrew or MacPorts).
>
> When used in other circumstances (on clusters, or, apparently, with
> [mini]conda) failures are unfortunately common and one has to provide much
> more information manually. Hopefully the suggestion above helps a bit.
>
> Coincidentally I presented a talk on the Cactus build system (and some
> ways of verifying what is going on) at the ET summer school and
> workshop last week at LSU, which may help you find out exactly what is
> going on. You can find the slides for this here (and soon also on the
> summer school web-page):
>
> https://github.com/rhaas80/2024_LSU/blob/main/CactusBuildSytemTour.ipynb
>
> Yours,
> Roland
>
> On Wed, 12 Jun 2024 19:04:49 +0100, Jos? Ferreira wrote:
>> Hello Roland,
>>
>>
>> Thanks for the reply, and apologies for not including all relevant
>> information.
>>
>> One of the things is that I forgot to mention that conda (in this
>> case, micromamba, a drop-in alternative that is fully compatible)
>> sets some environmental variables by itself. Obviously, some of them
>> are are the overwritten with whatever is on the |.cfg| file.
>>
>> It turns out that micromamba sets |$LD| to point towards the |ld|
>> binary provided by the virtual environment
>>
>> Adding |LD = g++| as you suggested resulted in a slightly different
>> error
>>
>> |Creating cactus_empty in /home/undercover/projects/cactus/exe from
>> /home/undercover/.micromamba/envs/phd/bin/../lib/gcc/x86_64-conda-linux-gnu
>> /11.4.0/../../../../x86_64-conda-linux-gnu/bin/ld: cannot find -lz:
>> No such file or directory collect2: error: ld returned 1 exit status
>> make[1]: ***
>> [/home/undercover/projects/cactus/lib/make/make.configuration:150:
>> /home/undercover/projects/cactus/exe/cactus_empty] Error 1 make: ***
>> [Makefile:265: empty] Error 2 |
>>
>>
>> To avoid back and forth between e-mails, and to add some information
>> that was previously missing, here are the steps that I take to
>> reproduce the error
>>
>> 1.
>>
>> Create a new conda environment and activate it (in my machine it__
>> _s
>> called ?phd?)
>>
>> 2.
>>
>> |conda install gcc gxx gfortran openmpi openmpi-mpicc
>> openmpi-mpicxx openmpi-mpifort binutils|
>>
>> 3.
>>
>> Compile the toolkit with the thornlist |empty.th| and the options
>> file |venv.cfg|, both attached again to this e-mail
>>
>> 4.
>>
>> Configuration is created without any issues, with the terminal
>> output attached to |empty.log| (this file was missing in the
>> previous e-mail), and get the error making the binary, with the
>> terminal output attached in |cactus_empty.log|
>>
>>
>> Further relevant information about the running status of the machine:
>>
>> *
>>
>> Environmental variables: see file |env.txt| which includes a
>> stripped down version of the environmental variables. For
>> instance, you can see that |$LD| is set and carries on with its value
>> during compilation, but |$LDFLAGS|, |$CFLAGS| and |$CXXFLAGS| are
>> overwritten by whatever is in the |venv.cfg|. Even if I
>> concatenate the environmental variables from the shell with the ones
>> from the options file, it still doesn?t work.
>>
>> *
>>
>> OS: Manjaro
>>
>> *
>>
>> Kernel: Linux legion 5.10.218-1-MANJARO #1 SMP PREEMPT Mon May 27
>> 02:19:19 UTC 2024 x86_64 GNU/Linux
>>
>> *
>>
>> CPU: Intel(R) Core(TM) i5-7300HQ CPU @ 2.50GHz (quad core)
>>
>> *
>>
>> Package Manager: Micromamba
>> <https://urldefense.com/v3/__https://mamba.readthedocs.io/en/latest/use 
>> r_guide/micromamba.html__;!!DZ3fjg!4JUhc_Pyghv7QqhhZMN_0qShBOabzxJWmOQed8oS 
>> me19pKFVPvO_FgbMz2l69QVIuUf2kUS14LoJ0DHZJOeg$ >
>> using the conda-forge
>> <https://urldefense.com/v3/__https://conda-forge. 
>> org/packages/__;!!DZ3fjg!4JUhc_Pyghv7QqhhZMN_0qShBOabzxJWmOQed8oSme19pKFVPv 
>> O_FgbMz2l69QVIuUf2kUS14LoJ0BBzkfxl$ >  repositories
>>
>>
>> It should be noted that I am able of replicating this bug on my
>> laptop (this machine) and two different desktops that are both
>> running Arch Linux.
>>
>> This is not totally unexpected considering they are very similar OS__
>> _s with the same versions of the software that is being used.
>>
>>
>> I hope that I could make it as clear as possible.
>>
>> Best regards,
>>
>> Jos? Ferreira
>>
>>
>> On 12/06/24 15:59, Roland Haas wrote:
>>
>>> Hello Jose,
>>>
>>> Cactus uses the C++ compiler to link things.
>>>
>>> This is controlled by the LD option list option.
>>>
>>> In your option list (thank you for including it) you do not set it,
>>> so it should default to the value of CXX.
>>>
>>> However if there is an environment variable LD set, then this will
>>> override the option list default (you'd see eg LD in the output of
>>> the env command).
>>>
>>> So as a first try, I'd add
>>>
>>> LD = g++
>>>
>>> to your option list and recompile from scratch.
>>>
>>> If that does not help, then more information will be required.
>>> Please see:
>>>
>>> https://urldefense.com/v3/__http://einsteintoolkit.org/support.html*gener
>>>
>> al-guidelines-for-questions__;Iw!!DZ3fjg!4JUhc_Pyghv7QqhhZMN_0qShBOabzxJWmO
>> Qed8oSme19pKFVPvO_FgbMz2l69QVIuUf2kUS14LoJ0A8OitkU$ >
>>> for what to include.
>>>
>>> Yours,
>>> Roland
>>>
>>> On Wed, 12 Jun 2024 15:51:13 +0100, Jos? Ferreira wrote:
>>>> Dear toolkit users and developers,
>>>>
>>>>
>>>> With the latest update of GCC to version 14, there is a known error
>>>> that prevents the compilation from taking place, preventing me from
>>>> compiling the toolkit.
>>>>
>>>> I?ve been trying to do something which I probably should have so
>> me
>>>> time ago to avoid this kind of issues, while also granting some
>>>> portability between machines, which is to setup a virtual
>>>> environment using Conda to compile the toolkit.
>>>>
>>>>
>>>> I am sending you this e-mail because I?ve failed to compile the
>>>> toolkit in a virtual environment, where I am currently stuck with
>>>> an error during the linking phase. Before the update to GCC 14, and
>>>> without the virtual environment, I was able of compiling the
>>>> toolkit without any issue.
>>>>
>>>> Here are the steps that I have performed:
>>>>
>>>> 1.
>>>>
>>>> Activate an empty virtual environment managed by a conda (or a
>>>> drop-in replacement) with the conda-forge repository configured
>>>>
>>>> 2.
>>>>
>>>> |conda install gcc gxx gfortran openmpi openmpi-mpicc
>>>> openmpi-mpicxx openmpi-mpifort binutils|
>>>>
>>>> 3.
>>>>
>>>> Compile the toolkit with an empty thornlist, attached in
>>>> |empty.th|, and an option file that points towards the virtual
>>>> environment that is activated, attached in |venv.cfg|
>>>>
>>>> 4.
>>>>
>>>> Get the following error from |ld| (the full log for making the
>>>> config and the binary are attached in |cactus_empty.log|)
>>>>
>>>> |Creating cactus_empty in /home/undercover/projects/cactus/exe from
>>>> /home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-ld:
>>>> unrecognised emulation mode: arch=native Supported emulations:
>>>> elf_x86_64 elf32_x86_64 elf_i386 elf_iamcu make[1]: ***
>>>> [/home/undercover/projects/cactus/lib/make/make.configuration:150:
>>>> /home/undercover/projects/cactus/exe/cactus_empty] Error 1 make:
>>>> *** [Makefile:265: empty] Error 2 |
>>>>
>>>>
>>>> To me, the previous error indicates that something is passing the
>>>> wrong flags to |ld|, because even if the emulation mode was not
>>>> recognized it should give the error |ld: unrecognised emulation
>>>> mode: <something>| instead of |ld: unrecognised emulation mode:
>>>> arch=<something>|.
>>>>
>>>> Removing the flag |-march=native| from the compilers confirms my
>>>> guess by revealing a different error at the same stage
>>>>
>>>> |Creating cactus_empty in /home/undercover/projects/cactus/exe from
>>>> /home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-ld:
>>>> unrecognized option '-DMPICH_IGNORE_CXX_SEEK'
>>>> /home/undercover/.micromamba/envs/phd/bin/x86_64-conda-linux-gnu-ld:
>>>> use the --help option for usage information make[1]: ***
>>>> [/home/undercover/projects/cactus/lib/make/make.configuration:150:
>>>> /home/undercover/projects/cactus/exe/cactus_empty] Error 1 make:
>>>> *** [Makefile:265: empty] Error 2 |
>>>>
>>>> and if I were to remove the corresponding flag in the config file,
>>>> |ld| will complain about something else.
>>>>
>>>> It really seems like something is passing the flags onto |ld| where
>>>> it shouldn?t, but I cannot tell who and where.
>>>>
>>>>
>>>> I should note that compiling very basic programs in C in the
>>>> virtual environment doesn?t raise any issues, although I haven?t
>>   tested it
>>>> very thoroughly.
>>>>
>>>> Please do let me know if you have any issues in rendering this
>>>> e-mail!
>>>>
>>>>
>>>> Best regards,
>>>>
>>>> Jos? Ferreira
>>>>
>>>>
>>>> ?
>> ?

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.einsteintoolkit.org/pipermail/users/attachments/20240612/67feda15/attachment-0001.htm>

From rhaas at illinois.edu  Wed Jun 12 17:15:01 2024
From: rhaas at illinois.edu (rhaas at illinois.edu)
Date: Wed, 12 Jun 2024 17:15:01 -0500
Subject: [Users] Einstein Toolkit Meeting Reminder
Message-ID: <E1sHWFB-00000003LHC-2inC@ekohaes8.ncsa.illinois.edu>

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 scupp1 at my.apsu.edu  Thu Jun 13 09:45:22 2024
From: scupp1 at my.apsu.edu (Cupp, Samuel D.)
Date: Thu, 13 Jun 2024 14:45:22 +0000
Subject: [Users] Meeting minutes for 2024-06-13
Message-ID: <CH0PR01MB6858846A0C03DF81FDEB6260D9C12@CH0PR01MB6858.prod.exchangelabs.com>

Present: Sam, Keith, Steve, Lucas, Zach, Leo, Roland

# ET Workshop recap
* Other than Steve getting very sick, meeting went well
* in process of gathering slides, videos to provide links
* should add a page on the wiki for "things to keep in mind while planning a workshop"
* Try to collect pictures from meeting to share

# ET Release
* working to get testing, gallery examples completed
* goal: have release out by the end of June
* BNS gallery example needs some additional instructions to better clarify the required steps to run
* Z4c is delayed to next release, so it was removed from manifest thornlist

# Tickets
* Ticket 2803: this PR is already merged; the commit will be closed
* Ticket 2802: needs similar fix as in ticket 2801
* Ticket 2801: PR resolves compilation failures; should be reviewed and merged

Next week
Chair: Lucas
Minute taker: Roland

   Samuel Cupp
   Postdoctoral Researcher
   Department of Physics
   University of Idaho
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.einsteintoolkit.org/pipermail/users/attachments/20240613/4fb79fab/attachment.htm>

From alarconjason033 at gmail.com  Sat Jun 15 10:30:23 2024
From: alarconjason033 at gmail.com (Jason Alarcon)
Date: Sat, 15 Jun 2024 11:30:23 -0400
Subject: [Users] Using FUKA ID's in ETK
Message-ID: <CAH3G3srDu-fhvUZnAiCJq2JcOK=u7aM8AEKwFfCaswKtckSjHQ@mail.gmail.com>

Hello,

I am new to using the Kadath FUKA solver as a thorn for the Einstein
Toolkit and I decided to use the BBH.info <http://bbh.info/> ID located in
the KadathImporter/par path and its respected .par file, however when I run
my usual create and submit command with simfactory, there is some parsing
error:

   - /home/eilyn/simulations/BBH/SIMFACTORY/exe/cactus_sim -L 3
   /home/eilyn/simulations/BBH/output-0000/BBH.info <http://bbh.info/>
   WARNING level 0 from host Girls-DESKTOP33. process 0
   in thorn cactus, file BBH.info:2 <http://bbh.info:2/>:
   -> ERROR IN PARAMETER FILE:Parse Error
   Expected one of the following characters: ':'initial
   {
   ^

I have tried fixing the formatting but nothing has worked thus far. Here is
the ID file:


How can this file be put into Cactus format?


Best regards,

Jason Alarcon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.einsteintoolkit.org/pipermail/users/attachments/20240615/9b03b7b1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BBH.info
Type: application/octet-stream
Size: 2278 bytes
Desc: not available
URL: <http://lists.einsteintoolkit.org/pipermail/users/attachments/20240615/9b03b7b1/attachment.obj>

From sbrandt at cct.lsu.edu  Mon Jun 17 09:34:55 2024
From: sbrandt at cct.lsu.edu (Steven Brandt)
Date: Mon, 17 Jun 2024 09:34:55 -0500
Subject: [Users] Using FUKA ID's in ETK
In-Reply-To: <CAH3G3srDu-fhvUZnAiCJq2JcOK=u7aM8AEKwFfCaswKtckSjHQ@mail.gmail.com>
References: <CAH3G3srDu-fhvUZnAiCJq2JcOK=u7aM8AEKwFfCaswKtckSjHQ@mail.gmail.com>
Message-ID: <1e088fab-8ef3-4e0a-bfb1-05cf6b6cac49@cct.lsu.edu>

Hello Jason,

It looks like you've given a FUKA parfile to Cactus. It doesn't work 
that way. You have to give the FUKA parfile to FUKA, then use a 
Cactus-style parfile to run.

--Steve

On 6/15/2024 10:30 AM, Jason Alarcon wrote:
> Hello,
>
> I am new to using the Kadath FUKA solver as a thorn for the Einstein 
> Toolkit and I decided to use the BBH.info <http://bbh.info/>?ID 
> located in the KadathImporter/par path and its respected .par file, 
> however when I run my usual create and submit command with simfactory, 
> there is some parsing error:
>
>   * /home/eilyn/simulations/BBH/SIMFACTORY/exe/cactus_sim -L 3
>     /home/eilyn/simulations/BBH/output-0000/BBH.info <http://bbh.info/>
>     WARNING level 0 from host Girls-DESKTOP33. process 0
>     in thorn cactus, file BBH.info:2 <http://bbh.info:2/>:
>     -> ERROR IN PARAMETER FILE:Parse?Error
>     Expected one of the following characters: ':'initial
>     {
>     ^
>
> I have tried fixing the formatting but nothing has worked thus far. 
> Here is the ID file:
>
>
> How can this file be put into Cactus format?
>
>
> Best?regards,
>
> Jason Alarcon
>
>
> _______________________________________________
> Users mailing list
> Users at einsteintoolkit.org
> http://lists.einsteintoolkit.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.einsteintoolkit.org/pipermail/users/attachments/20240617/d76fdd72/attachment.htm>

From rhaas at illinois.edu  Mon Jun 17 15:18:01 2024
From: rhaas at illinois.edu (rhaas at illinois.edu)
Date: Mon, 17 Jun 2024 15:18:01 -0500
Subject: [Users] Agenda for Thursday's Meeting
Message-ID: <E1sJInh-00000009vRe-31Jb@ekohaes8.ncsa.illinois.edu>

Please update the Wiki with agenda items for Thursday's meeting. Thanks!

https://docs.einsteintoolkit.org/et-docs/meeting_agenda

--The Maintainers

From alarconjason033 at gmail.com  Mon Jun 17 22:51:15 2024
From: alarconjason033 at gmail.com (Jason Alarcon)
Date: Mon, 17 Jun 2024 23:51:15 -0400
Subject: [Users] Using FUKA ID's in ETK
Message-ID: <CAH3G3sq+=P0z5OZq+evH5HG6p_D=kqpEfLk=38PS4qOPBXKrLg@mail.gmail.com>

Hello,

I fixed the issue. I for some reason placed the ID as the parfile. However,
starting the simulation segment ends short when the thorn Kadath_Importer
cannot be found. The parfile I am using includes it as an active thorn and
the thornlists seemed to have included in both KadathImporter and
KadathThorn. KadathThorn also fails to be found when included in the
parfile.

I have included both the output and parfile below for a BBH setup:

Best regards,
Jason Alarcon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.einsteintoolkit.org/pipermail/users/attachments/20240617/16f1b839/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GW150914.par
Type: application/octet-stream
Size: 21122 bytes
Desc: not available
URL: <http://lists.einsteintoolkit.org/pipermail/users/attachments/20240617/16f1b839/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BBH.out
Type: application/octet-stream
Size: 2952 bytes
Desc: not available
URL: <http://lists.einsteintoolkit.org/pipermail/users/attachments/20240617/16f1b839/attachment-0003.obj>

From sbrandt at cct.lsu.edu  Tue Jun 18 07:50:51 2024
From: sbrandt at cct.lsu.edu (Steven Brandt)
Date: Tue, 18 Jun 2024 07:50:51 -0500
Subject: [Users] Using FUKA ID's in ETK
In-Reply-To: <CAH3G3sq+=P0z5OZq+evH5HG6p_D=kqpEfLk=38PS4qOPBXKrLg@mail.gmail.com>
References: <CAH3G3sq+=P0z5OZq+evH5HG6p_D=kqpEfLk=38PS4qOPBXKrLg@mail.gmail.com>
Message-ID: <55da8bf7-17f7-4365-8a76-b5420dafa2be@cct.lsu.edu>

Jason,

It sounds like you didn't build the KadathImporter. Is it in your 
thornlist? i.e. in Cactus/thornlists/einsteintoolkit.th?

--Steve

On 6/17/2024 10:51 PM, Jason Alarcon wrote:
> Hello,
>
> I fixed the issue. I for some reason placed the ID as the parfile. 
> However, starting the simulation segment ends short when the thorn 
> Kadath_Importer cannot be found. The parfile I am using includes it as 
> an active thorn and the thornlists?seemed to have included in both 
> KadathImporter and KadathThorn. KadathThorn also fails to be found 
> when included in the parfile.
>
> I have included both the output and parfile below for a BBH setup:
>
> Best regards,
> Jason Alarcon
>
> _______________________________________________
> Users mailing list
> Users at einsteintoolkit.org
> http://lists.einsteintoolkit.org/mailman/listinfo/users

From rhaas at illinois.edu  Tue Jun 18 08:28:26 2024
From: rhaas at illinois.edu (Roland Haas)
Date: Tue, 18 Jun 2024 08:28:26 -0500
Subject: [Users] Using FUKA ID's in ETK
In-Reply-To: <CAH3G3sq+=P0z5OZq+evH5HG6p_D=kqpEfLk=38PS4qOPBXKrLg@mail.gmail.com>
References: <CAH3G3sq+=P0z5OZq+evH5HG6p_D=kqpEfLk=38PS4qOPBXKrLg@mail.gmail.com>
Message-ID: <20240618082826.0493c6dd@ekohaes8.ncsa.illinois.edu>

Hello Jason,

If the thorn named in the error message is indeed "Kadath_Importer" but
your thornlist file contained a thorn "KadathImporter" (note the
underscore) then my guess would be that there is a typo in the
ActiveThorns (and maybe other) line(s) of the parameter file and it
should say "KadathImporter" as well.

Yours,
Roland

On Mon, 17 Jun 2024 23:51:15 -0400, Jason Alarcon wrote:
> Hello,
> 
> I fixed the issue. I for some reason placed the ID as the parfile. However,
> starting the simulation segment ends short when the thorn Kadath_Importer
> cannot be found. The parfile I am using includes it as an active thorn and
> the thornlists seemed to have included in both KadathImporter and
> KadathThorn. KadathThorn also fails to be found when included in the
> parfile.
> 
> I have included both the output and parfile below for a BBH setup:
> 
> Best regards,
> Jason Alarcon


-- 
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/20240618/2ceaafbe/attachment.sig>

From alarconjason033 at gmail.com  Tue Jun 18 10:08:37 2024
From: alarconjason033 at gmail.com (Jason Alarcon)
Date: Tue, 18 Jun 2024 11:08:37 -0400
Subject: [Users] Using FUKA ID's in ETK
In-Reply-To: <20240618082826.0493c6dd@ekohaes8.ncsa.illinois.edu>
References: <CAH3G3sq+=P0z5OZq+evH5HG6p_D=kqpEfLk=38PS4qOPBXKrLg@mail.gmail.com>
 <20240618082826.0493c6dd@ekohaes8.ncsa.illinois.edu>
Message-ID: <CAH3G3srnv5RJjhXBOdX2VDOgHXHGjt7eGaTve=cep3hSUKd1zA@mail.gmail.com>

Hello,

I retried without the underscore and it does not seem to fix the
problem. I checked the thornlists and KadathThorn with KadathImporter
seems to be included. I have included the two parts concerning FUKA
from the thornlists, note the two commented lines at the end:

# FUKA initial data thorns
# the crazy path works around a bug in GetComponents that does not handle
# symbolic links and ".." correctly
!TARGET = $ARR/Fuka/KadathThorn/src/fuka/../../../../repos/KadathThorn/src/fuka
!TYPE   = git
!URL    = https://bitbucket.org/fukaws/fuka
!REPO_BRANCH = $ET_RELEASE
!CHECKOUT = Cmake build_debug build_release codes eos include
install_par.sh install_seq.sh src src_par src_seq

!TARGET   = $ARR
!TYPE     = git
!URL      = https://bitbucket.org/fukaws/$2
!REPO_BRANCH = $ET_RELEASE
!REPO_PATH=../$2
!CHECKOUT = Fuka/KadathImporter Fuka/KadathThorn
#DISABLED Fuka/KadathImporter
#DISABLED Fuka/KadathThorn

I would assume these thorns would be getting built correctly or? I
will have to test the Boost thorn as explained by Samual Tootle to see
if it can be recognized in the parfile.

On Tue, Jun 18, 2024 at 9:28?AM Roland Haas <rhaas at illinois.edu> wrote:
>
> Hello Jason,
>
> If the thorn named in the error message is indeed "Kadath_Importer" but
> your thornlist file contained a thorn "KadathImporter" (note the
> underscore) then my guess would be that there is a typo in the
> ActiveThorns (and maybe other) line(s) of the parameter file and it
> should say "KadathImporter" as well.
>
> Yours,
> Roland
>
> On Mon, 17 Jun 2024 23:51:15 -0400, Jason Alarcon wrote:
> > Hello,
> >
> > I fixed the issue. I for some reason placed the ID as the parfile. However,
> > starting the simulation segment ends short when the thorn Kadath_Importer
> > cannot be found. The parfile I am using includes it as an active thorn and
> > the thornlists seemed to have included in both KadathImporter and
> > KadathThorn. KadathThorn also fails to be found when included in the
> > parfile.
> >
> > I have included both the output and parfile below for a BBH setup:
> >
> > Best regards,
> > Jason Alarcon
>
>
> --
> 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 illinois.edu  Tue Jun 18 10:17:33 2024
From: rhaas at illinois.edu (Roland Haas)
Date: Tue, 18 Jun 2024 10:17:33 -0500
Subject: [Users] Using FUKA ID's in ETK
In-Reply-To: <CAH3G3srnv5RJjhXBOdX2VDOgHXHGjt7eGaTve=cep3hSUKd1zA@mail.gmail.com>
References: <CAH3G3sq+=P0z5OZq+evH5HG6p_D=kqpEfLk=38PS4qOPBXKrLg@mail.gmail.com>
 <20240618082826.0493c6dd@ekohaes8.ncsa.illinois.edu>
 <CAH3G3srnv5RJjhXBOdX2VDOgHXHGjt7eGaTve=cep3hSUKd1zA@mail.gmail.com>
Message-ID: <20240618101733.6a43f696@ekohaes8.ncsa.illinois.edu>

Hello Jason,

> !TARGET   = $ARR
> !TYPE     = git
> !URL      = https://urldefense.com/v3/__https://bitbucket.org/fukaws/$2__;!!DZ3fjg!_fcvNW5pBtmHLaGjq1LKcZnU4h0IK3foxvw0dSLoxI1ErCAVnLHhBoGEyulUnrAJRiHpvQkjZCeQ9ub9qzErRgd4NA$ 
> !REPO_BRANCH = $ET_RELEASE
> !REPO_PATH=../$2
> !CHECKOUT = Fuka/KadathImporter Fuka/KadathThorn
> #DISABLED Fuka/KadathImporter
> #DISABLED Fuka/KadathThorn

These two lines comment out the thorn ("#" is a comment marker in
parameter file). You will have to remove the "#DISABLED " leading
string to actually compile them. Otherwise they will only be checked
out, but not compiled (b/c of the !CHECKOUT line above).

Please note that Kadath may require extra code for example the Boost
library as provided by

https://github.com/dradice/Boost.git

(not part of the ET).

> I would assume these thorns would be getting built correctly or? I
> will have to test the Boost thorn as explained by Samual Tootle to see
> if it can be recognized in the parfile.

As far as I can tell they are not being built. You can check which
thorns are compiled into your Cactus executable using the "-T" command
line option.

Eg

exe/cactus_sim -T

which lists all compiled in thorns.

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: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.einsteintoolkit.org/pipermail/users/attachments/20240618/e86cc168/attachment-0001.sig>

From zachetie at gmail.com  Tue Jun 18 13:07:24 2024
From: zachetie at gmail.com (Zach Etienne)
Date: Tue, 18 Jun 2024 11:07:24 -0700
Subject: [Users] New Testing Framework for Individual Einstein Toolkit Thorns
Message-ID: <CAP6hNvySW1bhWNaX7k3aE4Lo5HhUq+sT=N-s56VrchbXQXcsXg@mail.gmail.com>

Einstein Toolkit community:

I have completed a new, automated, and fast framework for testing
individual or small groups of thorns within the Einstein Toolkit. Although
it is developed with GitHub Actions in mind, it can be run locally. As I
believe this may be useful for the community, I am sharing all the details
in this email.

While the framework is developed for thorns generated with NRPy2, it can be
simplified fairly straightforwardly for thorns developed by hand. Here's
how it works:

With each push to the NRPy2 `main` branch, the following happens (as
documented here:
https://github.com/nrpy/nrpy/blob/main/.github/workflows/main.yml#L136):
GitHub Actions first downloads an Apptainer (formerly Singularity) SIF
image I have prepared here:
https://github.com/nrpy/einsteintoolkit_ci_images/releases. The above image
contains a recent (24.04) Ubuntu distribution with two pieces of software
installed in /opt:
1. A *compiled* version of a recent (pre-2024-06 release) version of the
Einstein Toolkit, with Baikal*, IllinoisGRMHD, WaveToyNRPy, and all other
required thorns.
2. A recent NRPy2.

After downloading the above image, Actions runs a script that pulls the
latest NRPy2 main branch, generates Baikal* and WaveToyNRPy thorns,
overwrites these thorns in the Einstein Toolkit, and then compiles them
within the Toolkit. Since other thorns are not compiled, this is a very
quick check to ensure that updates to NRPy2-generated thorns do not break
the compilation.

Finally, the Einstein Toolkit testsuite is run on each of these thorns. If
any of the above steps ({download, thorn generation, compilation,
testsuite}) fail, then GitHub Actions fails and it automatically sends me
an unpleasant email.

We plan to extend the framework to CarpetX (Baikal*X and WaveToyNRPyX
thorns) in the coming months, probably with a separate Apptainer image.
Please feel free to use the Apptainer image available at
https://github.com/nrpy/einsteintoolkit_ci_images/releases, or the script
available at
https://github.com/nrpy/nrpy/blob/main/.github/workflows/main.yml#L136 if
you may find it useful. Everything here is open source.

This complements the very nice existing Einstein Toolkit testing framework (
https://einsteintoolkit.github.io/tests/), which builds the entire Toolkit
automatically after any ET thorn or the flesh is updated. The full build
requires about 90 minutes, whereas my testing framework is more limited in
scope and completes in under 10 minutes (as it focuses only on a small
collection of thorns).

-Zach

*     *     *
Zachariah Etienne
Assoc. Prof. of Physics, U. of Idaho
Adjunct Assoc. Prof. of Physics & Astronomy, West Virginia U.
https://etienneresearch.com
https://blackholesathome.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.einsteintoolkit.org/pipermail/users/attachments/20240618/9ea63158/attachment.htm>

From bozzola.gabriele at gmail.com  Wed Jun 19 11:24:00 2024
From: bozzola.gabriele at gmail.com (Gabriele Bozzola)
Date: Wed, 19 Jun 2024 09:24:00 -0700
Subject: [Users] New release of kuibit (now with support for OpenPMD files)
Message-ID: <CAMLD_5EHFN6BEtkhrPPqPUEZvwKr=KzEQpwW6JhdEyeD0J-cPA@mail.gmail.com>

Dear Einstein Toolkit community,

kuibit 1.5.0 was just released.

kuibit 1.5.0 comes with one big feature and one important fix.

The fix is for the (unmaintained) tikzplotlib package, which stopped
working with recent
versions of matplotlib. This led to problems with using the `visualize`
module in kuibit.

Second, more excitingly, kuibit now comes with experimental support for
reading OpenPMD
grid files, such as the ones produced by CarpetX.

This is the result of the impressive year-long effort by high-school
student Krishiv Bhatia,
supervised by Erik Schnetter and Lucas Carneiro.

kuibit abstractions work in the same way regardless of the file format
(ASCII, HDF5, or OpenPMD).

For example, the following piece of code plots a equatorial slice of a 3D
field:
```
import kubit
sd = SimDir("PATH_TO_SIM_OUTPUT")
iteration_num = 0
kuibit.visualize_matplotlib.plot_color(sd.gf.xyz["my_var"][iteration_num].sliced(cut=[None,
None, 0]), shape = [100, 100])
```

Support for reading OpenPMD files should be considered experimental at this
point.
Please, report any issue you might find.

https://github.com/Sbozzolo/kuibit

Best,
Gabriele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.einsteintoolkit.org/pipermail/users/attachments/20240619/c85ea9f9/attachment.htm>

From rhaas at illinois.edu  Wed Jun 19 17:15:01 2024
From: rhaas at illinois.edu (rhaas at illinois.edu)
Date: Wed, 19 Jun 2024 17:15:01 -0500
Subject: [Users] Einstein Toolkit Meeting Reminder
Message-ID: <E1sK3a1-0000000Cbah-3c5F@ekohaes8.ncsa.illinois.edu>

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 illinois.edu  Thu Jun 20 09:28:11 2024
From: rhaas at illinois.edu (Roland Haas)
Date: Thu, 20 Jun 2024 09:28:11 -0500
Subject: [Users] meeting minutes for 2024-06-20
Message-ID: <20240620092811.3a99c29b@ekohaes8.ncsa.illinois.edu>

Present: Roland, Steve, Lucas, Peter, Keith, Sam, Zach

ET release
==========

* Steve is running tests on LSU machines
* draft of ET release announcement in
https://einsteintoolkit.org/about/releases/ET_2024_05_announcement.md
* will confirm with champions that all those who contributed to the
  contributed code and the release are recorded

kuibit release
==============

* will try to include in release
* major update is reading openPMD files, as output by CarpetX

ET CI tests failing
===================

* Roland provided an update on issue with CI server, due to bokeh
  version update

Gallery tests
=============

multipatch example:
* Lucas encountered issues with instructions, will provide updates
* has Python script for plotting, which should be less fragile than
  session files
* Roland mentions that there is a "Open Session with Sources", which
  may help as well

TOV star:
* Roland reports that Maxwell should be working on them, will poke him

Tickets
=======

* no updates on #963: Improve McLachlan accuracy
* will not make it into the release, #2776: zlib: also use pkg-config
  when searching for installed version
* discussed "#2789: Citation suggestion for Kranc", consensus is that
  2006 paper is most appropriate, but no response from authors yet

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: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.einsteintoolkit.org/pipermail/users/attachments/20240620/77922e83/attachment.sig>

From rhaas at illinois.edu  Mon Jun 24 15:18:01 2024
From: rhaas at illinois.edu (rhaas at illinois.edu)
Date: Mon, 24 Jun 2024 15:18:01 -0500
Subject: [Users] Agenda for Thursday's Meeting
Message-ID: <E1sLq8X-00000001ruS-2AEU@ekohaes8.ncsa.illinois.edu>

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 illinois.edu  Wed Jun 26 17:15:01 2024
From: rhaas at illinois.edu (rhaas at illinois.edu)
Date: Wed, 26 Jun 2024 17:15:01 -0500
Subject: [Users] Einstein Toolkit Meeting Reminder
Message-ID: <E1sMaur-00000005aD4-2Han@ekohaes8.ncsa.illinois.edu>

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 SilvaRL at cardiff.ac.uk  Thu Jun 27 08:01:14 2024
From: SilvaRL at cardiff.ac.uk (Rhiannon Silva)
Date: Thu, 27 Jun 2024 13:01:14 +0000
Subject: [Users] ET on COSMA, Durham
Message-ID: <CWLP265MB6287EEC6B54A486335A5FB35E4D72@CWLP265MB6287.GBRP265.PROD.OUTLOOK.COM>

Hi,

I need to set up Simulation Factory for using the Einstein Toolkit on the COSMA supercomputer at Durham University (UK). I'm wondering if anyone has used ET on COSMA before and, if so, if I could use their simfactory mdb files, please.

Thanks,
Rhiannon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.einsteintoolkit.org/pipermail/users/attachments/20240627/48b46d3b/attachment.htm>

From rhaas at illinois.edu  Thu Jun 27 09:33:08 2024
From: rhaas at illinois.edu (Roland Haas)
Date: Thu, 27 Jun 2024 09:33:08 -0500
Subject: [Users] ET on COSMA, Durham
In-Reply-To: <CWLP265MB6287EEC6B54A486335A5FB35E4D72@CWLP265MB6287.GBRP265.PROD.OUTLOOK.COM>
References: <CWLP265MB6287EEC6B54A486335A5FB35E4D72@CWLP265MB6287.GBRP265.PROD.OUTLOOK.COM>
Message-ID: <20240627093308.373e69df@ekohaes8.ncsa.illinois.edu>

Hello Rhiannon,

> I need to set up Simulation Factory for using the Einstein Toolkit on
> the COSMA supercomputer at Durham University (UK). I'm wondering if
> anyone has used ET on COSMA before and, if so, if I could use their
> simfactory mdb files, please.

We discussed this in today's ET call, but no one ran on COSMA

There is however a ET "Seminar" that may be useful for you since it
shows how to set up a new machine in simfactory:

https://www.einsteintoolkit.org/seminars/2022_02_24/index.html

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: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.einsteintoolkit.org/pipermail/users/attachments/20240627/86923601/attachment.sig>

From rhaas at illinois.edu  Thu Jun 27 09:34:37 2024
From: rhaas at illinois.edu (Roland Haas)
Date: Thu, 27 Jun 2024 09:34:37 -0500
Subject: [Users] meeting minutes for 2024-06-27
Message-ID: <20240627093437.0629cf1a@ekohaes8.ncsa.illinois.edu>

Present: Steve, Roland, Johnny, Keith, Lucas, Peter

ET Release
==========

* Baikal does not regenerate identical code, generated code fails at
  least one test

* will release with not-regenerated code in order to meet AMS meeting
  deadline

* release is anticipated Friday June 27


Gallery run
===========

* BBH: Deborah will run
* BNS: Dhruv has run, will update website
* Poisson: Steve has run
* Scalar wave: Lucas has run, has provided more details in gallery to
  make it easier to reproduce
* TOV: Maxwell has run, is working on plots

Steve added Lucas to release team

List of machines
================

* Johnny will run on Frontera
* Roland will run delta, expanse, golub
* Maxwell has set up Anvil but not tested yet
* Peter ran Sunrise
* Steve will run LSU machines

Release announcement draft
==========================

Available at 

https://einsteintoolkit.org/about/releases/ET_2024_05_announcement.md

if need to comment do so ASAP (release may be as early as tomorrow)

Unanswered questions
====================

* ET on COSMA at Durham,
  http://lists.einsteintoolkit.org/pipermail/users/2024-June/009372.html
  Roland will 

No meeting next week (July 4th).

Will meet during EU ET summer school and workshop.

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: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.einsteintoolkit.org/pipermail/users/attachments/20240627/0f3c7680/attachment-0001.sig>

From sbrandt at cct.lsu.edu  Fri Jun 28 21:06:04 2024
From: sbrandt at cct.lsu.edu (sbrandt at cct.lsu.edu)
Date: Fri, 28 Jun 2024 21:06:04 -0500
Subject: [Users] ET_2024_05 "Lev Landau" Einstein Toolkit Release
 Announcement
Message-ID: <mailman.0.1719626769.93599.users@einsteintoolkit.org>

Release Announcement

Click here to read the announcement in HTML (with hyperlinks):
https://einsteintoolkit.org/about/releases/ET_2024_05_announcement.html

We are pleased to announce the twenty-eighth release (code name "Lev
Landau") of the Einstein Toolkit, an open-source, community-developed
software infrastructure for relativistic astrophysics. The major changes
in this release include:

One new thorn has been added:

 * NewRadX -- This thorn provides radiative outer boundaries for the
   CarpetX driver.

Updated thorns:

 * GRHayL-based IllinoisGRMHD -- this release introduces entropy
   evolution, tabulated equation of state, and piecewise polytrope
   support
 * Baikal(Vacuum) -- updated to use the new version of the Python
   code generator NRPy 2.0
 * GRHayLHD(X) -- now has a tabulated EOS
 * Kuibit -- now supports reading the OpenPMD files generated by
   CarpetX

In addition, bug fixes accumulated since the previous release in Nov
2023 have been included. Including ticket number 2647, correction to the
WENO coefficients.

The Einstein Toolkit is a collection of software components and tools
for simulating and analyzing general relativistic astrophysical systems.
It builds on numerous software efforts in the numerical relativity
community, including codes to compute initial data parameters, the
spacetime evolution codes Baikal, lean_public, and McLachlan, analysis
codes to compute horizon characteristics and gravitational waves, the
Carpet AMR infrastructure, and the relativistic (magneto)hydrodynamics
codes GRHayLHD, GRHayLHDX, GRHydro, and IllinoisGRMHD. Data analysis and
post-processing are handled by the kuibit library. The Einstein Toolkit
also contains a 1D self-force code. For parts of the toolkit, the Cactus
Framework is used as the underlying computational infrastructure,
providing large-scale parallelization, general computational components,
and a model for collaborative, portable code development.

The Einstein Toolkit uses a distributed software model. Its different
modules are developed, distributed, and supported either by the core
team of Einstein Toolkit Maintainers or by individual groups. Where
modules are provided by external groups, the Einstein Toolkit
Maintainers ensure quality control for modules included in the toolkit
and help coordinate support. The Einstein Toolkit Maintainers currently
involve staff and faculty from five different institutions and host
weekly meetings that are open to anyone.

Guiding principles for the design and implementation of the toolkit
include: open, community-driven software development; well thought-out
and stable interfaces; separation of physics software from computational
science infrastructure; provision of complete working production code;
training and education for a new generation of researchers.

For more information about using or contributing to the Einstein
Toolkit, or to join the Einstein Toolkit Consortium, please visit our
web pages at http://einsteintoolkit.org, or contact the users mailing
list users at einsteintoolkit.org.

The Einstein Toolkit is primarily supported by NSF
2004157/2004044/2004311/2004879/2003893/2114582/2227105 (Enabling
fundamental research in the era of multi-messenger astrophysics).

The Einstein Toolkit contains about 400 regression test cases. On a
large portion of the tested machines, almost all of these tests pass,
using both MPI and OpenMP parallelization.

Deprecated functionality
 * Convert_to_HydroBase and ID_converter_ILGRMHD are deprecated, as
   their functionality has been incorporated into IllinoisGRMHD
 * Many IllinoisGRMHD parameters are deprecated, as they are now
   controlled by GRHayLib

Contributors

Among the many contributors to the Einstein Toolkit and to this release
in particular, important contributions to new and existing components
were made by the following authors:

 * Alexandru Dima
 * Cheng-Hsin Cheng
 * Erik Schnetter
 * Gabriele Bozzola
 * Hayley Macpherson
 * Helvi Witek
 * Jake Doherty
 * Jay Kalinani
 * Krishiv Bhatia
 * Leonardo Werneck
 * Liwei Ji
 * Lucas Timotheo Sanches
 * Michail Chabanov
 * Roland Haas
 * Samuel Cupp
 * Samuel Tootle
 * Steven R. Brandt
 * Swapnil Shankar
 * Wolfgang Tichy
 * Zach Etienne

How to upgrade from Meitner Release (ET_2023_11)

To upgrade from the previous release, use GetComponents with the new
thornlist to check out the new version.

See the Download page (http://einsteintoolkit.org/download.html) on the
Einstein Toolkit website for download instructions.

The SelfForce-1D code uses a single git repository; thus, using

git pull; git checkout ET_2024_05

will update the code.

To install Kuibit, do the following:

pip install --user -U kuibit==1.5.0

Machine notes

Supported (tested) machines include:

 * Debian, Ubuntu, Fedora, Mint, OpenSUSE, and macOS installations
   with dependencies installed as prescribed in the official
   installation instructions
 * Anvil
 * Deep Bayou
 * Supermike
 * Queen Bee 3 and 4
 * Delta
 * Expanse
 * Frontera
 * Sunrise

Note for individual machines:

 * TACC machines: defs.local.ini needs to have `sourcebasedir =
   $WORK` and `basedir = $SCRATCH/simulations` configured for this
   machine. You need to determine $WORK and $SCRATCH by logging in to
   the machine.

All repositories participating in this release carry a branch ET_2024_05
marking this release. These release branches will be updated if severe
errors are found.

The "Lev Landau" Release Team on behalf of the Einstein Toolkit
Consortium (2024-06-28)

 * Steven R. Brandt
 * Roland Haas
 * Peter Diener
 * Lorenzo Ennoggi
 * Deborah Ferguson
 * Liwei Ji
 * Jay Kalinani
 * Lucas Timotheo Sanches
 * Bing-Jyun Tsao
 * Maxwell Rizzo
 * Dhruv Srivastava
 * Terrence Pierre Jacques

June 28, 2024