-
|
I'm trying to use pcp_combine (MET v.9.0) to sum hourly precip files (from HRRR output, so in GRIB2 format) into 6-hour increments. I get some kind of error no matter which method I try to use.
The file list shows that, indeed, the file HRRR_slim_t03z_f22.grib2 has zero size:
But why is that particular file even being involved in the summing? I only want HRRR_slim_t03z_f0[1-6].grib2 to be involved, and the valid times of these files are correct (using wgrib2 -VT to check). HRRR_slim_t03z_f22.grib2 doesn't even have a valid time within the requested range!
Not sure what that syntax error means, but I'm guessing this has nothing to do with that.
I'll admit that one potential sticking point in doing this is that the input files have two different APCP arrays in them...one is 1-hour accumulations...the other is running-forecast-total accumulations (see below example):
So, a few questions. 1) Is there a way to specify record number 12 (the one I actually want) when calling pcp_combine instead of just the array title (APCP)? 2) How to solve the problem using -sum. Thanks. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 2 replies
-
|
@Jeff-Duda I know you can specify the record number in the level information. This is from the MET documentation: The “level” entry specifies a level type and value: ZNNN-NNN for a range of vertical levels I may have had a similar problem with pcp_combine. I was using "-sum" with "-pcprx f.*.2019060600", and got an error when it tried to read a file "f024.2019060700.PRATE", though the format of the file did not match the argument given to -pcprx. I fixed it by moving around the files structure differently, so it wasn't a big deal, just odd. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your question @Jeff-Duda. And a big thanks @malloryprow for the answers on this! @Jeff-Duda, I'll build on what was already said, taking each problem you're having in turn. The problem you've encountered with pcp_combine reading in files that are not associated with your MET run is due to the design of the tool: pcp_combine is supposed to be flexible enough to read in data files ranging widely in format, so when you ran As @malloryprow correctly indicated, this issue can be resolved with the
to indicate a range of values for the files you're interested in. The second problem, the one you encountered when running pcp_combine in -add mode, was due to a syntax error. When using the
Hopefully that helps set things in the right direction. If there are still issues with this pcp_combine run please let us know with a response here. If the information provided has helped you solve this issue, please let us know by marking one of the comments in this discussion as the answer (there's a button in the lower left corner of each comment box to do so) and I'll mark the discussion as closed. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks to both of you for the quick and helpful response. Since Mallory's suggestion would require me to be constantly moving files around, although I understand how that would work, I opted to use j's method. pcp_combine outputs some ambiguous wording regarding the separation between record numbers 11 and 12 in my files which forced me to try specifying Example output:
One issue that stuck me a bit was the syntax of specifying the field entry; there are both single and double quotes involved. pcp_combine did not like it when I reversed the usages, which I was not expecting. Finally, I request that this type of field specification be added to the documentation for the pcp_combine tool. I know this information can be found elsewhere within the total MET documentation, but I would never have known where to search for it since pcp_combine was all I was trying to use. And even though I have used MET utilities for many years now, I never remember that you can specify some config file options for the bigger tools (e.g., GridStat, MODE, etc.) on the command line. It would help if a note indicating that this can be done, with a link to a page that shows how to do it, could be added to the documentation. But I do have the method working now, so thank you! |
Beta Was this translation helpful? Give feedback.
-
|
@Jeff-Duda glad you were able to get these details sorted out. I saw your request to update the documentation. I made the following change in a feature branch I'm working on right now: Does that look sufficient? FYI, the way we resolve this discussion is by marking one of the responses as being a the "Answer". Either the person asking the question or one of the respondents can do that. We've also decided that once the poster confirms the answer, we'll "LOCK" the discussion to prevent future posts. That encourages folks to post new questions in new discussions rather than old ones. We've found that we lose track of new posts to old discussions. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, John. Looks good. I've marked a response as "the answer" |
Beta Was this translation helpful? Give feedback.
Thank you for your question @Jeff-Duda. And a big thanks @malloryprow for the answers on this!
@Jeff-Duda, I'll build on what was already said, taking each problem you're having in turn.
The problem you've encountered with pcp_combine reading in files that are not associated with your MET run is due to the design of the tool: pcp_combine is supposed to be flexible enough to read in data files ranging widely in format, so when you ran
pcp_combine 20190815_03 01 20190815_09 06 HRRR_precip_06h_f06.ncthe tool by default attempts to read in all files in the runtime directory (or-pcpdirif specified). Since one of the files was unreadable with the provided commands, the tool errors out.As @m…