Trac June 2023

trac@lists.einsteintoolkit.org

1 participants
81 discussions

#2737: define CCTK_DEVICE and CCTK_HOST in Cactus
by Roland Haas 07 Jun '23

07 Jun '23

#2737: define CCTK_DEVICE and CCTK_HOST in Cactus Reporter: Roland Haas Status: new Milestone: Version: Type: enhancement Priority: minor Component: Cactus Comment (by Roland Haas): Alternatively one may also look for `__HCC__` and `__CUDACC__` according to [https://sep5.readthedocs.io/en/latest/Programming\_Guides/HIP-porting-guide… -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2737/define-cctk_devic…

1 0

#2737: define CCTK_DEVICE and CCTK_HOST in Cactus
by Roland Haas 07 Jun '23

07 Jun '23

#2737: define CCTK_DEVICE and CCTK_HOST in Cactus Reporter: Roland Haas Status: new Milestone: Version: Type: enhancement Priority: minor Component: Cactus Cactus supports CUDA programming in the option lists level via various `CUDA_FOO` variables but does not provide macros for `__device__` and `__host__` modifiers used by both CUDA and HIP accelerators. It would be good if Cactus could provide those depending on which compiler is detected, Predefined defines to look for are \(copying AMReX\): `CUDA_ARCH || HIP_DEVICE_COMPILE || SYCL_DEVICE_ONLY` \(in its `include/AMReX_GpuQualifiers.H`\). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2737/define-cctk_devic…

1 0

#2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no"
by Vikram Manikantan 06 Jun '23

06 Jun '23

#2497: IllinoisGRMHD is incompatible with setting TmunuBase::stress_energy_at_RHS = "no" Reporter: Gabriele Bozzola Status: open Milestone: Version: development version Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Vikram Manikantan): Hi Leonardo, In your suggested modification above, do you mean to replace the current lines that have ‘SetTmunu’ or just append this IF statement to the end of the file? See below for existing code in schedule.ccl. ``` schedule IllinoisGRMHD_conserv_to_prims in SetTmunu after (compute_B_and_Bstagger_from_A, TmunuBase_ZeroTmunu) { LANG: C } "Compute primitive variables from conservatives. This is non-trivial, requiring a Newton-Raphson root-finder." schedule IllinoisGRMHD_outer_boundaries_on_P_rho_b_vx_vy_vz in SetTmunu after IllinoisGRMHD_conserv_to_prims { # We must sync {P,rho_b,vx,vy,vz} here. SYNC: grmhd_primitives_allbutBi LANG: C } "Apply outflow-only, flat BCs on {P,rho_b,vx,vy,vz}. Outflow only == velocities pointed inward from outer boundary are set to zero." ``` ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2497/illinoisgrmhd-is-…

1 0

#2736: consider using git+https together with a branch name or kuibit install
by Gabriele Bozzola 02 Jun '23

02 Jun '23

#2736: consider using git+https together with a branch name or kuibit install Reporter: Roland Haas Status: new Milestone: Version: Type: enhancement Priority: trivial Component: Other Comment (by Gabriele Bozzola): In addition, kuibit comes with an internal notion of version \(\`kuibit.\_\_version\_\_\`\), which is used for deprecated features or to check if some features are available. If I don’t change this, `kuibit@ET_2023_05`would still advertise itself as version 1.4.0, which might introduce some confusion. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2736/consider-using-gi…

1 0

#2736: consider using git+https together with a branch name or kuibit install
by Gabriele Bozzola 02 Jun '23

02 Jun '23

#2736: consider using git+https together with a branch name or kuibit install Reporter: Roland Haas Status: new Milestone: Version: Type: enhancement Priority: trivial Component: Other Comment (by Gabriele Bozzola): I can see another drawback to this. When you install kuibit with `pip install kuibit`, you are served the wheels from PyPI. These are very small files \(460 kB\) and are supposed to work immediately on all the supported architectures/versions. When you install kuibit from git, you have to download the entire repo \(along with the tests, some data files, and so on, and the entire git history\), which can be 100s of MBs - 1 GB. Moreover, you have to recompile the package locally. This should not be a problem for 99 % of the cases, but I would not be surprised if there were incompatibilities in some cases. So, as developer, I would prefer sticking with PyPI for the slightly better user experience, but I do not feel strongly about this. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2736/consider-using-gi…

1 0

#2736: consider using git+https together with a branch name or kuibit install
by Roland Haas 02 Jun '23

02 Jun '23

#2736: consider using git+https together with a branch name or kuibit install Reporter: Roland Haas Status: new Milestone: Version: Type: enhancement Priority: trivial Component: Other Each ET release is tied to a specific kuibit version and @{557058:4b0c8315-696b-4d2e-92da-2da5fea9e8d4} allows the ET to create branches and tags in kuibit. Yet to then install kuibit the instruction in the ET use numeric version numbers `1.4.0` or so and thus a code which may not actually match up with the ET branch `ET_YYYY_MM` of any release \(unless special care is taken by the release coordinator to create a release branch of the version \(tag\) that will be used for the release\). It may be interesting to consider instead to use: ```shell pip install git+https://github.com/Sbozzolo/kuibit@ET_2023_05 ``` instead. At least from the point of view of consistent ET versions. The downside of course being that this probably breaks pip’s logic to compare newer versions and may inundate kuibit’s bug tracker with version numbers that are really ET versions and not kuibit version.s -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2736/consider-using-gi…

1 0

#2723: No boundary conditions registered for variables in group LEANBSSNMOL
by Roland Haas 02 Jun '23

02 Jun '23

#2723: No boundary conditions registered for variables in group LEANBSSNMOL Reporter: Vikram Manikantan Status: resolved Milestone: ET_2023_05 Version: ET_2022_11 Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Thank you for the fix. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2723/no-boundary-condi…

1 0

#2723: No boundary conditions registered for variables in group LEANBSSNMOL
by Roland Haas 02 Jun '23

02 Jun '23

#2723: No boundary conditions registered for variables in group LEANBSSNMOL Reporter: Vikram Manikantan Status: resolved Milestone: ET_2023_05 Version: ET_2022_11 Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2723/no-boundary-condi…

1 0

#2723: No boundary conditions registered for variables in group LEANBSSNMOL
by Miguel Zilhão 02 Jun '23

02 Jun '23

#2723: No boundary conditions registered for variables in group LEANBSSNMOL Reporter: Vikram Manikantan Status: new Milestone: ET_2023_05 Version: ET_2022_11 Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Miguel Zilhão): I’ve now merged the master branch with development, so this change should now be present also in master. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2723/no-boundary-condi…

1 0

#2735: EinsteinBase: storage declaration simplification
by Samuel Cupp 01 Jun '23

01 Jun '23

#2735: EinsteinBase: storage declaration simplification Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: trivial Component: EinsteinToolkit thorn Comment (by Samuel Cupp): Right now, the PR removed them in ADMBase. They remain in HydroBase because there are many different variables using the same parameter that one may or may not need in a given run. Essentially, the ‘initial\_Y\_e’ and similar parameters are serving to determine whether these variables are active. However, in ADMBase the only variables with this behavior are `dtshift`, `dtlapse`, and `shift`. There’s definitely no need for shift to do this, as its storage is already controlled by `shift_timelevels`. The only question is whether we need to reintroduce the ``` if (! CCTK_Equals(initial_dtlapse, "none")) { dtlapse[lapse_timelevels] } if (! CCTK_Equals(initial_dtshift, "none")) { dtshift[shift_timelevels] } ``` ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2735/einsteinbase-stor…

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac June 2023