Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

Einstein Toolkit Meeting Reminder
by Roland Haas 15 Sep '13

15 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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#. Topics: * outstanding patches * moving grid function tags into actual interface.ccl options: ** checkpoint ** tensortypealias ** others * GetComponents -p and svn versions >= 1.7 * Kranc activity As always, we will answer questions and hear comments that come up at the meeting. Roland Haas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlI2RCQACgkQTiFSTN7SboXkmwCfS6nCozvAhraGQOqrX9GHHNY9 QakAnjszSRe/bgVf7BdU7LkwxsKV8W6T =Q42C -----END PGP SIGNATURE-----

1 0

splitting grid ARRAY along given direction only
by Roland Haas 13 Sep '13

13 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all, is there a way to split a grid array (not a grid function) only along a given direction when doing the decomposition into processor components? In my usage case I have a grid array: CCTK_REAL phi TYPE=ARRAY SIZE=nphi,ntheta,nrad DISTRIB=DEFAULT ... and would like to split only in the last (radial) direction so that each process gets full spherical shells (I would have more shells than processes and could also live with empty processes). I looked at the code in SetupGH.cc and it seems as if currently the mapping DISTRIB=DEFAULT => SplitRegions_Automatic automatic is hard-coded and I could not find a way to make SplitRegions_Automatic split only in the z direction (but found a new method to cause "grid structure inconsistent" assert()s). Before I start hacking Carpet and/or Cactus, is there known way on how to achieve 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlIyTzkACgkQTiFSTN7SboVQrwCg1I6UAe/KVZ223+Ud1FwuvnIa xuMAoKmPLHUs6U4ycem6zCGn8rygD0+6 =atMr -----END PGP SIGNATURE-----

3 3

Meeting Minutes
by Roland Haas 12 Sep '13

12 Sep '13

Present: Frank, Roland, Peter, Erik, Matt, Ian, Josh, Maria, Yosef, Philipp git to svn transition: * Ian (and other contributors) created a wiki page outlying ideas for how to organize repositories: https://docs.einsteintoolkit.org/et-docs/Version_control * majority of call participants prefer git over svn, points mentioned are easier management of branches and patches and availability of powerful GUIs * suggest using GUIs even for "advanced" users. For git there is SourceTree for OSX and SmartGit or GitEye (see http://git-scm.com/downloads/guis) Goals to achieve while moving the repositories, some of which might be conflicting, in no particular ordering: * simplify exchanging patches, in particular patches for review where right now we exchange patch files, instead we might want to point to a revision in a branch or private repository * consistency of thorns in toolkit is easier to achieve is strongly dependent thorns are in a single repository * simplify work-cycle for developers, read-only access for end-users is already provided by GetComponents * minimize amount of code downloaded * keep modularity of framework, avoid monolithic repository Opinions: * consistency is given low priority, instead require framework to enforce this (eg via interface.ccl etc). * avoid overly large repository with many unrelated thorns * using branches and cherry picking commits to choose a working set of thorns that mixes cutting edge versions of some thorns and bugfix-only versions of another is hard to do, takes lots of time. * we lack the manpower to keep a always working mainline for all thorns, GRHydro currently follows this paradigm and requires ~0.5 days a week to choose and push patches. The advantage is that Zelmani can do whatever it wants and does not have to worry about "external" users pulling code that contains bugs. This is not in line with the ET philisophy of having trunk branches under development then releases every 6 months. Hosting: * Frank (who will be admin) advertises to host the git repos at CCT, Ian suggests using gitolite as the front-end which uses a plain git repository for admin task (keeps record of admin actions) * desire to be able to automate actions on multiple repositories (assuming we will have multiple/many repositories) * suggestion to consider bitbucket/github as external hoster for speed and/or certificate issues, did not find much support * want to make sure that certificates work and that speed is acceptable * rather spend some money than spend time * bitbucket might be a viable option when using teams and would simplify infrequent tasks, major problem is scriptability * github source code made be available to use even for locally hosted repos if we want a web-based UI, Ian to test this Proposed repository structure: * structure not fully decided on, use wiki page (see above) as location to hash out proper layout Yours, Roland

6 10

reported vs real memory usage + CarpetRegrid2?
by Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY] 11 Sep '13

11 Sep '13

Hi. I'm running a vacuum BHB evolution with a larger-than-usual set of inner refinement regions (levels 8, 9, 10 11 have radii of 12M, 8M, 6M, and 4M, respectively) and consequently the memory usage is a bit higher than normal. But I'm finding that it jumps up almost 100% after the first regridding, and stays there. My diagnostic for this is the result of top on each of the nodes (via "qtop.pl", a script on the machine I'm using). Sampled before the first regridding, it shows each core using ~ 1.5% of the node's total memory, while after regridding, it's more like 2.9% (these are Sandy Bridge nodes, with 16 available cores). However, the periodic output message from Carpet reporting the Grid structure etc. shows regions only marginally larger than before, and --- crucially for me --- has a marginally larger "Total required memory" (164 GB -> 167 GB, for instance). So (a) what's using the extra memory, and (b) why isn't Carpet reporting it? How seriously should I be taking that "Total required memory" message? I see this with executables generated from both the last (ET_2012_11) and current (ET_2013_05) stable releases, BTW. I'm attaching the current parameter file and SCROUT from a run. Thanks, Bernard

2 2

Meeting Minutes
by Roland Haas 09 Sep '13

09 Sep '13

Present: Peter, Erik, Frank, Roland, Philipp, Zacharia Etienne, Ian ET projects: * loosing momentum now that MHD paper is (almost) published * next project: staggered vector potential * currently working (with code in Zelmani): cell centered vector potential using algebraic gauge * started to work on reconstruction required for edge based A field * Philipp will make parfiles for cell centered A field available * Doodle poll for edge-A MHD call http://doodle.com/vahwwt5mbd6thmez Zach's MHD code: * Zach has send email too mailing list detailing plans and current status * Ian cleanup up Kranc's code over the last couple days, no changes in results are expected, please contact Ian (possibly via the mailing list so as to avoid duplication) if you experience problems Yours, Roland

1 0

IllinoisGRMHD Thorn Status, General Strategy, and Timeline
by Zach Etienne 09 Sep '13

09 Sep '13

Fellow ET folks, As many of you know, I am now working on rewriting the Illinois group's staggered vector potental GRMHD code for insertion into the latest ET code as an open-source thorn called IllinoisGRMHD. The motivations for rewriting the existing thorn are threefold: 1) Make the existing code easier to read and extend, to quickly and efficiently do new science 2) Speed up the code 3) Make the code smaller and easier to insert into ET. There are 3 tasks involved in getting our code ready for insertion into ET, and I am happy to announce that the first, most difficult task is complete, as well as Task 2A. Task 2B is underway: Task 1) Rewrite the guts of our old GRMHD thorn, including the, Ai->Bi routine, PPM, flux evaluation, and RHS computation routines. To speed up the turnaround time in getting this code ready and quickly try new techniques for optimization, I developed it as a standalone piece of software, allocating memory for gridfunctions filled with random but physical data (think: 10^{-2} noise atop Minkowski background), and then going through the full reconstruction process in the new code & measuring the speed. The code "guts" I described now take up only about 1300 lines of code, where before they took up several times that. Task 2A) Embed the code developed in Task 1 into a new thorn called IllinoisGRMHD in our years-old version of ET, adding to it our primitives solver (already open sourced) and boundary condition routines. (We will be abandoning our old boundary condition routines once we move to the latest ET, as ET apparently has a much nicer infrastructure for BCs.) Task 2B) I will then write a very simple initial data thorn that sets all input gridfunctions to have random but physical values at all gridpoints. Using these initial data, I will then perform Cowling evolutions and compare output from our current code with the new code. If after N timesteps the results are identical to roundoff error, I will announce that Task 2 is complete, and publicly release the IllinoisGRMHD thorn as an open-source piece of software. Task 3) Work with the ET community to embed our new open-sourced thorn into the latest ET. I plan to work with Philipp Moesta on this task, as he has already ported our open-sourced AMR prolongation/restriction operators into a relatively recent version of Carpet. We will work together to embed our work into the *latest* ET. -= Timeline =- The initial data thorn in Task 2B was written this past weekend, and I am now working on comparing results from our old GRMHD thorn and the new IllinoisGRMHD thorn, using these initial data as input for an evolution. Differences beyond roundoff error in the evolution are regarded as bugs, and I am deep into backtracing differences between the evolution codes at this moment. I hope to complete this task within a couple weeks, and once it is complete I will publicly release the thorn as an open-source module and begin Task 3. Please feel free to ask questions or share any feedback/suggestions. -Zach

1 0

Einstein Toolkit Meeting Reminder
by Frank Loeffler 09 Sep '13

09 Sep '13

1 1

User level documentation for PITTNull code
by Roland Haas 06 Sep '13

06 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all, I was just (due to questions from students whom I had asked to run the PITTNull code for me) looking for documentation on PITTNull's variables in particular precise definitions of News and NewsB as well as (preferably) the other variabels in NullNews' interface.ccl. Is there any such documentation in the thorns? I had briefly skimmed through the paper pointed to in the README file but then translating from what the paper uses to what the code uses seems like a risky thing to do to me. 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlIqGEcACgkQTiFSTN7SboUUrQCfVtUO82uuFYTE1fK/ErjYcXD5 bHgAoMrFHwDOcOz/U4gy1RC9mra7LvMr =qM/Y -----END PGP SIGNATURE-----

1 0

Einstein Toolkit Meeting Reminder
by Frank Loeffler 31 Aug '13

31 Aug '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#. As always, we will answer questions and hear comments that come up at the meeting. Please take a look at issues that are under review [1]. We currently have 8, but some of them are already waiting for quite a while. Frank Löffler [1] https://trac.einsteintoolkit.org/query?status=review&col=id&col=summary&col…

1 1

Multigrid elliptic solver released.
by Eloisa Bentivegna 28 Aug '13

28 Aug '13

Dear Cactus and Einstein Toolkit users, I have been working on a solver for elliptic PDEs based on the multigrid paradigm, and developed as a Cactus thorn using Carpet. The solver is now able to tackle some basic problems and could be applied to other cases of interest to this community. You can obtain a copy by checking out the Cosmology arrangement from its repository: git clone git@bitbucket.org:eloisa/cosmology.git There you will also find documentation, license information, and a test suite. There is no tutorial, but I think that what is under docs/ and par/ should suffice to get most people started. For more information, you can also peruse <http://arxiv.org/abs/arXiv:1305.5576>, especially if you are interested in elliptic problems on spaces without boundaries. Please notice that the spirit of the solver is not to replace existing state-of-the-art tools, but to provide a way of solving elliptic PDEs with is both easy to learn and to extend, and gives reasonable answers in a reasonable amount of time. In order to keep this flexibility, the solver is simply unable to compete with other software tailored to specific equations or geometries. In areas where these alternatives exist, they should be used instead. Finally, beware of the lack of explicit support for some of the latest Carpet features, such as multipatch and cell-centered grids. Being unfamiliar with these features, I cannot estimate how much work would be necessary to include them. I hope many of you will find this tool useful, and I look forward to hear your feedback. Eloisa

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users