modified on 23 July 2012 at 14:43 ••• 5,614 views

NWChem Planning

From NWChem

Jump to: navigation, search

NWChem Future Strategy Planning

Below are the pictures of the planning board of our first meeting on May 2nd.

Activities that were going to be pursued:

  • Edo: Internode communication. I.e., what does it take to make NWChem ARMCI free (wrappers to MPI)
  • Marat and Eric: Starting NWChem as a C++ program (nwchem.cpp). Does this work?
  • Eric and Bert: Intranode communication. I.e., possibilities and needs with homogeneous and heterogeneous systems (CUDA, OpenCL, OpenACC, OpenMP, TBB, Threads)
  • Eric and Marat: Cloud computing. I.e., possibilities and needs with latency tolerant algorithms, zeroMQ
  • Niri and Marat: Looking at APIs, what's needed and what needs to happen
  • Huub and Ken: Researching code documentation using DOXYGEN
  • Huub and Bert: New hardware including iPad, ARM, mixed precision, playing with clock cycles (last two are more energy optimization)
  • Eric and Niri: What needs to be done to advance solid state

If there are additional activities not yet discussed but on the board that you want to add to the list, go ahead!

Infrastructure 1 Infrastructure 2 Infrastructure 3

Infrastructure 4 Infrastructure 5 Infrastructure 6

Infrastructure 7 Infrastructure 8

Solvers 1 Solvers 2

Reduced Scaling Solid State

Excited States Rare Events

Strong Correlation 1 Strong Correlation 2

Embedding 1 Embedding 2

Outreach Workflow

NWChem ARMCI free

To enhance the portability of the code NWChem may need to become ARMCI free. This would require something to be done about the Global Array library. A simple approach would be to re-implement the Global Array interface on top of MPI in some way. Crucial for such an attempt is knowing how many routines need to be re-implemented. The following spreadsheet contains a list of Global Array routines that NWChem uses.


The suitability of Doxygen for documenting the NWChem source code has been considered. Doxygen is a documentation tool based on ideas similar to JavaDoc. It parses the source code of a project to extract information like module names, function names, function arguments, call trees and caller trees. In addition the tool recognizes and extracts specially formatted comments. The parsing capabilities make this tool more versatile than Robodoc and Ricky Kendall's SeeTeX. The advantage being that you get something out of it even if you do not do anything to the source code (without annotations SeeTeX or Robodoc do not give you anything).

In the process of evaluating Doxygen the directory NWChem/contrib/doxygen was created. This directory contains 3 Doxygen configuration files and a run script. The different configuration files specify different levels of documentation (text only, text and call graphs, or manpages) and the appropriate configuration file can be selected using command line flags when invoking the run script. The configuration files are set up so that Doxygen can be used in any subdirectory of the source tree.

The experience with using Doxygen is mixed. The overall idea is very powerful and useful information can extracted using the tool. However, the tool is occasionally temperamental. It is not always clear how something should be done and some advertised features do not work as described in the manual. Hence, considerable experimentation is needed to establish what works and how, and which features are better ignored. Finally, the resources consumed by Doxygen can be non trivial if the tool is run against the whole NWChem source code for the most extensive form of documentation. As an upper limit Doxygen can take over an hour to run and produce around 4 GB of data. For text only documentation the resource requirements are much more modest.