Opened 6 years ago

Closed 5 years ago

Last modified 3 years ago

#1395 closed Defect (fixed)

AGRIF compilation

Reported by: timgraham Owned by: timgraham
Priority: low Milestone:
Component: OCE Version: release-3.6
Severity: Keywords: AGRIF SETTE


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 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.y, fortran.yy.c)

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

Commit History (2)


Changed function definition in stopar.F90 to avoid problem with AGRIF (see #1395)


Changed function definition in stopar.F90 to prevent problem with AGRIF (see #1395).

Change History (11)

comment:1 Changed 5 years ago by 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?

comment:2 Changed 5 years ago by rblod

Problem is the declaration

REAL(wp) FUNCTION sto_par_flt_fac( kpasses )


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

is ok for me

comment:3 Changed 5 years ago by jchanut

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

comment:4 Changed 5 years ago by bouttier

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

comment:5 Changed 5 years ago by timgraham

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

comment:6 Changed 5 years ago by timgraham

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

comment:7 Changed 5 years ago by timgraham

  • Resolution set to fixed
  • Status changed from new to closed

This was merged with the AGRIF branch

comment:8 Changed 4 years ago by nicolasmartin

  • Keywords SETTE added; sette removed

comment:9 Changed 4 years ago by nicolasmartin

  • Keywords nemo_v3_6* added

comment:10 Changed 3 years ago by nemo

  • Keywords release-3.6* added; nemo_v3_6* removed

comment:11 Changed 3 years ago by nemo

  • Keywords release-3.6* removed
Note: See TracTickets for help on using tickets.