Understanding PCPCombine behaviour #2694
Replies: 1 comment 4 replies
-
|
Hi:
You mention seeing differences when computing a day 2 total. What type of differences are seeing between the R and MET versions? Are they small or large? Are the spatial patterns consistent between the two scripts or do these differ? Are the differences still present for the non-DA runs? Having more information about the differences may help understand what is going on. I have seen MET produce differences previously as a result of the way data is packed. However, this would produce only very small differences if it was impacting the results here. It's also possible something isn't working as expected in MET/METplus. Having some examples would help track down what may be causing these differences if you are able to upload data and configuration to test one of the commands using the instructions. Christina |
Beta Was this translation helpful? Give feedback.
-
|
@CPKalb working on it! The differences are substantive, max values are ~10 mm different for example. I am struggling to understand what could cause such differences for a scenario which involves reading in two files and subtracting one from the other... |
Beta Was this translation helpful? Give feedback.
-
|
Differences that large are probably not likely due to data packing. It seems like there must be something happening differently in the two calculations but figuring out what that is will be the challenge. Let me know if you are able to upload data and I can take a look to see. Or, if it's easier you could post a log here. We may need to turn the log verbosity up (if it isn't already) to help figure this out. Christina |
Beta Was this translation helpful? Give feedback.
-
|
Ok. I think I am getting somewhere. Subtract does work. Once I got myself untwisted. However the use case where I need to sum and then subtract doesn't seem to be working quite as I would like. I've constructed a complex use case (attached), which only works if all the files are in the same directory and conform to the same template, even though clearly MET tools tend to require CF compliance, MET netcdf output is not and I don't know whether this causes some other issues. To get the wrapper to work I've had to copy the t+0h field into the PCPCombine output dir. It doesn't accept a comma separated list of input dirs or file templates. Both options fail. So, bottom line, the output names from one PCPCombine run have to conform to the input template and be in the saem directory. This is done with MET11.0.0 and METplus 5.1. `[config] LOOP_BY = INIT INIT_TIME_FMT = %Y%m%d%H LEAD_SEQ = 24 MODEL = LF FCST_IS_PROB = false FCST_PCP_COMBINE_RUN = True [add3h] FCST_PCP_COMBINE_METHOD = SUM FCST_PCP_COMBINE_INPUT_NAMES = precipitation_amount FCST_PCP_COMBINE_OUTPUT_ACCUM = 24H FCST_PCP_COMBINE_INPUT_DIR = /scratch/frmm/NGVER/netcdf_trial_o-aa067 FCST_PCP_COMBINE_INPUT_TEMPLATE = Fcast_{init?fmt=%Y%m%d}{init?fmt=%02H}00{lead?fmt=%HHH}globalprecip.nc [subtp0] FCST_PCP_COMBINE_METHOD = SUBTRACT FCST_PCP_COMBINE_INPUT_NAMES = precipitation_amount FCST_PCP_COMBINE_OUTPUT_ACCUM = 24H FCST_PCP_COMBINE_INPUT_DIR = {OUTPUT_BASE}/PCPCombine/PCPCombine_sum/o-aa067 FCST_PCP_COMBINE_INPUT_TEMPLATE = Fcast_{init?fmt=%Y%m%d}{init?fmt=%02H}00{lead?fmt=%HHH}globalprecip.nc As for the command line tests, I am now dealing with significant negative precip values which are a bit of a headache and we don't get those with the UM as it accumulates from the start. You might get small negative values mostly due to floating point/rounding issues. Not sure how I can fix that or even if there should be any negatives. If I did have to deal with them, any suggestions? All the black areas on the plot have sig negative precip. |
Beta Was this translation helpful? Give feedback.
-
|
Hi: MET can read both MET version netCDF and CF compliant netCDF. Specifically, there are 3 types of netCDF files MET can read, NetCDF files following the CF conventions, netCDF files containing WRF output post-processed using wrf_interp, or netCDF files produced by the MET tools themselves. So, there shouldn't be any issue with reading the output from PCP-Combine back into PCP-Combine. PCP-Combine can actually be run using files with different names that are in different directories. To do this, the USER_DEFINED option is needed, rather than subtract. USER_DEFINED gives the user to specify the Pcp-Combine command directly to allow for more flexibility. For a subtraction, the USER_DEFINED setup would look something like this: FCST_PCP_COMBINE_METHOD = USER_DEFINED FCST_PCP_COMBINE_INPUT_DIR = {OUTPUT_BASE}/PCPCombine/PCPCombine_sum/o-aa067 FCST_PCP_COMBINE_INPUT_TEMPLATE = Fcast_{init?fmt=%Y%m%d}{init?fmt=%02H}00{lead?fmt=%HHH}globalprecip.nc For the USER_DEFINED command above, MET subtracts the second file from the first. Regarding the negative values, could you post an image of the individual fields that are being subtracted so we can see if it makes any sense for them to be there. It seems like we shouldn't be seeing large negative values if the calculation is doing what it is supposed to, so there may still be a setting that needs to be adjusted. Negative values can't be fixed in the output, but they can be easily fixed the next time you read them into MET (assuming you are running Grid-Stat, Point-Stat, or some other tool on the output). To do this, you would want to set censor_val and censor_thresh, in the configuration for whatever tool is being run on the file with negative values. For Grid-Stat, this would be set in the variable options and would look something like this: FCST_GRID_STAT_VAR1_OPTIONS = censor_thresh = < 0; censor_val = 0.0; This would reset all negative values to 0. Does this help? Christina |
Beta Was this translation helpful? Give feedback.
-
I am struggling to get PCPCombine accumulations to match those calculated using independent means. I am taking the same files fed into PCPCombine and an R script (netcdf) to check. I was trying to understand whether the behaviour of the METplus / MET functionality that has been added for the Met Office, to subtract t+0 precip (i.e. the DA precip accumulated from t-3h) from the accumulation, was doing what I thought it should be doing. Non-DA runs do not have t+0h precip to subtract.
FCST_PCP_COMBINE_USE_ZERO_ACCUM = True
This is set to false if you have no t+0h and true if you do, i.e. use it.
This was implemented specifically for the UM which accumulates precip from the start of the run, and t+0h always needs to be subtracted for accumulations which may feature t+0h, i.e. t+1h for hourly, t+3h for three-hourly, t+6h for 6h etc. Later lead times it makes no difference, because computing a day 2 total is simply subtracting the t+24h from the t+48h. For this we use the SUBTRACT option, which I thought worked ok but in my latest tests even this doesn't agree with the independent calculation. The log file suggests it picking up the right files and doing the right thing. It does look like it's subtracting but the numbers are not the same.
Roll up LFRic which is doing things differently. Now we have discrete 3h or 6h accumulations which need to be added, but we still have a t+0h that needs to be subtracted from the t+3h (or t+6h for the DA runs, or whichever is the first accumulation from t+0h), which is really awkward. I've questioned why this is happening but it seems it's unlikely we can do anything about this. I can't reconcile any numbers on this with ADD or SUM either. It does seem to be picking up the files ok, but what it does with t+0h is unclear. The log file isn't that forthcoming. Specific mention of the switch and when it is doing something like "Subtracting t+0h precip now" might be good.
So, question time.
For LFRic it might be a case of having to run PCPCombine twice, e.g. for a 24h accum I first run ADD (to add 4 or 8 accums together) and then again with SUBTRACT just for the first accum of the forecast (to subtract t+0h).... but I am still not sure why I can't get the numbers to agree with independent tests.
Beta Was this translation helpful? Give feedback.
All reactions