Big domain, shorter time_step ???

[gsrepsoper]

Hi WRF colleagues,

With WRF4.6.1 we are going to move our LAM-EPS at 2.5km to a bigger DOMAIN
from 565x469 to 789x637 horizontal grid points BUT surprisingly we have been force
to reduce the time_step from 12 seconds to 9 seconds in order not to fail.

Last calling subroutines just before it fails with the bigger domain
789x637 when using time_step of 10 or 12 seconds are different in
distinct execution dates:

...
calling inc/HALO_EM_C_inline.inc
...
calling inc/HALO_EM_PHYS_PBL_inline.inc
...
calling inc/HALO_EM_C2_inline.inc (<== several times)
...
microphysics_driver: calling thompson
...

Does it make any sense that a bigger domain requires a shorter
time_step ???

ToKnow: both domains are centered over Iberian Peninsula and both intercep
in their N/E corner with Alps mountain range which maybe it could
play some role in integrating problems.

Happy WRFing !!!

Alfons and Juanjo
AEMET Predictability Team

PD: more complete output
...
call phy_prep_part2
call moist_physics_prep
call microphysics_driver
calling inc/HALO_EM_SBM_inline.inc
microphysics_driver: calling thompson
MP-GT:qc: 0.000000E+00 ( 0, 0, 0) qr: 0.000000E+00 ( 0, 0, 0) qi: 0.000000E+00 ( 0, 0, 0) qs: 0.000000E+00 ( 0, 0, 0) qg: 0.000000E+00 ( 0, 0, 0) ni: 0.000000E+00 ( 0, 0, 0) nr: 0.000000E+00 ( 0, 0, 0)
microphysics_driver: returning from
call moist_physics_finish
calling inc/HALO_EM_THETAM_inline.inc
calling inc/PERIOD_EM_THETAM_inline.inc
call chem polar filter
calling inc/HALO_EM_D3_5_inline.inc
calling inc/PERIOD_BDY_EM_D3_inline.inc
calling inc/PERIOD_BDY_EM_MOIST_inline.inc
calling inc/PERIOD_BDY_EM_CHEM_inline.inc
calling inc/PERIOD_BDY_EM_TRACER_inline.inc
calling inc/PERIOD_BDY_EM_SCALAR_inline.inc
call set_phys_bc_dry_2
call spec_bdy_final
calling inc/HALO_EM_C_inline.inc
calling inc/PERIOD_BDY_EM_E_inline.inc
call set_w_surface
calling inc/HALO_EM_PHYS_W_inline.inc
calling inc/HALO_EM_PHYS_HCW_inline.inc
--> TOP OF AFTER ALL RK STEPS
--> CALLING DIAGNOSTICS DRIVER
--> TOP OF DIAGNOSTICS PACKAGE
--> CALL DIAGNOSTICS PACKAGE: LIGHTNING_DRIVER
lightning_driver: determining cloud extents for CRM
lightning_driver: Max cell count = 0.0000000E+00
lightning_driver: calculating flash rate
lightning_driver: calling Price and Rind 1992 (w_max, CRM)
lightning_driver: partitioning IC:CG
lightning_driver: using option-default IC:CG method
lightning_driver: converting flash rates to flash counts
lightning_driver: returning from
--> CALL DIAGNOSTICS PACKAGE: ACCUMULATED AND BUCKET DIAGNOSTICS
--> CALL DIAGNOSTICS PACKAGE: CLIMATE DIAGNOSTICS
Re-initializing accumulation arrays
Re-initializing accumulation arrays
Re-initializing accumulation arrays
Re-initializing accumulation arrays
call HALO_RK_E
calling inc/HALO_EM_E_5_inline.inc
forrtl: error (78): process killed (SIGTERM)
Image PC Routine Line Source
wrf.exe 000000000312447B for__signal_handl Unknown Unknown
libpthread-2.28.s 000014569AD9ACF0 Unknown Unknown Unknown
libucp.so.0.0.0 00001456779793F2 ucp_worker_progre Unknown Unknown
libopen-pal.so.40 000014569A049324 opal_progress Unknown Unknown
libmpi.so.40.30.1 000014569B41D1D7 ompi_request_defa Unknown Unknown
libmpi.so.40.30.1 000014569B44B022 PMPI_Wait Unknown Unknown
wrf.exe 00000000030738B1 Unknown Unknown Unknown
wrf.exe 000000000124F265 Unknown Unknown Unknown
wrf.exe 00000000010E41B0 Unknown Unknown Unknown
wrf.exe 0000000000F1CD3C Unknown Unknown Unknown
wrf.exe 0000000000430E43 Unknown Unknown Unknown
wrf.exe 0000000000416EF1 Unknown Unknown Unknown
wrf.exe 0000000000416EA6 Unknown Unknown Unknown
wrf.exe 0000000000416E22 Unknown Unknown Unknown
libc-2.28.so 000014569A9FDD85 __libc_start_main Unknown Unknown
wrf.exe 0000000000416D2E Unknown Unknown Unknown

 

[Ming Chen]

This is not an unexpected behavior of model. With larger domain, the grid distortion will become more severe, and time step has to be adjusted (reduced) accordingly. Hope this us helpful for you. Please let us know if you have more questions.