Opened 2 years ago

Closed 2 years ago

#171 closed Defect (duplicate)

Segmentation Fault Flexpart WRF 3.3

Reported by: fcarotenuto Owned by: pesei
Priority: minor Milestone:
Component: FP coding/compilation Version: FLEXPART-WRF
Keywords: segmentation fault Cc:


Dear all,

I'm trying to run flexpart-wrf-3.3 on Ubuntu Budgie 17.04 (gfortran) but every time I try running it, it crashes with "Segmentation fault".

  • Error happens both with serial and omp
  • Using netcdf 4
  • Stack-size unlimited with ulimit -s unlimited and confirmed by running ulimit -S -a
  • No errors during compilation, only two warnings:

gfortran -c -I/usr/local/include -O3 -m64 -mcmodel=medium -fconvert=little-endian -finit-local-zero -fno-range-check -DNETCDF4_OUTPUT random.f90

1 v1=2.*ran3(idum)-1.


Warning: Missing actual argument for argument ‘inext’ at (1)



Warning: Missing actual argument for argument ‘inext’ at (1)

  • Program is being compiled and run into a VM at the moment (my main workstation is locked into a WRF job)

Thanks for the support!

Change History (6)

comment:1 Changed 2 years ago by pesei

  • Component changed from FP other to FP coding/compilation
  • Owner set to pesei
  • Priority changed from major to minor
  • Status changed from new to accepted

This is very similar to #169, please read this ticket (if you haven't done so yet). And please use appropriate syntax for quoting code (also explained in this ticket, or under the WikiFormatting link which will appear just above any editing window.

comment:2 Changed 2 years ago by fcarotenuto

The problem was apparently the virtualization: as soon as I could test flexpart wrf on the actual workstation there were no segmentation faults.

The model halts at line 236 of of readinput.f90 with the message At line 236 of file readinput.f90 (unit =1, file= 'flexwrf.input) Fortran runtime error: Bad integer for item 1 in list input, but it does after starting the read inputs routine.

I still have to figure out this error, since line 236 is about the verbosity of the model (read(unitcommand,*) option_verbose), but there's no segmentation fault anymore.

Thanks for the support.

comment:3 Changed 2 years ago by adingwell

This suggests that flexwrf.input is missing a line.
Does your flexwrf.input have a line with LU_OPTION (between the TURB_OPTION and CBL_SCHEME)?

The default file in v3.3 should have it but it was found out from ticket #156 that the supplied example files were missing that option. Updated example files are included in v3.3.1.

comment:4 follow-up: Changed 2 years ago by fcarotenuto

Thanks, that's exactly the case: I found it by running gdb and printing each variable in turn, since ldirect returned as 20100518 I guessed there was a missing line. I recompiled flexpartwrf3.3.1 and now the simulation starts to run!

It complains that No (or incomplete) flux data contained in WRF output file (which should happen in readwind_nests) then crashes due to calcpar - richardson failure - ix,jy= 82 148. The crash happens when processing the second wrf file (wrfout_d02_2010-05-18_03)

I did download the WRF files from (row 33 "Wrfdata.gz"), are those the correct data to run the example simulation flexwrf.input.forward1 contained in examples?

Last edited 2 years ago by fcarotenuto (previous) (diff)

comment:5 Changed 2 years ago by anphi

I had the exact same error with different data! In my case, the problem could be solved by changing the starting point of simulation. The reason was, that the windfields were mean wind fields and the first time steps are used for initialization. Therefore, they don't have reasonable results. This led to incorrect height calculations in the richardson.f90 routine.

comment:6 in reply to: ↑ 4 Changed 2 years ago by pesei

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

I think the main topic of this ticket is solved by #156. Thus I'll close the ticket as duplicate.

The Warning about flux data is just a warning. FLEXPART does not need flux data to be included in the WRF data.

If there is a crash in richardson.f90, this is possibly caused by using time-integrated output in WRF and starting the FLEXPART simulation so that the first WRF output is ingested. Obviously, time-integrated winds can't be defined in this first output. This is currently not checked and caught in FLEXPART-WRF. If users have trouble with this issue, it would be useful to open another ticket.

Note: See TracTickets for help on using tickets.
hosted by ZAMG