#2553: Cactus' link command uses CPPFLAGS and CXXFLAGS
Reporter: Roland Haas
Status: open
Milestone:
Version: development version
Type: bug
Priority: minor
Component: Cactus
Comment (by Steven R. Brandt):
For the upcoming release, we need to compile with nvcc. This leads to errors in ctthorns because Kranc detects cuda and starts putting the device tag on its functions. This leads to compiler failures for ctthorns. If we didn’t have to set CXX globally to nvcc, this problem should go away.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2553/cactus-link-comma…
#2747: Inclusion of sgrid importer in Einstein Toolkit
Reporter: Samuel Cupp
Status: new
Milestone: ET_2023_11
Version:
Type: enhancement
Priority: major
Component: EinsteinToolkit thorn
Comment (by Roland Haas):
GetComponents supports some very limited replacement variables in the `URL`, `AUTH_URL` and `REPO_PATH` variables, namely it will take the `<ARRANGEMENT>/<THORN>` entry of each thorn and will assign `<ARRANGEMENT>` to `$1` \(ie the first thingy\) and `$2` will be set to `<THORN>` \(ie the second component\). More or less like Perl with do when one used a pattern `m!([^/]*)/(.*)!`.
There is _also_ some magic in how `REPO_PATH` behaves depending on whether it does or does not contain a `$1` or `$2`.
If it does contain a `$1` or `$2` then the relative path inside of the repository will be exactly as given by `REPO_PATH` \(after variable expansion\). If on the other hand no `$1` or `$2` is found, then the relative path in the repo is `<REPOS_PATH>/<ARRANGEMENT>/<THORN>`.
What needs to go into `REPO_PATH` thus hugely depends on the git repository layout. `$2` often works nicely because people tend to put all thorns into the root of the git repo. `..` is somewhat unusual.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2747/inclusion-of-sgri…
#2747: Inclusion of sgrid importer in Einstein Toolkit
Reporter: Samuel Cupp
Status: new
Milestone: ET_2023_11
Version:
Type: enhancement
Priority: major
Component: EinsteinToolkit thorn
Comment (by Michal Pirog):
First: I hope it's all we need to add, and I'll be more than happy if you do it. Thanks!
Second: It's Wolfgang's repo, so I think we should ask him. I'm writing an email to him right now.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2747/inclusion-of-sgri…
#2746: Make Seed_Magnetic_Fields independent of IllinoisGRMHD
Reporter: Samuel Cupp
Status: new
Milestone: ET_2023_11
Version:
Type: enhancement
Priority: major
Component: EinsteinToolkit thorn
Comment (by Samuel Cupp):
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2746/make-seed_magneti…
#2746: Make Seed_Magnetic_Fields independent of IllinoisGRMHD
Reporter: Samuel Cupp
Status: new
Milestone: ET_2023_11
Version:
Type: enhancement
Priority: major
Component: EinsteinToolkit thorn
Comment (by Samuel Cupp):
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2746/make-seed_magneti…
#2747: Inclusion of sgrid importer in Einstein Toolkit
Reporter: Samuel Cupp
Status: new
Milestone: ET_2023_11
Version:
Type: enhancement
Priority: major
Component: EinsteinToolkit thorn
Comment (by Samuel Cupp):
This means adding the thorns to the `einsteintoolkit.th` in the master branch of the manifest \([link](https://bitbucket.org/einsteintoolkit/manifest/src/master/einsteintoolkit.th)\). As long as the thorns are in a publicly accessible repo, it should be fine. Note that we usually make branches and tags for every single release on these repositories \(see, for example, the plethora of `ET_YYYY_MM` branches in [wvuthorns](https://bitbucket.org/zach_etienne/wvuthorns/src/master/)\). This either means giving the ET maintainers permission to create branches in the repository \(and possibly letting any future release managers/maintainers have access\) or be willing to create these branches and tags on behalf of the ET. Generally, letting at least a few of the senior maintainers have commit access will help ensure smooth future releases in case people get sick or something at the same time as a release.
So right now, the most important thing is making sure we put in the correct information. Based on what is in the linked git repo, it is
```
!TARGET = $ARR
!TYPE = git
!URL = https://github.com/wofti/CactusSgrid.git
!REPO_PATH = ..
!CHECKOUT =
CactusSgrid/DNSdata
```
If that’s all we need to add, then I can do that today.
@{634afd8853df3c01232121fd} what does the `$2` that most thorns use mean for repo\_path? I ask because I don’t know if the `..` in the above is what GetComponents normally expects or not.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2747/inclusion-of-sgri…
#2747: Inclusion of sgrid importer in Einstein Toolkit
Reporter: Samuel Cupp
Status: new
Milestone: ET_2023_11
Version:
Type: enhancement
Priority: major
Component: EinsteinToolkit thorn
Comment (by Michal Pirog):
I was convinced that there is some specific place where files must be uploaded. Anyway, I'm still confused. There is a deadline today which says:
"2023-09-27 \(-10wk\): all codes proposed for inclusion in master branch \(still under review\) \[dates pushed back for delayed release\]"
What should I/we do to not miss this deadline.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2747/inclusion-of-sgri…
#2747: Inclusion of sgrid importer in Einstein Toolkit
Reporter: Samuel Cupp
Status: new
Milestone: ET_2023_11
Version:
Type: enhancement
Priority: major
Component: EinsteinToolkit thorn
Comment (by Roland Haas):
You don’t have to upload it anywhere, really. All that is needed for it to be “in the Einstien Toolkit” is that there is a correct checkout line of it in the official ET thornlist in the ET “manifest” repository \(since, strictly speaking, this is all the ET is: a collated list of externally developed software\).
_If_ you however would like to have the code hosted somewhere that is not e.g. your pesonal github or Bitbucket account \(eg b/c you may change jobs, or b/c you would need to grant at least some access to the ET release chair / a maintainer\) it can also be moved into an appropriate repository in [https://github.com/einsteintoolkit](https://github.com/einsteintoolkit) e.g. the thorn could go into “EinsteinInitialdata”. Downside: you lose some “branding” since your name no longer appears in the URL, upside you do not have to eg handle access and the ET maintainers will take care of the all steps required for each release.
Examples for “include” are eg the Outflow thorn in EinsteinAnalysis. Examples for “not include” are eg Carpet.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2747/inclusion-of-sgri…
#2747: Inclusion of sgrid importer in Einstein Toolkit
Reporter: Samuel Cupp
Status: new
Milestone: ET_2023_11
Version:
Type: enhancement
Priority: major
Component: EinsteinToolkit thorn
Comment (by Michal Pirog):
Publicly available repo is here:
[https://github.com/wofti/CactusSgrid.git](https://github.com/wofti/CactusSg…
The thorn itself is at the directory "DNSData" \("BNSData" is an old version\)
We are using the thornlist "[dns.th](http://dns.th)" from the directory "useful\_files" as an argument for "GetComponents".
Finally, we compile Cactus with the option list "dns.cfg" from the directory "useful\_files".
PS: "README" is to update. And I need to prepare some .par file for testing. Again: where exactly should I upload this thorn?
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2747/inclusion-of-sgri…