Trac

trac@lists.einsteintoolkit.org

8708 discussions

#2572: Build failure in PITTNullCode SphericalHarmonicReconGen
by Wolfgang Kastaun 02 Nov '21

02 Nov '21

#2572: Build failure in PITTNullCode SphericalHarmonicReconGen Reporter: Wolfgang Kastaun Status: open Milestone: Version: ET_2021_05 Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Wolfgang Kastaun): Changing only HDF5\_DIR=BUILD, it build without problem. So it is not a problem connected to the compiler. Maybe the Arch Linux hdf5 package is simply messed up. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2572/build-failure-in-…

1 0

#2572: Build failure in PITTNullCode SphericalHarmonicReconGen
by Roland Haas 01 Nov '21

01 Nov '21

#2572: Build failure in PITTNullCode SphericalHarmonicReconGen Reporter: Wolfgang Kastaun Status: open Milestone: Version: ET_2021_05 Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Hmm, correction, if I build my `hdf5-1.12.0.tar.gz` tarball without options it does default `H5_USE_112_API_DEFAULT` ie the new API is used by default. I get no breakage though. Looking at the source code, the function in question $H5iter$ is declared as: ```c++ herr_t SPH_db_SpEC_H5::H5iter(hid_t loc_id, const char* name, const H5L_info_t* info, void* operator_data) ``` i.e. it takes a `H5L_info_t` and inconsistencies in type would be blamed on HDF5. I cannot make it actually fail though. Even with gcc-11 and a self-compiled HDF5 1.12.0. I tried no options. `-with-default-api-version=v110` and `-with-default-api-version=v18` all let me compile the ET without issue. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2572/build-failure-in-…

1 0

#2573: Cactus treats a directory "configs/FOO/ThornList" as an empty thornlist file
by Roland Haas 01 Nov '21

01 Nov '21

#2573: Cactus treats a directory "configs/FOO/ThornList" as an empty thornlist file Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: minor Component: Cactus Perl lets one open a directory with the regular `open` command but then reports no content in it ie it shows up as an empty file. Eg. ```perl #!/usr/bin/perl use strict; use warnings; open(my $FH, "<", "empty") or die; print "$FH\n"; while(<$FH>) { print $_; } close $FH; ``` will work without error after a `mkdir empty`. The suggested solution seems to be to use Perl’s `-f` operator to check for file type first. Eg something like: ```perl -f "empty" && open(my $FH, "<", "empty") or die; ``` which I verified to fail if empty is a directory or a symbolic link to a directory but works fine for files and symbolic links to files. This actually happened to someone “in the wild”, so it not quite hypothetical. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2573/cactus-treats-a-d…

1 0

#1472: simfactory:dsitribute key envsetup should be optional
by Roland Haas 01 Nov '21

01 Nov '21

#1472: simfactory:dsitribute key envsetup should be optional Reporter: Frank Löffler Status: closed Milestone: Version: development version Type: bug Priority: minor Component: SimFactory Changes (by Roland Haas): status: closed (was new) When trying distribute from my workstation I get: $ ~/utils/simfactory/bin/distribute --no-benchmark --no-recover --thornlist ./thornlists/ET_2013_11.th mike ... $ tail log/mike.out Info: Executing command for remote machine: mike Error: machine spine is missing a required key: envsetup Aborting Simfactory. My workstation doesn't need a envsetup key, nor should it matter here as I am already on that machine. **Keyword:** -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1472/simfactory-dsitri…

1 0

#1472: simfactory:dsitribute key envsetup should be optional
by Roland Haas 01 Nov '21

01 Nov '21

#1472: simfactory:dsitribute key envsetup should be optional Reporter: Frank Löffler Status: new Milestone: Version: development version Type: bug Priority: minor Component: SimFactory Comment (by Roland Haas): envsetup is not specific to the distribute helper script. As of right now the key is not required for simfactory, ie a machine db entry without it works fine. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1472/simfactory-dsitri…

1 0

#2572: Build failure in PITTNullCode SphericalHarmonicReconGen
by Roland Haas 01 Nov '21

01 Nov '21

#2572: Build failure in PITTNullCode SphericalHarmonicReconGen Reporter: Wolfgang Kastaun Status: open Milestone: Version: ET_2021_05 Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Interesting. Ok. The Silo one is an actual bug in HDF5 since it’s symbols are not internally consistent. This one here may be different though even so the newsletter “\[…\]that includes deprecated symbols $the default$\[…\]” to me would read as if the default settings should be a backwards compatible API $which of course Arch Linux may change if they want to be on the bleading edge$. I will give this a try on my workstation with a self-compiled HDF5 1.12. Semantic versioning by HDF5 would be great so that API change → major version change. But then, with the Linux kernel now also updating major version numbers when the devs run out of fingers and toes to count, this is probably a futile hope… -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2572/build-failure-in-…

1 0

#2572: Build failure in PITTNullCode SphericalHarmonicReconGen
by Wolfgang Kastaun 01 Nov '21

01 Nov '21

#2572: Build failure in PITTNullCode SphericalHarmonicReconGen Reporter: Wolfgang Kastaun Status: open Milestone: Version: ET_2021_05 Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Wolfgang Kastaun): I confirm that the problem is HDF5 version 1.12.0. I was not using the bundled ET HDF5 but the one installed on the OS $Arch Linux$. On the HDF groups website this version is announced as major release that breaks backwards compatibility. Adding the suggested CPPFLAGS did not solve the problem $the rest of the optionlist is identical to ET’s generic.cfg$. I note that the flags suggested on the HDF webpage [https://www.hdfgroup.org/2020/03/release-of-hdf5-1-12-0-newsletter-172/](ht… are different from the ones suggested above, but I did not try those yet. ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2572/build-failure-in-…

1 0

#2551: include RePriMand in the ET
by Wolfgang Kastaun 01 Nov '21

01 Nov '21

#2551: include RePriMand in the ET Reporter: Roland Haas Status: open Milestone: ET_2021_11 Version: development version Type: enhancement Priority: major Component: Comment (by Wolfgang Kastaun): Sphinx can do Latex. If this can be embedded in other latex documents is a different question. Is the idea to have an offline copy distributed with the ET or also to embed this into the ET latex documentation? If it is just the offline aspect, I’d prefer to embed the html doc which are not that big either. ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2551/include-reprimand…

1 0

#2551: include RePriMand in the ET
by Roland Haas 29 Oct '21

29 Oct '21

#2551: include RePriMand in the ET Reporter: Roland Haas Status: open Milestone: ET_2021_11 Version: development version Type: enhancement Priority: major Component: Comment (by Roland Haas): Is there way to use sphinx to generate TeX documentation that could be included in the ET? This could be a once-per-release step, but I would prefer having offline TeX files rather than always referring to online HTML files if possible.. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2551/include-reprimand…

1 0

#2551: include RePriMand in the ET
by Roland Haas 29 Oct '21

29 Oct '21

#2551: include RePriMand in the ET Reporter: Roland Haas Status: open Milestone: ET_2021_11 Version: development version Type: enhancement Priority: major Component: Comment (by Roland Haas): One unrelated issue to mention: since git uses a delta compression between revisions in the repo, you likely will $eventually$ have a smaller repository by storing an uncompressed tarball $just `*.tar`$ rather than a compressed tarball $`*.tar.gz`$ in the repo $since git can run a useful diff even on the tar file, but no on a compressed file since compression makes the whole file change if a single byte a the beginning of the tarfile changes$. This is not much of an issue for the ET since it can $and will$ use svn checkout to get _just_ the ET\_interface thorn and _only_ the trunk copy $and not the full version history git would do$. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2551/include-reprimand…

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac