Users September 2016

users@lists.einsteintoolkit.org

17 participants
23 discussions

running ML_ADMConstraints with timelevels=1 and no SYNCs
by Roland Haas 23 Sep '16

23 Sep '16

Hello all, I am wondering if there would be anything wrong with running ML_ADMConstraints with just a single time level for the constraints as well as using no SYNCs for it as long as I set it's calc_every parameter to the frequency of the coarsest level. Obviously this will give my "nonssense" values in the ghost zones, buffer zones and boundary (though on the boudary I can just set it to zero). However since the constraints are pure output and nothing ever depends on them the bad values only matter if they were to eg show up in the norms. It is my recollection that CarpetReduce actually does not use any values from the ghost zones (certainly that would be wrong) or buffer zones (this may be more recent). Is there any any other way the "bad" values could make it into the norms? Note that I do not worry about 1d, 2d, 3d output for the constraints. 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

use of NO_ALLOCATION in simfactory machine definition files
by Roland Haas 21 Sep '16

21 Sep '16

Hello all, I would like to remove the allocation = NO_ALLOCATION lines from simfactory's machine definition files. They seem to have not benefit that I can see and cause two types of problems: * simfactory does not default to the allocation in the [default] section which is the only one set up when doing sim setup on the cluster itself * simfactory does not warn/abort if no allocation is set for the cluster since as far as simfactory is concerned, there actually is an allocation defined (namely "NO_ALLOCATION"). This is eventually caught by qsub and friends but simfactory's handling of qsub errors is not very good unfortunately Does anyone remember why we introduced NO_ALLOCATION? And would anyone object to remove it from all the affected ini files (which is most of them it seems). 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 4

web site development
by Frank Loeffler 20 Sep '16

20 Sep '16

Hi, Our website needs an update. This can usually mean two things, and in our case it means both: content update/refresh and/or web technology update. This email and discussion should only be about the latter: which web technology to use. This email also got quite long. If you don't feel like reading through all this, please at least skip to the last paragraph and read that. What do we have now? Status quo is hand-written html with usage of php on every site, but mostly only for includes. There are exceptions, but there are only a few, and they can always be treated special. Why should we change the current setup? 1) The usage of php makes it necessary to use a local web server to view the pages before committing. While this isn't usually a big problem, because installing a small php-capable webserver is easy, it is a hurdle we rather shouldn't have when we want people to contribute to the pages. 2) The web layout doesn't look particularly nice on tablets, or even phones. While that was fine when the site was created, this should be addressed nowadays. What could we do instead? There might be more than these two issues (please speak up if you have more), but in the following, I will go only go into these two; separately because they don't really depend on each other in any way. 1) php We use php mainly to include common snippets, like headers and/or footers. php does this server-side, but because this requires a server to view the pages, we would have to use something else. There are only two possibilities. Either we do includes client-side, or we do them before the server sends out the pages: developer-side. Client-side the only available option is java-script, as that is the only 'active' component that is widely available client-side. Developer-side would mean that every web-developer would need to process includes after each change to the web pages, and would hand the result over to the web server. This can be automated, such that after each change to the repository a script (on the webserver) runs this step and creates the then static web pages. Requiring compilation on the developer-side would mean to require that every developer would need to install the tools needed for this, a situation we tried to avoid in the first place (local webserver). It would also mean to commit generated files into the web-repository, which in general is a bad idea. On the other hand, automating this step on the server would mean that the web sites couldn't be viewed locally again without installing the necessary tools. I would welcome something else than javascript that would work client-side, so we wouldn't depend on it being enabled. However, I am not aware of anything in that direction, so I see it as the best of the alternatives that we have. 2) layout The problem here is that it is difficult to create pages that look good both on large (desktop) and small screens (phones), especially if you think about plain html pages. The "usual" (as in often-used) solution is to change the layout of the page slightly depending on the size of the screen. Html doesn't allow for this, so again we arrive at javascript. There are probably tons of frameworks that implement common elements for so-called "responsive" web pages. Don't hesitate to throw in others, but I'll go on show-casing one I did play with. That one is called "Bootstrap". I am not saying it is the best, but it is one that seems to be widely used, open source, actively developed, and has tons of documentation. So I went ahead and used it to create a (not quite mock-up anymore) page for Chemora: https://chemoracode.cct.lsu.edu/ Note that this isn't mean to be a final "product", but it shows the basic feature of a menu. That menu is a simple top-navigation bar if inside a window that is wide enough to show it. If the windows size gets too small (you can try that yourself by just resizing your desktop window), this bar gets replaced by a pop-up menu. Feel free to look at the source code. You won't find a lot of scripting inside the actual pages. Most of that is hidden in files that are included, and most of that is inside the bootstrap library itself (that you don't really need to look at at all). How to get involved? I will have a student at LSU go through the pages and "improve" them, creating a "preview" first for everyone to look at. However, apart from a more "modern" page, one prime objective is to make it really, really easy to edit those pages, for every developer. Please share your opinion about how to edit/compose our web pages. How would *you* like to edit and view them? Frank

2 3

meeting minutes for 2016-09-19
by rhaas＠illinois.edu 20 Sep '16

20 Sep '16

Present: Jonah, Roberto, Roland, Eloisa, Matt, Zach, Erik, Frank, Vasili Mewes, Yosef * Jenkins move * will move to NCSA, master server up and running but requires backups to be still set up. git super repo needs to be moved. Roland to get this up and running. * Request for (final) review of https://trac.einsteintoolkit.org/ticket/1523 * Roland asks for documenation to be added to the Cactus maintainers guide, eg the grid paper Grid 2010 : CBHPC 2010 Workshop --- Session 3 * technical review should be done again * currently Piraha compares its parsing result with the old code so it is "safe" * Frank will apply for google academic institution to increase the number of participants to 15 * recap of the SI2 NSF grant kickoff meeting in Atlanta * Frank gave a quick overview * will send out the grant proposal to the mailing list and postpone until next week, will include sub-project list * Topics for monthly hack-a-days * (summer) student projects on https://docs.einsteintoolkit.org/et-docs/Summer_student_projects * ELoisa suggests to try and apply for a google summer of code project for some of the projects * An automated way to collect citation info from thorns, to be output at runtime. * postponed to next week, please contact knarf(a)cct.lsu.edu for suggestions * Decision on technical solution for web pages. * Bootstrap * remaining question: "offline" (jekyll) vs. "online" (javascript). * undergraduate student at LSU tasked with redoing the websites, currently learning the ropes. * Frank suggests using bootstrap for layout (can be used with Jekyll) * Erik suggests to create a couple of mock up pages using the different packages to see what itt takes and what it looks like . Currently we have one for Chemora: https://chemoracode.cct.lsu.edu/ * will move this to the mailing list * Ian suggest also include a content management system in the list 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 1

Einstein Toolkit Meeting Reminder
by Roland Haas 18 Sep '16

18 Sep '16

Hello, Please consider joining the weekly Einstein Toolkit phone call at 9:30 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/ We use a Google hangout, with the URL: https://hangouts.google.com/call/5xt7voshalqmdcztr4zhfeox2ia Topics: * recap of the SI2 NSF grant kickoff meeting in Atlanta * (summer) student projects on https://docs.einsteintoolkit.org/et-docs/Summer_student_projects Please suggest additional topics that you would like to add to the agenda. Roland Haas -- 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 1

-xHost in edison.cfg
by Roland Haas 18 Sep '16

18 Sep '16

Hello all, NERSC's edison cluster specifies -xHost in its cfg file. However login nodes and compute nodes are actually different (Sandy Bridge vs. Ivy Bridge cpus). A quick test removing -xHost reveals a possible reason: without -xHost the compiled exectuables do not run on the head node. No for the actual question: is it worthwhile to claim cross compilation (and the requirement to have to specify endianess, type sizes etc manually) to possibly gain some more speed? Given that Ivy and Sandy Bridge are tick and tock I would not expect much of a gain (though maybe Ivy Bridge actually offers wider AVX instructions?). At least I will add a comment to edison.cfg explaining why either -xHost is used or why a cross compilation is required. 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 3

Problem with compiling Einstein Toolkit on Cray system
by L.S. Oswald 16 Sep '16

16 Sep '16

Hello I'm attempting to install the Einstein Toolkit on Dora, which is a Cray system supercomputer. In doing so I came across the following error: Configuration script for thorn MPI returned exit code 5 Error message: 'MPI could not be configured: neither automatic nor manual configuration succeeded' In addition the log stated that: No MPI compiler wrapper found beneath MPI_DIR (MPI_DIR = /usr) I subsequently discovered that it was looking in the wrong place for the MPI root directory and that the reason it was looking under /usr instead of /opt/cray/mpt/7.3.2/gni/mpich-cray/8.3 was because that was the setting in the ubuntu configuration file that I had used when configuring SimFactory. On a reattempt therefore I did not use the ubuntu.cfg file when configuring SimFactory, and got the following error instead: Configuring with flesh MPI Warning: use of flesh MPI via MPI option is deprecated and should be replaced with the thorn ExternalLibraries/MPI and its MPI_DIR option MPI selected, but no known MPI method - what is "/opt/cray/mpt/7.3.2/gni/mpich-cray/8.3" ? Attempts at altering the Makefile and the config-info file resulted in either no change, or more errors. Please would you be able to advise me on the correct way to specify the root directory for MPI? Many thanks, Lucy Oswald

4 8

Continuation of problems downloading ET onto Dora
by L.S. Oswald 16 Sep '16

16 Sep '16

Hello again In previous emails I detailed the problems I was having downloading the Einstein Toolkit, first on the Dora supercomputer and then on a local computer. Following further efforts to solve my MPI issue on the Dora supercomputer I have come up against a new problem. This is the method I used to reach this point: I downloaded Cactus using the method described in https://docs.einsteintoolkit.org/et-docs/Simplified_Tutorial_for_New_Users I created my own configuration file based on the debian.cfg file which I have attached. This file specifies the path for the MPI directory (and this solves the MPI issue) I configured Simfactory using the following command: ./simfactory/bin/sim setup --optionlist=dora.cfg --runscript debian.sh I built the Einstein Toolkit with the following command: ./simfactory/bin/sim build --mdbkey make 'make -j2' --thornlist=manifest/einsteintoolkit.th This is the error I got. It seems to be some kind of syntax error: /users/lsoswald/old/Cactus/arrangements/CactusTest/TestLoop/src/TestLoopPointwise.c: In function ‘TestLoopPointwise_All’: /users/lsoswald/old/Cactus/arrangements/CactusTest/TestLoop/src/TestLoopPointwise.c:31: error: expected ‘#pragma omp’ clause before ‘collapse’ Creating /users/lsoswald/old/Cactus/configs/sim/lib/libthorn_TestLocalInterp2.a /users/lsoswald/old/Cactus/arrangements/CactusTest/TestLoop/src/TestLoopPointwise.c: In function ‘TestLoopPointwise_Int’: /users/lsoswald/old/Cactus/arrangements/CactusTest/TestLoop/src/TestLoopPointwise.c:90: error: expected ‘#pragma omp’ clause before ‘collapse’ /users/lsoswald/old/Cactus/arrangements/CactusTest/TestLoop/src/TestLoopPointwise.c: In function ‘TestLoopPointwise_Bnd’: /users/lsoswald/old/Cactus/arrangements/CactusTest/TestLoop/src/TestLoopPointwise.c:158: error: expected ‘#pragma omp’ clause before ‘collapse’ /users/lsoswald/old/Cactus/arrangements/CactusTest/TestLoop/src/TestLoopPointwise.c: In function ‘TestLoopPointwise_IntBnd’: /users/lsoswald/old/Cactus/arrangements/CactusTest/TestLoop/src/TestLoopPointwise.c:231: error: expected ‘#pragma omp’ clause before ‘collapse’ make[3]: *** [TestLoopPointwise.c.o] Error 1 make[2]: *** [make.checked] Error 2 make[1]: *** [/users/lsoswald/old/Cactus/configs/sim/lib/libthorn_TestLoop.a] Error 2 make[1]: *** Waiting for unfinished jobs.... make: *** [sim] Error 2 Could you advise me on what the issue with this might be and how I may solve it? Many thanks, Lucy

2 4

TwoPunctures::Newton_maxit
by Ian Hinder 14 Sep '16

14 Sep '16

Hi, What is the logic behind the parameter TwoPunctures::Newton_maxit? Its default is set to 5, and if the Newton iteration doesn't converge in this number of iterations, the solution is just used anyway. Shouldn't there be a fatal error in this case? Is it ever legitimate to use a solution which has not converged to within the tolerance? I think I would prefer to be told to specify a larger tolerance than to have a solution which does not meet the tolerance I set. -- Ian Hinder http://members.aei.mpg.de/ianhin

2 1

Einstein Toolkit Meeting Reminder (not for today)
by Frank Loeffler 12 Sep '16

12 Sep '16

Hi No meeting happened today, leaving next Monday as the next time. I expect a lot on the agenda, and will send an email about that later this week. Let me know if you have something to put on it already now. Next Monday it will be again, as usual: Please consider joining the weekly Einstein Toolkit phone call at 9:30 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/ We use a Google hangout, with the URL: https://hangouts.google.com/call/5xt7voshalqmdcztr4zhfeox2ia Frank Loeffler

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users September 2016