Users June 2010

users@lists.einsteintoolkit.org

19 participants
61 discussions

Moving thorn QuasiLocalMeasures into arrangement EinsteinAnalysis
by Erik Schnetter 15 Jun '10

15 Jun '10

Eloisa and I suggest to move the thorn QuasiLocalMeasures into the arrangement EinsteinAnalysis, we are the authors of this thorn. This will circumvent the problems with the CCT cvs server. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/

1 0

GetComponents git-repos vs repos
by Eric Seidel 15 Jun '10

15 Jun '10

Hi all, Last night I made a change to GetComponents that had been requested by a few people; it now clones git, hg, and darcs repos into a single "repos" directory instead of "xxx-repos". I think this is a good change as it removes some clutter and is more tool-agnostic, but unfortunately it is not backwards-compatible. If you try to update ET with the new GetComponents it will error due to the repos directory not existing. There are a few possible solutions I can see, and I'd like your feedback: 1) Everyone could do a clean checkout of ET, and there would be no further issues as all git repos will be cloned into the repos folder. This could be very inconvenient for some people though. 2) I could have GetComponents move existing git/hg/darcs repos into a "repos" folder and then fix the symlinks. This could be dangerous though, as there's always a chance that some files could be clobbered in the process. 3) Erik suggested that I could add some logic to GetComponents for now that will just create symlinks from git-repos etc to repos. That way existing checkouts of ET will be provided with the new repos folder, but without the danger of automatically moving files around. Then at some point in the future we would remove that functionality and enforce the new structure. On the other hand, this would increase clutter in the root directory. Let me know what you think about these ideas, or if you have other suggestions. Thanks, Eric

2 1

Cannot update QuasiLocalMeasures
by Erik Schnetter 15 Jun '10

15 Jun '10

When I try to update QuasiLocalMeasures from LSUThorns, I receive the following error message: Updating module: LSUThorns/QuasiLocalMeasures from repository: :pserver:cvs.cct.lsu.edu/numrel located in: Cactus/arrangements cvs [update aborted]: received broken pipe signal ERROR: Could not update module LSUThorns/QuasiLocalMeasures Died at Utilities/Scripts/GetComponents line 1402. There seem to be two problems: - CVS at the CCT is broken - GetComponents should not abort if it encounters an errors; instead, it should skip the module (or the repository?) and report the error message later -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/

6 15

No rule to make target 'Riemann1d', needed by `utils' on Damiana
by Ian Hinder 14 Jun '10

14 Jun '10

Hi, I am trying to build the ET on Damiana, and everything compiles except the utilities. The Carpet utilities build successfully, but I get an error when it tries to build the GRHydro utility: Building utilities for sim... Executing: make -j 16 -l 8 sim-utils ________________________________________________________________________ Building utilities for sim Compiling /home/ianhin/Cactus2/etrelease/arrangements/Carpet/ CarpetIOASCII/src/util/carpet2xgraph.c Compiling /home/ianhin/Cactus2/etrelease/arrangements/Carpet/ CarpetIOHDF5/src/util/hdf5toascii_slicer.cc Compiling /home/ianhin/Cactus2/etrelease/arrangements/Carpet/ CarpetIOHDF5/src/util/hdf5_slicer.cc make[1]: *** No rule to make target `/home/ianhin/Cactus2/etrelease/ exe/sim/Riemann1d', needed by `utils'. Stop. make[1]: *** Waiting for unfinished jobs.... make: *** [sim-utils] Error 2 Uncaught exception from user code: Error 2 occurred while executing command "make -j 16 -l 8 sim- utils" at simfactory/sim line 4525. at simfactory/sim line 4525 main::execute('make -j 16 -l 8 sim-utils') called at simfactory/sim line 1708 main::command_build() called at simfactory/sim line 452 Riemann1D is a .f90 file in GRHydro/src/util. Is there something special which has to be done to build Fortran utilities? -- Ian Hinder ian.hinder(a)aei.mpg.de

2 2

MHD collaboration page
by Frank Loeffler 14 Jun '10

14 Jun '10

Hi, I created the following page to hold information about the planned MHD implementation on the ET wiki. Please expand it the best you can. http://docs.einsteintoolkit.org/et-docs/MHD_implementation_details_and_disc… Frank

1 0

QuasiLocalMeasures test cases failing
by Erik Schnetter 14 Jun '10

14 Jun '10

Some of the test cases for the thorn QuasiLocalMeasures are currently failing. I won't have time in the coming week to look at these. Is there a volunteer to look at these test cases? The test cases need to pass before the release. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/

3 3

Changes to Multipole
by Ian Hinder 12 Jun '10

12 Jun '10

Hi all, Multipole is a thorn which provides mode decomposition of grid functions into spherical harmonics, and it is part of the Einstein Toolkit. As the thorn is not yet widely used, and we are approaching a release of the toolkit, I would like to clean up some aspects of the API now before the release. If there are no objections, I will make these changes so that they can be tested as part of the release process. Currently, Multipole has two modes of operation. "all modes" and "specific mode" to determine whether a range of modes from l_min to l_max are computed, or a single l, m mode. Some parameters are shared between these two methods, and this leads to confusion. For example, if you specify "all modes" (the default, and the one everyone will need), then to specify the maximum l_mode you set l_mode = X. You also have to set m_mode otherwise you only get up to m = 2, even though you are getting the higher l modes. I don't think it is necessary to have these two modes of operation, and propose to simplify the interface so that all modes up to a given l_max are computed, for all m. Specifically: Deprecate parameters mode_type, l_min, l_mode, m_mode. Replace with a single new parameter l_max. All modes from l = 0 to l = l_max will be computed. If someone sets l_mode and not l_max, l_mode will be used for l_max to keep backward compatibility for a while. -- Ian Hinder ian.hinder(a)aei.mpg.de

3 3

path expansion in git/darcs/hg repositories
by Roland Haas 11 Jun '10

11 Jun '10

Hello all, So my feature request is to have functionality similar to the URL expansion done for svn either in the REPO_PATH variable or in the git URL. The later might be more consistent with with svn but requires some extra logic in the form of way to mark where the actual repository URL ends and where the directory-within-repository part start. We have a thorn SoundSpeed that computes the speed of sound and which lives in its own git repository: Scotch/Soundspeed/.git I would like to be able to do say !TARGET = $ARR !TYPE = git !URL = git://someurl/Scotch/SoundSpeed !AUTH_URL = rhaas3@someotherurl/Scotch/SoundSpeed !REPO_PATH= ../$2 !CHECKOUT = Scotch/SoundSpeed and !TARGET = $ARR !TYPE = git !URL = git://someurl/PersonalCode !AUTH_URL = rhaas3@someotherurl/PersonalCode !REPO_PATH= Cactus/Hydro/$1/experimental/$2 !CHECKOUT = Scotch/SoundSpeed Or if everything was to be encoded in the URL part the way it is done for subversion: !URL = git://someurl/PersonalCode/.git/Cactus/Hydro/$1/experimental/$2 !CHECKOUT = Scotch/SoundSpeed where '.git/' serves as a marker to separate the actual URL of the repository from the path in the repository. Currently neither of this is possible. Patterning after the McLachlan entry, an entry in the thornlist might look like: !TARGET = $ARR !TYPE = git !URL = git://someurl/Scotch/SoundSpeed !AUTH_URL = rhaas3@someotherurl/Scotch/SoundSpeed !REPO_PATH= . !CHECKOUT = Scotch/SoundSpeed This does not work. I get [rhaas3@phys44230 tmp]$ ls -l Cactus1/arrangements/Scotch/ total 0 lrwxrwxrwx 1 rhaas3 phys-numrel 46 Jun 7 13:31 SoundSpeed -> ../../git-repos/SoundSpeed/./Scotch/SoundSpeed Fiddling around with !REPO_PATH by adding '..' does not help either (would work if the repository structure was Scotch/.git) because of the Scotch part of the !CHECKOUT line. Using the $2 syntax I would try !REPO_PATH = ../$2 which does not work either [rhaas3@phys44230 tmp]$ ls -l Cactus2/arrangements/Scotch/ total 0 lrwxrwxrwx 1 rhaas3 phys-numrel 37 Jun 7 13:34 SoundSpeed -> ../../git-repos/SoundSpeed/SoundSpeed since GetComponents only checks for the presence of $2 and then overwrites the whole path by the second part of !CHECKOUT. This is due to line (for rev 630) 905 in handle_git overwriting the whole of $repo_path with $2. 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 15

MHD plans
by Christian D. Ott 10 Jun '10

10 Jun '10

Dear All, Scott Noble and I wrote up some notes on MHD development in GRHydro. This is the basis of the discussion currently going on on the ET phone call. - Christian -------------------------- We propose the following strategy for implementing GRMHD in EinsteinEvolve/GRHydro: * Follow the formalism laid out in Anton et al. 2006, i.e., the Valencia formulation of GRMHD. Key components to implement / technical challenges will be: (a) Con2Prim (b) GRMHD Riemann problem (c) Constrained transport (d) Recovery procedure for handling unphysical/intractable updates (e) GRMHD with AMR, refluxing and all. Logical Steps: (I) Initially, focus on unigrid; no AMR. Do AMR in a second step. Get basic formalism working with a GRMHD Con2Prim scheme, TVD reconstruction, HLL Riemann solver, constrained transport. (II) Extend to AMR. Concrete steps in (I): (1) Define comoving magnetic field b^a in GRHydro as one 3D scalar and one 3D vector GF (b0 and b^i). (2) Implement (in its own routine) a Con2Prim routine for GRMHD based on routine(s) used in Scott Noble's HARM3D code. This will use the old EOS interface and will be tested with polytropes (no special routine for polytropes, though) and gamma-law EOS. Perform Con2Prim tests. (3) Implement Prim2Con, reconstruction (add calls), GRMHD Riemann problem, and update of the magnetic field variables (via MoL). Implement divergence check; run code to see how div B grows in test problems. Initial data routines to setup test problems (e.g. those in Gammie++ 2003) will be written. (4) Implement constrained transport on unigrid. Initial strategy will be to use the FluxCT algorithm (with parabolic EMF reconstruction) as in HARM3D and the lower-order version as in the original HARM code. Future plans may involve adding alternate divergence constraint methods. (5) Once all the basic routines are tested and working together, we will add a more sophisticated recovery procedure for dealing with instances where either the floor is penetrated, Con2Prim fails to converge to a physical solution, or a sudden and significant loss of energy/momentum/mass conservation occurs due to runaway recovery operations. From prior experience, this procedure will likely require an evolutionary style of development which will have to be tailored to the problem at hand. (I.1)-(I.5) should be done without touching GRHydro's GRHD routines/capabilities. Concrete steps in (II): (Need Erik's input as it they will require expertise on Carpet's data structures/interfaces that are not readily accessible to Cactus-at-large methods). (1) Support for "refluxing", aka child-to-parent flux communication along refinement boundaries. This procedure requires interface to Carpet's data structures. refs: Berger & Colella 1989. (2) Injection/restriction routine for communicating children EMF data to parent for parent's constrained transport method. This will likely require breaking down the FluxCT procedure into two parts: one that interpolates the face-centered fluxes to calculate the EMFs at the cell vertices, and one that uses the EMFs to calculate the constraint-preserving numerical fluxes. The restriction step will come in between these two steps, as it will modify the parent's EMFs before they are used to calculate the parent's final numerical fluxes. refs: Toth 2000, Balsara & Spicer 1999 (3) Adding a mask function that indicates whether a particular cell is covered by finer cells. This will be useful for adjusting the rigor with which we recover the variables (see I.5). For example, if a cell's updated conserved variables fail to yield a physical set of primitive variables and that cell has "children" then we can immediately skip (I.5) and wait for the restriction operation.

3 2

Re: [Users] [Commits] [svn:einsteintoolkit] www/ (Rev. 188)
by Frank Loeffler 09 Jun '10

09 Jun '10

On Wed, Jun 09, 2010 at 01:35:42PM +0000, roland.haas(a)physics.gatech.edu wrote: > add hack to make WebKit based browsers (ie. Safari) display last entry in > multicolumn lists Why do we 'waste' so much time on this formating issue? Couldn't we just use something standard which works everywhere? Frank

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users June 2010