-----------------------------------------
Release Notes for Trilinos Package Epetra
-----------------------------------------

Current (Trilinos 11.5)
-----------------------

* Removed a few "using std::" statements from Epetra headers.
These were for std::{string, istream, ostream, cerr, cout, endl, flush}.
User code that inadvertently relied on such names being available
in global namespace could see errors.  They should explicitly
use std::name or place the appropriate "using std::name;" statement
in their code.


Trilinos 11.0:
--------------
Added support for 64-bit global indices
 
Epetra supports 64-bit global indices beginning with Trilinos Release 11.0
by using the "long long" datatype.  Epetra still supports 32-bit global
indices and the interface for using them remains the same.
 
- To construct Epetra objects for 64-bit indices, certain input arguments
  must be "long long" instead of "int".  For example, compare
   
    32: Epetra_BlockMap(int NumGlobalElements, int NumMyElements,
                        const int *MyGlobalElements, ...)
    64: Epetra_BlockMap(long long NumGlobalElements, int NumMyElements,
                        const long long *MyGlobalElements, ...)
 
- New member functions that return a long long value have a suffix "64".  For
  example, GID64, NumGlobalNonzeros64, MaxAllGID64, etc.  These functions work
  whether the underlying object is 32-bit or 64-bit based.  The older
  non-suffixed functions work for 32-bit objects only.
 
- New classes added for "long long" data: Epetra_LongLongVector,
  Epetra_LongLongSerialDenseVector, Epetra_LongLongSerialDenseMatrix.
 
- To build Epetra and dependent packages without any 64-bit support turn on
  the CMake flag Trilinos_NO_64BIT_GLOBAL_INDICES.  Default is off.
 
- To enforce that a code is truly compatible with 64-bit Epetra
  turn on the CMake flag Trilinos_NO_32BIT_GLOBAL_INDICES, and fix any
  compile-time or run-time errors.  Default is off.
 
Epetra 64-bit support FAQ (compile problem)
 
Epetra-dependent code may not compile if it relied on automatic type
conversion to "int" from non-int types when constructing Epetra objects or
calling certain member functions.  This is because now there can be ambiguity
due to overloading.  Use explicit conversion to either "int" or "long long".
