Trac January 2023

trac@lists.einsteintoolkit.org

1 participants
91 discussions

#2691: New features to particle_tracerET
by Roland Haas 31 Jan '23

31 Jan '23

#2691: New features to particle_tracerET Reporter: Leonardo Werneck Status: new Milestone: ET_2023_05 Version: Type: enhancement Priority: major Component: Comment (by Roland Haas): Not having read most of the remainder of the ticket nor looked at the code. it can also be useful to in cases like this, add: ``` CarpetIOASCII::compact_format = yes ``` which removes a lot of the extra whitespace and comments \(but also changes the column mapping so you must not rely on say column 10 being “time” and have to parse the header on top for a column name to column mapping\). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2691/new-features-to-p…

1 0

#2691: New features to particle_tracerET
by Leonardo Werneck 31 Jan '23

31 Jan '23

#2691: New features to particle_tracerET Reporter: Leonardo Werneck Status: new Milestone: ET_2023_05 Version: Type: enhancement Priority: major Component: Comment (by Leonardo Werneck): Gabriele--- Upon further discussion, the functionality you seek is already provided by the thorn, although it is not its default behavior. For example, the following non-standard output configuration: ``` particle_tracerET::output_freq = 4 particle_tracerET::output_format = "ascii" # Default ``` can be made standard by doing ``` particle_tracerET::output_freq = 0 <...> CarpetIOASCII::out1D_every = 128 # Or whatever CarpetIOASCII::out1D_vars = " <...> particle_tracerET::particle_position_arrays{out_every=4} " ``` Note that in the standard output the particle positions would be in the file `particle_traceret-particle_position_arrays.x.asc`, while the non-standard output file is named `particles.asc`. In fact one can enable both outputs at the same time using e.g., ``` particle_tracerET::output_freq = 4 <...> CarpetIOASCII::out1D_every = 128 # Or whatever CarpetIOASCII::out1D_vars = " <...> particle_tracerET::particle_position_arrays{out_every=particle_tracerET::output_freq} " ``` Granted, this is not well documented, so we should add this to the thorn’s documentation. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2691/new-features-to-p…

1 0

#2697: Include BBH+scalar field initial data code from Canuda in ET
by Cheng-Hsin Cheng 31 Jan '23

31 Jan '23

#2697: Include BBH+scalar field initial data code from Canuda in ET Reporter: Cheng-Hsin Cheng Status: new Milestone: Version: Type: enhancement Priority: minor Component: We propose for inclusion the thorns TwoPunctures\_BBHSF and NPScalars\_SF from Canuda/Scalar. The codes are hosted in the UIUC branch: [https://bitbucket.org/canuda/scalar/src/Canuda\_SF\_UIUC/](https://bitbucke… TwoPunctures\_BBHSF is an initial data solver based on TwoPunctures for a black hole binary plus a cloud of massive scalar field. Namely, it solves the Hamiltonian constraint for the BBH system with back-reaction from a massive scalar field minimally-coupled to GR. Currently, it supports scalar field configurations with vanishing initial momentum and a spherically symmetric or dipolar angular profile, centered at the origin. NPScalars\_SF is an extension of the NPScalars thorn that computes the gravito-electric and gravito-magnetic fields taking into account contributions from the massive scalar field. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2697/include-bbh-scala…

1 0

#2691: New features to particle_tracerET
by Leonardo Werneck 31 Jan '23

31 Jan '23

#2691: New features to particle_tracerET Reporter: Leonardo Werneck Status: new Milestone: ET_2023_05 Version: Type: enhancement Priority: major Component: Comment (by Leonardo Werneck): We can add the standard Cactus output as an option as well, but as far as I know the default output will have to remain as is for the sake of backwards compatibility. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2691/new-features-to-p…

1 0

#2691: New features to particle_tracerET
by Gabriele Bozzola 31 Jan '23

31 Jan '23

#2691: New features to particle_tracerET Reporter: Leonardo Werneck Status: new Milestone: ET_2023_05 Version: Type: enhancement Priority: major Component: Comment (by Gabriele Bozzola): \(The thorn name got fixed in the PR, so ignore my first point!\) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2691/new-features-to-p…

1 0

#2691: New features to particle_tracerET
by Gabriele Bozzola 31 Jan '23

31 Jan '23

#2691: New features to particle_tracerET Reporter: Leonardo Werneck Status: new Milestone: ET_2023_05 Version: Type: enhancement Priority: major Component: Comment (by Gabriele Bozzola): ``` CCTK_VWarn (1, __LINE__, __FILE__, CCTK_THORNSTRING, "VolumeIntegrals_GRMHD:file_output_routines.C Problem creating directory '%s' " "for output", actual_dir); ``` The thorn name here is `VolumeIntegrals_GRMHD` which is not the correct one. > The thorn’s output is non-standard because it deals with arrays, not grid functions. Each particles' position is evolved using the thorn’s own RK method. Thus each line of the output file looks like “time x\_1 y\_1 z\_1 x\_2 y\_2 z\_2 …” where the subscript is the particle ID and \(x,y,z\) the particle position. The positions are already grid arrays, why not outputting those with Carpet directly? E.g., one could directly output `particle_tracerET::particle_position_x`as an HDF5 file in CarpetIOHDF5 \(or as an ASCII file in CarpetIOASCII\). \(In that case, it would be nice if the size of the array was not hardcoded in the `interface.ccl`\). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2691/new-features-to-p…

1 0

#2696: Update kuibit to 1.4.0
by Gabriele Bozzola 31 Jan '23

31 Jan '23

#2696: Update kuibit to 1.4.0 Reporter: Gabriele Bozzola Status: new Milestone: ET_2023_05 Version: Type: enhancement Priority: major Component: Comment (by Gabriele Bozzola): In that case, kuibit 1.3.6 will still work. Unfortunately, it is pretty much impossible to support at the same time Python 3.7 and Python 3.11 if I want to ensure that all the dependencies are satisfied and known to be compatible. I am acutely aware of how clusters are stuck back in time, and I tried hard to see if I could squeeze in at least Python 3.7. Given [NEP29](https://numpy.org/neps/nep-0029-deprecation_policy.html), that meant hard-coding a several versions of packages specifically for Python 3.7, and the result was that the dependency solver wouldn’t even convergence. \(At the moment, the usage of features available only in Python>3.7 is either 0 or very minimal, so the main problem is with the dependencies.\) We can discuss how to handle this, but form a technical point of view the only solution is to forgo any check on the dependency tree and cross fingers that things will install and work \(as 80% of the Python world routinely does anyway\). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2696/update-kuibit-to-…

1 0

#2619: include Ellipitca (reader) in Einstein Toolkit
by Alireza R. 31 Jan '23

31 Jan '23

#2619: include Ellipitca (reader) in Einstein Toolkit Reporter: Roland Haas Status: open Milestone: Version: Type: enhancement Priority: major Component: Comment (by Alireza R.): Hey @{557058:088051f9-5b94-4b5e-bfbe-71137030b9c1} .Yes, I’ll plan to do so. Sure, me and @{5d6ebe02608c0a0dae6f564c} will be attending. Thanks! -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2619/include-ellipitca…

1 0

#2691: New features to particle_tracerET
by Leonardo Werneck 31 Jan '23

31 Jan '23

#2691: New features to particle_tracerET Reporter: Leonardo Werneck Status: new Milestone: ET_2023_05 Version: Type: enhancement Priority: major Component: Comment (by Leonardo Werneck): The thorn’s output is non-standard because it deals with arrays, not grid functions. Each particles' position is evolved using the thorn’s own RK method. Thus each line of the output file looks like “time x\_1 y\_1 z\_1 x\_2 y\_2 z\_2 …” where the subscript is the particle ID and \(x,y,z\) the particle position. I do not see the typo in line 43 of `file_output_routines.C`. Could you be more specific? Also note that you are looking at the master branch, but the proposed changes have not been merged yet. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2691/new-features-to-p…

1 0

#2674: Einstein Toolkit != Cactus
by Gabriele Bozzola 31 Jan '23

31 Jan '23

#2674: Einstein Toolkit != Cactus Reporter: Zach Etienne Status: new Milestone: Version: Type: bug Priority: minor Component: Comment (by Gabriele Bozzola): Indeed, I listed it among the stand-alone codes in my message \(and the icon in the plot was supposed to represent it\) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2674/einstein-toolkit-…

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac January 2023