[Q-e-developers] Google Summer Of Code

[Paolo Giannozzi]

I am writing an application for the QE foundation as mentoring  
organization
to the "Google Summer of Code" (deadline 9 march). The application  
has very
little probability to be accepted without (and maybe even with) a  
credible
list of projects (should be online by the 9th). There is a list of  
projects
in the "Road Map" section of the wiki:
http://www.quantum-espresso.org/wiki/index.php/Projects , or in
the new website: http://testwp.qe-forge.it/wordpress-3.1.4/?page_id=564
(slighty more updated) but it isn't satisfactory.

Projects should consist of coding, at least as the main activity;
projects should be well-defined and should be feasible in a few months;
at least a few projects should not require any knowledge of physics
(there might be physics students applying, but I don't expect many of  
them,
and in any case it si unlikely that they know about DFT and the like);
there must be a mentor (not a mentitor), better two, following each  
project.

This is what I have been thinking of, also recycling another call for
summer students that never materialized. They all have the same problem:
it's work on an existing code base, rather than new code.

* Write or improve interface between the MOKA builder and QE input/ 
output
   - Prerequisites: Java, XML

* Write new XML output format for QE
   - Prerequisites: Fortran-95, XML

* Interface QE with genetic/evolutionary algorithm
   A working interface between the C++ code developed at Ames and an old
   version of QE exists. The work consists in understanding what changes
   need to be done to QE and how to introduce these changes with minimal
   disruption, in view of a public release
   - Prerequisites: C++, some knowledge of Fortran-95

* Interface with ASE (https://wiki.fysik.dtu.dk/ase/index.html)
   The work consists in understanding how QE routines can be recast into
   a form that can be easily called from a scripting language
   - Prerequisites: Python, Fortran-95

* Portable I/O
   The work consists in making it possible to save large files in  
(portable)
   hdf or unicode format instead of the current(non-portable) binary  
format.
   Alternatively: finding a trasparent way to write formatted but  
compressed
   (gzipped or bzipped) files from Fortran
   - Prerequisites: Fortran-95, C

Any more (better) ideas? Mentors?

PG
---
Paolo Giannozzi, Dept of Chemistry&Physics&Environment,
Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222