HvD: Re-enabled the Klamt-Schuurmann model. There were a couple of things
that had not been completely re-instated yet:
1. Rsolv was still set to 0, whereas it should be something like 0.5
2. The surface and volume calculations required a wierd thing that depends
   on the triangulation of a sphere between minbem and maxbem. 


git-svn-id: https://svn.pnl.gov/svn/nwchem/trunk@26346 85dd5168-0e29-45a6-bdf9-2122c44e486f
removed sqrts from parameter defn...EJB

git-svn-id: https://svn.pnl.gov/svn/nwchem/trunk@26347 85dd5168-0e29-45a6-bdf9-2122c44e486f
fix for cray ftn mpi detection

git-svn-id: https://svn.pnl.gov/svn/nwchem/trunk@26348 85dd5168-0e29-45a6-bdf9-2122c44e486f
fix for previous checkin

git-svn-id: https://svn.pnl.gov/svn/nwchem/trunk@26349 85dd5168-0e29-45a6-bdf9-2122c44e486f
implementation of popcnt, leadz, and trailz...might not be correct.  Huub needs to test...EJB

git-svn-id: https://svn.pnl.gov/svn/nwchem/trunk@26350 85dd5168-0e29-45a6-bdf9-2122c44e486f
...EJB

git-svn-id: https://svn.pnl.gov/svn/nwchem/trunk@26351 85dd5168-0e29-45a6-bdf9-2122c44e486f
...EJB

git-svn-id: https://svn.pnl.gov/svn/nwchem/trunk@26352 85dd5168-0e29-45a6-bdf9-2122c44e486f
...EJB

git-svn-id: https://svn.pnl.gov/svn/nwchem/trunk@26353 85dd5168-0e29-45a6-bdf9-2122c44e486f
HvD: Eric found that the Fortran 2008 intrinsics POPCNT, LEADZ and
TRAILZ are not supported by older compilers. This caused problems
building the NWXC libraries on a variety of machines. Hence he added
regular Fortran implementations of these functions. I have tweaked
these implementations a little bit using BTEST (Fortran 1995) which 
seems to work on with all compilers tried so far. I have also added 
a little description. 

Having explicit implementations of these functions did have a knock
on effect on the NWAD implementation. This module actually uses these
functions to keep track of the independent variables a given quantity
depends on (easy to do because the number of variables a functional
depends on is maximally 9 in practice). To save memory I had explicitly
declared the corresponding variable as INTEGER*4. However, NWChem 
typically promotes all integers to INTEGER*8 causing the Fortran 
implementation of LEADZ and TRAILZ to clash with the explicit 
INTEGER*4 data type. Hence I have removed the explicit INTEGER*4 
declaration from the module. The NWXC library is written in such a 
way as to automatically detect the size of the TYPE(NWAD_DBLE) 
data structures so no changes are needed to account for that.


git-svn-id: https://svn.pnl.gov/svn/nwchem/trunk@26354 85dd5168-0e29-45a6-bdf9-2122c44e486f
HvD: Attempting something beyond crazy... The NWXC library currently supports
higher order derivatives through automatic differentiation. The problem is that 
this model is 4.3 times slower than running hand written code. Maybe symbolic
algebra written code is faster (no do-loop overheads in every operator). So 
I have extended the NWAD automatic differentiation library such that it can
print the expression it is evaluating as a Maxima equation. The Maxima equation
can be differentiated by Maxima and the results translated into Fortran (but
without the operator overloading, do-loops for the partial derivatives, etc.).
Subsequently the Fortran can be compiled for integration into the NWXC library.
This material is associated with this pipeline. 

The input files listed in the directory "input" are for the little functional
printing program. These inputs are written specifically to pick out individual
functional terms. The rest of the process is driven by the GNUMakefile.

Now, let's try and run this. What could possibly go wrong???


git-svn-id: https://svn.pnl.gov/svn/nwchem/trunk@26355 85dd5168-0e29-45a6-bdf9-2122c44e486f
moved linux64 _cpu definition for aarch64

git-svn-id: https://svn.pnl.gov/svn/nwchem/trunk@26358 85dd5168-0e29-45a6-bdf9-2122c44e486f
python-config --libs should figure out all the libraries python needs

git-svn-id: https://svn.pnl.gov/svn/nwchem/trunk@26359 85dd5168-0e29-45a6-bdf9-2122c44e486f
HvD: Main change is to add the combine function to try and get Maxima
to generate more compact expressions. Also the names of the functional 
subroutines have been corrected. At the moment the code generated still is
pretty insane, to the point that the ifort compiler refuses to compile it.
Fixing this issue is the next priority. (The M06 correlation functional 
should really not produce a 41 MB and 565,000 line large subroutine.)


git-svn-id: https://svn.pnl.gov/svn/nwchem/trunk@26360 85dd5168-0e29-45a6-bdf9-2122c44e486f
HvD: A unit test working out how to get Maxima to generate optimized Fortran
code. This is the basis for generating optimized Fortran in autoxc.


git-svn-id: https://svn.pnl.gov/svn/nwchem/trunk@26361 85dd5168-0e29-45a6-bdf9-2122c44e486f
HvD: Unit test for the generation of optimized TeX representations
of the equations. This forms the basis for the TeX generation in autoxc.


git-svn-id: https://svn.pnl.gov/svn/nwchem/trunk@26362 85dd5168-0e29-45a6-bdf9-2122c44e486f
HvD: Deleted a superfluous print statement.


git-svn-id: https://svn.pnl.gov/svn/nwchem/trunk@26363 85dd5168-0e29-45a6-bdf9-2122c44e486f
HvD: An example of the insanity that results from generating code with a
symbolic algebra package but without using proper optimization. 
This subroutine is 41 MB or 565,000 lines in size. The Fortran standard
allows a single statement to take up to 40 lines, the Intel compiler extends
this to 512 lines. Still the Intel compiler rejects this code with

./f77/nwxcm_c_m06.F(211023): error #5157: Too many continuation lines
./f77/nwxcm_c_m06.F(213690): catastrophic error: Statement too long

The GNU gfortran compiler happily attempts to compile this but essentially
runs out of memory during the optimization.

In a next incarnation of the autoxc script we will have Maxima optimize
the expressions and see what that will do. Still I would like to keep a copy
of this version of this file just as a deterrent.


git-svn-id: https://svn.pnl.gov/svn/nwchem/trunk@26364 85dd5168-0e29-45a6-bdf9-2122c44e486f
HvD: Added capabilities to optimize the various expressions before Maxima
generates Fortran. Hopefully the optimized source code will address issues
with compiling the code as well as issues with compiler optimization. I still
want to see if we can optimize the TeX documentation produced as well. The 
math expressions that can only be viewed properly in a panoramic view are
kind of hard to read. A more compact representation of these expressions
would be welcome.


git-svn-id: https://svn.pnl.gov/svn/nwchem/trunk@26365 85dd5168-0e29-45a6-bdf9-2122c44e486f
HvD: Changed the script so that now it will generate optimized Fortran and
TeX. The optimized Fortran should help produce code that compilers will actually
accept. The optimized TeX hopefully generates documentation that someone
can actually read.


git-svn-id: https://svn.pnl.gov/svn/nwchem/trunk@26366 85dd5168-0e29-45a6-bdf9-2122c44e486f
HvD: Fixed the filenames recorded in the source code documentation.


git-svn-id: https://svn.pnl.gov/svn/nwchem/trunk@26368 85dd5168-0e29-45a6-bdf9-2122c44e486f