10:00 Chi-kwan Chan: Rolling Cache Method for High-Order Finite Difference on GPU
11:20 Chunlin Tian: High Performance Computation with Programble General Purpose GPU
14:15 Wolfgang Dobler: ``Object-oriented fluid dynamics'' -- a Numpy toolbox for testing solvers for PDEs
To be decided during the week.
General code discussion issues
===============================
Architecture/coding conventions
---------------------------------------------
- avoiding a complete rebuild from the source code every time model size or processor grid is changed
- simplification of restart (without copy of snapshots - read from different location)
- automatic remeshing (both grid-size/processor number changes)
- automatic detection of changed physics
- merge of start and run
- notification scheme at irregular stop/signal catching
- relaxed modularity requirements by PROTECTED attribute (FORTRAN 2003)
- diagnostics
* too many lines in the physics modules devoted to diagnostics! -> in specific
subroutines
* set diagnostics output in wall-clock times
* change the frequency of xyaverages through a new d1davg
and allow the time units to be changed to wall-clock hours
- a common data file (like cdata.f90) to be shared between density,
eos and entropy.(say cthermo.f90 (common thermodynamics))
may solve some problems with modularity of the code.
- cleaning up *.h files and check for breaks in modularity (automation?)
- branching of the code, how to keep both up-to-date?
- use of C preprocessor
Visualization
------------------
- routines to transform data into a format recognised by
VAPOR/Paraview/etc. + documentation
New Physics/Skills
--------------------------
- testfield for spherical geometry
- anelastic solver
- still questions regarding the particle module, especially about
collisions. More documentation needed.
- non-grey radiation transport
- Athena's Double Mach Reflection
- routine to convert vector fields between geometries,
(spherical/cartesian/cylindrical)
Organisation
============
- need for a table to identify who entered whom as project member
* or does this already exist under google wiki?
- whould participation in mailing lists be mandatory?
* who is *not* on the list
* check who should be in the list, and send an email obliging them
to be on the list.
* remove spurious spammers that seem to have made to the list
- list in the webpage all papers that were published using Pencil.
* php script
- quarterly Pencil Code progress meeting (Skype)
* try monthly, schedule in advance, say, last Tuesday of the month,
and let people organize themselves around it.
* have a doodle, lime survey, or whatever online voting stuff
in the pencil code page for voting
List of registrants
Application
Application Form