#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-…
#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…
#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…
#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…
#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-…
#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-…
#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…