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/
I short: the number is (+1) 225-578-4942 or (+1) 866-573-0359 and the conference id is 118682#.
Topics are welcome from everyone, here is what I would like to discuss:
- The ET paper has entered the review process of CQG. We should still work on the remaining small issues, which we would be allowed to change. - We should start an Einstein Toolkit Seminar series, with the idea the any topic interesting for a large part of the community could be presented, regardless of within the ET or not. One nice example was last weeks talk from Zach. Talks could be irregular at the beginning, and as last week use the time of the regular ET meeting if there isn't anything urgent to discuss (like a paper, release or similar). If this turns out to be a success we probably should find another time. Talks would be announced at least here on this list, and at http://einsteintoolkit.org/seminars/ Potential talks could be proposed and discussed here: https://docs.einsteintoolkit.org/et-docs/Einstein_Toolkit_Seminar_Proposals - /incoming contains: - ADMDerivatives: Why was that put in, in connection with the PITTNull code and Christian R. extraction method? - SphericalSlice: Ok to go to CactusNumerical? - TOVSolverHot: There are too many versions of TOVSolver around and the code (of TOVSolver) should be cleaned up anyway. Does anyone has a student who could do that (and also learn that way how to use [and not use] various numerical methods and software engineering techniques)? Although, it might be good to wait with the cleanup until after a few versions merged. - I am thinking about creating ET profiles including logins, separate from CCT logins. - Advantages would be that, since we manage them, we can help people directly, we can pick our own policies (think about expired passwords), we can more easily add data about people like their home institution, their avatar. - Disadvantage would be that we have to manage it, and that it would be yet another login for everyone. Before thinking about implementation details, or who (probably at LSU) would actually do that: is this something the majority of users would like to see? Why? Why not? What are the weak points of the current account handling? Would such an approach be an improvement? Should it be done entirely differently, if so: how? Could this somehow be combined with a similar approach for the Cactus framework? Essentially what I would like to hear at the call is a wish-list, prioritized as much as possible. In how far this is feasible remains then to be seen.
Frank Loeffler