Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

Bug when restarting, when using Thompson microphysics

This post was from a previous version of the WRF&MPAS-A Support Forum. New replies have been disabled and if you have follow up questions related to this post, then please start a new thread from the forum home page.

bartbrashers

New member
With WRF-4.0.x and WRF-4.1, when you try to restart a run that uses Thompson microphysics, an error occurs:

Code:
# tail wrf.rsl.error.0000
d03 2016-01-24_12:00:00  Input data is acceptable to use: wrflowinp_d03
d03 2016-01-24_12:00:00 Input data processed for aux input   4 for domain   3
OBS NUDGING: Reading new obs for time window TBACK =   -1.000 TFORWD =    1.000 for grid =  3
File open on obs nudging unit (           63 ) with wrong name
File open on obs nudging unit is named freezeH2O.dat but it should be named OBS_DOMAIN301
This likely means this unit number was opened elsewhere in WRF
-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE:  wrf_fddaobs_in.b  LINE:     460
wrf_fddaobs_in: in4dob STOP Obs nudging file name mismatch
-------------------------------------------

Deleting the file freezeH2O.dat first allows the restart to work OK – WRF runs.

The LUN for opening OBSDOMAINd01 is dynamically set in share/wrf_fddaobs_in.F (line425):

Code:
    obs_domain_file_unit = NVOLA+INEST-1

The LUN for opening freezeH2O.dat is hard-coded in phys/module_mp_thompson.F (line 4065):

Code:
          OPEN(63,file="freezeH2O.dat",form="unformatted",err=1234)

A possible solution is to simply close the file after reading it in phys/module_mp_thompson.F (starting line 4065):

Code:
          CALL wrf_message("ThompMP: read freezeH2O.dat instead of computing")
          OPEN(63,file="freezeH2O.dat",form="unformatted",err=1234)
          READ(63,err=1234)tpi_qrfz
          READ(63,err=1234)tni_qrfz
          READ(63,err=1234)tpg_qrfz
          READ(63,err=1234)tnr_qrfz
          READ(63,err=1234)tpi_qcfz
          READ(63,err=1234)tni_qcfz
          CLOSE(63)                            ! BAB proposed solution
          good = 1

I have verified with WRF-4.1 that this fix allows WRF to restart without the FATAL error. But I have not followed every possible if-then outcome to verify that is the best solution.

Bart Brashers
 
Bart,
Thank you for reporting this, and for the effort to correct it. Do you mind posting this to our GitHub Issues page for the WRF repository? This will allow several developers to see it and get it corrected sooner.

Just as an FYI - we do prefer that you first post the bugs here so that we can review them before they are posted to the GitHub page. So you did this correctly - thank you!
 
Top