AGRIF compilation

[timgraham]

Currently AGRIF compilation does not work correctly on all systems (in particular systems that don't use the cc compiler) without making modifications at run time.

The following list of changes should enable the AGRIF demonstrator to be compiled correctly on all systems (although it will require project officers to modify the cc compiler and C flags for their systems).

List of changes:
1) Add C compiler and flags to ARCH files
2) Modify Fprep_agrif.sh to compile conv using FCM build (instead of gmake)
3) Modify TOOLS/COMPILE/conv.cfg to pick up the C compiler and flags from the ARCH file and comment out the following lines as they cause it to fail and don’t seem to be needed anyway:
#bld::tool::cflags::convsrc -O0
#bld::tool::ld::convsrc cc
#bld::tool::ldflags::convsrc -O ../obj/fortran.o ../obj/fortran.o
#bld::pp 1
4) Remove unused files from the AGRIF/LIB directory as FCM build tries to compile these and they fail (Makefile.lex, convert.lex, fortran.lex, fortran.tab.c, fortran.y, fortran.yy.c)

If no one has any objections I will commit these changes this week.

[timgraham]

This seems to be a problem in conv. After conv preprocessing the top of the sto_par_flt_fac function is

   REAL(wp) FUNCTION sto_par_flt_fac( kpasses )
      !!----------------------------------------------------------------------
      !!                  ***  FUNCTION sto_par_flt_fac  ***
      !!
      !! ** Purpose :   compute factor to restore standard deviation
      !!                as a function of the number of passes
      !!                of the Laplacian filter
      !!----------------------------------------------------------------------
      INTEGER(wp), INTENT(in) :: kpasses

but in the source code kpasses is defined as

      INTEGER(wp), INTENT(in) :: kpasses

I've tested this by manually deleting the (wp) after the preprocessing and then recompiling and compilation it then compiles successfully (although it crashes on the first time step).

Any ideas how to stop conv adding in the (wp)? Perhaps this is similar to the eos_fzp problem that required a subroutine instead of a function?

[rblod]

Problem is the declaration

REAL(wp) FUNCTION sto_par_flt_fac( kpasses )

Writing

FUNCTION sto_par_flt_fac( kpasses )
REAL(wp) :: sto_par_flt_fac

is ok for me

[jchanut]

Thanks Rachid. Just to confirm the same issue here, except that ifort went through this !

[bouttier]

Yes, with ifort, I don't see that problem. Thanks Rachid.

[timgraham]

Thanks Rachid. I'm testing this now. Assuming it works I'll commit this fix to the trunk and 3.6 stable branch.

[timgraham]

Apologies - at some point I've confused this ticket with #1571. I've summarised the changes on there and closed that ticket.

[timgraham]

This was merged with the AGRIF branch