On 12 Jan 2015, at 13:43, Erik Schnetter schnetter@gmail.com wrote:
On Jan 11, 2015, at 22:10 , Frank Loeffler knarf@cct.lsu.edu wrote:
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 and the conference id is 118682#.
This being the first meeting in 2015 we should take a step back and discuss what we want the ET to be one year from now, and how this can be achieved.
Of course, other topics are as always welcome.
I would like to discuss:
- having a type that is CCTK_INT8 by default on 64-bit platforms
- adding a new type CCTK_INT16
- merging the McLachlan rewrite branch
I may be late in calling in.
I would add the following potential goals for the next year:
- Improving timelevel handling and making Carpet more flexible wrt time prolongation orders etc (https://trac.einsteintoolkit.org/ticket/620)
- Dependency-based scheduling, to avoid errors and allow potential parallelisation
- Output of simulation metadata in a standardised form (i.e. avoiding the need to parse parameter files) (https://trac.einsteintoolkit.org/ticket/1370)
- Get tickets under control (https://trac.einsteintoolkit.org/ticket/1698) - We have a system for triaging tickets which seems to work (https://docs.einsteintoolkit.org/et-docs/Tickets), and have applied it to the most recent tickets. We need to apply it to the rest, and work out how to make sure that this is done in future.
- Make tests independent of number of processes, or run on the right number (https://trac.einsteintoolkit.org/ticket/1075, https://trac.einsteintoolkit.org/ticket/1230). - With some care, we now have all the required features to make Carpet 1D output be independent of the number of processes, and I started converting some of the tests a few weeks ago. This needs to be extended to all tests, and probably instructions added to the documentation for how to write a test such that it can be run on any number of processes.