Hello, everyone, I am using 2019 GEFS data driven WRF4.0, wps and real module can run normally, but in running WRF. Exe, automatic break (RSL.error file without any error), the same method to run 2018 GEFS data when there is no problem, Is there no way to drive WRF with GEFS data in 2019？If so, how should it be driven？ Thank you
The 2019 GEFS data cannot drive WRF4.0
- Thread starter Bozhero
- Start date
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.
Hi,
Although there could be a problem with the data, it's likely not the specific "type" of data that is causing the problem if the method is working for a previous year. Do you know whether GEFS data was changed between 2018 and 2019? Can you attach the namelist.input file you're using, along with all of the rsl* files (packaged into a single *.tar file)? Thanks!
Although there could be a problem with the data, it's likely not the specific "type" of data that is causing the problem if the method is working for a previous year. Do you know whether GEFS data was changed between 2018 and 2019? Can you attach the namelist.input file you're using, along with all of the rsl* files (packaged into a single *.tar file)? Thanks!
Dear teacher, I am glad to receive your reply.
I put 2018 GEFS data, using ncl_filedump gec00. t00z. pgrb2a. 0p50. f000 file and gec00 t00z. pgrb2b. 0p50. f000 file content presented to you separately, and named 2018 gefs_a_file. TXT and 2018 gefs_b_file. TXT, using the data of 2018 I was completely can run through the WRF, can get wrfout file.
However, the GEFS data for 2019 should be updated. I present their contents to you in a similar way, named 2019gefs_a_file.txt and 2019gefs_b_file.txt.I used 2019 GEFS data, ungrib.exe, metgrid.exe and real.exe without any problems.However, wrf.exe will stop automatically after the end of the first integral step, and there is no error report. Attached are the relevant files and namelist, thank you for your help
I put 2018 GEFS data, using ncl_filedump gec00. t00z. pgrb2a. 0p50. f000 file and gec00 t00z. pgrb2b. 0p50. f000 file content presented to you separately, and named 2018 gefs_a_file. TXT and 2018 gefs_b_file. TXT, using the data of 2018 I was completely can run through the WRF, can get wrfout file.
However, the GEFS data for 2019 should be updated. I present their contents to you in a similar way, named 2019gefs_a_file.txt and 2019gefs_b_file.txt.I used 2019 GEFS data, ungrib.exe, metgrid.exe and real.exe without any problems.However, wrf.exe will stop automatically after the end of the first integral step, and there is no error report. Attached are the relevant files and namelist, thank you for your help
Thank you for sending those!
For the 2018 GEFS case(s), was the namelist identical to the 2019 case, and were you using the same processor, compiler, etc.?
Can you also try to attach your wrfbdy_d01 and wrfinput_d01 files so that I can run a test with this? If the files are too large to attach, see instructions for submitting large files on the home page of this forum.
For the 2018 GEFS case(s), was the namelist identical to the 2019 case, and were you using the same processor, compiler, etc.?
Can you also try to attach your wrfbdy_d01 and wrfinput_d01 files so that I can run a test with this? If the files are too large to attach, see instructions for submitting large files on the home page of this forum.
Thank you for your reply
I confirm that the two cases in 2018 and 2019 used the same operating environment
I uploaded all files generated by an individual case in 2019, including files generated by ungrib and metgird, wrfinput and wrfbdy, and also uploaded GEFS data (20190401), named 2019gefs_drive_wrfv4.tar on the Netcloud. please help to check, thank you very much
I confirm that the two cases in 2018 and 2019 used the same operating environment
I uploaded all files generated by an individual case in 2019, including files generated by ungrib and metgird, wrfinput and wrfbdy, and also uploaded GEFS data (20190401), named 2019gefs_drive_wrfv4.tar on the Netcloud. please help to check, thank you very much
Hi,
I used your wrfinput/wrfbdy files to run a test and the model also stops for me immediately. I'd like to try to reproduce this, starting with WPS.
1) Can you please also attach the Vtable that you used to process these data?
2) Can you also please let me know if your namelist was identical (besides dates/times) between the 2018 and 2019 cases? i.e., did you use the same domain (same size), the same physics options, etc.
3) Are you using the same number of processors in the 2018 case and the 2019 case?
Thanks!
I used your wrfinput/wrfbdy files to run a test and the model also stops for me immediately. I'd like to try to reproduce this, starting with WPS.
1) Can you please also attach the Vtable that you used to process these data?
2) Can you also please let me know if your namelist was identical (besides dates/times) between the 2018 and 2019 cases? i.e., did you use the same domain (same size), the same physics options, etc.
3) Are you using the same number of processors in the 2018 case and the 2019 case?
Thanks!
Dear teacher, thank you for your prompt reply
I use Vtable.GFSENS, for this Vtable, after I check, it does not change in different versions of WRF (including the latest version of the WRF4.1 and WPS4.1), and I used the same script run more than 60 cases in 2017 and 2018 succesfully, But all the individual cases in 2019 failed. it is strange that there is no error in this process. These individual cases all use the same namelist (including the study area) and the same number of nodes. I have attached vtable.gfsens, please check it. Thank you very much for your help!
some of my my script:
ln -sf ${current_path}/nl/Vtable.GFSENS ./WPS/Vtable
./link_grib.csh ../extm_data/*grb2a*
cp namelist.wps.a namelist.wps
yhrun -n 1 -p TH_SR1 ./ungrib.exe
./link_grib.csh ../extm_data/*grb2b*
cp namelist.wps.b namelist.wps
yhrun -n 1 -p TH_SR1 ./ungrib.exe
cp namelist.wps.ab namelist.wps #FNL not use,GEFS use
yhrun -n 2 -p TH_SR1 ./metgrid.exe
I'm sure I'll have no problem running WRF scripts because I've run a lot of examples
Thanks again for your help！
I use Vtable.GFSENS, for this Vtable, after I check, it does not change in different versions of WRF (including the latest version of the WRF4.1 and WPS4.1), and I used the same script run more than 60 cases in 2017 and 2018 succesfully, But all the individual cases in 2019 failed. it is strange that there is no error in this process. These individual cases all use the same namelist (including the study area) and the same number of nodes. I have attached vtable.gfsens, please check it. Thank you very much for your help!
some of my my script:
ln -sf ${current_path}/nl/Vtable.GFSENS ./WPS/Vtable
./link_grib.csh ../extm_data/*grb2a*
cp namelist.wps.a namelist.wps
yhrun -n 1 -p TH_SR1 ./ungrib.exe
./link_grib.csh ../extm_data/*grb2b*
cp namelist.wps.b namelist.wps
yhrun -n 1 -p TH_SR1 ./ungrib.exe
cp namelist.wps.ab namelist.wps #FNL not use,GEFS use
yhrun -n 2 -p TH_SR1 ./metgrid.exe
I'm sure I'll have no problem running WRF scripts because I've run a lot of examples
Thanks again for your help！
Hi,
I compiled the code with a debugging option and was able to see the line of code that was stopping the model. It's in /phys/module_sf_noahdrv.F (line 1808). There seems to be a problem with TSLB (soil temperature), so I went back to look at the incoming soil temperature for the GEFS 2019 data vs. the 2017 data. All looks okay with the 2017 data, as was expected. But the 4th soil level has bad values for soil temperature all along the coastal regions. I'm attaching a screen shot to show you what I'm seeing. At this time, I don't think this is a problem with WPS or WRF. I believe this is likely related to the GEFS data, itself. I would advise plotting soil temperature for the 2019 data (prior to going through the ungrib process) and see what that looks like, to see if there are bad values in there.
I compiled the code with a debugging option and was able to see the line of code that was stopping the model. It's in /phys/module_sf_noahdrv.F (line 1808). There seems to be a problem with TSLB (soil temperature), so I went back to look at the incoming soil temperature for the GEFS 2019 data vs. the 2017 data. All looks okay with the 2017 data, as was expected. But the 4th soil level has bad values for soil temperature all along the coastal regions. I'm attaching a screen shot to show you what I'm seeing. At this time, I don't think this is a problem with WPS or WRF. I believe this is likely related to the GEFS data, itself. I would advise plotting soil temperature for the 2019 data (prior to going through the ungrib process) and see what that looks like, to see if there are bad values in there.
Attachments
Thank you for your prompt reply and help！
If there is a problem with the soil temperature of the GEFS data in 2019, is there any way that I can use the GEFS in 2019 to drive WRF? Does the soil temperature need to use other data, such as GLDAS? Thank you very much for your help
If there is a problem with the soil temperature of the GEFS data in 2019, is there any way that I can use the GEFS in 2019 to drive WRF? Does the soil temperature need to use other data, such as GLDAS? Thank you very much for your help
I assume that you saw this problem in multiple 2019 dates/times? If it was only 1 time, then perhaps you could use their data for all other runs you are interested in, but if you are seeing it in all the 2019 dates, then it does seem to be a problem. If so, you could use the GEFS data for all variables except for soil temperature (and for completeness, you would probably want to include soil moisture in that exception, as well) . You could use another model to force the soil data. For this, you would run ungrib as you've been doing, with two different datasets, except you would now run a 3rd time for the soil dataset. You'll need to make sure you are using a correct namelist for the soil dataset. When you run metgrid, you will have three prefixes set in the "fg_name" field.