Opened 6 years ago

Closed 6 years ago

#14 closed Support (fixed)

runtime errors linked to compile-time options

Reported by: wintermute Owned by: jbrioude
Priority: major Milestone:
Component: FP coding/compilation Version: FLEXPART-WRF
Keywords: Cc:

Description

Kind Flexpart team,

I'm trying to run a Flexpart-WRF (version 3) simulation but I encounter code-related runtime errors. I'm compiling flexpart using a PGI compiler:

  • if I compile with openmp, the program compiles with no error, but at runtime it returns only a "segmentation fault (core dumped)" error (even at verbosity 100)
  • if I streamline compilation reducing the needs of external libraries with a "serial" compilation, the program compiles with no error but at runtime it returns "PGFIO-F-235/formatted write/unit=6/ edit descriptor does not match item type. File name=stdout formatted, sequential access record=7 In source file_read_ncwrfout.f90 at line number 781".

May it be linked with the wrf netcdf extension? My wrf netcdf files are written with no final .nc in filename (see attached input and available files).

Attachments (8)

flexwrf.input.testfw1 (7.9 KB) - added by wintermute 6 years ago.
Input file
AVAILABLE2 (1.6 KB) - added by wintermute 6 years ago.
Available file
run.log (8.2 KB) - added by wintermute 6 years ago.
newrun.log (8.2 KB) - added by wintermute 6 years ago.
log of run with version 2 of gridcheck and read_nc
flexwrf.input.reference (6.3 KB) - added by wintermute 6 years ago.
input file using reference WRF files
makefile.mom (6.7 KB) - added by wintermute 6 years ago.
read_ncwrfout.f90 (31.4 KB) - added by jbrioude 6 years ago.
read_ncwrf version 3
gridcheck.f90 (22.6 KB) - added by jbrioude 6 years ago.
gridcheck version 3

Download all attachments as: .zip

Change History (26)

Changed 6 years ago by wintermute

Input file

Changed 6 years ago by wintermute

Available file

comment:1 Changed 6 years ago by wintermute

I've tested the program in serial mode using also the test cases and the error is still present.

Since line 781 is a I/O line (a write statement) and the error refers to the file name "stdout" is it possible that flexpart passes a stdout() as fnamenc (or a stdout() inside that kind of write statement)?

In that case the break is explained as the PGI Software compilers consider this a break of the Fortran standard and therefore does not support those kind of statements...

comment:2 Changed 6 years ago by jbrioude

  • Owner changed from somebody to jbrioude
  • Status changed from new to accepted

Hi,

The name format of your WRF output files shouldn't be a problem.
Which version of pgi do you use?

I have attached a new version of read_ncwrfout.f90. I have changed the way fnamenc is declared. Can you copy that to your flexpart directory, compile and use the new binary?

When you run flexpart, do you get any output message from it or does it crash right away?

Thanks
Jerome

comment:3 Changed 6 years ago by wintermute

Hi,

thanks for your reply! Unfortunately this evening I won't have access to the workstation running flexpart.

When I run it flexpart says "using <inputfile name> as input", then an iee inexact signalling error which closes with the PGFIO error I've already metioned.

As soon as I can reach the workstation I'll replicate the error with maximum verbosity to post the results here, and then test the new ncwrfout.

Thanks!

comment:4 Changed 6 years ago by jbrioude

Good.
Based on your input file, you should also see this message before it crashes:

----------------

INFORMATION: SUBGRIDSCALE TERRAIN EFFECT IS
NOT PARAMETERIZED DURING THIS SIMULATION.

----------------

For the moment, I see two reasons: the problem is either fnamenc (as you suggested), or the netcdf library is not compiled with the same compiler.
I have attached a modified gridcheck.f90 that will give a lot of information on the netcdf file it tries to read. Please copy that to your directory as well, and let me know what you get as message output when you'll run.

J.

comment:5 Changed 6 years ago by wintermute

I've replicated the error (with all the original .f90 files) and I confirm you that before the PGFIO output flexpart displays the message about subgridscale terrain effect.

Unfortunately I've still been unable to try with the new .f90 file: if I try serial compilation the compiler quits for "too much syntax errors" in gridcheck.f90 (line from 1 to 33 then exits). Probably it's just a free-form/fixed-form issue of PGI (already happened) I will check gridcheck.f90 and let you know as soon as possible!

Changed 6 years ago by wintermute

comment:6 Changed 6 years ago by wintermute

I realized that the message I thought I sent, was not actually sent. The file run.log is the output of the flexpart software after the introduction of the new files you kindly attached (the syntax error was quickly corrected: it was only a download error).

I also want to add that by commenting out line 784 and 785 from read_ncwrfout (the I/O write statement in the if loop) the error disappears.

The program can't still complete correctly (* checkgrid -- error in doing ncread of XLAT), but the previous error is no more.

comment:7 Changed 6 years ago by wintermute

Last update: I'm investigating on the ncread error and I found that in the flexpart wrf-data xlong and xlat seem to be 3D matrixes, while I would expect 2D m*n matrixes (where m and n are the unstaggered xlong/xlat length). Can this be a problem?

comment:8 Changed 6 years ago by jbrioude

xlat and xlong should be 3D. the third dimension is time. xlat and xlong might vary over time in WRF (if you move a nested domain for instance).

I have attached a new gridcheck.f90 and read_ncwrfout.f90. Can you try those and send the log file?

Can you tell me the version of the pgi compiler you use, and the compiling options you used in makefile.mom?

Thanks

comment:9 Changed 6 years ago by wintermute

I've tested the new files and attached the new log: again the PGI compiler complains about the stdout format error.

To minimize the effect of possible irregularities of my WRF file I'm using the Flexpart example WRF files for the simulation (see attached flexwrf.input.reference), but it still outputs the aforementioned format error

The version of my PGI compiler is 13.4

Changed 6 years ago by wintermute

log of run with version 2 of gridcheck and read_nc

Changed 6 years ago by wintermute

input file using reference WRF files

comment:10 Changed 6 years ago by jbrioude

Ok. It seems that it cannot read matrices from the netcdf file.
Can you tell me the compilation option you used, and can you confirm me that the netcdf library you use has been compiled by the same compiler you use?

Thanks

comment:11 Changed 6 years ago by wintermute

I can confirm you that the netcdf were compiled with the same compiler I'm using for flexpart.

The options used are the default pgi options in makefile.mom (I provide the file in attachment for further details):

PGI_FFLAGS = -fastsse -mcmodel=medium
PGI_LDFLAGS = -fastsse -mcmodel=medium -lnetcdf

Changed 6 years ago by wintermute

Changed 6 years ago by jbrioude

read_ncwrf version 3

Changed 6 years ago by jbrioude

gridcheck version 3

comment:12 Changed 6 years ago by jbrioude

Can you try the gridcheck and read_ncwrf version 3 I have uploaded?

Please compile flexpart with the following options:
PGI_FFLAGS = -fastsse -mcmodel=medium -traceback -Mbounds -Mchkfpstk -Mchkptr -Mchkstk
PGI_LDFLAGS = -fastsse -mcmodel=medium -traceback -Mbounds -Mchkfpstk -Mchkptr -Mchkstk -lnetcdf

do a clean before compiling in serial:
make -f makefile.mom clean
make -f makefile.mom serial

if you have the program gdb installed, do the following
cp flexwrf.input.reference flexwrf.input
gdb ./flexwrf30_pgi_serial
and then type
run

Let me know what gdb says when flexpart crashes.

comment:13 Changed 6 years ago by wintermute

Sorry if I reply that late, I had a problem with gdb that took me a while to solve.

Gdb reports the same error as running flexpart directly:

FLEXPART WARNING: NO WIND FIELDS ARE AVAILABLE.
A TRAJECTORY HAS TO BE TERMINATED.

Warning: ieee_inexact is signaling
NO METEO FIELDS AVAILABLE
[Inferior 1 (process 5619) exited normally]

From my experience with the previous flexpart release this happened when the program could not find the data files: did I messed up the path to the wrf files in the flexpart input file?

comment:14 Changed 6 years ago by jbrioude

by doing this
gdb ./flexwrf30_pgi_serial
flexwrf30 will try to read the default input file in the current directory, flexwrf.input
make sure that you have changed the name of the input file (flexwrf.input.reference) accordingly before running gdb.

comment:15 Changed 6 years ago by pesei

  • Component changed from FP coding/compilation to FP post-processing

comment:16 Changed 6 years ago by jbrioude

  • Component changed from FP post-processing to FP coding/compilation

pesei,
This is a coding/compilation problem here. There is no post-processing here, the model is not even working.

comment:17 Changed 6 years ago by wintermute

I'm sorry for the late answer: I had some technical issues that prevented me from working on flexpart.

I've checked again the flexwrf.input.reference and adjusted the timing of the simulation and release start/end to match the available file and the model is now running in serial mode.

Thanks for all the assistance!

comment:18 Changed 6 years ago by jbrioude

  • Resolution set to fixed
  • Status changed from accepted to closed
Note: See TracTickets for help on using tickets.
hosted by ZAMG