#2558: incorrect checkout line in thornlist for POWER
Reporter: Roland Haas
Status: open
Milestone:
Version: ET_2021_05
Type: bug
Priority: major
Component: EinsteinToolkit thorn
Comment (by Roland Haas):
Please review
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2558/incorrect-checkou…
#2558: incorrect checkout line in thornlist for POWER
Reporter: Roland Haas
Status: open
Milestone:
Version: ET_2021_05
Type: bug
Priority: major
Component: EinsteinToolkit thorn
Changes (by Roland Haas):
status: open (was new)
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2558/incorrect-checkou…
#2558: incorrect checkout line in thornlist for POWER
Reporter: Roland Haas
Status: new
Milestone:
Version: ET_2021_05
Type: bug
Priority: major
Component: EinsteinToolkit thorn
Both the release \(ET\_2021\_05\) and current development thorn list [einsteintoolkit.th](http://einsteintoolkit.th) contain an incorrect stanza for POWER that results in a broken symbolic link. Bil Gabella kindly reported this first to myself.
Pull request [https://bitbucket.org/einsteintoolkit/manifest/pull-requests/8/fix-checkout… fixes this.
tag: backport
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2558/incorrect-checkou…
#2538: Inclusion of kuibit
Reporter: Gabriele Bozzola
Status: open
Milestone: ET_2021_11
Version: development version
Type: enhancement
Priority: major
Component:
Comment (by Gabriele Bozzola):
How would kuibit be distributed with the Einstein Toolkit? Would users have to install it with pip? Would the repo be included?
It would be nice to distribute the repo because they contain the examples, which, in my opinion, are the fastest way for new users to start visualizing their simulations. On the flip side, installing with `pip kuibit` is the easiest way to obtain a working copy of kuibit.
Also, I wrote a page [\(first steps\)](https://sbozzolo.github.io/kuibit/dev/first_steps.html) to introduce users to kuibit. I don’t know if it is useful or not, so @{557058:d079f9c2-ad27-47b2-bf4b-ecc6bbe288b0} , if you have no prior experience with kuibit, feedback on the on-boarding process would be appreciated!
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2538/inclusion-of-kuib…
#2557: support AMD AOCC compiler
Reporter: Roland Haas
Status: new
Milestone:
Version: development version
Type: enhancement
Priority: minor
Component:
AMD;'s new compiler currently is not supported in the ET since, the known-architecture file aborts if it cannot identify the compiler \(even when CC and CFLAGS etc are all being provided\).
See [http://lists.einsteintoolkit.org/pipermail/users/2021-August/008157.html](h…
AMD’s compiler suite has its own C compiler and Fortran compiler either forked off from the PGI compiler \(old and current version\) or flang \(current and future version\).
Right now it is unclear if it would offer a performance benefit over GNU or Intel compilers.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2557/support-amd-aocc-…
#2549: inlcude FLRWSolver in ET
Reporter: Roland Haas
Status: new
Milestone:
Version: development version
Type: enhancement
Priority: major
Component:
Comment (by Luciano Combi):
I’m a PhD student from Argentina and I’m also interested in using FLRWSolver for future applications. I think it would be very useful if it’s included in the ETK.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2549/inlcude-flrwsolve…
#2551: include RePriMand in the ET
Reporter: Roland Haas
Status: new
Milestone:
Version: development version
Type: enhancement
Priority: major
Component:
Comment (by Roland Haas):
We currently state \([http://einsteintoolkit.org/contribute.html](http://einsteintoolkit.org/contribute.html)\) that
> All components must be distributed under an [open source licence](http://einsteintoolkit.org/software-license.html) so that others can use these components without restrictions \(except as mandated by scientific integrity\), can modify and improve them as necessary, and can pass on these modifications to their collaborators as they see fit.
We suggest GPL compatible and link to the the OSI’s definition page \([https://opensource.org/licenses/category](https://opensource.org/licenses/category)\). I do not think that the issue has come up before. So for not I will take note and bring it with in some initial review for discussion in the ET call \(the questions whether this is problem\). It certainly would be problem if this was intended to be a “Cactus\*” thing since all “Cactus\*” must be LGPL so that explicitly derived object can be distributed without exposing all code. This is for example why AEILocalInterp is in Numerical and not CactusNumerical \(the author explicitly requires it to be GPL and not LGPL\). The ET however does not have that LGPL requirement.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2551/include-reprimand…