Fortran runtime error on ideal.exe

[gsever]

Hello,

Just testing the WRFv4.0 binaries (serial) on my Windows 10. It seems like the ideal simulations cannot be started due to an error in ideal.exe.

\wrf-cmake-4.0-serial-basic-release-windows\test\em_hill2d_x
also same error in em_les

$ ..\..\main\ideal.exe
 Ntasks in X            1 , ntasks in Y            1
IDEAL V4.0 PREPROCESSOR
 *************************************
 Parent domain
 ids,ide,jds,jde            1         202           1           3
 ims,ime,jms,jme           -4         207          -4           8
 ips,ipe,jps,jpe            1         202           1           3
 *************************************
DYNAMICS OPTION: Eulerian Mass Coordinate
   alloc_space_field: domain            1 ,              65282320  bytes allocated
  pi is    3.14159274
At line 19288 of file C:/projects/releases/WRF/build/inc/nl_config.inc
Fortran runtime error: Actual string length is shorter than the declared one for dummy argument 'mminlu' (4/256)

Error termination. Backtrace:

Could not print backtrace: libbacktrace could not find executable to open
#0  0xffffffff
...

Could you take a look at this problem? real.exe and wrf.exe are running just fine.

Thanks for your efforts.

[letmaik]

Good catch. We actually did test ideal.exe, but then we enabled additional runtime checks to catch more user errors in real/wrf (which otherwise sometimes just lead to crashes instead of proper error messages), but we didn't test ideal.exe again apparently. What you found is obviously not a user error but actually a bug in WRF's code. I reported the issue here: wrf-model#631. We'll see if we can apply a quick work-around without having to wait for a proper fix from the WRF developers.

Note that we have automated testing for real cases, but not yet for ideal cases. We'll add these as well so that we detect any future problems immediately without relying on manual testing. The reason we only test real cases currently is that this is what we need for our QGIS plugin GIS4WRF.

[gsever]

Thanks for the update and good to see this is not a Windows specific error :)

[letmaik]

The underlying issue is still in progress to be fixed, but we released new binaries, now in debug and release variants. The release variant has all performance optimizations enabled and runtime checks disabled, whereas the debug variant does the opposite (useful during case setup, as it is slower but includes more checks). This means you can now at least run the ideal cases with the release variant. In the debug variant they will still fail until the issue is fixed upstream.

[gsever]

Both ideal.exe and wrf.exe works fine testing via "wrf-cmake-4.0-dmpar-basic-release-windows" bundle.

Perhaps spoke a bit too quick for the wrf.exe component. Here (Windows 10) integration is fine, yet the model doesn't create any output.

Testing in wrf-cmake-4.0-dmpar-basic-release-windows/test/em_hill2d_x
#edited namelist.input e_sn =10, then ran a 1-min dummy case.

Timing for main: time 0001-01-01_00:00:20 on domain   1:    0.06903 elapsed seconds
Timing for main: time 0001-01-01_00:00:40 on domain   1:    0.06503 elapsed seconds
Timing for main: time 0001-01-01_00:01:00 on domain   1:    0.03482 elapsed seconds
Timing for Writing wrfout_d01_0001-01-01_00:01:00 for domain        1:    0.01558 elapsed seconds
med_restart_out: opening wrfrst_d01_0001-01-01_00:01:00 for writing
Timing for Writing restart for domain        1:    0.08470 elapsed seconds
d01 0001-01-01_00:01:00 wrf: SUCCESS COMPLETE WRF

everything looks fine, though there is no wrfout or wrfrst created. Linux dmpar-release version just works fine. Could this be due to colon character ":" in file names?

[dmey]

@gsever I have just noticed your edit -- note that GitHub does not send notifications when you edit an issue (see https://stackoverflow.com/a/39091460).

Re your specific comment, have you set the nocolons flag to true in the expected section in both WPS and WRF namelists?

• WPS

&share
nocolons = .true.

• WRF

&time_control
nocolons = .true.

[gsever]

Yes, that was the fix. Apparently this is mentioned in the User's guide: http://www2.mmm.ucar.edu/wrf/users/docs/user_guide_v4/v4.0/users_guide_chap5.html but not in the README.namelist provided in the WRF/run directory.
Thanks.

[letmaik]

I will close this issue now. The (harmless) bug is still not fixed upstream, but in our release builds for newer versions (e.g. WRF-CMake 4.0.3) we don't have runtime checks enabled anymore (which makes sense, as they incur a performance hit) so you are not affected by this issue anymore under normal conditions.