Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

Re: [Users] [Einstein Toolkit] #1191: CaKernel not compiling under Cactus
by Marek Blazewicz 06 Dec '12

06 Dec '12

On 05/12/12 20:35, Einstein Toolkit wrote: > #1191: CaKernel not compiling under Cactus > ----------------------------------+----------------------------------------- > Reporter: marqs@… | Owner: > Type: defect | Status: new > Priority: major | Milestone: > Component: Cactus | Version: development version > Resolution: | Keywords: > ----------------------------------+----------------------------------------- > > Comment (by eschnett): > > I applied a correction to the trunk. Can you confirm that this solves the > problem? > Hi, It works for me (compilation), thanks. I tested on 3 different CaKernel applications. Are you able to add the patch to branches/4.1? I wanted to make it a reference branch of Cactus that works with CaKernel.... Regards, Marek

1 0

meeting minutes
by Roland Haas 03 Dec '12

03 Dec '12

Present were: Frank, Roland, Ian, Steve, Josh, Yosef, Erik, Tanja, Philipp, Seth, Bruno Erik gave a quick explanation on where the Ninja build system differs from make (see email http://cactuscode.org/pipermail/developers/2012-December/006331.html). Essentially: * Ninja is lower level than make * two stage procedure: first one defines rules eg how to compile c++ files, then one assigns files to rules. No automatic assignment based on filename patterns occurs. * Ninja build files look cleaner than makefiles * not high priority. Might want a student to have a look at. Problem: needs to understand the Cactus build system first. Changes to code over the last week, coding crusade against warnings: * arrangements folder is no longer in flesh repository, this should fix issue with parallel checkouts * Erik has suggestions on how the remove warnings from Vectors thorn. Will try to go back to use inline functions for vectorized operations rather than macros (originally Erik found that some compilers do not properly inline the functions resulting in a ~5 slowdown). * disable shadow warning in default option lists Misc: * Roland will host next meeting (Dec. 10th). Yours, Roland

1 0

Einstein Toolkit Meeting
by Frank Loeffler 03 Dec '12

03 Dec '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#. Eight tickets have been closed last week [1]. This includes - The flesh repository doesn't contain the 'arrangements' directory anymore. It created problems when checking out thornlists in parallel when thorns got checked out before the flesh. This does not mean that there is no arrangements directory anymore. It just means that GetComponents is now creating it (or a user by hand), not the checkout of the flesh itself. - CarpetEvolutionMask is now used (optional) within GRHydro - Cactus doesn't allow negative error levels anymore. This in particular means that calls like CCTK_WARN(0,"") will always abort the run. - The default for WARN in some generic option lists has been changed to "yes". This in particular changed the osx-* and sl6* optionlists. Depending on the rest of your option list you might now see more or a lot more warnings when compiling. We are (constantly) working on that. Warnings: A daily overview is generated at [2] but this location is likely to change in the future. At the moment, about 99% of the warnings are generated by warnings about 'shadowed' variables. This means this is very likely all valid code, but unfortunately also a pattern for a common error, thus the warning. It seems to be connected to the thorn Vectors, which is used in especially Kranc-generated code. A nice solution to this problem would be appreciated. :) Frank Löffler [1] https://trac.einsteintoolkit.org/wiki [2] http://www.cct.lsu.edu/~knarf/ET_stats/warnings.png

2 1

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 26 Nov '12

26 Nov '12

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users