Users

users@lists.einsteintoolkit.org

3 participants
3983 discussions

weak scaling performance comparison
by Jian Tao 06 May '10

06 May '10

Hi All, The total evolution time per point per iteration of KL9 of both the CCATIE code and ML in Einstein Toolkit is shown in the attached graph. We run 3 times for each benchmark and the run with minimum evolution time is used. 1. the total evolution time of ET is shorter with larger number of cores. 2. the physics code of ET is faster when more than 8 cores are used. 3. the infrastructural time (regrid + restriction + sync) of ET is longer. I am using the git version of Carpet. Regards, Jian

1 0

Schedule change in Exact.
by Eloisa Bentivegna 04 May '10

04 May '10

Hello, I'd like to propose the following patch for the schedule.ccl of thorn Exact: ------------------------------------------------------ 135a136,140 > > schedule Exact__initialize in MoL_PostStep > { > LANG: Fortran > } "Set data from exact solution on an exact slice" ------------------------------------------------------ This should ensure that Exact__initialize is executed after regridding, in the same way that Exact__gauge already is. Thanks! Eloisa

5 9

GetComponents
by Bruno Coutinho Mundim 04 May '10

04 May '10

Hi, would it be possible to add a directive such as !PROTOCOL to GetComponents? That would be useful to access git repositories with ssh protocol, for example. Some private arrangements may need this feature and it would be interesting to use GetComponents for them as well. What do you think? Thanks, Bruno.

2 1

McLachlan no longer compiles
by Tanja Bode 03 May '10

03 May '10

Hello all, I did a completely fresh checkout of the Einstein Toolkit today using the einsteintoolkit.th file from the website, but it fails to compile McLachlan. There are many errors which pop up, specifically with respect to GenericFD functions and vectorization. The version had to be reset to patch 1309ac14bdb5406b3f274ff2a3eb09f41d6ab2d2 (before both regenerate code commits) before McLachlan compiled again. Cheers, Tanja

1 0

possible CVS server issues
by Roland Haas 03 May '10

03 May '10

Hello all, the cvs server at cvs.cct.lsu.edu seems to have become unaccessible from outside of LSU (I can still ping it from is.cct.lsu.edu). Trying to check out a thorn from LSUThorns I get: Updating module: LSUThorns/QuasiLocalMeasures from repository: :pserver:cvs.cct.lsu.edu/numrel located in: whisky/arrangements ERROR: Could not update module LSUThorns/QuasiLocalMeasures Died at ./GetComponents line 1353. Yours, Roland -- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net.

3 3

benchmarking scripts
by Jian Tao 03 May '10

03 May '10

Hi, Please give it a try, http://www.cct.lsu.edu/~jtao/cct/xirel/einsteintoolkit/BENCHMARKS.tgz BENCHMARK should be under your Cactus directory. After you cd BENCHMARK, run ./xirelbench.sh To avoid any errors, you must have the whole set of einsteintoolkit downloaded and simfactory correctly configured. Regards, Jian

1 0

unable to build documentation due to change in data format
by Roland Haas 29 Apr '10

29 Apr '10

Hello all, it seems the move from CVS to subversion has had the side effect of changing the date field in checked out files from \def\CA@styledate{\CA@getcvsdate $Date: 2009/02/13 15:45:19 $} to \def\CA@styledate{\CA@getcvsdate $Date: 2009-02-13 10:45:19 -0500 (Fri, 13 Feb 2009) $} in doc/latex/cactus.sty this causes \CA@getcvsdate (line 36) in \CA@styledate to fail. This in turn prevents me from building documentation (at least for the HydroBase thorn). Changing the \def line back to what it looked like before the move fixes this. Yours, Roland -- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net.

2 2

FW: HydroBase description
by Aaryn Tonita 27 Apr '10

27 Apr '10

I believe the best place to have mass and temperature units set is in the equation of state thorns and to have the magnetic field units set by the code implementing the particular implementation of the Maxwell equations. This goes into one of your original questions about whether there were other dimensions left to specify, but in principle one could measure temperature using a completely different unit system--for instance taking c=MeV=k_b=1 and using MeV to measure temperature. Since this would only affect the equation of state thorn (the hydro equations don't see temperature directly) it wouldn't introduce any inconsistency if one was measuring the density in units where c=G=M_sun=1. The equation of state thorn would need to do some internal bookkeeping on the two different unit systems, is all. This would be useful if one was working internally with some statistical physics expressions directly so that you would not need to continuously convert the temperature. As I see it now, when using the ideal fluid equation of state (or polytrope), one is free to interpret the units. Always. This is really unavoidable: there is no microphysical interpretation of kappa or gamma. This changes when you use a realistic (or a fit) equation of state, the units would then be specified by the particular thorn which is implementing the functions needed by EOS_Base. In short: I believe the units to be best specified in the particular equation of state thorns. Cheers, Aaryn -----Original Message----- From: Roland Haas [mailto:roland.haas@physics.gatech.edu] Sent: Tuesday, April 27, 2010 4:16 PM To: Aaryn Tonita Subject: Re: [Users] HydroBase description Hello all, > Actually, the units of "Whisky" is a myth I have been trying to dispel from > some of the people at the AEI for a while now. In the hydro equations, the > only place that a mass scale enters is through the equation of state. So > HydroBase will work with any choice of mass unit (defined through the > equation of state) so long as G=c=1 is used consistently. I have run quite > successfully using polytropic units and kilometres. Well it should certainly possible to remove these statements from documentation and interface.ccl. I agree that in particular fixing the mass unit is awkward (Tanja Bode here has simulations where the natural mass unit is 10^8 M_sun) for some simulations. Is there a strong preference for fixing all (or only G=c=eps0=mu0=1, maybe k_B=1?) units or should they be left unspecified? > As for the ideal magnetohydrodynamic equations, Whisky_Exp chooses > div(Faraday) = 4-current without any constant of nature, so this is > equivalent to choosing the permeability of free space (\mu_0) to be unity. Hmm, mostly I was curious about factors of \sqrt{4\pi} in B^i. I believe that B^i as defined in HydroBase is Anton's et. al. (astro-ph/0506063v1) b^\mu after the rescaling by \sqrt{4\pi} in Eq (29). > However, this would not be defined by HydroBase unless HydroBase sets the > stress energy tensor. HydroBase does not set Tmunu. Fully determining the units might be useful for some analysis thorns. Another option might be to add parameters defining the units/describing the fluid to HydroBase or EOS_Base, though this did not seem to be very popular when it was suggested before. Eg. the unit mass in gramms, unit length in cm etc. Yours, Roland -- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net.

1 0

HydroBase description
by Roland Haas 27 Apr '10

27 Apr '10

Hello all, I have put a short description of HydroBase, its grid-variables and the units used into the wiki. It is really just what can be found in the documentation (currently out of date) and interface.ccl. Since I have never done MHD and don't know the conventions used in that field would someone who is knowledgeable mind reading through it and checking in particular the units I give for B and its definition in terms of the (dual) Faraday tensor, please? One could also add descriptions for the parameters, but these would really be just copies of what is in param.ccl. Also it would be nice to note if these choices for units of the various quantities exhaust the freedom to choose units (I would think that with temperature and specific entropy they should, even determine the mass of the (ideal gas) particle that makes up the fluid). Yours, Roland -- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net.

4 3

GetComponents
by Roland Haas 22 Apr '10

22 Apr '10

Hello all, I had played around with converting our codebase to the new directory layout (so far it compiles without problems) and found it useful to add darcs support to GetComponents. For this I copied the git routines and did a s/git/darcs/ (almost literally just that). Also slightly changed how git, darcs and hg create links by using Perl's File::Spec->abs2rel function to create relative paths. This avoids the hard-coded assumption that git-repos is two directory levels above the target. Finally I added close($output) statements to run_command which seem to be necessary to catch the return value of 'which'. Otherwise GetComponents does not seem to detect that there is no darcs eg. on Ranger. If these seem like good things to have, would it be possible to add them to GetComponents? Yours, Roland

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users