SimulationTimeSeriesModel redesign

[asnyv]

Test

[asnyv]

@sigurdp

[sigurdp]

I have created a draft for a possible new interface for SimulationTimeSeriesModel as a basis for further discussion.

The draft is based on the observed usage pattern in the ParameterAnalysis and PropertyStatistics plugins and initial discussions with @HansKallekleiv

I have included the file contents below, but it may be easier to just have a look at: https://github.com/CeetronSolutions/webviz-subsurface/blob/sigurdp/draft-interfaces/webviz_subsurface/_models/draft_simulation_timeseries_model.pyi

Near the bottom of the file I have added some of the considerations/discussion points that have come to mind as of now.

Contents of draft_simulation_timeseries_model.pyi:

from typing import List, Dict, Optional, Iterable, Tuple, Sequence

import pandas as pd

# fmt: off

class SimulationTimeSeriesModel:
    def __init__(self, smry_df: pd.DataFrame, smry_meta_df: Optional[pd.DataFrame] = None) -> None: ...
    
    @property
    def ensemble_names(self) -> List[str]: ...

    # Queries for available vector names
    # Do we need more or other filters here, eg.: only non-zero, exclude historical vectors, by type
    @property
    def all_vector_names(self) -> List[str]: ...
    @property
    def simulation_vector_names(self) -> List[str]: ...
    @property
    def historical_vector_names(self) -> List[str]: ...

    # Should this kind of functionality be here at all?
    @property
    def vector_groups(self) -> Dict[str, dict]: ...

    @property
    def dates(self) -> List[str]: ...

    def daterange_for_vector(self, ensemble: str, vector_name: str) -> Tuple[str, str]: ...

    def get_vector(self, ensemble: str, vector_name: str) -> pd.DataFrame: ...
    def get_vector_filtered_by_realizations(self, ensemble: str, vector_name: str, realizations: Sequence[int]) -> pd.DataFrame: ...

    def get_vectors_for_date(self, ensemble: str, date: str, vector_names: Sequence[str]) -> pd.DataFrame: ...

    # If we were to have this method, what is the definition of "all" vectors
    def get_all_vectors_for_date(self, ensemble: str, date: str) -> pd.DataFrame: ...

    # Does this method make sense? Probably not
    def get_historical_vector(self, vector_name: str) -> pd.DataFrame: ...

    # To be considered
    #   Data type for dates?
    #   Is DataFrame the best data structure for return values?
    #   Query for the existence of a vector by name, eg.: has_vector_named()
    #   Vectors grouped by type, does this even belong here or rather in separate helper? Or just needed in GUI component
    #   Getter(s) for min/max date(s)
    #   Any need for querying available realizations?
    #   Mapping between simulation and historical vectors, eg.: map_to_hist_vec_name() 

# fmt: on

[HansKallekleiv]

Good start :)

• I think the most used return value would be a single vector for a given date => pd.Series with date as index?
• Should statistical calculations go in this class? E.g. averaging a vector for a date over an ensemble

[asnyv]

I am a little bit confused, thought maybe you were planning to have a data model for time series data with access methods, but this one takes the full data set as input? How convenient is that if we are to be able to have a more load-on-demand/API like structure in the future? Was thinking something similar to the current EnsembleModel, but separating out the timeseries stuff to avoid that EnsembleModel grows massive when we add various other data types?
Also: There is a lot of other use cases than what is covered in ParameterAnalysis and PropertyAnalysis, at least take a look at the regular ReservoirSimulationTimeseries plugins (including ReservoirSimulationTimeseriesOneByOne and ReservoirSimulationTimeseriesRegional).

So I'm happy to have a chat 😅

Don't think pd.Series with date as index is very convenient @HansKallekleiv? We often have to keep e.g. ENSEMBLE and REAL columns too, and possibly multiple vectors, so think either pure numpy arrays, or DataFrames, not pd.Series?

get_historical_vector means? Get the corresponding historical to a vector_name (if it exists)? If so, that makes a lot of sense. May not exist, so donno if it should return empty pd.DataFrame or None in that case?

Since most of the methods may utilize a realization filter, I wonder if we should have them duplicated like you have for get_vector / get_vector_filtered_by_realizations, or just an optional realization sequence? And should the realization filter be per ensemble or not?

daterange may vary on ensemble and sometimes realization, but it is not vector dependent (I read it like you here return the two dates)?
A method to return vector(s) as a function of a daterange might be useful

Probably want the option to return multiple vectors instead of just one.

Think when it comes to statistics, maybe we should have one class for just data access and filtering, one class for calculations, and one class for "standard plots" or something like that? We need e.g. a vector calculator as well in the future.

Functions like filtering on all zeros/ all constant, exclude historicals, by type and etc are useful.

Other methods needed:
metadata (unit, vector type and etc)
lineshape (probably belongs in a plot class if we make that)

A calculation class may also utilize the new unit convertion system to handle various unit systems.

[sigurdp]

Updated draft interface based on our Teams discussion:
https://github.com/CeetronSolutions/webviz-subsurface/blob/sigurdp/draft-interfaces/webviz_subsurface/_models/draft_simulation_timeseries_model.pyi