-
Notifications
You must be signed in to change notification settings - Fork 16
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
Query with dates of CMIP6 outputs with heatwaveR - NAs appear after ts_whole <- make_whole_fast(ts_xy) #13
Comments
Hello, |
Hi Robert
Yes I use the as.Date function with the origin option to get them to the 2010-01-01 format as the cmip time outputs are just numeric.
Best,
Meg
Get Outlook for iOS<https://aka.ms/o0ukef>
…________________________________
From: Robert William Schlegel <notifications@github.com>
Sent: Thursday, January 21, 2021 10:07:19 AM
To: robwschlegel/heatwaveR <heatwaveR@noreply.github.com>
Cc: Meg Rounsley <mr17809@bristol.ac.uk>; Author <author@noreply.github.com>
Subject: Re: [robwschlegel/heatwaveR] Query with dates of CMIP6 outputs with heatwaveR - NAs appear after ts_whole <- make_whole_fast(ts_xy) (#13)
Hello,
Without looking into this in too much depth, my first question is if you have made certain that the date values you are getting from the CMIP6 data are set to date values with the as.Date() function specifically. The issue may be that the CMIP6 data are still some sort of POSIX date value.
Let me know what you find.
All the best,
-Robert
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#13 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ASRD363T2TCMHSLLZAQ2VF3S274FPANCNFSM4WMRAKVQ>.
|
Hello Meg, Regardless of what it may be, there is some sort of hidden date info in your data.frame that is causing the mismatch. Even though it doesn't show up when you look at the structure of the data. The fix is to simply convert your dates to character strings and then back to dates. Everything should work after that. C'est la vie, eh? library(tidyverse)
library(heatwaveR)
M <- readRDS(gzcon(url("https://github.com/megrounsley/mrounsley_dir/raw/main/modelsubsetforheatwaveR.Rds"))) %>%
mutate(t = as.Date(as.character(t)))
clim <- ts2clm(data = M, climatologyPeriod = c("2010-01-01", "2014-12-30"))
All the best, |
Thats great thank you very much! Best, |
Regarding which OS I've use I've switched the code between linux, Mac and windows!! |
Curious. Thanks for letting me know. |
Hi there,
In R I am using the heatwaveR package to produce heatwave metrics for CMIP6 sea surface temperature outputs, except with using the ts2clm() function the output is only ever NA whichever CMIP6 model I am using. I’ve found it is at the line
ts_whole=make_whole_fast(ts_xy) that the NAs appear.
In that ts_xy looks like
but ts_whole looks like
and within the make_whole_fast() function I found that the NAs appear at the line
ts_merged <- merge(ts_full, data, all.x = TRUE).
A colleague tried manually playing around with the merge command, as there are options as to how the function deals with missing values or things that don't match perfectly. By tweaking it so it includes all data in all dimensions, using the command: merge(ts_full, data, all = TRUE), you get the following table
So strangely, the model 'dates' don't seem to be read in the same way as the dates in the table it is trying to merge with.
For example, rows 1 and 2 of ts_x look to be exactly the same ("2010-01-01"), but if we check what R thinks it disagrees
ts_merged3$ts_x[1] == ts_merged3$ts_x[2]
[1] FALSE
It does correctly recognise that all of the entries in ts_x are dates. E.g. checking if it is a date using the inherits command:
inherits(ts_merged3$ts_x[1],'Date')
[1] TRUE
I don’t have this issue with satellite sea surface temperature datasets (OISST) only ones derived from the CMIP6 models. However, both types of data are dealt with exactly the same to produce a table of lon, lat, t and temp to then be inputted into the heatwaveR workflow. Is actually some time component as well which is not shown and although the model and new table have the same date, they are different times on those dates and therefore are technically not equal? I wonder if you can help or suggest a way to correct this issue I am having.
Reproducible code example:
Created on 2021-01-21 by the reprex package (v0.3.0)
Meg Rounsley
mr17809@bristol.ac.uk
The text was updated successfully, but these errors were encountered: