#2692: Inclusion of FUKA importer thorns
Reporter: tootle
Status: new
Milestone: ET_2023_05
Version: ET_2023_05
Type: proposal
Priority: blocker
Component: EinsteinToolkit thorn
Comment (by Roland Haas):
Is it possible to include the \(hopefully small\) parts of Boost needed in the KadathThorn source code?
While I can see that eventually Boost may be included in the ET \(for Kadath, Reprimand, CarpetX\), it is a large amount of code and not always good about backwards compatibility so one can likely end up a situation where different thorns require conflicting Boost versions.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2692/inclusion-of-fuka…
#2692: Inclusion of FUKA importer thorns
Reporter: tootle
Status: new
Milestone: ET_2023_05
Version: ET_2023_05
Type: proposal
Priority: blocker
Component: EinsteinToolkit thorn
Comment (by tootle):
Unfortunately this is not a dependency that can be easily removed so I will have to exclude the importers from the official release. If this changes I will consider inclusion at a later date.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2692/inclusion-of-fuka…
#1946: sim setup should create a section for the current machine
Reporter: Roland Haas
Status: open
Milestone:
Version: development version
Type: enhancement
Priority: minor
Component: SimFactory
Comment (by Roland Haas):
It’s a failed attempt at a fix. I may be adaptable though I am not really sure. The problem is that, as written, it also sets `basedir` which should not be done. The pull request would have duplicated the created `default` section as a section for the current machine, which is too much. Basically there are only some options that one wants to overwrite \(one must overwrite since the options exist in the machine entry, obvious for `basedir` but also, annoyingly, for things like `allocation` which is set to `NO_ALLOCATION` for most machines that do require an allocation\).
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1946/sim-setup-should-…
#1881: Unclear error message for parameter file error
Reporter: Erik Schnetter
Status: open
Milestone:
Version: development version
Type: bug
Priority: minor
Component: Cactus
Comment (by Roland Haas):
The error message is still not optimal since it eg points to the wrong line \(though at least it now shows the incorrect line\). Since the parfile attachment seems to have vanished I tried with a simpler reproducer:
```perl
Cactus::cctk_itlast = 10
# this line is wrong
Cactus::cctk_full_warnings
# this line is ok
Cactus::cctk_run_title = "lineno test"
```
which fails with:
```text
Activating thorn Cactus...Success -> active implementation Cactus
WARNING level 0 from host ekohaes8 process 0
in thorn cactus, file lineno.par:7:
-> ERROR IN PARAMETER FILE:Parse Error
Expected one of the following characters: '[', '='
Cactus::cctk_full_warnings
# this line is ok
Cactus::cctk_run_title = "lineno test"
^
WARNING level 0 from host ekohaes8 process 0
in thorn cactus, file lineno.par:7:
-> ERROR IN PARAMETER FILE:Parse Error
Expected one of the following characters: '[', '='
Cactus::cctk_full_warnings
# this line is ok
Cactus::cctk_run_title = "lineno test"
^
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD
with errorcode 1.
```
maybe instead of pointing to the first wrong character, point to the last good one \(not counting whitespace and comments\) would be better in this case? Though it obviously comes with its own issues such as this file:
```
Cactus::cctk_itlast = 12
# now an incorrect line
::this_does_not_work = 42
```
which should point out that `:` is wrong, since the line above could be parsed correctly. Ie the error message would be state dependent \(and will almost certainly violate a nice layered approach to the parser\).
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1881/unclear-error-mes…