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

WRF stops immediately..Help!

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.

S

sinisters93

New member
tail rsl.error.0000
#3 0x2BAD510 in __module_ra_rrtm_MOD_taugb3
#4 0x2BAEF0A in __module_ra_rrtm_MOD_gasabs
#5 0x2BC30AB in __module_ra_rrtm_MOD_rrtm
#6 0x2BC81F8 in __module_ra_rrtm_MOD_rrtmlwrad
#7 0x22ADF01 in __module_radiation_driver_MOD_radiation_driver
#8 0x27E8D8C in __module_first_rk_step_part1_MOD_first_rk_step_part1
#9 0x1D38DAF in solve_em_
#10 0x1B7D279 in solve_interface_
#11 0x485B5A in __module_integrate_MOD_integrate
#12 0x408793 in __module_wrf_top_MOD_wrf_run


I have gone through different solutions given on this forum like reducing time step and smoothing options and changing processors but nothing worked.
Actually, this was working before but recently I have recompiled WRF to include many variables which I need by modifying the registry file. Compilation worked fine but now it is giving this error during run.

namelist attached.
 

Attachments

  • namelist.input
    8.6 KB · Views: 50
Hi,

If it still is not working after a "./clean -a", instead of changing the registry, try using a my_iofields file, described in the WRF documentation.

Jordan
 
./clean -a worked for me and the variables are reflecting now, but ./wrf.exe is still showing this error that I mentioned.

What to do now?
 
Hi,

Can you please attach your rsl.out/error.0000 file for a run with debug_level > 100?

Please also make sure there are not different error messages for different processors/rsl. files

Jordan
 
I am attaching two rsl.error* files all were same only 23rd one was a little bit different, so I am attaching two here.

Kindly check and tell what's wrong
 

Attachments

  • rsl.error.0000.txt
    1.3 MB · Views: 49
  • rsl.error.0023.txt
    1.3 MB · Views: 47
Hi,

It is not clear from your output what the problem - Since it seems your issue is related to the added history variables, I would try to:

1. Remove the "h" from the history column in the Registry (those that you added)
2. ./clean -a and recompile
3. In your run directory, place an iofields file (see the WRF user guide for format), and add the variables you need a few at a time to see if it is a particular variable causing the issue, or just the amount of output.

If the latter, you can try using quilting processors or remove unused 3D+Time variables from the history output (also with the iofields files).

Jordan
 
I didn't get this third thing 'IO Field', I read the documentation but couldn't get it completely as to how to do it.
(third point and last line made this complicated)

can you please show some sample format or any links which shows the procedure as how to do it?
 
Sure, lets say you wanted to add the variable "ebio_iso" to the output.

1. Create a plain text file in your run directory named "my_iofields_list.txt" that contains the single line:
+:h:0:ebio_iso
2. in the time_Control namelist, add the following line:
iofields_filename = "./my_iofields_list.txt"

Then you can add variables successively to see if one of them or a certain amount of them are the problem (e.g., if you also wanted to add ebio_oli, the line in the file will be: +:h:0:ebio_iso,ebio_oli)

The benefit of this method is that one does not need to ./clean -a and recompile to add (or subtract, simply add a new line with a "-" instead of a "+" to the iofields file) variables from the history stream.

Jordan
 
Ok, thanks for the help
Now it is working !

My another question is I have included ebu_xyl variable in .text file and using biomass_burn_opt=1 also, but it is not reflecting in the output.
When I checked in registry I found ebu_xyl is not present here but ebu_in_xyl is there

# the following arrays only needed for burn options
package biomassb biomass_burn_opt==1 - state:mean_fct_agtf,mean_fct_agef,mean_fct_agsv,mean_fct_aggr,firesize_agtf,firesize_agef,firesize_agsv,firesize_aggr;ebu:ebu_no,ebu_no2,ebu_co,ebu_co2,ebu_eth,ebu_hc3,ebu_hc5,ebu_hc8,ebu_ete,ebu_olt,ebu_oli,ebu_pm25,ebu_pm10,ebu_dien,ebu_iso,ebu_api,ebu_lim,ebu_tol,ebu_csl,ebu_hcho,ebu_ald,ebu_ket,ebu_macr,ebu_ora1,ebu_ora2,ebu_so2,ebu_nh3,ebu_oc,ebu_bc,ebu_sulf,ebu_dms;ebu_in:ebu_in_no,ebu_in_no2,ebu_in_co,ebu_in_co2,ebu_in_eth,ebu_in_hc3,ebu_in_hc5,ebu_in_hc8,ebu_in_ete,ebu_in_olt,ebu_in_oli,ebu_in_pm25,ebu_in_pm10,ebu_in_dien,ebu_in_iso,ebu_in_api,ebu_in_lim,ebu_in_tol,ebu_in_csl,ebu_in_hcho,ebu_in_ald,ebu_in_xyl,ebu_in_ket,ebu_in_macr,ebu_in_ora1,ebu_in_ora2,ebu_in_so2,ebu_in_nh3,ebu_in_oc,ebu_in_bc,ebu_in_sulf,ebu_in_dms,ebu_in_ash

However ebu_xyl is present in top portion of the registry under the biomass burning section but is not there in biomass_burn_opt=1


My query is can I use ebu_in_xyl in place of ebu_xyl, what is the difference between them????
Not able to get the difference from registery!
 
Hi,

EBU_IN are the bb emissions that are read in from the wrffirechemi file. EBU are the actual emissions used after plumerise is invoked if you are using it (i.e. 2D vs. 3D). If you would like to output that array, you will need to add "ebu_xyl" to the bb==1 package and again either add an "h" to the registry entry or add the array to your io_fields file.

Jordan
 
Ok, to some extent I got this.

I need to add ebu_xyl to bb==1 package, but then again , the question arises that is there any file named bb==1 where I need to edit this or file with some other name???
Basically, I want to know where to make this edit?? The name of the file!

Second thing is after making this edit , do i need to recompile again ???
 
Hi,

You should only need to add the bolded part to the file Registry/registry.chem (then ./clean -a and recompile)

# the following arrays only needed for burn options
package biomassb biomass_burn_opt==1 - state:mean_fct_agtf,mean_fct_agef,mean_fct_agsv,mean_fct_aggr,firesize_agtf,firesize_agef,firesize_agsv,firesize_aggr;ebu:ebu_no,ebu_no2,ebu_co,ebu_co2,ebu_eth,ebu_hc3,ebu_hc5,ebu_hc8,ebu_ete,ebu_olt,ebu_oli,ebu_pm25,ebu_pm10,ebu_dien,ebu_iso,ebu_api,ebu_lim,ebu_tol,ebu_csl,ebu_hcho,ebu_ald,ebu_xyl,ebu_ket,ebu_macr,ebu_ora1,ebu_ora2,ebu_so2,ebu_nh3,ebu_oc,ebu_bc,ebu_sulf,ebu_dms;ebu_in:ebu_in_no,ebu_in_no2,ebu_in_co,ebu_in_co2,ebu_in_eth,ebu_in_hc3,ebu_in_hc5,ebu_in_hc8,ebu_in_ete,ebu_in_olt,ebu_in_oli,ebu_in_pm25,ebu_in_pm10,ebu_in_dien,ebu_in_iso,ebu_in_api,ebu_in_lim,ebu_in_tol,ebu_in_csl,ebu_in_hcho,ebu_in_ald,ebu_in_xyl,ebu_in_ket,ebu_in_macr,ebu_in_ora1,ebu_in_ora2,ebu_in_so2,ebu_in_nh3,ebu_in_oc,ebu_in_bc,ebu_in_sulf,ebu_in_dms,ebu_in_ash


Jordan
 
You must log in or register to reply here.
Top