question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Renaming dimensions once again....

See original GitHub issue

@aaronspring, it seems like the dimension names expected for climpred are getting confusing once again. To align all products (control, initialized ensemble, observations, references), we have to rename our time dimension to initialization. This clearly doesn’t make sense since the LENS for instance is defined by not being initialized. Further, not every single time step of that dimension is necessarily an initialization point.

Also, our perfect_model vs. reference_ensemble setup has begun to diverge with this. Currently, the perfect_model notebook expects a ‘time’ dimension for the control run for things like DPP and compute_skill. The reference_ensemble expects ‘initialization’ dimension and this has been incorporated into the relative entropy function for a LENS-like setup.


I suggest the following (hopefully final) changes for more clarity for us and future users:

  • Go back to using time as the main dimension for any of these simulations. This makes sense, since it’s the default dimension name that comes out of most simulations. This doesn’t imply that every time step is an initialization and doesn’t force us to rename time to initialization for a control run or uninitialized ensemble, which makes no sense.
  • Remove initialization entirely. This is a long word and doesn’t make sense for many cases.
  • Use lead as the new dimension that is returned from many of our functions. Although lead time makes more sense, this requires annoying dictionary indexing to deal with since there is a space in it. lead is a unique dimension that shouldn’t exist in any simulations and would only come out of our functions. It also makes more sense than time which we are currently using for lead time, which conflicts with the standard CF conventions for simulations.

This I think would help us avoid all confusion in the future. I am happy to do all the renaming and then we stick to this language for the object-oriented implementation.

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Comments:9

github_iconTop GitHub Comments

1reaction
aaronspringcommented, Feb 20, 2019

I will create a PR for bootstrapping before. Should be done by tonight. Then you can do the dimensionality naming afterwards.

1reaction
bradyrxcommented, Feb 19, 2019

Yeah, it will help with confusion since we renamed the conventional ‘time’ to ‘initialization’ every time. And then output a ‘time’ dimension that != the normal ‘time’ dimension. It’s a pain, but I’ll change all of this over in the next couple days and then I hope we don’t have any reason to change it again…

Read more comments on GitHub >

github_iconTop Results From Across the Web

Transforming Google Data Studio Reports: Renaming Metrics ...
Learn how to effectively communicate the results of your online efforts by updating metric and dimension names in Google Data Studio.
Read more >
Renaming dimensions in batch instead of individually???
I would like to know if there is a way to rename a series of dimensions as a batch instead of renaming them...
Read more >
Renaming Attribute and Dimension
This is why once a lot of reports are built, practically speaking it's impossible to change the attribute/dimension name.
Read more >
Not able to rename the dimension during ingestion time
If you are ingesting CSV or TSV you can just rename the dimensions in the columns list already. If you are ingesting JSON...
Read more >
How to Rename Dimension in a Planning Application where ...
How to Rename Dimension in a Planning Application where CAPEX/WORKFORCE has already been initialised? (Doc ID 1469652.1).
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found