Trac January 2023

trac@lists.einsteintoolkit.org

1 participants
91 discussions

#2672: obtain DNS enty to point https://tests.einsteintoolkit.org to https://einsteintoolkit.github.io/tests
by Roland Haas 13 Jan '23

13 Jan '23

#2672: obtain DNS enty to point https://tests.einsteintoolkit.org to https://einsteintoolkit.github.io/tests Reporter: Roland Haas Status: new Milestone: Version: Type: enhancement Priority: minor Component: EinsteinToolkit website Comment (by Roland Haas): Note that reading [https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-githu… one actually needs a CNAME entry that points [tests.einsteintoolkit.org](http://tests.einsteintoolkit.org) to [einsteintoolkit.github.io](http://einsteintoolkit.github.io) $and then GtiHub settings to link things to the repo in question$. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2672/obtain-dns-enty-t…

1 0

#2679: How to link an externally compiled library during ET compilation
by Maria Mutz 12 Jan '23

12 Jan '23

#2679: How to link an externally compiled library during ET compilation Reporter: Maria Mutz Status: open Milestone: Version: Type: bug Priority: minor Component: Comment (by Maria Mutz): There’s just a make.code.defn file in src, and the whole thing is: ``` # Main make.code.defn file for thorn Cocalthorn # Source files in this directory SRCS = coc2pri_mrs.f90 # Subdirectories containing source files SUBDIRS = ``` ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2679/how-to-link-an-ex…

1 0

#2679: How to link an externally compiled library during ET compilation
by Roland Haas 12 Jan '23

12 Jan '23

#2679: How to link an externally compiled library during ET compilation Reporter: Maria Mutz Status: open Milestone: Version: Type: bug Priority: minor Component: Comment (by Roland Haas): Thank you. Ok so the line that triggers the error is the last executed one: ``` gcc -L/cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen2/gcc-10.2.0/numactl-2.0.12-brsvuiqgwwnn2otgnu3pyemvgp6dal2n/lib/ -lm -lgfortran -L/home/mmutz/Cactus/arrangements/MRNS/Cocalthorn/src/Cocal_MRNS/Main_utility/ -lcocalmrns include_modulefiles_MRNS.f90.o -o include_modulefiles_MRNS.f90 ``` which indeed is full compile and link $no `-c` flag$. This line should not be there, in particular since the lines above: ``` 1673483420.23084 Compiling /home/mmutz/Cactus/arrangements/MRNS/Cocalthorn/src/include_modulefiles_MRNS.f90 current_wd=`pwd` ; cd /home/mmutz/Cactus/configs/sim18/scratch ; gfortran -m128bit-long-double -fcray-pointer -ffixed-line-length-none -fno-range-check -march=znver2 -fomit-frame-pointer -lgfortran -I/home/mmutz/Cactus/arrangements/MRNS/Cocalthorn/src/Cocal_MRNS/Include_file/ -O2 -mavx2 -mfma -fopenmp -I"/home/mmutz/Cactus/arrangements/MRNS/Cocalthorn/src" -I"/home/mmutz/Cactus/configs/sim18/config-data" -I"/home/mmutz/Cactus/configs/sim18/bindings/include" -I"/home/mmutz/Cactus/src/include" -I"/home/mmutz/Cactus/arrangements" -I"/home/mmutz/Cactus/configs/sim18/bindings/Configuration/Thorns" -I"/home/mmutz/Cactus/configs/sim18/bindings/include/Cocalthorn" -I"/home/mmutz/Cactus/arrangements/MRNS/Cocalthorn/src" -I"/home/mmutz/Cactus/configs/sim18/bindings/include/Cocalthorn" -c -o $current_wd/include_modulefiles_MRNS.f90.o $current_wd/include_modulefiles_MRNS.f90 1673483422.67902 Postprocessing /home/mmutz/Cactus/arrangements/MRNS/Cocalthorn/src/include_modulefiles_MRNS.f90 ``` already compiled that same file to an object file $note the `-c` option in the long `gfortran` line$. The only reason I could think of why this may happen is that there are rogue Makefile recipes present. In your case could you attach any and all files that have names like “Makefile”, “make.code.defn”, “make.code.deps”, “make.configuration.defn”, “make.configuration.deps” in the source code directory `/home/mmutz/Cactus/arrangements/MRNS/Cocalthorn/src/` that may help. My guess would be that there is somthing that COCAL added. Namely the link line uses `gcc` but Cactus would use `g++` to link. Also the error producing file is very wrong in itself already, since it uses `include_modulefiles_MRNS.f90` as the _output_ that is writes to it $writes the linked executable there if it succeeded$. The normal direction would be for `include_modulefiles_MRNS.f90` to be the _input_ and `include_modulefiles_MRNS.f90.o` $the object file$ be the output. That is what is in the “Compiling” line above. Unfortunately I am mostly guessing here, sorry. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2679/how-to-link-an-ex…

1 0

#2679: How to link an externally compiled library during ET compilation
by Maria Mutz 11 Jan '23

11 Jan '23

1 0

#2683: Slab fails to compile without MPI
by Roland Haas 11 Jan '23

11 Jan '23

#2683: Slab fails to compile without MPI Reporter: Roland Haas Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Roland Haas): status: open (was new) Comment (by Roland Haas): Please review. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2683/slab-fails-to-com…

1 0

#2683: Slab fails to compile without MPI
by Roland Haas 11 Jan '23

11 Jan '23

#2683: Slab fails to compile without MPI Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Slab only optionally depends on MPI and the Kranc tutorial [http://kranccode.org/tutorial.html](http://kranccode.org/tutorial.html) does use it without MPI $or Carpet for that matter$. In 9ea25cd9 this ability was lost due to `MPI_Alltoallv` being limited to `int` variables for offsets and sizes thus not usable with the 64 bit code anymore. Pull request [https://bitbucket.org/cactuscode/cactusnumerical/pull-requests/19/slab-supp… restores functionality to run without MPI and makes the Kranc tutorial work once more. It is not really nice since it fudges the function prototype of the `MPI_Alltoallv` dummy function used in Slab. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2683/slab-fails-to-com…

1 0

#2679: How to link an externally compiled library during ET compilation
by Roland Haas 11 Jan '23

11 Jan '23

#2679: How to link an externally compiled library during ET compilation Reporter: Maria Mutz Status: open Milestone: Version: Type: bug Priority: minor Component: Comment (by Roland Haas): Thank you. Indeed, `VERBOSE=1`, as shown on the webiste, does not work. The correct values is `VERBOSE=yes`. I have just corrected the website. If you could re-run with `VERBOSE=yes` and send the produced `make.log` file, that would be great. Sorry about the incorrect information on the website. Your `env.log` looks fine to me, so still no idea what is going on. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2679/how-to-link-an-ex…

1 0

#2679: How to link an externally compiled library during ET compilation
by Maria Mutz 11 Jan '23

11 Jan '23

1 0

#2679: How to link an externally compiled library during ET compilation
by Maria Mutz 11 Jan '23

11 Jan '23

#2679: How to link an externally compiled library during ET compilation Reporter: Maria Mutz Status: open Milestone: Version: Type: bug Priority: minor Component: Comment (by Maria Mutz): I did use VERBOSE=1 and -j1. The whole command was: ``` VERBOSE=1 simfactory/bin/sim build sim18 --thornlist ./thornlists/cocal_mrns.th --optionlist ./simfactory/mdb/optionlists/expanse-gnu.cfg -j1 2>&1 | tee make.log ``` ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2679/how-to-link-an-ex…

1 0

#2679: How to link an externally compiled library during ET compilation
by Roland Haas 11 Jan '23

11 Jan '23

#2679: How to link an externally compiled library during ET compilation Reporter: Maria Mutz Status: open Milestone: Version: Type: bug Priority: minor Component: Comment (by Roland Haas): Hello Maria, I had a look at make.log.pdf $a text file is sufficient, there is no need to convert to PDF$. Unfortunately, I am still not sure what is going on. The error message is produced by the linker $ld$ but the compilation does not yet have reached the final linking stage and seems to be just compiling `include_modulesfiles_MRNS.f90` which should only compile and not attempt to link. There may be “confusing” files present in the src directory $or your environment may contain strange variables$ is my best guess. Is the file that produces the error $`include_modulesfiles_MRNS.f90`$ the first Fortran 90 file ever compiled? Could you please use the command ``` VERBOSE=1 simfactory/bin/sim build -j1 2>&1 | tee make.log ``` indicated on [http://einsteintoolkit.org/support.html#general-guidelines-for-questions](h… to ensure that make outputs the actual commands it executes $this is what `VERBOSE=yes` does$ and compilation happens serially $`-j1`$ so that one is sure what command produces the error? Also if you could run `env >env.log` and attach the file `env.log` this may help. Ideally also if possible, could you inlcude the source file `MRNS/Cocalthorn/src/include_modulefiles_MRNS.f90` $via private mail to [rhaas@illinois.edu](mailto:rhaas@illinois.edu) if needed$? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2679/how-to-link-an-ex…

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac January 2023