Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updating WRF-DART tutorial obs converter doc and NCEP Prepbufr converter docs #823

Merged
merged 13 commits into from
Feb 6, 2025

Conversation

braczka
Copy link
Contributor

@braczka braczka commented Feb 3, 2025

Description:

Removed the NCEP atmospheric prepbufr observation conversion (optional instructions) in Step 3 of the WRF-DART tutorial because they were not designed to replicate the tutorial obs_seq file and were incorrect. Condenses step 3 to only a summary of major conversion steps and provides links to prepbufr converter and create_real_obs 2 stage converters in the observation converter documentation.

I modified the step 3 instructions and inserted them into a 'Quickstart Section' of the prepbufr conversion section. This provides the users with all necessary steps in the 2 stage conversion process, including the download of the raw prepqm file from campaign storage and/or RDA download for ds0900 or ds370 archived data. This helps clarify the confusion of the 2 stage conversion process (prepqm --> ascii text --> obs_seq) by having all steps in one place. This does not resolve the software issues related to github issue 634, (gfortran issues etc) but is an improvement, because it provides a complete conversion example using Derecho and intel compiler.

Fixes issue

This fixes issue 792 and improves (but does not completely fix) issue 634

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Documentation update

Documentation changes needed?

  • My change requires a change to the documentation.
    • I have updated the documentation accordingly.

Tests

I have run the quickstart instructions on Derecho using the intel compiler.

Checklist for merging

  • Updated changelog entry
  • Documentation updated
  • Update conf.py

Checklist for release

  • Merge into main
  • Create release from the main branch with appropriate tag
  • Delete feature-branch

Testing Datasets

  • Dataset needed for testing available upon request
  • Dataset download instructions included
  • No dataset needed
    Instructions provided on how to obtain prepqm from campaign or from RDA archive.

Generating quickstart instructions based on WRF-DART
step 3 conversion instructions
Moving prepbufr converter instructions
from WRF-DART tutorial to prepbufr docs.
Add warning that instructions to reproduce
the WRF-DART tutorial obs are not provided.
The previous WRF-DART tutorial obs conversion section
was migrated to prep_bufr and provides
full example of raw prepqm file conversion to obs_seq.
@braczka braczka added Documentation Improvements or additions to documentation Derecho issues related to running on NCAR's new supercomputer wrf Weather Research & Forecasting Model labels Feb 3, 2025
@braczka braczka requested a review from mjs2369 February 3, 2025 15:26
@braczka
Copy link
Contributor Author

braczka commented Feb 3, 2025

@mjs2369 i added you as a reviewer because of your good work with github issue 634. This PR likely needs more warnings and links related to the compiling/software issues outlined there. Not intended as a fix for 634, but a good upgrade in NCEP prepbufr instructions.

@hkershaw-brown
Copy link
Member

@braczka do you have someone who works with prepbufr data who can review this? Someone on the team who regularly uses prepbufr data in assimilations?

@braczka
Copy link
Contributor Author

braczka commented Feb 3, 2025

@hkershaw-brown Not sure if 'regular' is the word, but @kdraeder or @mgharamti have done this in the past I think.

@braczka
Copy link
Contributor Author

braczka commented Feb 3, 2025

I didn't merge in the latest changes from main, and I am getting a lint_for_svn_on_pr. Should I merge locally and re-push?

@hkershaw-brown
Copy link
Member

I didn't merge in the latest changes from main, and I am getting a lint_for_svn_on_pr. Should I merge locally and re-push?

Yup stay up to date with main. You can merge locally and push (make sure your local main is up to date with NCAR/main)
or you can click "update branch" on the pull request, and pull this to your local repo

Screenshot 2025-02-03 at 10 47 52 AM

The lint_for_svn_on_pr is not required to pass, it just flags any legacy svn info that is hanging around in files.

@mgharamti
Copy link
Contributor

Brett, thanks for working on this.
I will provide a review

@braczka braczka requested a review from mgharamti February 3, 2025 18:48
@braczka
Copy link
Contributor Author

braczka commented Feb 3, 2025

Brett, thanks for working on this. I will provide a review

Thanks @mgharamti, appreciate it. I also got a little loose with my use of the cosblocking tool -- I think I just took Nancy's and put it in my work directory, but maybe should have a better location for it. There is also still some redundancies between the 'Quickstart' section and the 'Prepbufr Overview' section, that I didn't fully address.

@nancycollins
Copy link
Collaborator

some history on the cosconvert tool here:
the 'cosconvert' tool used to be provided in a public place by the DSS folks on previous supercomputers. at some point they switched to uncosblocking files on a separate linux box before putting them on the DSS, so they didn't need to support it on the supers anymore. we sometimes ask for different versions of the DSS files and they can be given to us still cosblocked, especially older files. i asked chi-fan (from DSS) about it and he sent me the source code of the tool.

i talked to bob dattore in DSS about the tool because his name is on the source. he said it either has no license, or it could have a creative commons license, but we were free to do whatever we wanted with it. i have a copy in my home dir because i needed it for uncosblocking some older files. maybe a copy of it should go into the prep_bufr directory? it's probably not needed for more recent files, but if it is needed it might be hard to track down the source code again sometime in the future.

Copy link
Contributor

@mgharamti mgharamti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Brett, I appreciate all the efforts that went into this. This is beyond a doubt a very useful addition to the prepbuf obs saga. I have a bunch of comments and suggestions that will help clarify all of the obs preparation steps. I'd be happy to take another look after making the changes.

cd $DART_DIR/observations/obs_converters/NCEP/prep_bufr
./install.sh

Confirm the exe directory contains the executables ``prepbufr.x``, ``prepbufr_03z.x``,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

make sure naming of the executable is correct: prepbufr_03Z.x (Z upper case)

::

cd $DART_DIR/observations/obs_converters/NCEP/prep_bufr/work
./quickbuild.sh
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would add a sentence after running quickbuild telling the users what new executables they expect to find in the work directory. Is it only advance_time (and preprocess)?



- Obtain the PREPBUFR observations for your desired time. You can go to the
the campaign collections directory as:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a sentence saying that in this example, we will download data from the month of June, 2016.


::

/glade/u/home/bmraczka/cosconvert -b A25366-201706prepqmB.tar
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, if I recall there was an issue with the cosconvert provided by RDA. I also have a copy of the same executable in home directory. For the sake of this documentation, I suggest having a copy on /glade/campaign/cisl/dares/Observations/bufr/progs. We can point the users to use the one in our team campaign directory rather than our own. So, I would re-write the cos-unblocking step as:

/glade/campaign/cisl/dares/Observations/bufr/progs/cosconvert -b A25366-201706prepqmB.tar


::

/glade/u/home/bmraczka/cosconvert -b A25366-201706prepqmB.tar
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Didn't you rename the tar file to prepqm in the previous copying step?

cp A25366-201706prepqmB.tar $DART_DIR/observations/obs_converters/NCEP/prep_bufr/data/prepqm

The cosconvert won't work because the name of the file is different. I suggest keeping the original name. Unless you actually created a directory called prepqm inside observations/obs_converters/NCEP/prep_bufr/data. I would also tell the user to run cosconvert in the DART directory not the RDA directory. My suggestion is to be more verbose here.


cd $DART_DIR/observations/obs_converters/NCEP/prep_bufr/work
cp ../exe/\*.x .
./prepbufr.csh 2017 04 27
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because, we unzipped the files in previous steps they have a .nr extension. Executing the ./prepburf.csh 2017 06 27 with result in an error:

MISSING INPUT FILE: cannot find either ../data/prepqm/prepqm17062706 or ../data/prepqm/prepqm17062706.gz Script will abort now.

Perhaps, edit this as follows:
set BUFR_in = ${BUFR_idir}/prepqm${sdtg}.nr

format. Confirm that ``temp_obs.20170427*`` files within your
``~/data/prepout directory`` exist. Please note that the script can function
with only the *06* prepqm input file, but will need the
*12* and *18* files to run to completion.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The script did the 06, 12, and 18Z files but then aborted because it asked for the obs at 2017062800 file. This could be fixed perhaps by changing files_per_day in prepbufr.csh but no big deal. I think the idea is clear.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the scripting here is old and creaky. i think even if you don't ask for a "daily" file, that it still wants to process a day's worth of obs, which will output 4 intermediate files.

max_num = 800000,
select_obs = 0,
ObsBase = '../../prepbufr/data/prepout/temp_obs.',
daily_file = .false.,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be useful to describe this parameter. If this is set to true, then the program will look for temp_obs.{yyyy}{mm}{dd} files but since we do 6-hourly cycling we set this to .false.

::

cd $DART_DIR/observations/obs_converters/NCEP/ascii_to_obs/work
./create_real_obs
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I ran this and it created the obs sequence files for 06, 12, and 18Z. But it also gave me the following. Is it something we should look into? Or did I do something wrong?

 ERROR FROM:
  source : utilities_mod.f90
  routine: open_file:
  message:  Cannot open file "../../prep_bufr/data/prepout/temp_obs.2017062724" for read
  message: ...  File may not exist or permissions may prevent the requested operation
  message: ...  Error code was           29

Copy link
Collaborator

@nancycollins nancycollins Feb 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hi moha - i think this may be related to the issue that observations directly on the boundary time between 6H windows can occur in either the previous or following file. i think the converter tries to open the next file to collect any obs which are on the initial time boundary. OR - it's related to the script trying to do 4 6H files at a time if you pick "daily=false".

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i just went through the prepbufr script again. if you say "daily=true" it makes a single 24 hour output file. if you say "daily=false" it still tries to convert a full day's worth of data but outputs 4 6-hour files. to finish up a day, it needs the 0Z and 6Z files from the following day to be available. (it creates the 6, 12, and 18 h files just fine, but ends with an error when it tries to open the 0Z and 6Z file from the next day.)

into a readable tar file. On the NSF NCAR machine *yellowstone*, run:
| *> /glade/u/home/rdadata/bin/cosconvert -b rawfile data.tar*
into a readable tar file. On the NSF NCAR machine Derecho run:
| *> /glade/work/bmraczka/cosconvert -b data.tar*
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See my previous comments on cosconvert

@braczka braczka marked this pull request as draft February 4, 2025 18:09
@braczka
Copy link
Contributor Author

braczka commented Feb 4, 2025

Based on standup conversation -- I put this on draft such that I can implement conversion instructions using RDA download and avoid use of cosconvert tool if possible.

@braczka
Copy link
Contributor Author

braczka commented Feb 5, 2025

Latest commit includes fixes based on Helen/Moha comments. We may update the docs to switch from campaign to RDA download if we can avoid cosconvert.

@nancycollins
Copy link
Collaborator

i'm sorry for the confusion. i had thought the files on the public RDA site were already unblocked and it was just because we asked for special versions that we had to do the extra step. but i just downloaded a couple files directly off the public RDA site and they also needed to be unblocked before they could be read. so i'm proposing we leave the derecho instructions as-is -- that people can just copy the files off campaign storage and unblock them before they continue. the instructions for how to download them off the RDA website are still there for people who aren't on derecho.

@braczka
Copy link
Contributor Author

braczka commented Feb 5, 2025

Thank you Nancy -- I will keep the instructions as is, and add a few notes about the ds090, ds377 and CAM6 reanalysis observation differences. We should discuss at tomorrow's standup what we are OK to release to the user. Sorry - I am still a bit fuzzy on the discussion yesterday. Are only the newest ACAR obs restricted ?

@braczka braczka marked this pull request as ready for review February 5, 2025 20:57
@braczka
Copy link
Contributor Author

braczka commented Feb 5, 2025

I believe all comments have been addressed. Please have a look. Thank you @mgharamti , @nancycollins and @hkershaw-brown.

Comment on lines 667 to 668
operator are located in the `WRF namelist documentation.
<../../../models/wrf/readme.html#namelist>`__
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:doc: or :ref: rather than html

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do you do a :doc: ref when you want to refer to a header like #namelist, not just the page?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can add an anchor in wrf/readme.rst

e.g.

.. _wrfnamelist:


Running the install.sh script will build the library and main executable. You will probably have to edit this script to
set which fortran compiler is available on your system.
Running the ``install.sh`` script located within the ``~/observations/NCEP/prep_bufr`` directory will build the library
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

home directory:
~/observations/NCEP/prep_bufr
should be

$DART_DIR/observations/NCEP/prep_bufr

@hkershaw-brown
Copy link
Member

looks good to me Brett! I only checked the links and skimmed through the text (~ vs $DART ) was the only thing that stood out.

Copy link
Contributor

@mgharamti mgharamti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Everything looks good to me, thanks Brett.

- sounding temps (120),
- aircraft temps (130,131),
- dropsonde temps (132),
- mdcars aircraft temps (133 ???),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove "???"

@braczka
Copy link
Contributor Author

braczka commented Feb 6, 2025

@hkershaw-brown This should be good to go -- still getting 'lint_for_svn' build issues although I am up to date with main as far as I can tell.

Copy link
Contributor

@mgharamti mgharamti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great Brett and good to go.

@hkershaw-brown hkershaw-brown merged commit fd3a813 into main Feb 6, 2025
4 of 5 checks passed
@hkershaw-brown hkershaw-brown deleted the prepbufr_docs branch February 6, 2025 18:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Derecho issues related to running on NCAR's new supercomputer Documentation Improvements or additions to documentation wrf Weather Research & Forecasting Model
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants