~ubuntu-branches/ubuntu/utopic/nwchem/utopic

« back to all changes in this revision

Viewing changes to src/tools/ga-5-1/armci/src-portals/code_options.h

  • Committer: Package Import Robot
  • Author(s): Michael Banck, Daniel Leidert, Andreas Tille, Michael Banck
  • Date: 2013-07-04 12:14:55 UTC
  • mfrom: (1.1.2)
  • Revision ID: package-import@ubuntu.com-20130704121455-5tvsx2qabor3nrui
Tags: 6.3-1
* New upstream release.
* Fixes anisotropic properties (Closes: #696361).
* New features include:
  + Multi-reference coupled cluster (MRCC) approaches
  + Hybrid DFT calculations with short-range HF 
  + New density-functionals including Minnesota (M08, M11) and HSE hybrid
    functionals
  + X-ray absorption spectroscopy (XAS) with TDDFT
  + Analytical gradients for the COSMO solvation model
  + Transition densities from TDDFT 
  + DFT+U and Electron-Transfer (ET) methods for plane wave calculations
  + Exploitation of space group symmetry in plane wave geometry optimizations
  + Local density of states (LDOS) collective variable added to Metadynamics
  + Various new XC functionals added for plane wave calculations, including
    hybrid and range-corrected ones
  + Electric field gradients with relativistic corrections 
  + Nudged Elastic Band optimization method
  + Updated basis sets and ECPs 

[ Daniel Leidert ]
* debian/watch: Fixed.

[ Andreas Tille ]
* debian/upstream: References

[ Michael Banck ]
* debian/upstream (Name): New field.
* debian/patches/02_makefile_flags.patch: Refreshed.
* debian/patches/06_statfs_kfreebsd.patch: Likewise.
* debian/patches/07_ga_target_force_linux.patch: Likewise.
* debian/patches/05_avoid_inline_assembler.patch: Removed, no longer needed.
* debian/patches/09_backported_6.1.1_fixes.patch: Likewise.
* debian/control (Build-Depends): Added gfortran-4.7 and gcc-4.7.
* debian/patches/10_force_gcc-4.7.patch: New patch, explicitly sets
  gfortran-4.7 and gcc-4.7, fixes test suite hang with gcc-4.8 (Closes:
  #701328, #713262).
* debian/testsuite: Added tests for COSMO analytical gradients and MRCC.
* debian/rules (MRCC_METHODS): New variable, required to enable MRCC methods.

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
/* 
2
 
   Questions:
3
 
   ORNL - tipparajuv@ornl.gov 
4
 
   CRAY - ryan@cray.com
5
 
*/
6
 
 
7
 
/* --------------------------------------------------------------------------- *\
8
 
   PORTALS_USE_RENDEZ_VOUS
9
 
   =======================
10
 
   When the number of PEs gets very large, the data server is required to have
11
 
   buffer space available for all possible incoming messages which is defined
12
 
   by PORTALS_MAX_DESCRIPTORS = (MAX_BUFS+MAX_SMALL_BUFS).
13
 
   For each PE, the DS must have at least:
14
 
     min_memory_per_pe = PORTALS_MAX_BUFS*PORTALS_BUF_SIZE +
15
 
                         PORTALS_MAX_SMALL_BUFS*PORTALS_SMALL_BUF_SIZE
16
 
   This becomes a memory constraint at large core count.
17
 
   Rendez-vous message is one mechanism to get around requiring the DS to
18
 
   have buffer space for all messages. When rendez-vous (RZV) messaging is
19
 
   enabled, the messages what use the large buffers no longer send the entire
20
 
   buffer "eagerly".  Instead, only the data request (request_header_t) gets
21
 
   sent to the data server.  When the data server is ready to handle the
22
 
   request, it "pulls" the entire buffer over via a portals_get operation.
23
 
   One can immediately see that this can lead to a slow down in performance,
24
 
   since the data server is idle when it has to pull the data over.  This is
25
 
   the price paid when you remove the bufferign for those messsages.  Ideally,
26
 
   when the DS is pulling the message, it could be processing another request.
27
 
   This double buffering technique needs to be programmed in. Care must be
28
 
   taken to ensure proper ARMCI behavior. The next request handled can not be
29
 
   from the same PE, nor can it be a FENCE operation ... all other (?)
30
 
   requests/operations can be double buffered.
31
 
\* --------------------------------------------------------------------------- */
32
 
 # define PORTALS_USE_RENDEZ_VOUS
33
 
 
34
 
 
35
 
 
36
 
/* --------------------------------------------------------------------------- *\
37
 
   PORTALS_LIMIT_REMOTE_REQUESTS_BY_NODE
38
 
   =====================================
39
 
   Another means to reduce the required buffer needed by the data server is
40
 
   to limit the number of cores that can talk to the data server at any given
41
 
   moment.  When this options is turned on, only 1 request per node is allowed
42
 
   to be in the buffer of any given data server.  On a 10 core node, the size
43
 
   of the buffer required by the data server is reduced by more than an order
44
 
   of magnitude.  You get more than an order of magnitude, because you don't
45
 
   need to reserve space for any of the small buffers, since you can only have
46
 
   one small or one large from any given node in the ds buffer at any one time.
47
 
   Another major benefit is you can increase MAX_BUFS and MAX_SMALL_BUFS to
48
 
   increase concurrency without affecting the DS's buffer size.
49
 
 
50
 
   Can be used with PORTALS_USE_RENDEZ_VOUS.
51
 
 
52
 
        notes: every request needs to respond with an ack, even gets.
53
 
        acks actually send data when we limit remote request ... the ack
54
 
        response is needed to trigger that the outstanding request has
55
 
        been finished by the data server ... the ack zeros out the index
56
 
        in the active_requests_by_node array.
57
 
\* --------------------------------------------------------------------------- */
58
 
 # define PORTALS_LIMIT_REMOTE_REQUESTS_BY_NODE_TURNED_OFF
59
 
 
60
 
 
61
 
/* --------------------------------------------------------------------------- *\
62
 
   PORTALS_AFFINITY
63
 
   ================
64
 
   When initializing compute processes and data servers, the affinity passed
65
 
   in by aprun/alps is ignored.
66
 
 
67
 
   Compute processes are bound strictly to a particular core.  Cores are
68
 
   evenly divided between sockets keeping the last core (mask = 1 << (ncpus-1))
69
 
   free for the data server.
70
 
 
71
 
   If the node is not fully subscribed, then the data server is bound to the
72
 
   last core on the node (mask = 1 << (ncpus-1)); otherwise, the data server
73
 
   is "free floating" (mask = (1 << ncpus)-1) on a fully subscribed node.
74
 
\* --------------------------------------------------------------------------- */
75
 
 # define PORTALS_AFFINITY
76
 
 # define PORTALS_AFFINITY_NSOCKETS 2
77
 
 
78
 
 
79
 
/* --------------------------------------------------------------------------- *\
80
 
   CRAY_USE_MDMD_COPY 
81
 
   ================== 
82
 
   Used MDMD copy instead of PtlGetRegion for on-node "local" transfers
83
 
\* --------------------------------------------------------------------------- */
84
 
 # define CRAY_USE_MDMD_COPY
85
 
 
86
 
 
87
 
 
88
 
/* --------------------------------------------------------------------------- *\
89
 
   ORNL_USE_DS_FOR_REMOTE_GETS 
90
 
   =========================== 
91
 
   Vinod informed us of a modification that can be made to enable the use of
92
 
   the data server for remote gets.  Without this option, direct gets are 
93
 
   used.  This can cause severe network congestion, because many armci_gets
94
 
   are not stride 1.  The data server packs those gets into contiguous blocks
95
 
   and sends them back as a single put.  However, the direct gets, require
96
 
   many small messages.
97
 
 
98
 
   Unfortunately, there is a small bug in the DS for remote gets.  This bug
99
 
   may cause the program to abort or print out the following message:
100
 
   %d: server wrote data at unexpected offset %d
101
 
 
102
 
   This is a bug actively being worked on @ CRAY and ORNL.
103
 
\* --------------------------------------------------------------------------- */
104
 
 # define ORNL_USE_DS_FOR_REMOTE_GETS   
105
 
 # define CRAY_USE_ARMCI_CLIENT_BUFFERS