Trac

trac@lists.einsteintoolkit.org

8708 discussions

#2685: credentials are not taken from ORCID
by Anonymous 18 Jan '23

18 Jan '23

#2685: credentials are not taken from ORCID Reporter: Status: new Milestone: Version: Type: bug Priority: major Component: I have tried creating new account using ORCID, as my institute (VECC, India) is not listed. But the email id and other information are not being taken in the request account form. Therefore, I am getting 'try again' message again and again. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2685/credentials-are-n…

1 0

#2684: The tarball with the results of static_tov is full of macOS-specific files
by Gabriele Bozzola 18 Jan '23

18 Jan '23

#2684: The tarball with the results of static_tov is full of macOS-specific files Reporter: Gabriele Bozzola Status: new Milestone: Version: Type: bug Priority: trivial Component: EinsteinToolkit website I downloaded `tov_20221026.tar.gz` from the TOV gallery and found that it contains a lot of `._XXXXXX` files, such as `._ml_bssn-ml_mom.minimum.asc`. According to `file`, these are `AppleDouble encoded Macintosh file`, which contribute nothing useful. I think it would be a good idea to remove them. I think that I cleaned the archive in the attached tarball. ‌ attachment: tov_20221026_clean.tar.gz (https://api.bitbucket.org/2.0/repositories/einsteintoolkit/tickets/issues/2…) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2684/the-tarball-with-…

1 0

#177: EXC_BAD_ACCESS in CarpetIOASCII
by Roland Haas 17 Jan '23

17 Jan '23

#177: EXC_BAD_ACCESS in CarpetIOASCII Reporter: Ian Hinder Status: closed Milestone: Version: Type: bug Priority: minor Component: Carpet Changes (by Roland Haas): status: closed (was resolved) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/177/exc_bad_access-in-…

1 0

#177: EXC_BAD_ACCESS in CarpetIOASCII
by Roland Haas 17 Jan '23

17 Jan '23

#177: EXC_BAD_ACCESS in CarpetIOASCII Reporter: Ian Hinder Status: resolved Milestone: Version: Type: bug Priority: minor Component: Carpet Changes (by Roland Haas): status: resolved (was closed) Comment (by Roland Haas): I assume. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/177/exc_bad_access-in-…

1 0

#177: EXC_BAD_ACCESS in CarpetIOASCII
by Roland Haas 17 Jan '23

17 Jan '23

#177: EXC_BAD_ACCESS in CarpetIOASCII Reporter: Ian Hinder Status: closed Milestone: Version: Type: bug Priority: minor Component: Carpet Comment (by Roland Haas): My guess would be that this is related to git hash [eb2c2b94](https://bitbucket.org/eschnett/carpet/commits/eb2c2b94649ce3217bb… "CarpetIOASCII: adapt to gdata::copy\_from being static" of \[carpet\]$[https://bitbucket.org/eschnett/carpet](https://bitbucket.org/eschnett/carpet) and git hash [6537e215](https://bitbucket.org/eschnett/carpet/commits/6537e215dbebd17b72b… "CarpetLib: make gdata transfer functions static functions" of [carpet](https://bitbucket.org/eschnett/carpet). Before those Carpet/CarpetLib would use a NULL pointer to call \(non-virtual$ member functions that it “knew” would not actually access member variables due to arguments in the call. This was never quite legal $`this` must not be NULL and must always \(even in the constructor$ point to a valid region of memory\). Essentially the compiler is free to optimize things like: ```c++ foo::bar(int a) { if(a) return 0; int b = this->c; return ; } ``` to ```c++ foo::bar(int a) { int b = this->c; if(a) return 0; return ; } ``` since the standard guarantees that `this` is valid. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/177/exc_bad_access-in-…

1 0

#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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac