You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
What's the minimum variables in wrfout_d01 needed for ndown run?
- Thread starter liqi123sh
- 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,
I just wanted to let you know that we are not purposefully neglecting your question. Our WRF support team is traveling internationally at the moment, and we have gotten a bit behind with forum questions. I've passed your question to a developer of the ndown program, and will let you know when I hear a response. Thank you for your patience.
I just wanted to let you know that we are not purposefully neglecting your question. Our WRF support team is traveling internationally at the moment, and we have gotten a bit behind with forum questions. I've passed your question to a developer of the ndown program, and will let you know when I hear a response. Thank you for your patience.
This is a good question.
The way that the NDOWN program works is that a previous WRF output file from the coarse grid with multiple time periods is used to provide lateral boundary conditions to the finer-grid domain. A single time period of the WRF input data, at the fine resolution, is used for the initial conditions.
The namelist settings for the NDOWN program require that the time_control namelist record has the io_form_auxinput2 and fine_input_stream defined:
These stream columns are associated with the specific domains (column 1 = the coarse grid, column 2 = the fine grid). The stream numbers are attributes that are associated with most state arrays. For example, look at the latitude field in the Registry:
The "1" says is the location informing us that the field is latitude (nameed XLAT).
The "2" says that this is an "i0" variable: it goes into WRF from the real program.
The "3" says that this is ALSO an i2 variable: it is a masked field that will be required for the IC file in NDOWN.
The "4" indicates that this is a "h" array: it is output from WRF.
For NDOWN to properly function, you may remove all of the state arrays from the model output that meet this condition: the field is output but the field is not input. For practical considerations, use ncview to identify two lists of 3d arrays: a list that is in the wrfinput_d01 file, and a separate list of fields that is in the wrfout_d01 file. You may remove all of the "h" fields (the wrfout fields) that are NOT in the wrfinput file.
You should do a before vs after test to insure that you are getting bit-wise identical results with your WRF simulation that follows NDOWN (remove optimization, only a few time steps are required, use the utility WRF/external/io_netcdf/diffwrf).
The fields may be removed from the WRF output file via capabilities listed in:
http://www2.mmm.ucar.edu/wrf/users/tutorial/201907/gill_registry.pdf
Look at page 1 of the PDF, slide #4.
The way that the NDOWN program works is that a previous WRF output file from the coarse grid with multiple time periods is used to provide lateral boundary conditions to the finer-grid domain. A single time period of the WRF input data, at the fine resolution, is used for the initial conditions.
The namelist settings for the NDOWN program require that the time_control namelist record has the io_form_auxinput2 and fine_input_stream defined:
Code:
&time_control
io_form_auxinput2 = 2
fine_input_stream = 0, 2,
/These stream columns are associated with the specific domains (column 1 = the coarse grid, column 2 = the fine grid). The stream numbers are attributes that are associated with most state arrays. For example, look at the latitude field in the Registry:
Code:
1 2 3 4
state real XLAT ij misc 1 - i0123rh0156{22}{23}du=(copy_fcnm) "XLAT" "LATITUDE, SOUTH IS NEGATIVE"The "1" says is the location informing us that the field is latitude (nameed XLAT).
The "2" says that this is an "i0" variable: it goes into WRF from the real program.
The "3" says that this is ALSO an i2 variable: it is a masked field that will be required for the IC file in NDOWN.
The "4" indicates that this is a "h" array: it is output from WRF.
For NDOWN to properly function, you may remove all of the state arrays from the model output that meet this condition: the field is output but the field is not input. For practical considerations, use ncview to identify two lists of 3d arrays: a list that is in the wrfinput_d01 file, and a separate list of fields that is in the wrfout_d01 file. You may remove all of the "h" fields (the wrfout fields) that are NOT in the wrfinput file.
You should do a before vs after test to insure that you are getting bit-wise identical results with your WRF simulation that follows NDOWN (remove optimization, only a few time steps are required, use the utility WRF/external/io_netcdf/diffwrf).
The fields may be removed from the WRF output file via capabilities listed in:
http://www2.mmm.ucar.edu/wrf/users/tutorial/201907/gill_registry.pdf
Look at page 1 of the PDF, slide #4.
Hello,
I have been thinking about this question and I find this post. However, I have a question about what Dave has mentioned here:
Shouldn't we also check wrfbdy file arrays as well to compare with wrfout arrays?
Thank you,
Mahdad
I have been thinking about this question and I find this post. However, I have a question about what Dave has mentioned here:
For practical considerations, use ncview to identify two lists of 3d arrays: a list that is in the wrfinput_d01 file, and a separate list of fields that is in the wrfout_d01 file. You may remove all of the "h" fields (the wrfout fields) that are NOT in the wrfinput file.
Shouldn't we also check wrfbdy file arrays as well to compare with wrfout arrays?
Thank you,
Mahdad
Mahdad,
When trying to modify standard settings in the Registry that supplies fields to the WRF model from ndown, certainly all of the data going into the second WRF model needs to be carefully reviewed.
The only fields that are members of the lateral boundary file are constructed from the associated fields that are available to (and inside of) the WRF input file. Verifying that the required fields are present in the initial condition file is sufficient for those derived fields also necessarily being part of the lateral boundary file.
When trying to modify standard settings in the Registry that supplies fields to the WRF model from ndown, certainly all of the data going into the second WRF model needs to be carefully reviewed.
The only fields that are members of the lateral boundary file are constructed from the associated fields that are available to (and inside of) the WRF input file. Verifying that the required fields are present in the initial condition file is sufficient for those derived fields also necessarily being part of the lateral boundary file.