#2549: inlcude FLRWSolver in ET
Reporter: Roland Haas
Status: new
Milestone:
Version: development version
Type: enhancement
Priority: major
Component:
Comment (by Roland Haas):
A thornlist stanza to check out FLRWSolver can look like this:
```
# FLRWSolver
# strange path is due to repo name
!TARGET = $ARR
!TYPE = git
!URL = https://github.com/hayleyjm/FLRWSolver_public.git
!NAME = FLRWSolver
!REPO_PATH= ../$2
!CHECKOUT =
EinsteinInitialData/FLRWSolver
```
where I mimic the naming convention \(up to capitialization\) suggested in README.Compilation to name the checkout FLRWSolver rather than FLRWSolver\_public \(this also makes the stanza using a bit less strange REPO\_PATH\).
Currently \(without running bulder.py\) fails to compile so is not “harmless” to include in master \(since it prevents the thornlist from compiling\).
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2549/inlcude-flrwsolve…
#2487: *_evolution_method = "LeanBSSNMoL" in Lean does nothing
Reporter: Gabriele Bozzola
Status: open
Milestone:
Version: development version
Type: bug
Priority: major
Component: EinsteinToolkit thorn
Comment (by Roland Haas):
You will have to consider what will happen to existing parfiles that may not have set the admbase parameters. These would fail \(or at least behave differently\) and ideally we want to reduce the cases where the same parfile produces different physics when run with different ET versions. Not checking the gauge evoluion method was a bug so in principle all “correct” parfiles that did set the gauge parameter to “lean” should continue to work fine. You may want to check what eg your example parfile did do.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2487/_evolution_method…
#2487: *_evolution_method = "LeanBSSNMoL" in Lean does nothing
Reporter: Gabriele Bozzola
Status: open
Milestone:
Version: development version
Type: bug
Priority: major
Component: EinsteinToolkit thorn
Comment (by Miguel Zilhão):
Unless anyone objects, I’d be happy to merge this with `master`.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2487/_evolution_method…
#2487: *_evolution_method = "LeanBSSNMoL" in Lean does nothing
Reporter: Gabriele Bozzola
Status: open
Milestone:
Version: development version
Type: bug
Priority: major
Component: EinsteinToolkit thorn
Comment (by Gabriele Bozzola):
These changes were merged into the `development` branch. Will they be moved to `master` for the upcoming release?
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2487/_evolution_method…
#2559: HDF5: disable building test executables and running tests
Reporter: Roland Haas
Status: resolved
Milestone:
Version: development version
Type: enhancement
Priority: minor
Component: EinsteinToolkit thorn
Changes (by Roland Haas):
status: resolved (was open)
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2559/hdf5-disable-buil…
#2566: check for -traditional in FPP's behaviour
Reporter:
Status: new
Milestone:
Version: development version
Type: enhancement
Priority: major
Component:
Cactus passes Fortran code (at least with extensions .F77 .F and .F90) through the C preprocessor in FPP passing FPPFLAGS.
This cpp must use traditional (pre-ANSI) behaviour, ie be string and not token based to preserve whitespace in Fortran fixed format code and handle concatenation using `FOO/**/BAR` correctly.
Getting this wrong by setting eg only FPP in an option list results in strange error messages.
Cactus' configure should check that FPP and FPPFLAGS behave as expected. Eg by processing:
```
TRAD/**/ITIONAL
```
which produces:
```
TRADITIONAL
```
with `--traditional` and
```
TRAD ITIONAL
```
without, so one can `grep` for the expected string.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2566/check-for-traditi…