Trouble running WRF with BEM

[Rtsquared]

When attempting to run WRF using BEM (sf_urban_physics = 3) I get the following error (specifically from only rsl.out.0068, am running on 128 cores):
d01 2018-05-01_00:00:00 Input data is acceptable to use:
d01 2018-05-01_00:00:00 Input data processed for aux input 4 for domain 1
d01 2018-05-01_00:00:00 Yes, this special data is acceptable to use: SFCFDDA FILE: SURFACE ANALYSES FOR NUDGING
d01 2018-05-01_00:00:00 Input data is acceptable to use:
d01 2018-05-01_00:00:00 Input data processed for aux input 9 for domain 1
d01 2018-05-01_00:00:00 Input data is acceptable to use:
d01 2018-05-01_00:00:00 Input data processed for aux input 10 for domain 1
d01 2018-05-01_00:00:00 Input data is acceptable to use:
Tile Strategy is not specified. Assuming 1D-Y
WRF TILE 1 IS 237 IE 295 JS 157 JE 175
WRF NUMBER OF TILES = 1
-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE: <stdin> LINE: 2462
singular matrix in gaussjbem
-------------------------------------------

This leads to a subroutine called gaussjbem in phys/sf_module_bem.f90 which is used to invert matrices (see page 60/61 of this PDF for the algorithm: https://websites.pmc.ucsc.edu/~fnimmo/eart290c_17/NumericalRecipesinF77.pdf). The issue that is causing the error is that there is a singular (non-invertible) matrix showing up causing the following part of the algorithm to fail:
if(ipiv(k).eq.0)then
if(abs(a(j,k)).ge.big)then
big=abs(a(j,k))
irow=j
icol=k
endif
elseif(ipiv(k).gt.1)then
CALL wrf_error_fatal3("<stdin>",2462 &
'singular matrix in gaussjbem')
endif

I have no idea where these matrices are coming from or why one of them is singular and killing my run. My namelist and data used for this run is exactly the same as it is in my currently running BEP simulation (sf_urban_physics=2) with the exception of using BEM. I've attached the namelist used in case that helps. My hope is that I can get the bug solved and the run going this week so I can start doing analysis in January (running May-September, it takes ~5.5 days to complete a month), but I have no idea what needs to be done here. It would be nice if all it required was a minor adjustment to the namelist.

On an unrelated note, there's something weird going on with the interaction between history_interval and restart_interval. If I have the output written too often in comparison to the restart files the program will get stuck trying to create the restart file. For example, I currently have the restart file set to every 6 hours because setting it to 12 or 24 hours will make it fail (though not actually quit- the program runs but does nothing so rsl.out.0000 needs to be checked to see if this is occurring) when trying to write the restart file for domain 4. I can do restart files every 24 hours if the history interval of domain 4 is 3 hours (currently set to 2 hours), but longer times between restart files don't work. It's very strange.

 

[Ming Chen]

Hi,
Your namelist.input looks fine except the radt had better be the same for all domains. I notice that num_land_cat = 40 in your namelist. Do you use NLCD as input data?

 

[Rtsquared]

I didn't know radt had to be the same for all domains- would it need to all be set to 0.44 to match the smallest domain? What effect does that have? The only thing it says in readme.namelist is to set it for 1 minute = 1km in domain size and to set it for all domains. It seems to be running fine with this setup using BEP. And yes, I am using NLCD for my land categories. I would have preferred to use the Noah MP LSM but it does not work with NLCD, I might have been able to if I had managed to get local climate zones working properly. I also attempted to get sf_lake_physics working but that ended up causing issues as well so I turned it off.

 

[Rtsquared]

Looking more closely at the code, the matrix inversion takes place as part of the processes used to determine the absorption of shortwave and longwave radiation that passes through a window by the inside walls of a building. There are a lot of variables used and, combined with several math-heavy subroutines to create the matrix that can't be inverted, make it basically impossible to know where in my data the issue originated. I've also tried turning off the int_rlrad and int_rsrad subroutines by setting the window percentage to zero or window albedo to 1, but the problem persists.

 

[drq95]

hi, Rtsquared, I also get the same error when I run BEP/BEM using WRFV4.3.3. I would be very appreciate if you could tell me how you solve this problem. Thank you so much in advance.

 

[Rtsquared]

Sorry it took so long to get back to you- the problem appears to have been the land surface dataset used. BEP-BEM does not work with NLCD which is what I was using at the time (BEP ran fine with NLCD, but has other issues as there appears to be a pretty substantial bug resulting in a strong growing nighttime cold bias). I haven't had this particular problem show up when using MODIS instead.