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

cu_physics=3

Many thanks, Ming,
But it did not help. wrf.exe crashed at the very beginning!
Here is the output:
===================================================================================
= BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
= RANK 0 PID 9869 RUNNING AT server
= KILLED BY SIGNAL: 9 (Killed)
===================================================================================

===================================================================================
= BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
= RANK 1 PID 9870 RUNNING AT server
= KILLED BY SIGNAL: 9 (Killed)
===================================================================================

===================================================================================
= BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
= RANK 2 PID 9871 RUNNING AT server
= KILLED BY SIGNAL: 9 (Killed)
===================================================================================

===================================================================================
= BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
= RANK 3 PID 9872 RUNNING AT server
= KILLED BY SIGNAL: 9 (Killed)
===================================================================================

===================================================================================
= BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
= RANK 4 PID 9873 RUNNING AT server
= KILLED BY SIGNAL: 9 (Killed)
===================================================================================

===================================================================================
= BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
= RANK 5 PID 9874 RUNNING AT server
= KILLED BY SIGNAL: 9 (Killed)
===================================================================================

===================================================================================
= BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
= RANK 7 PID 9876 RUNNING AT server
= KILLED BY SIGNAL: 9 (Killed)
===================================================================================

===================================================================================
= BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
= RANK 9 PID 9878 RUNNING AT server
= KILLED BY SIGNAL: 9 (Killed)
===================================================================================
 

Attachments

  • namelist.input
    3.9 KB · Views: 1
  • rsl.error.0000
    86.1 KB · Views: 1
  • rsl.out.0000
    85.8 KB · Views: 1
Sorry Ming,
But the model runs with this namelist lasted 10 minutes more!
here is His namelist: (no matter sst_update = 0/1)
--------------------------------------------------------------------------------------------------------------------------
&time_control
run_days = 1,
run_hours = 0,
run_minutes = 0,
run_seconds = 0,
start_year = 2023, 2023,
start_month = 08, 08,
start_day = 10, 10,
start_hour = 00, 00,
start_minute = 00, 00,
start_second = 00, 00,
end_year = 2023, 2023,
end_month = 08, 08,
end_day = 11, 11,
end_hour = 00, 00,
end_minute = 00, 00,
end_second = 00, 00,
interval_seconds = 10800,
input_from_file = .true.,.true.,
history_interval = 60, 60,
frames_per_outfile = 24, 24,
restart = .false.,
restart_interval = 1440,
write_hist_at_0h_rst = .true.,
io_form_history = 2,
io_form_restart = 2,
io_form_input = 2,
io_form_boundary = 2,
debug_level = 100,
auxinput4_inname = "wrflowinp_d<domain>"
auxinput4_interval = 360, 360,
io_form_auxinput4 = 2,
iofields_filename = "my_iofields.txt","my_iofields.txt","my_iofields.txt","my_iofields.txt",
ignore_iofields_warning = .true.,
/

&domains
time_step = 30,
time_step_fract_num = 0,
time_step_fract_den = 1,
use_adaptive_time_step = .true.,
step_to_output_time = .true.,
target_cfl = 1.2, 1.2, 1.2,
target_hcfl = 0.84, 0.84,
max_step_increase_pct = 5, 51, 51,
starting_time_step = 20, 6, -1,
max_time_step = 45, 15, 10,
min_time_step = 18, 6, -1,
adaptation_domain = 1,
max_dom = 2,
e_we = 277, 187,
e_sn = 136, 100,
e_vert = 41, 41,
eta_levels = 1.0000,0.9980,0.9955,0.9925,0.9890,0.9847,0.9795,0.9733,0.9659,0.9571,0.9467,0.9345,0.9201,0.9026,0.8811,0.8556,0.8261,0.7926,0.7556,0.7156,0.6736,0.6306,0.5876,0.5446,0.5016,0.4586,0.4156,0.3731,0.3316,0.2911,0.2516,0.2141,0.1786,0.1451,0.1141,0.0861,0.0611,0.0391,0.0211,0.0081,0.0000,
p_top_requested = 5000,
num_metgrid_levels = 34,
num_metgrid_soil_levels = 4,
dx = 9090.0, 3030.0,
dy = 9090.0, 3030.0,
grid_id = 1, 2,
parent_id = 1, 1,
i_parent_start = 1, 126,
j_parent_start = 1, 50,
parent_grid_ratio = 1, 3,
parent_time_step_ratio = 1, 3,
feedback = 1,
smooth_option = 0,
smooth_cg_topo = .true.,
/

&physics
mp_physics = 8, 8,
ra_lw_physics = 4, 4,
ra_sw_physics = 4, 4,
radt = 9, 9,
swint_opt = 1,
sf_sfclay_physics = 1, 1,
sf_surface_physics = 2, 2,
sf_urban_physics = 0, 0,
bl_pbl_physics = 1, 1,
bldt = 0, 0,
surface_input_source = 1,
num_soil_layers = 4,
num_land_cat = 21,
cu_physics = 3, 0,
cudt = 0, 0,
cugd_avedx = 1,
cu_rad_feedback =.true.,.false.,
prec_acc_dt = 60., 60.,
maxiens = 1,
maxens = 3,
maxens2 = 3,
maxens3 = 16,
ensdim = 144,
isfflx = 1,
ifsnow = 0,
icloud = 1,
sst_update = 1,
slope_rad = 0, 0,
topo_shading = 0, 0,
/

&fdda
/

&dynamics
w_damping = 0,
hybrid_opt = 0,
diff_opt = 1, 1,
km_opt = 4, 4,
diff_6th_opt = 0, 0,
diff_6th_factor = 0.12, 0.12,
base_temp = 290.
damp_opt = 3,
zdamp = 5000., 5000.,
dampcoef = 0.2, 0.2,
khdif = 0, 0,
kvdif = 0, 0,
non_hydrostatic = .true., .true.,
tke_adv_opt = 1, 1,
moist_adv_opt = 1, 1,
scalar_adv_opt = 1, 1,
/

&bdy_control
spec_bdy_width = 5,
spec_zone = 1,
relax_zone = 4,
specified = .true., .false.,
nested = .false., .true.,
/

&grib2
/

&namelist_quilt
nio_tasks_per_group = 0,
nio_groups = 1,
/
----------------------------------------------------------------------------------------------------------------------------------------------------------------
 
Hi all,
Can anyone provide a working namelist with the parameter:
cu_physics=3
I have 2 domains configuration:
dx = 9090, 3030,
dy = 9090, 3030,
and I can't find the correct parameterization scheme for
cu_physics = 3, 0,

I use GFS files as wrf(v4.5) model's initial and boundary conditions.
Is it possible that this is a model bug?

Thanks in advance!
 
Hi,
I just run a test case using the option cu_physics = 3, 0. This is a nest case with max_dom =2, just like your case. Please see my namelist.input attached here. Can you run your case with my namelist.input (remember to modify time, grid numbers and intervals etc.)? Please let me know whether it works for you. I suppose this will be the starting point for us to further investigate what is wrong in your original. run.
 

Attachments

  • namelist.input.txt
    6.5 KB · Views: 3
Ming Chen said:
Hi,
I just run a test case using the option cu_physics = 3, 0. This is a nest case with max_dom =2, just like your case. Please see my namelist.input attached here. Can you run your case with my namelist.input (remember to modify time, grid numbers and intervals etc.)? Please let me know whether it works for you. I suppose this will be the starting point for us to further investigate what is wrong in your original. run.
Click to expand...
Many thanks, Ming,
I've modified my namelist (it is attached) but wrf.exe crashed (but real.exe completed successfully):
$ mpirun -n 4 ./wrf.exe
starting wrf task 1 of 4
starting wrf task 2 of 4
starting wrf task 3 of 4
starting wrf task 0 of 4

===================================================================================
= BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
= RANK 1 PID 12627 RUNNING AT server
= KILLED BY SIGNAL: 9 (Killed)
===================================================================================

===================================================================================
= BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
= RANK 2 PID 12628 RUNNING AT server
= KILLED BY SIGNAL: 9 (Killed)
===================================================================================

===================================================================================
= BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
= RANK 3 PID 12629 RUNNING AT server
= KILLED BY SIGNAL: 9 (Killed)
===================================================================================

But in case
cu_physics = 5, 0,
the model completed successfully!
Maybe it deals with dx=9090 (gray zone)?
 

Attachments

  • namelist.input
    5.7 KB · Views: 0
  • rsl.error.0000
    131.4 KB · Views: 0
  • rsl.out.0000
    129.8 KB · Views: 0
Last edited:
I would suggest that you recompile WRF in debug mode, i.e.,
./clean -a
./configure -D
./compile em_real

Then rerun this case. The log file will tell when and where the model first crashes. This information will be helpful for debugging possible issues.
 
Ming Chen said:
I would suggest that you recompile WRF in debug mode, i.e.,
./clean -a
./configure -D
./compile em_real

Then rerun this case. The log file will tell when and where the model first crashes. This information will be helpful for debugging possible issues.
Click to expand...
Ok.
 
Ming Chen said:
I would suggest that you recompile WRF in debug mode, i.e.,
./clean -a
./configure -D
./compile em_real

Then rerun this case. The log file will tell when and where the model first crashes. This information will be helpful for debugging possible issues.
Click to expand...
Dear Ming,
I've compiled WRF in debug mode (as You advised) and ran it for the parameterization scheme:
cu_physics = 3, 0,
It ran very slowly but crashed with errors:
-----------------------------------------------------------------------------------------------------
forrtl: error (63): output conversion error, unit -5, file Internal Formatted Write
------------------------------------------------------------------------------------------------------

Here are the namelist and log files.
 

Attachments

  • rsl.out.0000
    1.8 MB · Views: 1
  • rsl.error.0000
    4.3 MB · Views: 1
  • namelist.input
    5.7 KB · Views: 0
I also disabled the adaptive time step, but wrf.exe crashed without any explicit errors!
 

Attachments

  • rsl.out.0000
    3.7 MB · Views: 0
  • rsl.error.0000
    3.7 MB · Views: 1
  • namelist.input
    5.7 KB · Views: 0
In your rsl.error.out, we can find the following information:

forrtl: error (63): output conversion error, unit -5, file Internal Formatted Write


Image PC Routine Line Source


wrf.exe 000000000DB7AACB Unknown Unknown Unknown


wrf.exe 000000000DBCABE0 Unknown Unknown Unknown


wrf.exe 000000000DA83513 fraction_to_strin 923 Meat.f


wrf.exe 000000000DA83725 fraction_to_strin 950 Meat.f


wrf.exe 00000000005AA4C3 module_domain_mp_ 20272 module_domain.f90


wrf.exe 00000000005B2678 get_current_time_ 20875 module_domain.f90


wrf.exe 0000000001B1A833 wrf_debug_ 33 wrf_debug.f90


wrf.exe 00000000005B53E8 module_integrate_ 333 module_integrate.f90


wrf.exe 0000000000415370 module_wrf_top_mp 326 module_wrf_top.f90


wrf.exe 00000000004147B5 MAIN__ 29 wrf.f90

Something first went wrong at the line 923 in Meat.f. Please print all variables in this line and find what variables are problematic.

Also, please set debug_level =0 in your namelist.input. Higher value of this option doesn't really help to provide more information. Instead, it makes the RSL file too large.
 
Ming Chen said:
In your rsl.error.out, we can find the following information:

forrtl: error (63): output conversion error, unit -5, file Internal Formatted Write


Image PC Routine Line Source


wrf.exe 000000000DB7AACB Unknown Unknown Unknown


wrf.exe 000000000DBCABE0 Unknown Unknown Unknown


wrf.exe 000000000DA83513 fraction_to_strin 923 Meat.f


wrf.exe 000000000DA83725 fraction_to_strin 950 Meat.f


wrf.exe 00000000005AA4C3 module_domain_mp_ 20272 module_domain.f90


wrf.exe 00000000005B2678 get_current_time_ 20875 module_domain.f90


wrf.exe 0000000001B1A833 wrf_debug_ 33 wrf_debug.f90


wrf.exe 00000000005B53E8 module_integrate_ 333 module_integrate.f90


wrf.exe 0000000000415370 module_wrf_top_mp 326 module_wrf_top.f90


wrf.exe 00000000004147B5 MAIN__ 29 wrf.f90

Something first went wrong at the line 923 in Meat.f. Please print all variables in this line and find what variables are problematic.

Also, please set debug_level =0 in your namelist.input. Higher value of this option doesn't really help to provide more information. Instead, it makes the RSL file too large.
Click to expand...
It is in this procedure of the code(Meat.f):
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
SUBROUTINE fraction_to_stringi8( numerator, denominator, frac_str )
USE WRF_ESMF_BaseMod
IMPLICIT NONE
INTEGER(ESMF_KIND_I8), INTENT(IN) :: numerator
INTEGER(ESMF_KIND_I8), INTENT(IN) :: denominator
CHARACTER (LEN=*), INTENT(OUT) :: frac_str
IF ( denominator > 0 ) THEN
IF ( mod( numerator, denominator ) /= 0 ) THEN
IF ( numerator > 0 ) THEN
WRITE(frac_str,FMT="('+',I2.2,'/',I2.2)") abs(numerator), denominator / line 923
ELSE ! numerator < 0
WRITE(frac_str,FMT="('-',I2.2,'/',I2.2)") abs(numerator), denominator
ENDIF
ELSE ! includes numerator == 0 case
frac_str = ''
ENDIF
ELSE ! no-fraction case
frac_str = ''
ENDIF
END SUBROUTINE fraction_to_stringi8
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
But it is a case with adaptive time steps.
When I turned it off there were no explicit errors!
 

Attachments

  • rsl.error.0000
    3.7 MB · Views: 1
Hi Ming,
wrf.exe crashed very soon from the start without any noticeable errors!
 

Attachments

  • namelist.input
    5.3 KB · Views: 2
  • rsl.error.0000
    57.9 KB · Views: 1
  • rsl.out.0000
    57.6 KB · Views: 0
Giamik said:
I am running WRF v4.5 in 2 domains(one nested) configuration using GFS data. They cover the Black and Caspian Seas (the first one with a 9km resolution) and Georgia (the nested one with a 3km resolution).
By the user guide recommendation (WRF Physics — WRF Users Guide documentation)
"Domains with grid spacing >=3km to <=10km: This is a “gray zone” where cumulus parameterization may or may not be necessary. If possible, try to avoid domains this size, but if it is unavoidable, it is best to use either the Multi-scale Kain Fritsch or Grell-Freitas scheme, as these take this scale into account."
When I use the Grell-Freitas scheme (cu_physics=3) real.exe runs successfully but wrf.exe stops at the very beginning with the error:
------------------------------------------------------------------------------------------------------------------
d02 2023-07-21_00:00:12 calling inc/PERIOD_BDY_EM_MOIST_OLD_inline.inc
d02 2023-07-21_00:00:12 calling inc/HALO_EM_A_inline.inc
d02 2023-07-21_00:00:12 calling inc/PERIOD_BDY_EM_A_inline.inc
d02 2023-07-21_00:00:12 calling inc/HALO_EM_PHYS_A_inline.inc
d02 2023-07-21_00:00:12 Top of Radiation Driver
d02 2023-07-21_00:00:12 calling inc/HALO_PWP_inline.inc
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image PC Routine Line Source
wrf.exe 000000000386115A for__signal_handl Unknown Unknown
------------------------------------------------------------------------------------------------------------------
When I use Multi-scale Kain Fritsch (cu_physics=11) real.exe does not run!
But with cu_physics=1 and cu_physics=5 model runs flawlessly!
Here are my namelist files.

Can anyone help me?
Click to expand...
Did you able to solve the problem ? I have same issue. The cu_physics= 1 and 11 is working fine. While 3 is not working .
 
priya_nit said:
Did you able to solve the problem ? I have same issue. The cu_physics= 1 and 11 is working fine. While 3 is not working .
Click to expand...
No priya_nit,
I have settled for cu_physical=5!
I think this is a bug in the model for the gray zone.

Good luck!
 
You must log in or register to reply here.
Top