Comments (3)
There are two things about this message:
- perfect_model_obs should not be reporting that the error came from filter
- the message is correct, but to explain why
advancing the model inside PMO and multiple file output not currently supported
and how to avoid it - is a much larger issue.
When the observations within a single assimilation window are assimilated and the state is updated, the observation sequence file is queried to see if there are more observations. If there are more observations, the model is advanced and the cycle continues. The Manhattan version of DART allows subroutine-callable models (lorenz_63, bgrid_solo and others) to continually update the same output files (analysis.nc, filter_output.nc, perfect_output.nc, preassim.nc, true_state.nc) with all the timesteps.
The input.nml:perfect_model_obs_nml:single_file_out = .true.
is supported for these models.
This is what is meant by 'single_file' ... a single file has the output for all the timesteps.
Models that are not subroutine-callable must have input.nml:perfect_model_obs_nml:single_file_out = .false.
(which is the default). The output files for these models are only allowed to have a single timestep in them - we have plans to support multiple timesteps, but this feature is not currently available.
NOTE: The filter
program has these same restrictions; the single_file_out
namelist variable appears in both the perfect_model_obs and filter namelists.
It is very common practice to have the observations for a single assimilation cycle in separate files.
User-supplied scripting then links the appropriate observation sequence file to obs_seq.[in,out]
and perfect_model_obs or filter reads in just those observations, does what it needs to do, writes out the output files - and stops. The scripting then renames the files with some date/time and then, if needed, advances the model to the next assimilation cycle and links the next observation sequence file ... There are many examples throughout the DART/model/*/shell_scripts directories for many models and queueing systems.
from dart.
Hello Tim,
Thanks for the detailed instructions. Now I know that the wrf model should be advanced outside the PMO. To do so, I created an advance_model.csh script in the ${DART}/model/wrf/shell_scripts. After ./perfect_model_obs.exe, another error occured:
PE 0: advance_state Model advance time is now: day= 152487 sec= 0
PE 0: advance_state Model advance time NOT what requested: day= 152487 sec= 21600
ERROR FROM:
PE 0: advance_state
routine: advance_state
message: Model advance complete but model time not correct
The problem occurred when calling the subroutine advance_state in ${DART}/assimilation_code/programs/perfect_model_obs/perfect_model_obs.f90.
if(ens_handle%my_pe == 0) call advance_state(ens_handle, 1, next_ens_time, async, …
where the subroutine advance_state is in the ${DART}/assimilation_code/programs/perfect_model_obs/perfect_model_obs.f90. The subroutine advance_state is performed in the following 3 main steps:
step 1: advance the wrf model to the target_time
rc = shell_execute(trim(adv_ens_command)//' '//trim(system_string)//' '//trim(control_file_name))
where the adv_ens_command is ../shell_scripts/advance_model.csh
step 2: read in the wrf states, including the ens_time, from the wrfinput_d01 file
call read_state(ens_handle, file_info_input, read_time_from_file, ens_time)
step 3: check that the wrf model is advanced correct
if (ens_time /= target_time) then
"Model advance complete but model time not correct"
…
endif
The above-mentioned errors occured in step 3.
My first question is:
The target_time is calculated as model_time + time_step, where time_step is determined by the wrfinput_d01 file (wrf%dom(1)%dt), which is 6 h (21600 s). After running WRF model outside PMO, ens_time is read from the wrfinput_d01. However, ens_time should be "day= 152487 sec= 0" unless wrfinput_d01 is replaced by another file such as wrfrst* file at the target_time. Does this mean that wrfinput_d01 file should be updated between step 2 and step 3? If so, the wrfinput_d01 should be replaced by wrfrst* file once the ./wrf.exe is completed. Am I right?
My second question is:
If the wrfinput_d01 file is replaced by wrfrst* file by the "../shell_scripts/advance_model.csh" script once the ./perfect_model_obs.exe is completed, how is the assimilation experiment performed by ./filter.exe? To be specific, the execution of ./filter.exe will also use the "../shell_scripts/advance_model.csh" script. In OSSE, a perturbation run (or experiment) should be performed with the simulated observations under evaluation added to the wrfinput_d01. After the execution of ./perfect_model_obs.exe, and when I want to perform the ./filter.exe, how should the wrfinput_d01 file be updated in the "../shell_scripts/advance_model.csh" script?
Could you please give some suggestions?
Any replies would be highly appreciated!
Yongbo
P.S., the shell scripts in ../shell_scripts/advance_model.csh are shown below:
set process = $1
set num_states = $2
set control_file = $3
#block 1
set temp_dir = 'advance_temp'${process}
\rm -rf $temp_dir || exit 1
mkdir -p $temp_dir || exit 1
cd $temp_dir || exit 1
set WRF_DIR = /data3/zyb/DART_RTTOV/DART/models/wrf/work/WRF_RUN/WRF/run
ln -s ${WRF_DIR}/wrf.exe . || exit 1
cp -r ${WRF_DIR}/namelist.input . || exit 1
cp ../input.nml . || exit 1
#Loop through each state
set state_copy = 1
set ensemble_member_line = 1
set input_file_line = 2
set output_file_line = 3
while($state_copy <= $num_states)
set ensemble_member = `head -$ensemble_member_line ../$control_file | tail -1`
set input_file = `head -$input_file_line ../$control_file | tail -1`
set output_file = `head -$output_file_line ../$control_file | tail -1`
#Block 2: copy/convert the DART state vector to something the model can ingest.
#added by zyb: input_file is wrfinput_d01, and output_file is perfect_output_d01.nc
#wrfinput_d01 and wrfbdy_d01 are placed in ${WRF_DIR} directory
#Block 3: advance the model
cd ${WRF_DIR}
echo ${WRF_DIR}
mpirun -np 32 ./wrf.exe
#Block 4: Move the updated state vector back to CENTRALDIR
mv wrfout_d01* ../../../$output_file || exit 4
cd ../../../$temp_dir
@ state_copy++
@ ensemble_member_line = $ensemble_member_line + 3
@ input_file_line = $input_file_line + 3
@ output_file_line = $output_file_line + 3
end
cd ..
\rm -rf $temp_dir
\rm -rf $control_file
exit 0
from dart.
Hello Yongbo,
The DART wrf/tutorial/README.md https://github.com/NCAR/DART/tree/master/models/wrf/tutorial
has excellent examples and provides a lot of information about running a DART experiment for a couple cycles.
This should answer your questions about timestepping and file motion and provide useful scripts.
You should definitely work through this before attempting anything more complicated.
from dart.
Related Issues (20)
- loops over calendar types are unneeded HOT 2
- Feature request: rework some of the dart netcdf utilities mod HOT 3
- add topic tag "data-assimilation" HOT 1
- bug: obs_diag/threed_cartesian & threed_sphere 'how to view rank histograms' doc links are broken
- bug: Updates to snow mass and snow height resulting from snow repartitioning in dart_to_clm.f90 are causing CLM to generate NaN fluxes to the coupler and NaN state variables. HOT 6
- Diagnostic failure (diagnostics_obs.csh) within WRF-DART Tutorial
- DART with WRF 4+ HOT 2
- cam-se fails if CLDICE, CLDLIQ, or Q (or PS) is not in the state vector HOT 6
- CLM SIF forward operator can lead to NaN values during assimilation testing HOT 2
- Feature request: Develop Aether cube sphere interface
- ☠️ CAM-SE vertical coordinate difference across model version HOT 1
- MPAS 8 vs 7 HOT 7
- bug: cam-se state missing on filter write restarts - probably not cam-se problem HOT 5
- Negative SIF value from the CLM SourceMods HOT 4
- bug: CLM water/snow/radiation/energy balance checks turned off when DA turned on HOT 2
- Manually generating obs_epoch.nc file within WRF-DART Tutorial fails
- Feature request: ...add a new DART quality flag for output in obs_seq.final HOT 2
- collection of garbage files in the repo to remove
- DART-LPF algorithm has incorrect pf_enkf_hybrid default option HOT 1
- Feature request: add QC flag instead of filter crash, when the ensemble member beyond the bounds setting in qceff_table.csv file. HOT 12
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dart.