Users November 2012

users@lists.einsteintoolkit.org

8 participants
20 discussions

Einstein Toolkit Meeting Reminder
by Frank Loeffler 14 May '15

14 May '15

Hi Please consider joining the weekly Einstein Toolkit phone call at 10 am US central time on Mondays. As usual, you can find instructions how to join on the following web site: http://einsteintoolkit.org/community/support/ I short: the number is (+1) 225-578-4942 or (+1) 866-573-0359 and the conference id is 118682#. My agenda contains: - Fall workshop - PLEASE let us know if you come [1]! - Hotel booking - Release planning - release date: Mon Oct 24 2011 - freeze date: Mon Sep 26 - the day of the call! - branch name: ET_2011_10 - List of release-concerning bugs [2] - ET paper: proposed "freeze" by Oct 3rd (Mon after this call) As always: feel free to add to this list. Frank Loeffler [1] https://docs.einsteintoolkit.org/et-docs/ET_Workshop_Fall_2011#Fall_Einstei… [2] https://trac.einsteintoolkit.org/query?status=!closed&milestone=ET_2011_11&…

10 31

Re: [Users] [ET Trac] [Einstein Toolkit] #1152: Add option to compute center of mass to hydro_analysis and lots of smaller changes
by Erik Schnetter 30 Nov '12

30 Nov '12

Adding thorn Fortran does not imply checking Fortran prototypes. For this, one has to explicitly add "use cctk" in all modules and routines as well. -erik On Tue, Nov 27, 2012 at 5:27 PM, Einstein Toolkit < trac-noreply(a)einsteintoolkit.org> wrote: > #1152: Add option to compute center of mass to hydro_analysis and lots of > smaller > changes > > ------------------------------------+--------------------------------------- > Reporter: rhaas | Owner: > Type: enhancement | Status: review > Priority: minor | Milestone: > Component: EinsteinToolkit thorn | Version: > Resolution: | Keywords: Hydro_Analysis > > ------------------------------------+--------------------------------------- > > Comment (by rhaas): > > Replying to [comment:5 knarf]: > > 0003-Hydro_Analysis-use-Fortran-modules-for-prototypes-if.patch: I > assume this is preparing following patches, e.g., 0004. Now, these then > use the table-interfaces from Fortan. Wouldn't that make this not only > optional but required? Do later patches compile without the FORTAN > capability? > > Fortran does not require prototypes and all functions are all usable > without the module. So this patch is purely optional. I like having > prototypes if possible since they help me catch errors. > > All patches seem to compile fine without Fortran modules present. I just > verified this by removing Fortran from my thornlist, which also disables > QuasiLocalMeasures. > > -- > Ticket URL: <https://trac.einsteintoolkit.org/ticket/1152#comment:7> > Einstein Toolkit <http://einsteintoolkit.org> > The Einstein Toolkit > _______________________________________________ > Trac mailing list > Trac(a)einsteintoolkit.org > http://lists.einsteintoolkit.org/mailman/listinfo/trac > -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/

1 0

**large** amplitude changes in WFs from Curie "bbh" parfiles when run in ET_2012_05
by Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY] 30 Nov '12

30 Nov '12

Hi. This may be related to something Yosef brought up back in July ["Differences in results ..." from 26 July], but I'm seeing sizable differences in WF amplitudes from Multipole when running the parameter files for the ETK paper (Loeffler et al.). Specifically, if I take the parameter file <Cactus>/par/arXiv:1111.3344/bbh/BBHMedHRes.par ... and run it with a Curie (ET_2011_05) executable, my r=30M (2,2) mode has a peak magnitude of just above 0.0027. Rerunning the same parameter file with *no* changes, using the current release, Lovelace (ET_2012_05), the same peak amplitude is just above 0.00257 -- a drop of almost 5%. Can anyone tell me what might be going wrong? Is there some kind of change in default dissipation that could explain such a large discrepancy? Does anyone have a drop-in replacement for these parameter files that will actually match the *results* from the Curie executable? Thanks, Bernard --------------------------------------------------------------------------- -- Bernard Kelly -- CRESST Research Associate, NASA/GSFC Phone: +1 (301) 286-7243 E-Mail: bernard.j.kelly(a)nasa.gov Web: http://science.gsfc.nasa.gov/sed/index.cfm?fuseAction=people.jumpBio&iphone bookid=13052 --------------------------------------------------------------------------- --

3 5

Re: [Users] [Commits] [svn:einsteintoolkit] WeylScal4/trunk/test/teukolsky/ (Rev. 129)
by Ian Hinder 27 Nov '12

27 Nov '12

On 27 Nov 2012, at 08:39, rhaas(a)tapir.caltech.edu wrote: > User: rhaas > Date: 2012/11/27 01:39 AM > > Modified: > /trunk/test/teukolsky/ > Psi4i.d.asc, Psi4i.x.asc, Psi4i.y.asc, Psi4i.z.asc, Psi4r.d.asc, Psi4r.x.asc, Psi4r.y.asc, Psi4r.z.asc > > Log: > WeylScal4: regenerate test data after Carpet change > > Carpet's 6b5c318bb1057851d0ee1b5bba6e633c5cf31ca6 which re-copies > init_fill_timelevels after initial restriction affects the ID we see and hence > the final answer Hi all, This sounds like it might change results for more than just this one test case. Does more test data need to be regenerated, and does this affect reproducibility of simulations? Erik, what was the reason for this change in Carpet? Am I worrying for nothing? -- Ian Hinder http://numrel.aei.mpg.de/people/hinder

3 4

meeting minutes
by Roland Haas 26 Nov '12

26 Nov '12

Present were: Frank, Eloisa, Roland, Ian, Steve, Josh, Yosef, Erik, Tanja, Philipp, Peter Frank quickly reported on the ongoing effort to remove warnings from the code. workshops: * next new users workshop suggested to be attached to Caltech summer school on astrophysics (proposed in meeting on Sept 3rd 2012 http://lists.einsteintoolkit.org/pipermail/users/2012-September/002505.html * school would end Saturday, attach workshop starting Monday (2 days) * date to be fixed, Christian Ott should now within this week * possibly attach developers workshop after new users workshop (otherwise fear that developers workshop is spend preparing for the workshop) * too early to already discuss topics for developer's workshop Yours, Roland

1 0

Einstein Toolkit Meeting
by Frank Loeffler 25 Nov '12

25 Nov '12

Hi Please consider joining the weekly Einstein Toolkit phone call at 10 am US central time on Mondays. As usual, you can find instructions how to join on the following web site: http://einsteintoolkit.org/community/support/ I short: the number is (+1) 225-578-4942 or (+1) 866-573-0359 and the conference id is 118682#. Not a lot of tickets changed over the course of last week (see [1] for an overview), but a number of compiler warnings got rid of (without bothering about opening a ticket for a lot of them). Still, a lot remain and a lot of them are not hard to fix - just time consuming. Also, quite a number of them could possibly fixed 'in bulk' because they happen either in generated code or in header files. A daily overview is generated at [2] but this location is likely to change in the future. Frank Löffler [1] https://trac.einsteintoolkit.org/wiki [2] http://www.cct.lsu.edu/~knarf/ET_stats/warnings.png

1 0

meeting minutes
by Roland Haas 21 Nov '12

21 Nov '12

Present were: Frank, Roland, Bruno, Ian, Erik ET release: * all (trunk,master) branches open development again * currently large number of tickets for review (13), please take time to review one [1] MHD status: * Bondi still fails, Bruno has fixes coded up but not yet tested * rotating collapse: various tests over weekend, none succeeded, higher-order interpolation not yet coded or tried Next release: * milestones are currently used to tag what (ticket, enhancement) we want to include in the next release, not necessary how important (severe) an issue is * suggested major release goal: scheduler improvements * query on cactususers for suggestions for next release goal Misc: * Roland will likely host the next call Yours, Roland [1] https://trac.einsteintoolkit.org/query?status=%21closed&milestone=ET_2013_0…

4 9

Carpet: How to turn off auto-prolongation for 'mesh-refinement ghosts'?
by Scott Hawley 21 Nov '12

21 Nov '12

My thorn BruiserSetBG saves a background spacetime which is then used by the solver thorn BruiserConstraints. The background is set via an analytic expression, even in the regions designated as ghost zones. The ones I'm concerned about in this e-mail are not inter-processor ghost zones, rather they are regions which (for all OTHER gridfunctions) are typically filled in via prolongation from a coarser grid. But for the background, I don't want this prolongation to occur, and it's happening automatically without my specifying to do so. BrusierSetBG is created in local mode, thus I'm not explicitly calling any sync operation, but the ghost info is getting overwritten before the data makes it to BrusierConstraints. Presumably this sync is being called inside the flesh/scheduler. BruiserConstraints is a global thorn. Question: Is there any way to specify that, for a particular set of grid functions (i.e. the background spacetime), no prolongation is to occur? I haven't seen a parameter that does this. I am open to re-writing BrusierSetBG as a 'global' thorn if that will make a difference. Otherwise perhaps I'll create a thorn called "BrusierBoth" or something, that feeds the background straight into the solver. Thanks very much, Scott

2 2

meeting minutes
by Roland Haas 19 Nov '12

19 Nov '12

Present were: Bruno, Roland, Philipp, Yosef, Tanja, Erik, Josh, Ian, Eloisa * Warnings during build process: which warning options should we use "-Wall" for sure but which additional ones? [1] * Erik provided a quick explanation of what Ninja [2] is: build system similar to make but more low level, uses auto-generated files to control process, LLVM moving towards it so can expect support from larger group of users, dependency tracking is build into Ninja. We would need a volunteer to work on this though. * Ian pointed out there is a wiki page outlining the current situation of ExternalLibraries' configure.sh scripts and what could be done to have them behave more uniformly eg with respect to where they look for libraries [3] * Eloisa would like to contribute her elliptic solver to the ET. Plans to have a public version out by January with examples for the most common use cases. Yours, Roland [1] https://trac.einsteintoolkit.org/ticket/1174 [2] https://trac.einsteintoolkit.org/ticket/1180 [3] https://docs.einsteintoolkit.org/et-docs/Improving_the_treatment_of_externa…

1 0

Einstein Toolkit Meeting
by Roland Haas 19 Nov '12

19 Nov '12

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users November 2012