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

Consider to always return datetime-indices #180

Open
berland opened this issue Nov 19, 2020 · 2 comments · May be fixed by #182
Open

Consider to always return datetime-indices #180

berland opened this issue Nov 19, 2020 · 2 comments · May be fixed by #182
Milestone

Comments

@berland
Copy link
Collaborator

berland commented Nov 19, 2020

get_smry() and load_smry() is not very consistent on what kind of index they return.

Consider going all in and always have the time-series indexed properly with Pandas datetime64 DateTimeIndex.

This would be a breaking change in the API, requires bumping major revision.

@berland berland added this to the 2.0 milestone Nov 19, 2020
@berland
Copy link
Collaborator Author

berland commented Feb 16, 2021

Using Pandas datetime64[ns] as default is a no-go due to the hard upper limit in year 2262.

The realization object returns summary dataframes with dates in the index (datetime64[ns] or datetime.datetime objects if necessary from ecl2df v0.11). This can continue as in fmu.ensemble 1.4 (it is returning libecl's pandas_frame() directly).

load_smry() in fmu-ensemble 1.4 realization.py performs a reset_index(). This will not be carried over to fmu.ensemble 2.0.

The Ensemble objects cannot have dates in their index, and is always doing a reset_index() (effectively) on dataframes from realization objects). This behaviour should be kept going to fmu.ensemble 2.0

@berland
Copy link
Collaborator Author

berland commented Mar 9, 2021

Current decision is to have a dummy index all-over fmu-ensemble, and DATE in a separate column. This is an API change from fmu.ensemble 1.5.0 to 2.0.0, in PR #182

@berland berland linked a pull request Mar 9, 2021 that will close this issue
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant