January 2018 - Trac - lists.einsteintoolkit.org

[Einstein Toolkit] #1974: Add WVUThorns_Diagnostics to the ET
by Einstein Toolkit 25 Jan '19

25 Jan '19

#1974: Add WVUThorns_Diagnostics to the ET --------------------------------+------------------------------------------- Reporter: zachetie@… | Owner: Type: enhancement | Status: new Priority: unset | Milestone: Component: Other | Version: development version Keywords: | --------------------------------+------------------------------------------- I have open-sourced a very useful set of diagnostic routines for GRMHD, GRHD, and even vacuum simulations. The thorns are available here: https://bitbucket.org/zach_etienne/wvuthorns_diagnostics Here's a brief description of each thorn: Brief description of included thorns '''Seed_Magnetic_Fields-modified''' Extended Seed_Magnetic_Fields thorn for binary neutron stars. Supercedes Seed_Magnetic_Fields thorn. '''Meudon_Bin_NS-modified''' Modifications to Meudon BNS initial data thorn to disable the overwriting of initial lapse/shift, which acts to significantly reduce coordinate eccentricity. Supercedes Meudon_Bin_NS thorn. '''VolumeIntegrals_GRMHD''' Nice GRMHD volume integration thorn, currently depends on IllinoisGRMHD and Carpet. Performs volume integrals on arbitrary "Swiss-cheese"-like topologies, and even interoperates with Carpet to track NS centers of mass. '''VolumeIntegrals_vacuum''' Nice GRMHD volume integration thorn, currently depends on ML_BSSN. There is a bit of code duplication and duplicated functionality between VI_GRMHD and VI_vacuum, to ensure that VI_vacuum can be used without enabling a GRMHD code. There is probably a better way of doing this, but I haven't had the time to think deeply about this. '''particle_tracerET''' Solves the ODE \partial_t x^i = v^i for typically thousands of tracer particles, using an RK4 integration atop the current timestepping. E.g., one RK4 substep in the particle integration might occur every 16 RK4 substeps in the GRMHD evolution. These tracer particle positions are quite useful for visualizing magnetic field lines in a consistent way from frame-to-frame in a movie (recall that in the GRMHD approximation, the magnetic field lines stay attached the fluid elements they thread ["Flux Freezing"]). Note that the velocity must be consistent with the velocity appearing in the GRMHD induction equation. This thorn reads in the HydroBase vel[] vector gridfunction, which assumes the Valencia formalism, and converts it into the induction equation velocity. '''smallbPoynET''' Computes b^i^, b^2^, and three spatial components of Poynting flux. It also computes (-1-u,,0,,), which is useful for tracking unbound matter. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1974> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #2101: Add Lean_public and Proca thorns to the ET
by Einstein Toolkit 25 Jan '19

25 Jan '19

#2101: Add Lean_public and Proca thorns to the ET -------------------------------------------------------+-------------------- Reporter: miguel.zilhao.nogueira@… | Owner: Type: enhancement | Status: new Priority: unset | Milestone: ET_2018_08 Component: EinsteinToolkit thorn | Version: development version Keywords: Lean_public | -------------------------------------------------------+-------------------- As discussed during the European ET meeting in Mallorca and during the 2018-01-22 ET telecon, we have a couple of Cactus thorns that we'd like to make available to the general ET community. These include: an updated evolution code that we used to evolve Proca fields (https://arxiv.org/abs/1505.00797), the corresponding analysis and initial data thorns, as well as a general metric evolution thorn (based on Uli Sperhake's Lean). We have been cleaning up the codes, and they are now available in following (public) bitbucket repositories: https://bitbucket.org/canuda/lean_public https://bitbucket.org/canuda/proca Included are some testsuites as well as some basic README files. We are currently working on a paper that would also serve as documentation. We would be very grateful if these could be considered for inclusion in the 2018_08 release. Sincerely, Helvi Witek Miguel Zilhão -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2101> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #1718: MemSpeed: Re-use allocated memory
by Einstein Toolkit 23 Jan '19

23 Jan '19

#1718: MemSpeed: Re-use allocated memory -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- Allocating memory is slow. In thorn MemSpeed, we should re-use memory that has been allocated instead of allocating new memory for each benchmark. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1718> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #2106: Make ParseFile.c more robust
by Einstein Toolkit 17 Dec '18

17 Dec '18

#2106: Make ParseFile.c more robust ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: Cactus | Version: development version Keywords: | ----------------------+----------------------------------------------------- We don't check for all the errors yet. https://bitbucket.org/cactuscode/cactus/pull-requests/45/flesh-make- parsefilec-a-bit-more-robust/diff -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2106> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 22

[Einstein Toolkit] #331: SimFactory does not abort if it has been given a nonexistent optionlist
by Einstein Toolkit 13 Dec '18

13 Dec '18

#331: SimFactory does not abort if it has been given a nonexistent optionlist ------------------------+--------------------------------------------------- Reporter: hinder | Owner: mthomas Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- If I specify a nonexistent optionlist in a machine's .ini file, I get the warning Info: optionlist is: None Warning: no option list specified, using blank option list This is incorrect. I have specified an optionlist, but it has not been found, which indicates an error. In this case I would expect a fatal error. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/331> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #2059: SimFactory should detect the number of cores automatically
by Einstein Toolkit 13 Dec '18

13 Dec '18

#2059: SimFactory should detect the number of cores automatically -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: development version Keywords: | -------------------------+-------------------------------------------------- SimFactory should detect the number of cores automatically. See pull request by Mikael Sahrling: https://bitbucket.org/simfactory/simfactory2 /pull-requests/20/simdtpy-detect-number-of-cpus/diff. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2059> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 30

[Einstein Toolkit] #228: Make it easier for users to create accounts on TRAC
by Einstein Toolkit 12 Dec '18

12 Dec '18

#228: Make it easier for users to create accounts on TRAC ----------------------------------+----------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit trac | Version: Keywords: | ----------------------------------+----------------------------------------- Currently, in order to interact fully with TRAC, it is necessary to have a CCT account. I would prefer that all potential users of the ET/Cactus TRAC could create accounts. This way, it would be possible for all bug reporters to be notified of changes to the tickets they create, and makes it more likely that they will respond to requests for further information and confirmations of fixes. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/228> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #270: Need web instructions for building on a new machine
by Einstein Toolkit 12 Dec '18

12 Dec '18

#270: Need web instructions for building on a new machine -------------------------------------+-------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit website | Version: Keywords: | -------------------------------------+-------------------------------------- We should have instructions on the web that explain how to build the Einstein Toolkit on a new machine, i.e. a machine for which we don't have a SimFactory entry already. This seems to be a fairly common case for new users, who rather want to build on their own machine instead of on Queen Bee. This should probably concentrate on configuring Cactus first, i.e. on configuring SimFactory for building a configuration. Job submission etc. should come later. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/270> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1804: Provide an Einstein Toolkit User Guide
by Einstein Toolkit 12 Dec '18

12 Dec '18

#1804: Provide an Einstein Toolkit User Guide -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Other | Version: development version Keywords: | -------------------------+-------------------------------------------------- We currently have documentation for individual thorns, but there is no documentation for the toolkit as a whole, describing how best to accomplish certain tasks. The [http://arxiv.org/abs/1111.3344 Einstein Toolkit paper] is a good starting point, but it is a static document, and is not quite at the level of documentation. I propose to take the paper and convert it into a user guide for the ET. It should not replicate detailed information already available in thorn documentation (rather it should link to it), but should provide a high level overview. It should also contain best practices for working with the ET. This would be the first point of reference for new users of the toolkit. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1804> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #2046: list of ET members out of date
by Einstein Toolkit 27 Nov '18

27 Nov '18

#2046: list of ET members out of date -------------------------------------+-------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit website | Version: development version Keywords: | -------------------------------------+-------------------------------------- The current list of ET members on http://einsteintoolkit.org/members.html is out of date (mostly I guess because there is no way to update one's information). Eg looking at http://einsteintoolkit.org/members.html Charalampos Markakis would be at Southampton (he has been at NCSA since 2016), Philipp Moesta would be at Caltech (he has been in Berkeley for a couple years now). Tanja Bode is no longer at Tuebingen but at UCSC etc etc. My suggestion would be to contact all persons listed for their current institution and remove those that do not respond within a month. For future registration I suggest that we ask for an email address and ping the addresses once a year, removing stale ones. We should also include a paragraph to contact maintainers(a)einsteintoolkit.org to update ones affiliation in any email send out along with the registration. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2046> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #2069: connection failures to svn.cactuscode.org
by Einstein Toolkit 20 Nov '18

20 Nov '18

#2069: connection failures to svn.cactuscode.org -------------------------------------+-------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: blocker | Milestone: Component: EinsteinToolkit website | Version: development version Keywords: SSL | -------------------------------------+-------------------------------------- I am getting connection failures to svn.cactuscode.org using svn 1.9.7 on Debian buster (which is starting to phase out tls 1.0 and 1.1 support https://lists.debian.org/debian-devel-announce/2017/08/msg00004.html). Namely I get: {{{ ET_Hack$ svn checkout https://svn.cactuscode.org/projects/ExternalLibraries/zlib/ svn: E170013: Unable to connect to a repository at URL 'https://svn.cactuscode.org/projects/ExternalLibraries/zlib' svn: E120171: Error running context: An error occurred during SSL communication }}} and openssl shows: {{{ ET_Hack$ openssl s_client -connect svn.cactuscode.org:443 CONNECTED(00000003) 140481992824064:error:14171102:SSL routines:tls_process_server_hello:unsupported protocol:../ssl/statem/statem_clnt.c:917: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 86 bytes and written 183 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1503529726 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no --- }}} systems which still allow tls1.0 (eg the QueenBee login nodes) return {{{ $ openssl s_client -connect svn.cactuscode.org:443 depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root verify return:1 depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority verify return:1 depth=1 C = US, ST = MI, L = Ann Arbor, O = Internet2, OU = InCommon, CN = InCommon RSA Server CA verify return:1 depth=0 C = US, postalCode = 70803, ST = Louisiana, L = Baton Rouge, street = 110 Thomas Boyd, O = Louisiana State University, OU = LSU A & M, CN = svn.cactuscode.org verify return:1 CONNECTED(00000003) --- Certificate chain 0 s:/C=US/postalCode=70803/ST=Louisiana/L=Baton Rouge/street=110 Thomas Boyd/O=Louisiana State University/OU=LSU A & M/CN=svn.cactuscode.org i:/C=US/ST=MI/L=Ann Arbor/O=Internet2/OU=InCommon/CN=InCommon RSA Server CA 1 s:/C=US/ST=MI/L=Ann Arbor/O=Internet2/OU=InCommon/CN=InCommon RSA Server CA i:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority 2 s:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root --- Server certificate -----BEGIN CERTIFICATE----- MIIGgDCCBWigAwIBAgIQHqWvzUQZraL+FC0Gui4TnTANBgkqhkiG9w0BAQsFADB2 MQswCQYDVQQGEwJVUzELMAkGA1UECBMCTUkxEjAQBgNVBAcTCUFubiBBcmJvcjES MBAGA1UEChMJSW50ZXJuZXQyMREwDwYDVQQLEwhJbkNvbW1vbjEfMB0GA1UEAxMW SW5Db21tb24gUlNBIFNlcnZlciBDQTAeFw0xNTEyMDEwMDAwMDBaFw0xODExMzAy MzU5NTlaMIG3MQswCQYDVQQGEwJVUzEOMAwGA1UEERMFNzA4MDMxEjAQBgNVBAgT CUxvdWlzaWFuYTEUMBIGA1UEBxMLQmF0b24gUm91Z2UxGDAWBgNVBAkTDzExMCBU aG9tYXMgQm95ZDEjMCEGA1UEChMaTG91aXNpYW5hIFN0YXRlIFVuaXZlcnNpdHkx EjAQBgNVBAsMCUxTVSBBICYgTTEbMBkGA1UEAxMSc3ZuLmNhY3R1c2NvZGUub3Jn MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA40EHmQwApNBq6wt6VyZ0 hWbeCpkOkYENmksB9kPtxzVSz0gK26nnPl68wyb3gTLN3qhfkH9rxlPNuQoo9L3q 5WnIAUrPgzz+afP/kXMzeUtD4GdKx4NhSFnOaVE8rimz2EiOAx7BC8uxfT+EOJ3i C07jwSKg8l+1M0SH1BQqjPK8HeVkfAP2jWQVBAThz/TMvs6P9w4yH8aKsUO2DpOw ocRUvEEvYd6cc4ouuJkhCkosw4NUHC5gCuuoJcVo8wuqR1F+aE8qvtG1CKNTkU6M 5QZgPcqQ4ENwM3SJTlSrWIsqebu24NDacmxc32K2CwLeBEQHM5YCKj1UAODAmtZB aBD3w7lVO0odunOWI+E/R9NARSpwyCBBCv43TDPDKp48Nmffaj7nhSRIl4hFxtTW FTC3rkoHL5fuSFWZBNVJDD7iYFsSovDUep9gAAd8szjQQdwdUTIY/ad/xFjS8UX+ Q6myUkLfBDnSQp2lMrDBYmrOBUacwMkFI4gJEyZpWA3RXAZloa8Mmopq8bHthgCN OjMDf7JAsXNo7OP7n3TIe52XVKtaYpK6OVpZelCaY7huYv/5+oZdqk0A4+ij5RBl 4GukstJQcLSErYiyheesAeSBwXMfQch57uhiB/bUL5W5lRE34Ru6gAckTt7E/Uji d9jAJ7K/ISCyp2qn9NDRtycCAwEAAaOCAcYwggHCMB8GA1UdIwQYMBaAFB4Fo3eP bJbiW4dLprSGrHEADOc4MB0GA1UdDgQWBBSuuHX667Gw/EAO8dHJCvbWxYzPHTAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcD AQYIKwYBBQUHAwIwZwYDVR0gBGAwXjBSBgwrBgEEAa4jAQQDAQEwQjBABggrBgEF BQcCARY0aHR0cHM6Ly93d3cuaW5jb21tb24ub3JnL2NlcnQvcmVwb3NpdG9yeS9j cHNfc3NsLnBkZjAIBgZngQwBAgIwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2Ny bC5pbmNvbW1vbi1yc2Eub3JnL0luQ29tbW9uUlNBU2VydmVyQ0EuY3JsMHUGCCsG AQUFBwEBBGkwZzA+BggrBgEFBQcwAoYyaHR0cDovL2NydC51c2VydHJ1c3QuY29t L0luQ29tbW9uUlNBU2VydmVyQ0FfMi5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9v Y3NwLnVzZXJ0cnVzdC5jb20wHQYDVR0RBBYwFIISc3ZuLmNhY3R1c2NvZGUub3Jn MA0GCSqGSIb3DQEBCwUAA4IBAQA8RerhAuPvOngiT4cSmhtiFp+r+i4hXzKB3UwU J3mjgrOQz3AxbmW1A9CyMEPAxtAhM1GdPmSR8T/KeGEE5/We5uVO1SvFpSA8BmsC 7vjirkNLVMlrIrDM89uUwJi5m/i7yupqhoxdReuuz4NP8PJqzOWSaU4uSvU98/Jq 1K5m4dsFdB+cW4EnO70Qv3Htl7AZUZHCNhRvbmtilQcAa+wTTYzBtJFiQ/GufDd8 DSMAa4icWq80UDdilikkt4IiMsFyEHJ0R6Jwppf3VnWD2Z+AtM5wEY6/Z4Loy0nn G/yFK5/d8vXprdFI2D3kfEx7YyMldqUwsfeEmu8Lk5bd4zqN -----END CERTIFICATE----- subject=/C=US/postalCode=70803/ST=Louisiana/L=Baton Rouge/street=110 Thomas Boyd/O=Louisiana State University/OU=LSU A & M/CN=svn.cactuscode.org issuer=/C=US/ST=MI/L=Ann Arbor/O=Internet2/OU=InCommon/CN=InCommon RSA Server CA --- No client certificate CA names sent Server Temp Key: DH, 1024 bits --- SSL handshake has read 5565 bytes and written 445 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 4096 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: 02B9ECA6650E99DAB46E41D229C6B6317D5B6649DE5602AAACB85DDA3D4BCB7F Session-ID-ctx: Master-Key: 6A79D044DE035A170C384CFFD2AD5B15B5691D518F04597E9A2BA9ED4A14CE93A18B0AB3D9CF65EC73A913FA7AC364EB Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1503529970 Timeout : 300 (sec) Verify return code: 0 (ok) --- DONE }}} and only fail if tls1.2 is forced: {{{ $ openssl s_client -connect svn.cactuscode.org:443 -tls1_2 CONNECTED(00000003) 47690330324936:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:339: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 5 bytes and written 7 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1503530008 Timeout : 7200 (sec) Verify return code: 0 (ok) --- }}} Is there any chance of having LSU update their webserver so that it offer tls 1.2 (around since August 2008)? Note that chances are that Ubuntu (which branches off from Debian unstable regularly) will pick up this change soon affecting the majority of our new Linux ET users. For Debian this is a blocker since it prevents me from even downloading the code. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2069> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #2064: Add GiRaFFE to the Einstein Toolkit
by Einstein Toolkit 19 Nov '18

19 Nov '18

#2064: Add GiRaFFE to the Einstein Toolkit -------------------------------------------+-------------------------------- Reporter: zachetie@… | Owner: Type: enhancement | Status: new Priority: unset | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: GiRaFFE, GRFFE, IllinoisGRMHD | -------------------------------------------+-------------------------------- We (the authors of GiRaFFE) hereby request that GiRaFFE be added to the Einstein Toolkit. In short, GiRaFFE is the first open source, dynamical- spacetime code for modeling plasma flows in general relativistic force- free electrodynamics (GRFFE). It will be the best code in the Toolkit for modeling black hole and neutron star magnetospheres, as these magnetically-dominated regions are best modeled numerically by a GRFFE code (GRMHD codes break down when modeling very highly magnetized plasmas). Here is the commit ID for code reviewer comments: https://bitbucket.org/zach_etienne/wvuthorns/commits/ca2aab4ac66b404cddc6a3… Here is the original release announcement to the mailing list, including link to the code release paper: We are pleased to announce the public release of GiRaFFE, an open-source General Relativistic Force-Free Electrodynamics (GRFFE) code for dynamical spacetimes. -= Code Release Paper =- Our code release paper--including a full description of the GiRaFFE code, a discussion of potential applications of GiRaFFE, and code validation test results--has been uploaded to the arXiv: https://arxiv.org/abs/1704.00599 . -= Executive Summary =- GiRaFFE adopts the strategy pioneered by McKinney [1] and modified by Paschalidis and Shapiro [2] to convert a general relativistic magnetohydrodynamic (GRMHD) code into a GRFFE code. In short, GiRaFFE exists as an extensive modification to IllinoisGRMHD [3]. Both GiRaFFE and IllinoisGRMHD leverage the Einstein Toolkit’s highly-scalable infrastructure [4,5] to make possible large-scale simulations of magnetized plasmas in strong, dynamical spacetimes on adaptive-mesh refinement (AMR) grids. As you are aware, IllinoisGRMHD is an open-source rewrite of the Illinois Numerical Relativity Group's GRMHD code. GiRaFFE, on the other hand, is not based on any existing GRFFE code and is designed only to solve the equations of GRFFE in the context of fixed or dynamically-generated spacetimes. GiRaFFE has passed a large suite of GRFFE code validation tests passed by other state-of-the-art GRFFE codes, leading us to conclude that GiRaFFE is now ready for large-scale, state-of-the-art GRFFE simulations in dynamical spacetimes. -= New Thorns for the Einstein Toolkit =- All GiRaFFE thorns are listed below. Next to the name of each thorn, we include the number of lines of code to highlight the fact that GiRaFFE is quite compact and designed to be welcoming to new users. In addition, the comment-to-line-of-code ratio is very nearly 50%, and the code release paper provides a clean, broad-brush overview of the formalism and algorithms adopted. To become acquainted with any given thorn, first take a look at its README file. * GiRaFFE (~1,600 lines of code): Solves the GRFFE equations in the formalism of Paschalidis & Shapiro [2] using the same reconstruction (PPM) and staggered vector potential methods as IllinoisGRMHD. * GiRaFFEfood (~1,300 lines of code): Code validation initial data and basic diagnostics. Contains Five 1D tests in flat spacetime (fast wave, Alfvén wave, degenerate Alfvén wave, "three-wave", FFE breakdown), One 3D test in flat spacetime (aligned rotator), and Three 3D tests in curved spacetimes ("Exact Wald" solution, "Magnetospheric Wald" solution, and split monopole). * ShiftedKerrSchild (~230 lines of code): Sets up all 3+1 quantities for a Kerr-Schild spacetime with an arbitrary radial shift, to mitigate effects of extreme spacetime curvature near r_{KS}=0. See Appendix of code release paper for full discussion. * VolumeIntegrals_slab_Gfood (~310 lines of code): Performs volume integrals over arbitrary rectangular prisms as specified in parameter files. * GiRaFFE_to_HydroBase & ID_converter_GiRaFFE (~230 lines of code): Acts as a translation layer to convert 3-velocities in HydroBase's Valencia formalism to/from the 3-velocity found in the induction equation (v^i = u^i/u^0; native to GiRaFFE). -= License =- To maximize compatibility with existing thorns in ET, all of the aforementioned GiRaFFE thorns are either licensed GPLv2+ or 2-clause BSD (FreeBSD). See LICENSE file in each. -= Download GiRaFFE! =- The collection of thorns comprising GiRaFFE may be downloaded here: https://bitbucket.org/zach_etienne/wvuthorns Sincerely, The GiRaFFE team -Zach Etienne -Mew-Bing Wan -Maria Babiuc -Sean McWilliams -Ashok Choudhary References: [1] J.C. McKinney. Mon. Not. R. Astron. Soc., 367:1797, 2006. [2] V. Paschalidis and S. L. Shapiro. Phys. Rev. D, 88:104031, 2013. [3] Z. B. Etienne, V. Paschalidis, R. Haas, P. M¨osta, and S. L. Shapiro. Class. Quantum Grav., 32(17):175009, 2015. [4] https://einsteintoolkit.org/ [5] https://carpetcode.org/ -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2064> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 17

[Einstein Toolkit] #2104: Support NixOS
by Einstein Toolkit 30 Oct '18

30 Oct '18

#2104: Support NixOS -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: unset | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- NixOS is a new Linux-based distribution. To make things work, a few small changes are necessary. https://bitbucket.org/cactuscode/cactus/pull-requests/46/flesh-support- nixos/diff -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2104> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1889: correct finding normalization value for relerr compuation
by Einstein Toolkit 31 Aug '18

31 Aug '18

#1889: correct finding normalization value for relerr compuation --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- Before it would have taken the larger of the abs value of the new and old data of the last data set rather than the largest abs value of the new and old data of all the datasets. This will make relative errros smaller and will be particularly noticeable in cases where the last dataset was small or zero. This should get rid of the "Error, how did I get here" warnings (that really indicated an logic error). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1889> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1885: support bibtex in thorn documenation files
by Einstein Toolkit 28 Aug '18

28 Aug '18

#1885: support bibtex in thorn documenation files -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- The pull request https://bitbucket.org/cactuscode/cactus/pull-requests/new?source=rhaas /docs-bibtex&t=1 adds support for bibtex to Cactus' documentation system. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1885> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 16

[Einstein Toolkit] #2055: Move gallery examples to EinsteinExamples repository
by Einstein Toolkit 28 Aug '18

28 Aug '18

#2055: Move gallery examples to EinsteinExamples repository -------------------------------------+-------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit website | Version: development version Keywords: | -------------------------------------+-------------------------------------- The [http://einsteintoolkit.org/gallery.html Einstein Toolkit Gallery examples] parameter files could be moved from the [https://bitbucket.org/einsteintoolkit/www/src/master/gallery/?at=master www] repository to the [https://bitbucket.org/einsteintoolkit/einsteinexamples/src/master/par/?at=m… EinsteinExamples] repository and arrangement. This would mean: * They are checked out when someone downloads the ET, avoiding a separate web browser or curl download * They will have branches like the rest of the ET, so they can be associated with a given release if necessary Note that this will separate them from the other related material on the website, such as thornlists, images, etc, but I think it is worth it to make it easier for new users. Eventually, we hope that all the gallery examples will use the standard ET thornlist anyway. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2055> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #2042: new thorns for hydro analysis
by Einstein Toolkit 28 Aug '18

28 Aug '18

#2042: new thorns for hydro analysis -------------------------+-------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: Other | Version: development version Keywords: | -------------------------+-------------------------------------------------- The LSU and Parma groups developed, and used for publications, a set of two thorns for analysis of hydro quantities, in particular for mode analysis. We would like to have those included in the Einstein Toolkit. We are aware that a few things are still missing for that (documentation, test suites), but before we go that extra step and create all of that, we want to be sure the following is seen as 'ok': The main thorn (GRHydro_Analysis, _not_ to be specific to GRHydro, it only inherits hydrobase - could and should probably be renames) does reductions of quire a few quantities. In practice, the memory required for this turned out to be a problem on some machines. These reductions are done at ANALYSIS, which means even telling Cactus to allocate/deallocate not once, globally, but instead doing that every time step does not help. Thus, there is a second thorn, a utility thorn called 'TempPool'. It's task is nothing else than to provide an array of grid functions that are always allocated, but which can be used by other thorns for, reductions - and, and this is the interesting part - can be re-used by other thorns, for other reductions after that; within the same time step in ANALYSIS. This is how TempPool is used by GRHydro_Analysis. TempPool is not tied to GRHydro_Analysis. Any other thorn can also request storage there, but there currently isn't another thorn. It just seemed to good idea to split this functionality. The book keeping already now makes sure that the number of allocated grid functions is only as large the maximum of any thorn using it. The relevant code can be found here: https://bitbucket.org/GravityPR/prthorns/src I'd like another developer to have a look and give input. Once/If this is deemed ok to be included, we will add the necessary documentation and test suites and make a proper proposal for inclusion. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2042> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #2008: NaNs when running static tov on >40 cores
by Einstein Toolkit 22 Aug '18

22 Aug '18

#2008: NaNs when running static tov on >40 cores -----------------------------------+---------------------------------------- Reporter: allgwy001@… | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: Other | Version: ET_2016_05 Keywords: | -----------------------------------+---------------------------------------- I've been trying to run the static tov example parameter file on an HPC cluster using >40 cores, but this results in NaNs in the data. I can't remember whether the issue first appears at 40 or 41 cores (and won't be able to check this for the next few days), but using 41+ cores definitely gives me NaNs. I remember testing with 39 cores and several other lower values (down to 4), but these runs all seemed fine. So far, I've been able to run larger simulations (e.g. BBHs) on more than 40 cores (same cluster) without any apparent issues. I'll attach the static tov parameter file I used (I think I changed one or two outdated parameters), as well as the PBS script and error/output files from a static tov run on 44 cores. The static tov runs were intended for speed test purposes. The results of the speed tests I've run so far (on fewer than 40 cores) seem quite strange to me, so I'm going to attach a text file with walltimes and CPU times for these runs, too. Any comments would be appreciated! -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2008> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

2 13

[Einstein Toolkit] #1263: Multipole does not handle variable names correctly
by Einstein Toolkit 13 Aug '18

13 Aug '18

#1263: Multipole does not handle variable names correctly -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: Multipole | -----------------------------------+---------------------------------------- When you specify variables for Multipole to decompose, you have the option of giving it a "name" for the variable to be used in the output filename. This is useful if you are decomposing Psi4r, with imaginary part Psi4i, and want the file to just be named "Psi4". If you don't specify a name, it is supposed to use the original variable name. However, at the moment, this last part seems to be broken. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1263> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1201: Incorrect dtshift in Exact with shift_add_{x, y, z} parameters
by Einstein Toolkit 09 Aug '18

09 Aug '18

#1201: Incorrect dtshift in Exact with shift_add_{x,y,z} parameters -----------------------------------+---------------------------------------- Reporter: barry.wardell | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- The Exact thorn has shift_add_{x,y,z} parameters for adding a constant to the shift. Considering these as a coordinate transformation using a vector v^i = [shift_add_x, shift_add_y, shift_add_z], such a transformation should affect both the shift and its time derivative. This is because the time derivative in the new coordinates differs from the time derivative in the old coordinates by a term v^j d(beta^i)/dx^j. This is correctly implemented as a 4D coordinate transformation in the EinsteinExact thorns and I have verified that the difference relative to the Exact thorn is given by this missing term. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1201> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1097: Describe Tmunu in GRHydro
by Einstein Toolkit 09 Aug '18

09 Aug '18

#1097: Describe Tmunu in GRHydro -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Describe in GRHydro's documentation how Tmunu is defined -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1097> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #660: Make MHD multipatch-aware
by Einstein Toolkit 09 Aug '18

09 Aug '18

#660: Make MHD multipatch-aware -----------------------------------+---------------------------------------- Reporter: tbode | Owner: tbode Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- At least the Con2PrimM routines need to be multipatch-aware. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/660> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #1690: The test system should treat a nonzero exit code from Cactus as a failure
by Einstein Toolkit 08 Aug '18

08 Aug '18

#1690: The test system should treat a nonzero exit code from Cactus as a failure --------------------+------------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- The test system seems to ignore the fact that Cactus exits with a nonzero exit code. It displays Cactus exited with error code 1 Please check the logfile... No files created in test directory Success: 0 files identical And in the summary at the end, it treats this as a passing test. In this case, there were no test reference files and no files output, because the test (by design) does not produce any data, it just aborts if the test fails. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1690> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #1103: simfactory download page points to outdated version
by Einstein Toolkit 02 Aug '18

02 Aug '18

#1103: simfactory download page points to outdated version ------------------------+--------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- currently http://simfactory.org/simfactory/download/ points to https://svn.cct.lsu.edu/repos/numrel/simfactory2/branches/ET_2011_10 for the "current" version, which is from the last release -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1103> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #1523: Use Piraha to Parse all CCL files
by Einstein Toolkit 02 Aug '18

02 Aug '18

#1523: Use Piraha to Parse all CCL files -------------------------+-------------------------------------------------- Reporter: sbrandt | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Cactus_4.3.0 Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- Piraha should be used to parse all the CCL files. This would give us a well-defined grammar and the ability to let other tools use the CCL files in a reliable way. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1523> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 11

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac January 2018