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

Breakthrough time as an observation type #145

Open
berland opened this issue May 11, 2020 · 2 comments
Open

Breakthrough time as an observation type #145

berland opened this issue May 11, 2020 · 2 comments
Labels
enhancement New feature or request

Comments

@berland
Copy link
Collaborator

berland commented May 11, 2020

Mismatch on breakthrough times (i.e. when some data vector crosses a given number in some direction, like when FWCT becomes more than 0.4) can be an important Observation type.

@berland berland added the enhancement New feature or request label May 11, 2020
@berland
Copy link
Collaborator Author

berland commented May 11, 2020

Example yaml config could be (under general_observations):

  - name: Breakthrough times
    category: breakthroughtimes   # Even more generic name?
    observations:
      # Error unit is days. Trigger is the value of the summary vector that defines the
      # breakthrough.  Dates restrict the time interval for which the first date with
      # summary value above trigger is searched for, optional.  smooth-days will add a
      # rolling mean filter with the given number of days (use with care)
      - {key: FWCT, value: 2001-09-01, trigger: 0.4, error: 10, min_date: 2001-01-01, max_date: 2003-01-01}
      - {key: FWCT, value: 2000-02-01, trigger: 0.1, error: 3, min_date: 2000-01-01, max_date: 2003-01-01, smooth_days: 30}

@asnyv
Copy link
Collaborator

asnyv commented May 12, 2020

Even though breakthrough of water, gas or tracer maybe are the most obvious, I don't see a reason to limit the category name? Maybe "triggertimes" or something like that?
Should there be an option for which way the trigger works (goes above/goes below)? Or will the code be smart enough to "guess" that?
Also, if goes below is an option: probably need an exception for 0, which often means closed?

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

No branches or pull requests

3 participants
@berland @asnyv and others