CO2Leakage plugin not supporting portable mode?

[anders-kiaer]

ERROR:webviz_app:Exception on /_dash-update-component [POST]
Traceback (most recent call last):
  File ".../root/lib64/python3.8/site-packages/webviz_config/webviz_store.py", line 162, in get_stored_data
    return pd.read_parquet(f"{path}.parquet")
  File ".../root/lib64/python3.8/site-packages/pandas/io/parquet.py", line 503, in read_parquet
    return impl.read(
  File ".../root/lib64/python3.8/site-packages/pandas/io/parquet.py", line 244, in read
    path_or_handle, handles, kwargs["filesystem"] = _get_path_or_handle(
  File ".../root/lib64/python3.8/site-packages/pandas/io/parquet.py", line 102, in _get_path_or_handle
    handles = get_handle(
  File ".../root/lib64/python3.8/site-packages/pandas/io/common.py", line 865, in get_handle
    handle = open(handle, ioargs.mode)
FileNotFoundError: [Errno 2] No such file or directory: '.../resources/webviz_storage/webviz_subsurface._utils.webvizstore_functions-read_csv-afe57c8ca8b6b79b001ab1fd113fbf70d5aafb262613668ef85745e3379f0d5c.parquet'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File ".../root/lib64/python3.8/site-packages/flask/app.py", line 1473, in wsgi_app
    response = self.full_dispatch_request()
  File ".../root/lib64/python3.8/site-packages/flask/app.py", line 882, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File ".../root/lib64/python3.8/site-packages/flask/app.py", line 880, in full_dispatch_request
    rv = self.dispatch_request()
  File ".../root/lib64/python3.8/site-packages/flask/app.py", line 865, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type: ignore[no-any-return]
  File ".../root/lib64/python3.8/site-packages/dash/dash.py", line 1373, in dispatch
    ctx.run(
  File ".../root/lib64/python3.8/site-packages/dash/_callback.py", line 465, in add_context
    output_value = _invoke_callback(func, *func_args, **func_kwargs)
  File ".../root/lib64/python3.8/site-packages/dash/_callback.py", line 40, in _invoke_callback
    return func(*args, **kwargs)  # %% callback invoked %%
  File ".../root/lib64/python3.8/site-packages/webviz_subsurface/plugins/_co2_leakage/_plugin.py", line 526, in update_map_attribute
    layers = create_map_layers(
  File ".../root/lib64/python3.8/site-packages/webviz_subsurface/plugins/_co2_leakage/_utilities/callbacks.py", line 310, in create_map_layers
    "data": _parse_polygon_file(file_containment_boundary),
  File ".../root/lib64/python3.8/site-packages/webviz_subsurface/plugins/_co2_leakage/_utilities/callbacks.py", line 427, in _parse_polygon_file
    df = read_csv(filename)
  File ".../root/lib64/python3.8/site-packages/webviz_config/webviz_store.py", line 213, in wrapper_decorator
    return WEBVIZ_STORAGE.get_stored_data(func, *args, **kwargs)
  File ".../root/lib64/python3.8/site-packages/webviz_config/webviz_store.py", line 170, in get_stored_data
    raise OSError(
OSError: Could not find file /.../resources/webviz_storage/webviz_subsurface._utils.webvizstore_functions-read_csv-afe57c8ca8b6b79b001ab1fd113fbf70d5aafb262613668ef85745e3379f0d5c, which should be the stored output of the function call read_csv(csv_file='.../share/results/polygons/containment--boundary.csv').

[vegardkv]

The issue is that the containment boundary file is not included in the portable app. In a separate fork, we have made some changes to how this file is read, which instead should yield a warning when the file is missing, instead of throwing an exception. This will at least ensure that the plugin at least opens in portable mode.

What remains then is to include the file with the app. This is probably best done by following the "provider" pattern that has been done for other data types. Currently, the file is read directly via read_csv.

It is tempting to suggest that the FaultPolygonsProvider can be generalized to arbitrary polygons, perhaps with some tags/metadata describing the type of polygon (FaultPolygon, ContainmentBoundary, General, etc.). An alternative, I guess, is to create a separate ContainmentBoundaryProvider, but this will duplicate a lot of the code in FaultPolygonsProvider.