User Tools

Site Tools


dev:todo

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
dev:todo [2016/03/20 15:36] – Add a note about forgetfulness rivanvxdev:todo [2020/11/19 17:46] (current) – update links and some todos tmueller
Line 5: Line 5:
 Some of them may be suitable for one or more [[https://developers.google.com/open-source/gsoc/|Google Summer of Code]] projects. Some of them may be suitable for one or more [[https://developers.google.com/open-source/gsoc/|Google Summer of Code]] projects.
  
-====== Wiki ====== +====== External Libraries ====== 
-  * Add support for CP2K input-files to [[https://github.com/GeSHi/|GeSHi]], which is what DokuWiki uses for syntax highlighting.+  * Use [[https://www.gnu.org/software/gsl/|GNU Scientific Library]] for special math functions, sorting, splines, physical constants,... 
 +  * Use the [[https://atztogo.github.io/spglib/|Space Group Library]] for handling crystal symmetries. 
 +  * Use BigDFTs wavelet Poisson solvers.
  
 ====== Input / Output ====== ====== Input / Output ======
Line 12: Line 14:
   * Make it clear in the output at which nesting level the output is happening. For example, print "Entering nesting level X" before and "Exiting nesting level X" after. Proivde tools for highliting and folding the output files.   * Make it clear in the output at which nesting level the output is happening. For example, print "Entering nesting level X" before and "Exiting nesting level X" after. Proivde tools for highliting and folding the output files.
   * Evolve the printkey into a real logging mechanism. If the ''WRITE'' statements were converted into functions calls, one could annotate the output in a standardized way. Such annotations would then allow for parsing the output in a generic fashion.   * Evolve the printkey into a real logging mechanism. If the ''WRITE'' statements were converted into functions calls, one could annotate the output in a standardized way. Such annotations would then allow for parsing the output in a generic fashion.
 +  * A lone keyword of type logical should always shortcut to YES. This should be hard coded.
  
 ====== Missing features ====== ====== Missing features ======
  
   * Cut-off auto-calibration (Is it possible to provide good cut-off default values based on basis sets and desired precision?)   * Cut-off auto-calibration (Is it possible to provide good cut-off default values based on basis sets and desired precision?)
-  * Estimation of time remaining until the simulation is done.Upper bound could possibly be provided using parameters from the input file with a good cost model, heuristics will likely be needed for more precise estimation.+  * Estimation of time remaining until the simulation is done. Probably easy to do for MD using FIST. Order of magnitude estimation could possibly be provided using parameters from the input file with a good cost model, heuristics will likely be needed for more precise estimation. 
 +  * Convergence analysis of SCF and automated abort if convergence will not be reached (e.g. oscillations, etc.) and/or adaptive convergence thresholds like ORCA
   * Estimation of disk size simulation output files will take.   * Estimation of disk size simulation output files will take.
-  * Support [[https://github.com/evaleev/libint|libint2]], according to the manual, the libint2 maintainer himself is looking for someone creating a Fortran wrapper (some hints on how to do it are given as well), so this may be a two-part job: create a generic Fortran wrapper and submit to libint2, integrate it in cp2k. +  * Support [[https://github.com/psi4/psi4public/wiki/LibMints LibMints ]] or [[https://github.com/sunqm/libcint libcint ]] as alternatives to libint 
-  * Alternatively, one could consider switching to [[https://github.com/psi4/psi4public/wiki/LibMints LibMints ]]. +  * Support [[https://github.com/dftlibs/xcfun|xcfun]]
-  * Support [[http://repo.ctcc.no/projects/xcfun/wiki|xcfun]]+
   * Support [[http://www.gromacs.org/|GROMACS]] format for force fields and topology files in MM.   * Support [[http://www.gromacs.org/|GROMACS]] format for force fields and topology files in MM.
   * Provide a cp2k library/API:   * Provide a cp2k library/API:
Line 29: Line 32:
   * Extend the preprocessor to accept @ELSE in the existing '@IF @ENDIF' and possibly remove the restriction on nesting.   * Extend the preprocessor to accept @ELSE in the existing '@IF @ENDIF' and possibly remove the restriction on nesting.
  
-====== Unit-Tests ======+====== Performance ====== 
 +  * Investigate performance delta of MM code in CP2K compared to another state of the art open source software (e.g. GROMACS). See if there are interesting ideas there which can be used. 
 + 
 +====== Testing ======
   * The [[http://www.cp2k.org/static/coverage/coverage_report_combined/src/xc/index.html| test coverage]] of the XC-functionals is pretty low. Since we have libxc as reference, one could easily write a unit-test that compares both implementations by applying them to a randomly generated density.   * The [[http://www.cp2k.org/static/coverage/coverage_report_combined/src/xc/index.html| test coverage]] of the XC-functionals is pretty low. Since we have libxc as reference, one could easily write a unit-test that compares both implementations by applying them to a randomly generated density.
 +  * Setup a regtester with the [[https://www.pgroup.com/products/community.htm|PGI Community Edition Compiler]].
 +  * Performance regression testing. Requires an empty machine for reproducibility. Test each kernel (FFT, LA, grid,...) in different regimes (compute-, communication-, overhead-bound).
 +
 +====== Wiki ======
 +  * Add support for CP2K input-files to [[https://github.com/GeSHi/|GeSHi]], which is what DokuWiki uses for syntax highlighting.
  
 ====== Dev Tools ====== ====== Dev Tools ======
   * A Fortran parser library for Python. As a starting point one could take the [[https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/fortran/parse.c?view=markup | parser from gfortran]] and extend it to preserve white spaces. Alternatively, one could try to get the [[http://fortran-parser.sourceforge.net/ | Open Fortran Parser ]] to work with CP2K. A third option would be to improve the [[https://github.com/llvm-flang/flang|Fortran frontend for LLVM]]. Such a parser library would allow for advanced tools like:   * A Fortran parser library for Python. As a starting point one could take the [[https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/fortran/parse.c?view=markup | parser from gfortran]] and extend it to preserve white spaces. Alternatively, one could try to get the [[http://fortran-parser.sourceforge.net/ | Open Fortran Parser ]] to work with CP2K. A third option would be to improve the [[https://github.com/llvm-flang/flang|Fortran frontend for LLVM]]. Such a parser library would allow for advanced tools like:
-    * prettify of the entire code, not just headers. 
     * static code analysis     * static code analysis
     * generation of nice API docs     * generation of nice API docs
Line 41: Line 51:
     * ALLOCATEs in OMP-regions or tight loops     * ALLOCATEs in OMP-regions or tight loops
     * ALLOCATABLEs / POINTERs that could go in the stack.     * ALLOCATABLEs / POINTERs that could go in the stack.
 +  * Fuzzy testing: Generate randomly valid input files, then check that they either run successfully for a few seconds or quit with a proper error message. The fuzzing could be extended to other settings, e.g. mpi, openmp, arch-file,etc.
  
 ====== Youthful Folly ====== ====== Youthful Folly ======
dev/todo.1458488162.txt.gz · Last modified: 2020/08/21 10:14 (external edit)