Opened 8 years ago

Closed 8 years ago

#915 closed help (fixed)

Compiling fortran on MONSOON

Reported by: ledm Owned by: ros
Component: MONSooN Keywords: NEMO
Cc: Platform:
UM Version:



I'm currently attempting to compile Nemo 3.2 coupled with ERSEM on Monsoon.

I'm getting a fortran compilation error, where the intrinsic fortran functions MAX, SIGN and others complain that they are receiving arguments of the wrong type.

In most cases, these intrinsic procedures look similar to this in our code:
real*8 :: Y,W, ALK

It appears that the compiler refuses to perform intrinsic procedures on in-line operations. Is this the case? The code being compiled here is legacy code, and has not changed in the last 10 years.

The relevant compiler line here is:
mpxlf90_r -o gas_dynamics.o -I/projects/imarnet/ldmora/UM/xhonc/nemo_cice/inc -qrealsize=8 -qextname -qsuffix=f=f90 -qarch=pwr6 -qtune=pwr6 -NS32768 -g -O3 -qstri
ct -I/projects/um1/lib/netcdf-3.6.0-p1_ec/LP64_underscore/include -c /projects/imarnet/ldmora/UM/xhonc/nemo_cice/ppsrc/nemo/TOP_SRC/ERSEM/ERSEM/gas_dynamics.f90

Change History (12)

comment:1 Changed 8 years ago by ros

  • Keywords NEMO added
  • Owner changed from um_support to ros
  • Status changed from new to accepted
  • UM Version <select version> deleted

Hi Lee,

Did this job ever work on MONSooN Phase1?

Different compilers can be fussy about how variables are declared. Some compilers don't like it if you use the real8 compile time flag (on the ibm -qrealsize=8) and then in the code you use the 0.0d0 declarations. I think you need to experiment with taking off the -qrealsize=8 flag on the affected files and/or modifying how the arguments are declared in the code to find a combination that works.

Hope this helps.


comment:2 Changed 8 years ago by ledm

Hi Ros,

This job is a new process and it never ran in phase1.

I've removed the -qrealsize=8 switch, and have started changing 0.0d0 declarations. However, the bulk of the code is not mine to change, and has not caused any trouble on other machines, such as our local cluster or HECToR.

I'm experimenting with compile flags at the minute, looking at

Are there any particular flags you would suggest trying?


comment:3 Changed 8 years ago by ledm

Hi Ros,

after changing a selection of compile flags, I've discovered that the NEMO code underneath the biogeochemical model requires the -qrealsize=8 flag to compile, so removing it is not an option.


comment:4 Changed 8 years ago by ros

Hi Lee,

Sorry I didn't mean remove the global -qrealsize=8, just to remove it on the files that aren't compiling properly. If you need help on how to do that then I can investigate how to do this for ERSEM/NEMO.

My guess is that you will have to change the code to fix the 0.0d0 declarations. From what you say it doesn't sound like the code has ever been compiled on an IBM - am I right? As I said different compilers behave in different ways and some are fussier than others. It is possible that code that has been around for years may need to be modified to be made more portable.


comment:5 Changed 8 years ago by ledm


Fixing 0.0d0 isn't solving the problems. Even when all the variables going into a min/max command are cast as real(*,8), it still fails to compile. If we could compile the ERSEM folders without -qrealsize=8 and compile the NEMO folders with -qrealsize=8, it may solve this problem. But is it possible?

Secondly, this UMUI/FCM setup makes the most recently changed file compile slower than the others. So each time a change to a file is made, it appears to fix the file, but only because something else breaks first.

comment:6 Changed 8 years ago by ros

Hi Lee,

To change the compile options on a specific directory or an individual file you need to add lines of the following form to your nemo_IBM_3.2_base_ersem.cfg file.

# Override options for the ERSEM directory
bld::tool::fflags::nemo::TOP_SRC::ERSEM  -qextname -qsuffix=f=f90.......

# Override options for a specific file for example: set_initial_conditions.F90
bld::tool::fflags::nemo::TOP_SRC::ERSEM::ERSEM::set_initial_conditions -options

I'm sorry, but I don't understand your second comment. When you change a file all files that are unchanged and successfully compiled on the previous attempt are skipped and it should continue to compile anything remaining. You should see in the output file for each successfully compiled file "Compilation successful for ….". So are you seeing a line like this for the changed file and then it falls over on a subsequent one?


comment:7 Changed 8 years ago by ledm

Hi Ros,

thanks for your help so far, I've successfully compiled NemoErsem? on Monsoon, and now I've reached the point where it starts to run and we even produce an ocean.output file!

It's not quite champagne time yet though. I'm trying to include all the namelists files (.nml) required for ERSEM. I've been putting them in the

→Model Selection


→Scientific Parameters and Sections

→Links to Nemo Model.

In this menu, there appears to be 25 spaces available for symbolic links, of which 22 are already taken.
However, Ersem uses at least 16 .nml files. Is there a way to extend the number of spaces in the UMUI? or maybe you know of a better solution?

Thanks, Lee

comment:8 Changed 8 years ago by ros

Hi Lee,

I can look at modifying the UMUI to extend the number of spaces available but obviously would need to test this out and check for any implications before making it "live".

In the meantime/before I look at making any changes to the UMUI can you please test out that adding the namelist files in this way does actually work. You can do this by creating a hand-edit to the umui_jobs/xhonc/SCRIPT file. I'm guessing you probably haven't used hand-edits before so to do this you need to create a file (eg. called add_ersem_nmls.ed) on PUMA using the following as a template:

/typeset -Z4 i=0/
ln -s -f /projects/imarnet/ldmora/ERSEMCONFIG/NemoErsem.nml \$DATAM/NemoErsem.nml
ln -s -f \$ERSEM_NML/ini_sv_conds.nml \$DATAM/initial_svn_conditions.nml
# Add rest of the namelist files in a similar format here


This script simply inserts your namelist symbolic link lines before the line 'typeset -Z4 i=0' in file SCRIPT. Make sure the file has execute permissions.

In the UMUI go to panel Input/Output? control and resources → User hand-edit file and enter the path to your hand-edit file and put a "Y" in the last column. Process your job and confirm that the lines have indeed be added to the umui_jobs/xhonc/SCRIPT file. Then submit your job in the usual way.

Let me know how you get on and I'll take a look at extending the UMUI table.


comment:9 Changed 8 years ago by ledm

Hi Ros,

Adding files to that list does work. It creates a symbolic link to the relevant file in the run directory and they are picked up by nemoersem at run time.

However, the hand edit is a much more powerful solution. Thanks!


comment:10 Changed 8 years ago by ledm

Hi Ros,

Still struggling with intrinsic functions, but this time it's "isnan". I'm getting the error: Entity isnan has undefined type.

I thought that isnan was an intrinsic function and should be available for debugging in IBM XL?

Thanks for all your help,


comment:11 Changed 8 years ago by ledm

Found a solution to that problem: use ieee_is_nan() instead of isnan().


comment:12 Changed 8 years ago by ros

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

This query is now being closed as there has been no further activity for 2 weeks.

Note: See TracTickets for help on using tickets.