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#.
The topics to discuss include the new users tutorial and developers workshop for next year which will be end of July (see last meeting minutes) at Caltech. Also the memory leaks that Ian reported (http://lists.einsteintoolkit.org/pipermail/users/2012-December/002686.html) and whether we want to provide "generic" option lists for common OSs in simfactory.
Roland Haas
Hi,
On Sun, Dec 16, 2012 at 10:41:45AM -0800, Roland Haas wrote:
and whether we want to provide "generic" option lists for common OSs in simfactory.
We already do for several, and I strongly believe that this is a good idea.
Also, I would like to suggest that each of the machines in simfactory (at least the most important, but also the generic ones) get an official maintainer. That would make it easier to find the one that might actually know something about that particular machine. For example I found this weekend that with what is in simfactory I cannot build on kraken and I wonder who would be best to ask about that machine.
(on that particular issue: the current default optionlist uses the intel12 compiler (as 'cc'). However, simfactory does apparently not switch to that module when you login (using 'sim login'). Even when I do that by hand I get link errors that look like some intel library is missing from the link-line. I didn't investigate further yet.)
Frank
On Sun, Dec 16, 2012 at 10:13 PM, Frank Loeffler knarf@cct.lsu.edu wrote:
Hi,
On Sun, Dec 16, 2012 at 10:41:45AM -0800, Roland Haas wrote:
and whether we want to provide "generic" option lists for common OSs in simfactory.
We already do for several, and I strongly believe that this is a good idea.
I would keep these generic options lists radically simple, and only specify things that are necessary for correctness. I would avoid fancy compiler options, or requiring people to build&install software ahead of time. As much as possible Cactus should work out of the box.
Also, I would like to suggest that each of the machines in simfactory
(at least the most important, but also the generic ones) get an official maintainer. That would make it easier to find the one that might actually know something about that particular machine. For example I found this weekend that with what is in simfactory I cannot build on kraken and I wonder who would be best to ask about that machine.
(on that particular issue: the current default optionlist uses the intel12 compiler (as 'cc'). However, simfactory does apparently not switch to that module when you login (using 'sim login'). Even when I do that by hand I get link errors that look like some intel library is missing from the link-line. I didn't investigate further yet.)
To ask a question about an option list I would send email either to the Einstein Toolkit or Simfactory mailing list. I dislike maintainers, because this turns people away who otherwise would correct an error. It is also difficult to detect and dismiss maintainers that don't do their job. And to ask a question, it is anyway better to ask on a list than to send a private email to a single person, for several reasons.
Most of the HPC option lists are maintained by me (e.g. hopper, kraken, ranger, lonestar, gordon, trestles, orca, gpc, surveyor, vesta). This includes me regularly building and running on these machines.
"sim login" does not switch modules; it gives you a plain ssh session. Switching is done when Simfactory runs at a later time, e.g. for every build, submit, or run.
I just re-built on Kraken, and I did not encounter an error there.
-erik
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Frank Loeffler -
Roland Haas