Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

meeting minutes
by Roland Haas 25 Feb '13

25 Feb '13

Present were: Frank, Philipp, Yosef, Peter, Erik, Steve, Josh workshops: * create doodle poll for Monday * Roland put hotel rates for Saga Motor Home and Vagabond Inn into wiki (https://docs.einsteintoolkit.org/et-docs/ET_Workshop_Summer_2013 broken links/OpenDx: * remove broken links from website, replace with generic link to OpenDX reader plugin in svn * add statement that OpenDX is no longer being developped and that the reader is currently orphaned * suggest instead VisIt, DV (ask Bruno to verify instructions), Mathematica (ask Ian if he has pointers to his package) for visualization * Peter will give the reader a try Piranha parameter parser: * currently parses only parameter files, plan to extent to all ccl files * is easier to expand and maintain than current hand-written parsers * currently tested with ET test suite, needs to be tested on whole set of ET (and Cactus since it affects the flesh) machines * should use namespace and adhere to Cactus naming and commenting conventions: either use C++ namespace cctk (and cctki?) and/or prefix all externally visible functions by either cctk or cctki depending on whether they should be user callable or not * remove and replace existing math evaluator/parser by piranha one to have uniform math support * commmit to main flesh branch for easier testing tickets to look at: * radiation boundary condition https://trac.einsteintoolkit.org/ticket/1261 * unless objections are raised Frank will change the default for IOUtil::out_dir from "." to "$parfile" see https://trac.einsteintoolkit.org/ticket/1255 . No objections were raised in the phone call. Yours, Roland

1 0

Piraha in the Flesh
by Steven R. Brandt 25 Feb '13

25 Feb '13

I've hacked a version of Cactus to use Piraha for parameter parsing. Please take a look: https://svn.cactuscode.org/flesh/branches/with_piraha This version is able to run the ET testsuite. This version can understand the variables $parfile, $ENV{name}, and $pi (which is 3.14...). Variables can be standalone, or be substituted from inside strings. It can understand mathematical expressions including grouping, order of operation, and a few functions (sin, cos, tan, exp, sqrt). Other parameters from the parameter file are available for use in mathematical expressions. Some debug printing is in place so you can get an idea of what's going on. Cheers, Steve

5 12

Einstein Toolkit Meeting Reminder
by Roland Haas 24 Feb '13

24 Feb '13

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/ In short: the number is (+1) 225-578-4942 or (+1) 866-573-0359 and the conference id is 118682#. Points on my agenda: - Einstein Toolkit developers meeting - logistics - dead links on Cactus website - unsupported code on Cactus website - Piranha parameter file parsing As always, please feel free to ask any question somehow related to the toolkit. Roland Haas

1 0

Re: [Users] [Commits] [svn:einsteintoolkit] EOS_Omni/trunk/ (Rev. 74)
by Ian Hinder 24 Feb '13

24 Feb '13

On 24 Feb 2013, at 00:43, cott(a)tapir.caltech.edu wrote: > User: cott > Date: 2013/02/23 05:43 PM > > Added: > /trunk/tables/ > README, SLy_Tabulated.dat > > Modified: > /trunk/ > param.ccl, schedule.ccl > /trunk/doc/ > documentation.tex > /trunk/src/ > EOS_Omni_Handles.c, EOS_Omni_Module.F90, EOS_Omni_SingleVarCalls.F90, make.code.defn > > Log: > * add support for cold tabulated EOS (P=P(rho)) that > can be supplemented with a thermal gamma law Hi Christian, The automated build and test system picked up a problem with this commit; the build is failing now. I think you forgot to commit EOS_Omni_ColdEOSReadTable.F90. This is listed in make.code.defn: > jenkins@cactus-test:~/workspace/EinsteinToolkit$ svn cat https://svn.einsteintoolkit.org/cactus/EinsteinEOS/EOS_Omni/trunk/src/make.… > # Main make.code.defn file for thorn EOS_Omni > > # Source files in this directory > SRCS = EOS_Omni_Module.F90 EOS_Omni_Startup.F90 EOS_Omni_SingleVarCalls.F90 \ > EOS_Omni_SingleVarCalls_harm.F90 EOS_Omni_Handles.c \ > EOS_Omni_MultiVarCalls.F90 EOS_Omni_ColdEOSReadTable.F90 > > # Subdirectories containing source files > SUBDIRS = nuc_eos but is not in the repository: > jenkins@cactus-test:~/workspace/EinsteinToolkit$ svn ls https://svn.einsteintoolkit.org/cactus/EinsteinEOS/EOS_Omni/trunk/src/ > EOS_Omni_Handles.c > EOS_Omni_Module.F90 > EOS_Omni_MultiVarCalls.F90 > EOS_Omni_SingleVarCalls.F90 > EOS_Omni_SingleVarCalls_harm.F90 > EOS_Omni_Startup.F90 > make.code.defn > nuc_eos/ -- Ian Hinder http://numrel.aei.mpg.de/people/hinder

2 1

Bad Links: tools OpenDx import links
by David Bradley 24 Feb '13

24 Feb '13

I have been trying to download from the tools page the following is the results: 1. http://www.einsteintoolkit.org 2. http://cactuscode.org/documentation/visualization/ clicked on OpenDx, 3. http://cactuscode.org/documentation/visualization/openDX/ beneath the two graphics was a section OpenDXutils Package with several enumeration paragraphs like 1. importHDF5 4. Each of them resulted in : http://cactuscode.org/documentation/visualization/Visualization/ImportHDF5 Page Not Found - Error 404 Apologies, no page exists at this address. Please let the Cactus team know if there's a bad internal link somewhere.

5 5

logic of scheduling SelectBoundConds in McLachlan?
by Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY] 20 Feb '13

20 Feb '13

Hi. Can someone explain to me why ML_BSSN calls SelectBoundConds within MoL_PostStep? It seems like the kind of once-off routine that would happen near the start of a simulation, rather than something that has to be performed every single timestep. I wouldn't mind, but while trying to understand why ML_BSSN was evolving so slowly on one of our machines, I looked at the TimerReport files, and saw that SelectBoundConds was taking *much* more time (like 20 times as long) than the actual RHS calculation routines. Bernard

5 13

UIUC's GRMHD Primitives (Recovery) Solver
by Zach Etienne 19 Feb '13

19 Feb '13

Dear ET folks, I had a recent discussion with Tanja Bode about the GRMHD primitives solver in Maya/ET. It seems both of our primitives (recovery) solvers (aka conservative-to-primitives routines) are based on the open-source HARM code, and there is a real push now to get GRMHD working in ET. The Illinois group would like to become more involved in contributing to the ET community, and as a show of our support, I am sending this email. I have discussed the situation with Stu Shapiro, who is happy to contribute and has permitted me to attach our HARM-based primitives solver to this email. This code is GPL version 2 or 3 (whichever you prefer to maximize compatibility with ET and the existing HARM license). As you are already familiar with HARM's solver, we include no documentation. The current solver can handle Gamma-law equations of state. It will require some work, but it should be straightforward to extend the solver to arbitrary equations of state. The solver contains a driver with some quality-control features, like taking a norm of how much the conservatives have changed before and after the solver. It also contains a standalone version, so that when the solver fails during a run, it can dump a file with all the information necessary to rerun the solver *independently of the evolution code* and debug the solver. It also outputs benchmarks (# primitives/second) by default each time it is called. Finally, it includes all of the fixes our group has developed over the years (see appendix in Etienne et al., Phys. Rev. D 85, 064029 (2012)) to assess and repair the physicality of conservatives *before* going through the Newton-Raphson routine, as well as fixing unphysical primitives when they appear. With these features, we have some confidence in the robustness of our solver. There are parts of the code where you'll find commented-out lines, as evidence that a lot of tweaking has gone into this. As with all of our codes, this solver is a work in progress. As we haven't used it, we haven't updated the standalone solver in a while, so you may need to port some of the features from primitives_generic.C if you would like to use the standalone version. -Zach, on behalf of the Illinois group

2 1

meeting minutes
by Roland Haas 18 Feb '13

18 Feb '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Present were: Frank, Tanja, Philipp, Ian, Eloisa, Bruno, Peter, Steve, Erik, Josh workshops: * developer's workshop on Sat, Sun after users workshop (27-28th of July), possibly also on Monday * Erik, Roland and Philipp, Erik, Peter and Frank, ok with either option * Tanja and Ian do not know if they will make it, but likely not * ie need video conferencing setup * room should be no problem even for Monday since we are a small group * Roland will look into room rates for hotel (with Caltech rebate, likely the Saga or Vagabond Inn) * content will likely be a TOV star, which is low enough in resolution, memory footprint to be runnable by the students * will observe oscillations in central density, do fft, possibly use VisIt * add perturbation as an exercise Yours, Roland -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEi1ooACgkQTiFSTN7SboWRjwCfQPalUSJbe5n7Nrgy8QlXkC33 ViIAoLDKSe4oimsR3NcQAwQ0F4WIvlmP =vQUV -----END PGP SIGNATURE-----

1 0

McLachlan BSSN
by Erik Schnetter 18 Feb '13

18 Feb '13

Please keep all discussion on the McLachlan BSSN code on this mailing list. This ensures that everybody knows about everything that is going on, and avoid duplicate work. At the moment, we seem to have approximately three different versions of the BSSN code that seem to be incompatible: - the (official) trunk version - a version (potentially faster and more accurate) by Jim van Meter - a more flexible version (regarding gauge conditions) by Peter Diener I would suggest that we discuss things on this list before we proceed. John, Peter, could you describe your changes here? -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/

4 6

Einstein Toolkit Meeting Reminder
by Frank Loeffler 18 Feb '13

18 Feb '13

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/ In short: the number is (+1) 225-578-4942 or (+1) 866-573-0359 and the conference id is 118682#. Points on my agenda: - Einstein Toolkit new users workshop - schedule (Philipp: please post schedule of summer school) - how to advertise to students not attending summer school (only with some existing knowledge in nr) - Einstein Toolkit developers meeting - following ET new users meeting - logistics (need local organizer) As always, please feel free to ask any question somehow related to the toolkit. Frank Loeffler

2 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users