I think line 652 (and 539) of coef.f where chkjac routine is called, should be:
CHKJAC(JACM1(1,1,1,ie),NXYZ1,ie,xm1(1,1,1,ie),ym1(1,1,1,ie),zm1(1,1,1,ie),ndim,ierr) instead of
CHKJAC(JACM1(1,1,1,ie),NXYZ1,ie,xm1,ym1,zm1,ndim,ierr)
because of how chkjac routine is written. This will help output the right xm1,ym1,zm1 values in-case there is an inverted element.

Please delete the ut(0:N,0:N) declaration from subroutine local_grad2_t in navier1.f

The code does not compile on the BGQ with the PPLIST="BGQ" flag.
The mxm_wrapper.f and mxm_bgq.f contain f90 syntax. The code cannot compile neither with mpixlf90 nor with mpixlf77.

Even if the syntax in mxm_wrapper.f and mxm_bgq.f is converted to f77, we get “undefined references” to some blas routines at compile time.
The problem is not fixed either with the BLAS_MXM flag of PPLIST.

Are there any other flags that should be used along with "BGQ"?
If yes, it would be good to have it documented.

This suggested change will improve the include file handling.

Example use case:
I want to include SIZE.h in SIZE to hide some internals from the user. However, the Fortran standard prohibits recursion in include files.

As pointed out in a previous issue (#68), variables with identical names appear in various include files.
For example:

• x in GMRES, NEKUSE and ORTHOSTRS
• mu in GMRES and NEKUSE
• dd in FDMH1 and SEMHAT
• zgl in SEMHAT and WZF

This line was only half ported: the blas dependency still points to nek/blas instead of core/blas

@ananiast Is ALE + characteristics ready to go into v16 ?

Does it work for both PnPn and PnPn-2 ?

When this feature is added, we should add the example with exact solution to "Short Tests"

Currently, the GMRES algorithm for the pressure in Pn-Pn-2 contains multiplications with operators "U^(-1)" and "L^(-1)" defined as u(i)=sqrt(b(i)) and l(i)=sqrt(binv(i)) in uzawa_gmres_split0(). The reason to have these arrays is to my understanding to have the right inner product, i.e. r^T r = f^T B f (where f is the right-hand side, r = L^(-1) res, res=B f).

A simpler solution could be to modify the implementation and remove these arrays, by which the inner products would be carried out as
gamma(1) = sqrt(glsc3(r,r,bm2inv,ntot2))
instead of
gamma(1) = sqrt(glsc2(r,r,ntot2)).

(this possible modification was originally suggested to me by James Lottes)

A case with 4M elements and AMG needs more than 15min (on BGQ) to initialize. This is due to the poor I/O performance reading the input files (.re2, .map, AMG files) on MPI_RANK_0 only. A parallel-read would speed up things quite a bit.

Hi, I am trying to compile Nek5000 with xlf/xlc.

Here is my maketools configuration:

#!/bin/bash

# binary path
mkdir -p $HOME/bin
bin_nek_tools="$HOME/bin"

# specify your compilers here
F77="xlf"
CC="xlc"

# enable BIG MEMORY suuport
BIGMEM="true"

And here is the error output:

[u0017592@sys-83764 tools]$ ./maketools all
** underscore_test   === End of Compilation 1 ===
1501-510  Compilation successful for file test_underscore.f.
----------------------
Make genmap...
----------------------
make[1]: Entering directory `/home/u0017592/projects/Nek5000/tools/genmap'
xlf -q64 -c -qrealsize=8 genmap.f
** genmap   === End of Compilation 1 ===
** makemesh   === End of Compilation 2 ===
** linearmsh   === End of Compilation 3 ===
** exitti   === End of Compilation 4 ===
** exitt   === End of Compilation 5 ===
** cscan_dxyz   === End of Compilation 6 ===
** set_d2   === End of Compilation 7 ===
** cscan_bcs   === End of Compilation 8 ===
** rd_bc   === End of Compilation 9 ===
** blank   === End of Compilation 10 ===
** ltrunc   === End of Compilation 11 ===
** indx1   === End of Compilation 12 ===
** cscan   === End of Compilation 13 ===
** readwrite   === End of Compilation 14 ===
** readwrite2   === End of Compilation 15 ===
** log2   === End of Compilation 16 ===
** iglmin   === End of Compilation 17 ===
** ivlmax   === End of Compilation 18 ===
** iglmax   === End of Compilation 19 ===
** glmax   === End of Compilation 20 ===
** glmin   === End of Compilation 21 ===
** icopy   === End of Compilation 22 ===
** cmult2   === End of Compilation 23 ===
** copy   === End of Compilation 24 ===
** copy8   === End of Compilation 25 ===
** izero   === End of Compilation 26 ===
** cfill   === End of Compilation 27 ===
** rint   === End of Compilation 28 ===
** jjnt   === End of Compilation 29 ===
** ifill   === End of Compilation 30 ===
** icadd   === End of Compilation 31 ===
** cadd   === End of Compilation 32 ===
** cmult   === End of Compilation 33 ===
** chcopy   === End of Compilation 34 ===
** getfile2   === End of Compilation 35 ===
** isort   === End of Compilation 36 ===
** iswap_ip   === End of Compilation 37 ===
** iswapt_ip   === End of Compilation 38 ===
** sort   === End of Compilation 39 ===
** csr_sort_colj   === End of Compilation 40 ===
** out_csrmati   === End of Compilation 41 ===
** iranku   === End of Compilation 42 ===
** rec_bisect   === End of Compilation 43 ===
** fill_order   === End of Compilation 44 ===
** count_sep   === End of Compilation 45 ===
** bipart_sort   === End of Compilation 46 ===
** part_clean   === End of Compilation 47 ===
** ident_sep   === End of Compilation 48 ===
** outmatti   === End of Compilation 49 ===
** outmati   === End of Compilation 50 ===
** outmat   === End of Compilation 51 ===
** out_mapfile   === End of Compilation 52 ===
** dmp_mapfile   === End of Compilation 53 ===
** ituple_sort   === End of Compilation 54 ===
** tuple_sort   === End of Compilation 55 ===
** iftuple_ialtb   === End of Compilation 56 ===
** iftuple_altb   === End of Compilation 57 ===
** iftuple_ianeb   === End of Compilation 58 ===
** iftuple_iaeqb   === End of Compilation 59 ===
** tuple_swapt_ip   === End of Compilation 60 ===
** set_outflow   === End of Compilation 61 ===
** assign_order   === End of Compilation 62 ===
** periodic_vtx   === End of Compilation 63 ===
** find_connctd_pairs   === End of Compilation 64 ===
** out_order   === End of Compilation 65 ===
** out_a   === End of Compilation 66 ===
** set_a   === End of Compilation 67 ===
** outaij   === End of Compilation 68 ===
** ipush   === End of Compilation 69 ===
** ipop   === End of Compilation 70 ===
** is_connected   === End of Compilation 71 ===
** spec_bis   === End of Compilation 72 ===
** sbisect   === End of Compilation 73 ===
** glanczos   === End of Compilation 74 ===
** ax   === End of Compilation 75 ===
** ortho1   === End of Compilation 76 ===
** lanczos2   === End of Compilation 77 ===
** calcvec   === End of Compilation 78 ===
** ident   === End of Compilation 79 ===
** rzero   === End of Compilation 80 ===
** glsc2   === End of Compilation 81 ===
** add2s2   === End of Compilation 82 ===
** add2s1   === End of Compilation 83 ===
** reverse_p   === End of Compilation 84 ===
** unique_vertex2   === End of Compilation 85 ===
** out_geofile   === End of Compilation 86 ===
** self_chk   === End of Compilation 87 ===
** mult_chk   === End of Compilation 88 ===
** rd_bc_bin   === End of Compilation 89 ===
** buf_to_bc   === End of Compilation 90 ===
** buf_to_xyz   === End of Compilation 91 ===
** outcheck   === End of Compilation 92 ===
** open_bin_file   === End of Compilation 93 ===
** if_byte_swap_test   === End of Compilation 94 ===
** copyi4   === End of Compilation 95 ===
** copy4   === End of Compilation 96 ===
** copy4r   === End of Compilation 97 ===
** copy48r   === End of Compilation 98 ===
** indx132   === End of Compilation 99 ===
** cell2v   === End of Compilation 100 ===
** cell2v1   === End of Compilation 101 ===
** greedy   === End of Compilation 102 ===
** build_proc_el   === End of Compilation 103 ===
** indxi   === End of Compilation 104 ===
** c2c   === End of Compilation 105 ===
** c2cs   === End of Compilation 106 ===
** outbc   === End of Compilation 107 ===
** breadth_first_fill   === End of Compilation 108 ===
** cell_plot   === End of Compilation 109 ===
** spec_bis_conn   === End of Compilation 110 ===
** sort_count   === End of Compilation 111 ===
** assign_gllnid   === End of Compilation 112 ===
** maptest   === End of Compilation 113 ===
** outcell   === End of Compilation 114 ===
** face_chk   === End of Compilation 115 ===
** find_v2   === End of Compilation 116 ===
** fix_geom   === End of Compilation 117 ===
** mod1   === End of Compilation 118 ===
1501-510  Compilation successful for file genmap.f.
xlc -q64  -c  ../../core/byte.c
xlf -q64 -qrealsize=8 -o /home/u0017592/bin/genmap genmap.o byte.o
make[1]: Leaving directory `/home/u0017592/projects/Nek5000/tools/genmap'

----------------------
Make n2to3...
----------------------
make[1]: Entering directory `/home/u0017592/projects/Nek5000/tools/n2to3'
xlf -q64 -c   n2to3.f
** trans   === End of Compilation 1 ===
** rea23   === End of Compilation 2 ===
** rea2re2   === End of Compilation 3 ===
** re2_bc   === End of Compilation 4 ===
** re2_curve   === End of Compilation 5 ===
** re2_xyz   === End of Compilation 6 ===
** bufchk   === End of Compilation 7 ===
** blank   === End of Compilation 8 ===
** ltrunc   === End of Compilation 9 ===
** indx1   === End of Compilation 10 ===
** readwrite   === End of Compilation 11 ===
** glmax   === End of Compilation 12 ===
** glmin   === End of Compilation 13 ===
** addc   === End of Compilation 14 ===
** cmult   === End of Compilation 15 ===
** copy   === End of Compilation 16 ===
** icopy   === End of Compilation 17 ===
** chcopy   === End of Compilation 18 ===
** rzero   === End of Compilation 19 ===
** izero   === End of Compilation 20 ===
** rzero8   === End of Compilation 21 ===
** rdcurve   === End of Compilation 22 ===
** out_curve   === End of Compilation 23 ===
** mod1   === End of Compilation 24 ===
** sweep_circ   === End of Compilation 25 ===
** out_e_hdr   === End of Compilation 26 ===
** newcurve   === End of Compilation 27 ===
** outcurve   === End of Compilation 28 ===
** get_midside   === End of Compilation 29 ===
** capit   === End of Compilation 30 ===
** exitt   === End of Compilation 31 ===
** exitrr   === End of Compilation 32 ===
** rdparam   === End of Compilation 33 ===
1501-510  Compilation successful for file n2to3.f.
xlc -q64  -c  byte.c
xlf -q64   -o /home/u0017592/bin/n2to3 n2to3.o byte.o
make[1]: Leaving directory `/home/u0017592/projects/Nek5000/tools/n2to3'

----------------------
Make postnek...
----------------------
make[1]: Entering directory `/home/u0017592/projects/Nek5000/tools/postnek'
xlf -q64 -c    postnek.f
** fprep   === End of Compilation 1 ===
** plotit   === End of Compilation 2 ===
** readln   === End of Compilation 3 ===
** drmesh   === End of Compilation 4 ===
** readhs   === End of Compilation 5 ===
** comand   === End of Compilation 6 ===
** setatt   === End of Compilation 7 ===
** setres   === End of Compilation 8 ===
** setloc   === End of Compilation 9 ===
** getpt   === End of Compilation 10 ===
** draxis   === End of Compilation 11 ===
** show   === End of Compilation 12 ===
"postnek.f", line 1977.20: 1516-044 (S) A conversion from type INTEGER is not permitted.
** init   === End of Compilation 13 ===
** tem   === End of Compilation 14 ===
** fill_tx   === End of Compilation 15 ===
** colrbar   === End of Compilation 16 ===
** drfram   === End of Compilation 17 ===
** driso   === End of Compilation 18 ===
** plerr   === End of Compilation 19 ===
** drerr   === End of Compilation 20 ===
** mespos   === End of Compilation 21 ===
** vel   === End of Compilation 22 ===
** dspobj   === End of Compilation 23 ===
** findnam   === End of Compilation 24 ===
** relite   === End of Compilation 25 ===
** initstate   === End of Compilation 26 ===
** dmpstate   === End of Compilation 27 ===
** outstate   === End of Compilation 28 ===
** init0   === End of Compilation 29 ===
** post_reset_window   === End of Compilation 30 ===
** setloc_bdry   === End of Compilation 31 ===
** noncon_chk   === End of Compilation 32 ===
** temvel   === End of Compilation 33 ===
** exitt   === End of Compilation 34 ===
** get_subset_list   === End of Compilation 35 ===
** copy4b   === End of Compilation 36 ===
** copy8b   === End of Compilation 37 ===
** copyi   === End of Compilation 38 ===
** quickfill   === End of Compilation 39 ===
1501-511  Compilation failed for file postnek.f.
make[1]: *** [postnek.o] Error 1
make[1]: Leaving directory `/home/u0017592/projects/Nek5000/tools/postnek'
make: *** [all] Error 1

Seems like this is probably just a minor code problem that xlf is more strict with than gfortran.

Nek5000 typically uses a 3rd order time-stepper (BDF/EX3). To do a full restart, which avoids a drop in integration order, you'd expect to need 3 checkpoint frames. However, in Nek5000 you need 4. Why?

CC: @oanaoana

PrgEnv-cray expands the ftn wrapper to ftn_driver.exe ... This compiler is not supported in makenek.inc. I believe the right flags are:

  *ftn*)        P="-s default64 -eF"

This is needed for the new .par file workflow.

Hey all,

It seems that with the newest version of Nek5000 (September 5th) when running maketools, everything makes excluding postnek. That specific tool does not compile due to the following error:

It seems the "blas.f" file got moved to /Nek5000/core/3rd_party directory and the makefile was not updated. It compiles fine if a new /nek/3rd_party/ with the blas.f file is created. So if the makefile is fixed, I imagine this issue could be fixed rather quickly.

Lane

EDIT: Turns out it has already been fixed by issue #16, but isn't reflected on the master branch.

@smaithal made me aware of some difficulties using prex in Ubuntu and OS X. When you enter more than a few lines of text in the GUI, the prompt disappears below the bottom of the window, and resizing doesn't seem to help.

I've confirmed this on my MacBook. It's running OS X 10.9.5 and XQuartz 2.7.7. When prenek is compiled, it links to /opt//X11/lib/libX11.6. But this all might be tangential to the problems on @smaithal's version of Ubuntu.

I've got no clue where to start with this. Any takers?

Nek uses two parameters to control order of time integration NAB and NBD (in TSTEP). Max value of NBD can be set by parameter(27) (general:tOrder), however max value NAB is hard-coded to be 3. For optimal forcing we have to restrict time integration to Euler and we would like to be able to control both NAB and NBD. Simple solution would be to keep current behaviour for positive values of parameter(27) and to set both parameters to NBDINP for negative one. Is it OK?

#99

modify bcdirsc, faceis and cresvsp accordingly to have stress formulation working for Pn-Pn?

There are three routines "ping_loop" types in comm_mpi.f and the number of arguments is inconsistent for ping_loop1 and ping_loop2.
It gives compilation errors with Intel compiler.

The other question is argument list for ping_loop
subroutine ping_loop(t1,t0,len,nloop,nodea,nodeb,nid,x1,y1,x2,y2)
which is referenced
call ping_loop (t1,t0,len,nloop,nodea,nodeb,nid,x,y,x,y)
with x1=x2 and y1=y2. Is it intentional? It seems that fortran does not recommend this type of operations.

If the viscosity is spatially varying the coupled Helmholtz solver has to be used (IFSTRS=T) for PN/PN otherwise you'll get a wrong result. Currently this is not checked by the code. We may want to add a check or set IFSTRS=T by default.

Traditionally, Nek's parallel test cases have been run with 4 MPI ranks. However, each Travis virtual environment only provides a maximum of 2 cores (reference). This likely contributes to the considerable slowdown of Nek's parallel test cases in Travis.

As @stgeke suggested, we could probably improve turnaround time of the Travis tests by running the Nek tests with only 2 MPI ranks.

To do so, we must:

• Allow the user to set MPI ranks in NekExamples/NekTests.py (see Nek5000/NekExamples#15)
• Update .travis.yml to use 2 MPI ranks

Causes wrong initialisation of IEDGEF and overwriting part of ICEDG by setedge

Would you consider prefacing makenek with set -e and set -o pipefail?

The problems are these lines at the end:

make -j4 -f makefile 2>&1 | tee compiler.out
exit 0

This always returns 0, even if makenek fails. It's not very convenient if you're running makenek as part of a larger build script, since it doesn't trap any errors in makenek.

Using set -e exits on all errors. Using set -o pipefail will trap any errors in make from in make -j4 -f makefile 2>&1 | tee compiler.out; without it, it will only trap errors from the last command in the pipe, which is tee.

If you don't want to trap all errors in makenek, then a more conservative option would be to use set -o pipefail and change the ending to:

make -j4 -f makefile 2>&1 | tee compiler.out
exit $?

Is there a particular reason for removing it from the makenek script in both develop and v16 branch?
It exists however in makenek.inc which seems inconsistent...
Do these branches have plugin support or not?

Robust but slow.

Since ntot2 in dofcnt is implicitly declared as an integer*4, the call to i8glsum can/will (depending on arch.) cause a bus error (the argument is expected to be of type integer*8). See backtrace (from a non x86) below,

Process 296370 (nek5000) stopped on signal SIGBUS: Bus error (default) at [i8glsum:1249 ,0x100e9140]
1249  tsum=tsum+a(i)
(dbx) where
>  0 i8glsum(A = (...), N = <illegal>) [".../nek5000/core/math.f":1249, 0x100e9140]
   1 dofcnt() [".../nek5000/core/drive2.f":1578, 0x10030624]
   2 nek_init(intracomm = <illegal>) [".../nek5000/core/drive1.f":152, 0x10027f78]
   3 NEKTON() [".../nek5000/core/drive.f":26, 0x10027b58]

In the user manual,

it states that the udiff is the term for density (or rho*cp, etc) and utrans is the term for viscosity (visc, thermal conductivity, etc). This is counter to what has been stated in this nek5000 user post: http://lists.mcs.anl.gov/pipermail/nek5000-users/2014-December/003146.html

"utrans and udiff are the transport and diffusion coefficients, respectively, in a particular advection-diffusion equation. " Which implies the udiff and utrans are flipped in the user manual.

Can this be clarified?

To fix this, we need to explicitly declare all variables used in all INCLUDE files.

I suggest to add a SIZE.usr (this file will live in user space). SIZE (static file in the source) contains whatever we want to hide from the user (e.g. variable declarations or other internals). SIZE will include SIZE.usr. This is the cleanest solution I can think of and it improves the user experience (SIZE is less messy).

No code changes are required. However, the user needs to use the new SIZE.usr template (distributed with the source). I never liked the makenek magic to tweak old SIZE files.

Overall I do not think this is a big deal as we do something similar with makenek.

We had a similar discussion at the user meeting.
@fischer1 @pschlatt1 What are your thoughts on that?

It is continuation of discussion abut user space in the new runtime parameters scheme we had at user meeting. Right now there are a number of "userparam" in "general" section, but for toolboxes it would be good to have separate user sections as well. With Stefan we've concluded that it would be enough to modify slightly parameter check, so sections starting with 'U' would be skipped, and keeping dictionary available for user during whole simulation (moving finiparser_free to nek_end).

Right now, all the Travis tests are compiled and run with MPI. That is, they are compiled with mpif77/mpicc and run with mpiexec. For the serial tests, we simply run with mpiexec -np 1.

In Nek5000/NekExamples#15, @stgeke suggested that we compile/run serial tests without MPI.

Just created the following wiki article
https://github.com/Nek5000/Nek5000/wiki/GitHub-workflow-and-branching-conventions

My main motivation was to summarize the basic concepts so that a newbie (like me) knows what to do. I am happy to discuss the suggested workflow and conventions.

I downloaded the nek5000 with svn, when I compile the tools with
./maketools all

it has an error that

Make exo2nek...

make[1]: Entering directory `/work/Nek5000-master/svn/nek5000/tools/exo2nek'
gfortran -mcmodel=medium -c -fdefault-real-8 exo2nek.f
exo2nek.f:42: Error: Can't open included file 'exodusII.inc'
make[1]: *** [exo2nek.o] Error 1

could anyone tell me how to fix thie problem?

Then I tried to downlad the nek with git, when I compile the tools, it has an error that

Make postnek...

make[1]: Entering directory `/work/Nek5000-master/nek/tools/postnek'
gfortran -mcmodel=medium -c ../../nek/3rd_party/blas.f
gfortran: error: ../../nek/3rd_party/blas.f: No such file or directory
gfortran: fatal error: no input files
compilation terminated.
make[1]: *** [blas.o] Error 4

Although I make a dir of nek/3rd_party, it did not work.

Any suggestion? I will appreciate it very much.

It would be very useful if makenek honored the following environment variables:

• F77
• FFLAGS
• CC
• CFLAGS
• CPPFLAGS
  makenek.inc could append the user's FFLAGS to whatever other flags it requires. This is the default behavior for an autotools-derived build system, and I've seen many simple makefiles that do that as well.

It's a clean way for the users to customize their builds without manually editing makefiles.

It would be great if we could increase the character limit for strings.

Right now, the limit for many strings is 132 characters. I've often exceeded this limit when using absolute pathnames in the SESSION.FILE.

Is there any reason this limit can't be increased?

On newer crays, the compiler vendor (e.g. intel, gfortran, pgi) is selected via the module programming environment. The fortran compiler is always invoked with ftn, so the case $F77comp in line in makenek.inc is unable to detect the compiler vendor and often offers incorrect flags.

I don't know if there is a standard way for figuring out which backend is in use. Maybe module list with some parsing logic? I'd vote for having the option to explicitly define the compiler type in makenek, e.g.:

F77="ftn"
vendor="intel"

CC: @RonRahaman

replacing NOTIMER in math.f

@ananiast should we append mean pressure to end of field file ...

Many of the run scripts have mv commands to back-up output files, e.g. nekmpi:6:

mv $1.log.$2 $1.log1.$2

When the output files aren't already present, these produce error messages that aren't actually errors. This is confusing to users. We should wrap those moves in if statements conditional on the existence of the file that is being moved.

The logfile provides us with a large amount of useful information but isn't aligned to make it easier to read. I've previously discussed this with @dshaver-ANL and @maxhutch and it seems like it should be a reasonable "improvement" to the code. Further, utilizing @dshaver-ANL's help the following fortran files which specific lines called out are below:

hmholtz.f - line 829-832 - Format Statements
gmres.f - line 522-525 - Format Statements
subs1.f - line 166-171 - Format Statements

Specially, can the output be aligned vertically to the "iteration number"?

Do we wish to include the high-pass filter routines within V16 release?
@fischer1 ?

/Prabal

There is a genmap issue -- fix suggested by Scicong/Elia -- that is required
for millions of elements when using periodicity.

The pressure solve with PN/PN-2 is 1.5x faster e.g. for turbChannel. Same applies for other cases. It looks you'll get less pressure iterations with PN/PN-2 compared to PN/PN. Not sure why - I guess the implementation of preconditioned is somehow different. Something we need to look at.

If a user morphs geometry in usrdat2 and does not set p59 > 0 they will not
get the right answer.

On some machines the ioinfo file is ignored. Not sure why. Digging into it.

Currently we do not comply with the MPI standard (maximum tag value < 32768) as we tag messages with nid.

Add capability to have inhomogeneous stress conditions (i.e. setting the "ambient pressure" pa) also for no-stress PnPn-2. This essentially means to make sure that "o" works fine. Question: Should this be done for R16?

The bash scripts are very simple (good) but also very picky and not self-documenting (bad). It would be nice to have a more generic run script with real argument parsing and a help message.

@RonRahaman do you have anything in mind?

I have added a new feature to prenek which allows the user to generate 2D circular-cartesian meshes (kind of hole in a box or meshes for annulus). Attached is an example script that makes the mesh for hole in the box (the files are renamed with txt so that they could be uploaded here.. please rename one2d.txt to one2d.rea and example.txt to example and then run example in terminal).

Reference pull request: #102

example.txt
one2d.txt

We planned on moving the tests that don't have large input files into short_tests. This strikes a balance between including some tests and examples with the code while also keeping checkout lightweight. Here's a list of some short tests. In most cases, the mesh information needs to be stripped from the rea file and the map file removed.

• eddy
• benard

Currently, there are no regression tests for the tools (prenek, postnek, genmap, genbox, etc). As @stgeke suggested, we should consider adding some.

extend the current linear adjoint for velocity with the respective terms in the temperature equation (with Boussinesq approximation). Question: Should we contribute that already for R16?