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

plotstyle() ignores units -- and anything it considers to be one #54

Open
0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q opened this issue Feb 2, 2023 · 4 comments
Assignees
Labels

Comments

@0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q
Copy link
Member

Differentiating entities by unit ("x (y)") in plotstyle() does not work.

@johannah-pik

Trucks;Trucks;#ff6a6a;;
ICE;ICE;#8c8c8c;;
NG;NG;#d11141;;
Trucks (<3.5t);Trucks (<3.5t);#ff7f50;;
Trucks (3.5t-16);Trucks (3.5t-16);#8b0000;;
Trucks (>16) ;Trucks (>16) ;#fa8072;;

> plotstyle(c('Trucks', 'Trucks (<3.5t)', 'Trucks (3.5t-16)', 'Trucks (>16)'))
   Trucks    Trucks    Trucks    Trucks 
"#ff6a6a" "#ff6a6a" "#ff6a6a" "#ff6a6a" 

You might want to replace the parentheses with brackets (Trucks [<3.5t]) to get that working.

Due to code-quirks, these however work

(0−3.5t);(0−3.5t);#B0EBEE;;
(7.5t);(7.5t);#2893A9;;
(40t);(40t);#172f56;;
(26t);(26t);#25467c;;
(18t);(18t);#325fa4;;

> plotstyle(c('(0−3.5t)', '(7.5t)', '(40t)', '(26t)', '(18t)'))
 (0−3.5t)    (7.5t)     (40t)     (26t)     (18t) 
"#B0EBEE" "#2893A9" "#172f56" "#25467c" "#325fa4" 

But maybe you want to be consistent and change it there, too.


@dklein-pik: The origin of these got wiped by the move from svn to git

Forcing|CO2 (W/m2);CO2;#331a00;;
Forcing|CH4 (W/m2);CH4;#ffe7a0;;
Forcing|N2O (W/m2);N2O;#44ba97;;
Forcing|F-Gases (W/m2);F-Gases;#ff9977;;
Forcing|Aerosol (W/m2);Aerosol;#6e7700;;
Forcing|Other (W/m2);Other;#08262f;;

and Anastasis isn't around anymore
Emi|GHGtot (Mt CO2-equiv/yr);GHG Emissions (Mt CO2-equiv/yr);red;;

> plotstyle(c('Forcing|CO2 (W/m2)', 'Forcing|CH4 (W/m2)', 'Forcing|N2O (W/m2)',
+             'Forcing|F-Gases (W/m2)', 'Forcing|Aerosol (W/m2)',
+             'Forcing|Other (W/m2)', 'Emi|GHGtot (Mt CO2-equiv/yr)'))
    Forcing|CO2     Forcing|CH4     Forcing|N2O Forcing|F-Gases Forcing|Aerosol   Forcing|Other 
      "#331a00"       "#ffe7a0"       "#44ba97"       "#ff9977"       "#6e7700"       "#08262f" 
     Emi|GHGtot 
          "red" 

but plotstyle() seems to be mostly your thing.

Should I clean those up in ./inst/extdata/plotstyle.csv? I'm working on an improvement to plotstyle() and would prefer not to carry over legacy edge cases, but issue a warning for entities with units instead.

@orichters
Copy link
Contributor

orichters commented Jul 9, 2024

@dklein-pik: Can we maybe find a solution for that? The NAVIGATE template contains a variable named Final Energy|Transportation (w/ bunkers), and plotting

d <- "/p/projects/remind/modeltests/remind/output/SSP2-NPi-AMT_2024-06-25_16.01.12/REMIND_generic_SSP2-NPi-AMT.mif" %>%
  piamInterfaces::generateIIASASubmission(outputFilename = NULL, mapping = "NAVIGATE", generatePlots = FALSE)
d %>% mip::showAreaAndBarPlots(c("Final Energy|Transportation", "Final Energy|Bunkers"), tot = "Final Energy|Transportation (w/ bunkers)", mainReg= "World", yearsBarPlot = c(2030, 2050))

fails with:

<error/rlang_error>
Error in `.rowNamesDF<-`:
! missing values in 'row.names' are not allowed
---
Backtrace:
     ▆
  1. ├─as_tibble(d) %>% ...
  2. ├─mip::showAreaAndBarPlots(...)
  3. │ └─... %>% ...
  4. └─mip::mipArea(., scales = scales, total = is.null(tot), ylab = lcp)
  5.   ├─ggplot2::scale_fill_manual(...)
  6.   │ └─ggplot2:::manual_scale(aesthetics, values, breaks, ..., na.value = na.value)
  7.   │   └─rlang::is_missing(values)
  8.   └─mip::plotstyle(levels(x[[dimToStack]]))
  9.     ├─base::`row.names<-`(`*tmp*`, value = uqEntity)
 10.     └─base::`row.names<-.data.frame`(`*tmp*`, value = uqEntity)
 11.       └─base::`.rowNamesDF<-`(x, value = value)

The reason is that mip::plotstyle("Final Energy|Transportation (w/ bunkers)") returns

Final Energy|Transportation
                  "#000000"

and the mipArea script is not able to match the color to the variable name.

Removing this line would do it, I guess, but I wonder whether there is a reason for the existence of this line…

@0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q
Copy link
Member Author

Removing this line would do it, I guess, but I wonder whether there is a reason for the existence of this line…

Plotting magpie objects, which have units in parentheses attached to their variable names.

@orichters
Copy link
Contributor

orichters commented Jul 9, 2024

Removing this line would do it, I guess, but I wonder whether there is a reason for the existence of this line…

Plotting magpie objects, which have units in parentheses attached to their variable names.

But most (all?) of the mip functions convert with as.quitte first, and this code in as.quitte.magpie separates variables and units anyway. I also doubt that it would actually work without that step, given that the code for mipArea obviously does not work if something that plotstyle guesses to be a unit is still around.

@0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q
Copy link
Member Author

I did not say it is a good reason.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants