Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #1179: Add dtlapse_evolution method to Exact
by Einstein Toolkit 27 Nov '12

27 Nov '12

#1179: Add dtlapse_evolution method to Exact -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: Exact | -----------------------------------+---------------------------------------- The attached patch actually does two things: 1. adds dtlapse_evolution method and dtshift_evolution method options 'exact' to the respective ADMBase keywords 1. schedules metric initialization in MoL_PostStep (in addition to CCTK_PRESTEP) which is in line with what the current gauge initialization routine does -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1179> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1092: et trac server quite slow
by Einstein Toolkit 27 Nov '12

27 Nov '12

#1092: et trac server quite slow -------------------------------------+-------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit website | Version: Keywords: | -------------------------------------+-------------------------------------- The ET trac server responds rather slowly right now. Eg. {{{ [rhaas@zwicky ~]$ time wget https://trac.einsteintoolkit.org --2012-09-14 15:54:54-- https://trac.einsteintoolkit.org/ Resolving trac.einsteintoolkit.org... 130.39.21.34 Connecting to trac.einsteintoolkit.org|130.39.21.34|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 38172 (37K) [text/html] Saving to: `index.html' 100%[===============================================================================================================================================================================>] 38,172 239K/s in 0.2s 2012-09-14 15:55:09 (239 KB/s) - `index.html' saved [38172/38172] real 0m14.766s user 0m0.013s sys 0m0.007s }}} ie. 14s to get the top level webpage. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1092> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #620: Simplify timelevel handling for Cactus thorn writers
by Einstein Toolkit 21 Nov '12

21 Nov '12

#620: Simplify timelevel handling for Cactus thorn writers -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- Currently, a thorn writer must declare the maximum number of timelevels for a variable in the interface.ccl file, then allocate a specific number of timelevels for which storage is allocated in the schedule.ccl file. There are rules for how many timelevels a variable should have. For example, to evolve using MoL I think you need at least two, whereas to evolve using mesh refinement with time prolongation order 2 you need three. The problem is that the person writing the thorn shouldn't have to know how it is going to be used. If I write an evolution thorn, I should not care whether it is used with mesh refinement or not. I certainly shouldn't have to care what prolongation order is going to be used. Would it be possible for Cactus to automatically determine the number of timelevels needed for a given variable? My proposal is that it should not be necessary for the user to specify the number of timelevels in the interface.ccl or schedule.ccl file for variables declared in that thorn. The only time a thorn writer should have to do that is if that thorn specifically uses the other timelevels. For example, a thorn which couples to MoL will probably only ever read or write to the current timelevel. MoL, on the other hand, could tell Cactus that it needs a certain number of timelevels at runtime for those variables. Similarly for mesh refinement. This goes along with the planned changes to the scheduling system to make it easier to program Cactus thorns and make it harder to make errors. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/620> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #1185: Automate auto-generating code
by Einstein Toolkit 21 Nov '12

21 Nov '12

#1185: Automate auto-generating code -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Other | Version: Keywords: | -------------------------+-------------------------------------------------- There should be an automated way for re-generating code, i.e. running Kranc and autoconf. Often, projects have a script "autogen.sh" that does so. This can't be a makefile, since this has to generate configure, which needs to run to generate the Makefile. In our case, autogen.sh would (unconditionally) run autoconf to generate configure, and would check each thorn for certain scripts/makefiles that then have the opportunity to re-generate code (if needed). For example, we could check for files "autogen.sh" in each thorn's main directory. E.g. McLachlan would contain the command "cd m; make" there. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1185> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #1183: add conservative ENO operator to Carpet
by Einstein Toolkit 20 Nov '12

20 Nov '12

#1183: add conservative ENO operator to Carpet -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: enhancement | Status: new Priority: optional | Milestone: Component: Carpet | Version: Keywords: | -------------------------+-------------------------------------------------- the attached patch adds a conservative ENO operator to Carpet which can be used in cell centered runs to conserve rest mass when regridding/prolongating. The operator is activated by setting he new Carpet parameter "Carpet::eno_interpolation_type" to "averages". The default is "samples" which selects the current ENO implementation. I also attach a parameter file that demonstrates the effect (can be turned into a test if we want to, also one can likely add the operator to CarpetExtra's prolongation test thorn). The final file attached contains the Maple worksheet to compute the ENO weights. All of this is based on the lecture notes by Shu http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19980007543_1998045663…. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1183> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1180: new option to save build logs of each compiled file
by Einstein Toolkit 19 Nov '12

19 Nov '12

#1180: new option to save build logs of each compiled file -------------------------+-------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- It would be convenient to have an option to automatically generate a log of building Cactus. This can usually be done just by piping the output of the 'make' command into a file, but for parallel builds this gets mixed up. It would be nice to have the output instead done by Cactus itself, on a file-by-file basis and, once done with a thorn, combined into a 'thorn- wide log' and once done with all thorns into an overall log file. This would then make it much easier to post-process such logs, e.g., for analysis of occurring compiler warnings. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1180> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1162: Slowdown due to gethostbyname
by Einstein Toolkit 19 Nov '12

19 Nov '12

#1162: Slowdown due to gethostbyname --------------------+------------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- When running the ET testsuite on my laptop, I found it was taking 7 minutes to run just the tests from the McLachlan arrangement. The CPU usage was negligible for much of the time. I noticed that when running an empty parameter file, there was a slowdown before printing the host name. Additionally, when I attached a debugger to find out why cactus was taking so long to run the tests, the backtrace showed: {{{ 0x00007fff90f0dd16 in kevent () (gdb) bt #0 0x00007fff90f0dd16 in kevent () #1 0x00007fff954c390a in _mdns_search () #2 0x00007fff954c3345 in mdns_hostbyname () #3 0x00007fff954c31c1 in search_host_byname () #4 0x00007fff954c30c1 in gethostbyname () #5 0x00000001096becf8 in Util_GetHostName (name=0x7fff56551550 "macbook", length=255) at Network.c:86 }}} Util_GetHostName first calls gethostname, and if that function returns something with no "." in it, it calls gethostbyname. Indeed, my local hostname does not have a "." in it. This is on Mac OS 10.8.2. Changing the hostname via {{{ sudo scutil --set HostName Ians-MacBook-Pro.local }}} so the hostname included a ".", the tests now run in 1m30s. I don't know why gethostbyname is so slow on my system. Does Cactus, or maybe simfactory, or maybe the test system, call gethostbyname very frequently? Perhaps the output could be cached if this call can sometimes be slow. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1162> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1182: Ensure that all computed quantities in WeylScal4 have regression tests
by Einstein Toolkit 19 Nov '12

19 Nov '12

#1182: Ensure that all computed quantities in WeylScal4 have regression tests -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: WeylScal4 | -----------------------------------+---------------------------------------- We currently have regression tests for the Psi4 variable computed by the WeylScal4 thorn. We should also have tests for the other quantities (the other Weyl scalars and the invariants computed from them). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1182> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #865: Add autoconf macro to test for OpenMP collapse statement
by Einstein Toolkit 17 Nov '12

17 Nov '12

#865: Add autoconf macro to test for OpenMP collapse statement ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/865> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1178: unused Fortran function arguments (here in EOS_IdealFluid)
by Einstein Toolkit 16 Nov '12

16 Nov '12

#1178: unused Fortran function arguments (here in EOS_IdealFluid) -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- In an effort to get rid of some of the warnings I wonder what the best way in Fortran is to suppress warnings about unused function arguments. Is there an 'unused' keyword? I any case: the quick solution I came up with is in the patch: 'var=var' - hopefully optimized away by the compiler. It silences the warning. See attached patch. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1178> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac