Trac

trac@lists.einsteintoolkit.org

8708 discussions

#2526: McLachlan has incorrect READ declarations for presync.
by Roland Haas 12 May '21

12 May '21

#2526: McLachlan has incorrect READ declarations for presync. Reporter: Peter Diener Status: new Milestone: ET_2021_05 Version: development version Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): The `READS` generation is somewhat related to using Tmunu in expression as of commit hash [e69182c](https://github.com/ianhinder/Kranc/commits/e69182cf0e78e4120d6d3e5… "generate READS statement for stress\_energy\_state if needed" of [Kranc](https://github.com/ianhinder/Kranc) which is in ET\_2020\_05\_v0. While that commit does _not_ produce `READS: TmunuBase:eTxx` it queries the `RequireGroups` variable for their presence and that variable is the one used to generate the `READS` and itself generates a `READS: TmunuBase::stress_energy_state`. Meaning: if there is a `READS: TmunuBase::stress_energy_state` then `RequireGroups` contained TmunuBase variables and `READS` for them will be generated. This seems to be what happens for ML\_BSSN\_ADMBaseEverywhere. That commit $once one ignores whitespace changes and putting code in a `Module`$ adds: ```mathematica (* must match list in CodeGenCalculation.m *) ignoreGroups = {"TmunuBase::eTtt", "TmunuBase::eTxx", "TmunuBase::eTxy", "TmunuBase::eTxz", "TmunuBase::eTyy", "TmunuBase::eTyz", "TmunuBase::eTzz", "TmunuBase::eTtx", "TmunuBase::eTty", "TmunuBase::eTtz"}; If[ContainsAny[lookupDefault[spec, RequiredGroups, {}], ignoreGroups], "READS: " <> "TmunuBase::stress_energy_state" <> "\n", ""], ``` ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2526/mclachlan-has-inc…

1 0

#2176: Test "Binary neutron star" example
by Roland Haas 12 May '21

12 May '21

#2176: Test "Binary neutron star" example Reporter: Roland Haas Status: open Milestone: ET_2021_05 Version: development version Type: task Priority: major Component: EinsteinToolkit website Comment (by Roland Haas): For now I have put a copy of the required thorn $only the most recent revision which is all I had a copy of$ to: [https://bitbucket.org/rhaas80/lsuthorns/src/master/](https://bitbucket.org/… and you should be able to use it with a GetComponents line like so: ``` # LSU Thorns !TARGET = $ARR !TYPE = git !URL = https://bitbucket.org/rhaas80/lsuthorns.git !REPO_PATH= $2 !CHECKOUT = LSUThorns/NSTracker ``` ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2176/test-binary-neutr…

1 0

#2176: Test "Binary neutron star" example
by Roland Haas 12 May '21

12 May '21

#2176: Test "Binary neutron star" example Reporter: Roland Haas Status: open Milestone: ET_2021_05 Version: development version Type: task Priority: major Component: EinsteinToolkit website Comment (by Roland Haas): Uh right. The svn server [svn.cct.lsu.edu](http://svn.cct.lsu.edu) was recently moved behind a firewall and is no longer publicly accessible. Though right now even when trying to access it from inside of LSU IP space $which worked fine yesterday$ I get a error 500 internal server error. @{557058:f7fd5133-6eee-4385-a5e5-3e03342a0b24} @{557058:1671c5c3-29cc-4e83-9850-a152d33a6235} is there a LSUThorns Bitbucket or github place where the thorns that wwere in [https://svn.cct.lsu.edu/repos/numrel](https://svn.cct.lsu.edu/repos/numrel) could be hosted? From the email that I received from IT support it seemed to me that the svn server would not be made public again $“svn access is restricted to internal users now.”$. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2176/test-binary-neutr…

1 0

#2176: Test "Binary neutron star" example
by Atul Kedia 11 May '21

11 May '21

#2176: Test "Binary neutron star" example Reporter: Roland Haas Status: open Milestone: ET_2021_05 Version: development version Type: task Priority: major Component: EinsteinToolkit website Comment (by Atul Kedia): There is some issue with the nsnstohmns.th thornlist that is disrupting the download of NSTracker. The issue, as I understand, is that [http://einsteintoolkit.org/gallery/bns/nsnstohmns.th](http://einsteintoolki… accesses the link [https://svn.cct.lsu.edu/repos/numrel/$1/$2/trunk](https://svn.cct.lsu.edu/r… which is dead and needs to be replaced with a new one. I last downloaded ET with the nsnstohmns.th a couple weeks ago and all went well, so this must have come up recently. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2176/test-binary-neutr…

1 0

#2527: Perl undefined variables warnings when tyring to inherit from a non existing thorn
by Roland Haas 11 May '21

11 May '21

#2527: Perl undefined variables warnings when tyring to inherit from a non existing thorn Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: minor Component: Cactus Changes (by Roland Haas): Erik Schnetter reported warnings from Perl of the sort: ``` Use of uninitialized value in concatenation (.) or string at /Users/eschnett/src/CarpetX/Cactus/repos/flesh/lib/sbin/interface_parser.pl line 176. ``` on Gitter. These seem triggered by trying to inherit from a non-existing thorn ``` CST error in /Users/eschnett/src/CarpetX/Cactus/repos/flesh/lib/sbin/interface_parser.pl (at 296) -> IDBRILLDATA (thorn IDBrillData) inherits from ellbase No thorn in your current ThornList implements ellbase Either remove IDBrillData, or add a thorn to your ThornList implementing ellbase No thorns in arrangements directory implement ellbase ``` and Perl trying to use a not yet defined array hash value when constructing the list of thorn ancestors. There are no such warnings when the code builds, yet the Perl code should not produce these warning even in the case of a later build failure. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2527/perl-undefined-va…

1 0

#2527: Perl undefined variables warnings when tyring to inherit from a non existing thorn
by Roland Haas 11 May '21

11 May '21

#2527: Perl undefined variables warnings when tyring to inherit from a non existing thorn Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: minor Component: Cactus Comment (by Roland Haas): oops, wrong string in the copy and paste buffer. I will update the description… -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2527/perl-undefined-va…

1 0

#2527: Perl undefined variables warnings when tyring to inherit from a non existing thorn
by Erik Schnetter 10 May '21

10 May '21

1 0

#2527: Perl undefined variables warnings when tyring to inherit from a non existing thorn
by Roland Haas 10 May '21

10 May '21

#2527: Perl undefined variables warnings when tyring to inherit from a non existing thorn Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: minor Component: Cactus Erik Schnetter reported warnings from Perl of the sort: ``` The Einstein Toolkit ecosystem: Enabling fundamental research in the era of multi-messenger astrophysics ``` on Gitter. These seem triggered by trying to inherit from a non-existing thorn ``` CST error in /Users/eschnett/src/CarpetX/Cactus/repos/flesh/lib/sbin/interface_parser.pl (at 296) -> IDBRILLDATA (thorn IDBrillData) inherits from ellbase No thorn in your current ThornList implements ellbase Either remove IDBrillData, or add a thorn to your ThornList implementing ellbase No thorns in arrangements directory implement ellbase ``` and Perl trying to use a not yet defined array hash value when constructing the list of thorn ancestors. There are no such warnings when the code builds, yet the Perl code should not produce these warning even in the case of a later build failure. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2527/perl-undefined-va…

1 0

#2413: Include "POWER" code to extrapolate waveforms to scri+ into ET
by Maria 06 May '21

06 May '21

#2413: Include "POWER" code to extrapolate waveforms to scri+ into ET Reporter: Roland Haas Status: open Milestone: Version: Type: task Priority: major Component: EinsteinToolkit thorn Comment (by Maria): If f0 is what will enable using Power to calculate the strain from BNS runs, then that’s it. Knowing the command line that should be used for this would be helpful too. And also, explaining how to manipulate Power in an IPython or Jupyter Notebook environment, making TwoPunctures.bbh and QLM output optional would be a good addition to the Documentation. ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2413/include-power-cod…

1 0

#2413: Include "POWER" code to extrapolate waveforms to scri+ into ET
by Gabriele Bozzola 06 May '21

06 May '21

#2413: Include "POWER" code to extrapolate waveforms to scri+ into ET Reporter: Roland Haas Status: open Milestone: Version: Type: task Priority: major Component: EinsteinToolkit thorn Comment (by Gabriele Bozzola): > Right now using FROM\_TWOPUNCTURES serves the purpose that is being suggested for f0 = None $FROM\_TWOPUNCTURES is just a string and I only use the variable name to try and avoid typos as much as possible given that Python is fully dynamically typed and requires no variable declarations at all$. I would rather not use None for this since there is only one None and one can get the total mass also in other ways which is easy to do by having another FROM\_XXX but not if None is already taken. I understand the reasoning now and it makes sense. > You can use `power.py` as a Python module `import power` then call the Python functions directly. This means you have to write Python code rather than shell code. My personal preference would be to call power with something like `power.py …. --f0 0.1 --ADM 1 --method POWER .` as opposed to creating a Python script, figuring out the function signature, taking care of saving the data myself, et cetera. Also, extending the `main()` function does not affect the functionalities for when you import `power` as a module, so you can still write Python code in exactly the same way. ‌ > My first guesses for bad POWER output would be: * make sure your psi4 starts and ends at 0 amplitude * make you may have to change the list of detectors being used, using detectors too far out or in can give bad results * TODO: probably there should be options to control the order of the polynomials that are being fit to the data I’ll try to play around and see. ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2413/include-power-cod…

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac