Opened 11 years ago
Closed 11 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)
Change History (26)
Changed 11 years ago by wintermute
comment:1 Changed 11 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 11 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 11 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 11 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 11 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 11 years ago by wintermute
comment:6 Changed 11 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 11 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 11 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 11 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
comment:10 Changed 11 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 11 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 11 years ago by wintermute
comment:12 Changed 11 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 11 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 11 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 11 years ago by pesei
- Component changed from FP coding/compilation to FP post-processing
comment:16 Changed 11 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 11 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 11 years ago by jbrioude
- Resolution set to fixed
- Status changed from accepted to closed
Input file