equinor / equinor/prisma-decision-api

Handle model asymmetry

Open
#350 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
C#
Stars
3
Forks
3
Avg merge
2d 13m
Merged PRs (30d)
27

Description

# Handle model asymmetry (case modeling)

## Overview
Asymmetry is a common characteristic of decision cases. To deal with realistic cases in the tool, we need to be able to handle efficiently both the modeling and representation aspects of case asymmetry.

Modeling in this respect is about how we implement asymmetry. This is about how we choose to enforce asymmetry on the model that is passed to the solver, e.g., through standalone restriction tables or directly through the probability/utility tables. Modeling also includes the evaluation part.

Representation regards how asymmetry is visualized in the various graphs types (ID, DT++). Clearly, both modeling and representation are interrelated since the representations are often the vehicles/interfaces for the implementation.

## Theory
We are dealing with three types of asymmetry: information (structural), domain (functional) and order asymmetry.

*Information* is when a child variable occurs only for some states of the parent but not for others.

*Domain* is when a state of a parent impacts the state(s) of its child.

*Order asymmetry* has to do with not knowing the order of the decisions in our model.

## Target
Practical and efficient asymmetry handling is a fundamental modeling capability for PRISMA to fully describe and analyze realistic subsurface decision cases.

PRISMA should be able to implement and solve asymmetric cases in a practical manner, and represent asymmetric features visually in an easy-to-understand manner.

## Status
We are currently able to model asymmetry through restriction tables and/or probability/utility tables but we need to make this solution robust/consistent and also well-integrated with solutions for representing asymmetry.

## Guidance on modeling

- Deal with information and domain asymmetry through restriction tables which are then used to transform both probability and utility tables into a consistent format/dimension for solving.

- Don't deal with order asymmetry at the moment, i.e., current approach is that if we encounter order asymmetry, we just model/solve the different permutations of the problem.

- ...

## Guidance on representation

- Implement restriction tables at edges instead of at nodes.

- Whatever asymmetry we have implemented in the model should be observable in the visual representations.

- ...

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.