Skip to content

Add kriging compute preview#224

Open
denis-simo wants to merge 14 commits intoSeequentEvo:mainfrom
BenLewis-Seequent:add-kriging-compute-preview
Open

Add kriging compute preview#224
denis-simo wants to merge 14 commits intoSeequentEvo:mainfrom
BenLewis-Seequent:add-kriging-compute-preview

Conversation

@denis-simo
Copy link
Contributor

Adding kriging compute that can be ran with preview flag.
Extending a lot of documentation and updating the changlog, as now the package should be in a good state to release without further outstanding changes.

@denis-simo denis-simo requested review from a team as code owners February 26, 2026 19:40
name = "evo-sdk-common"
description = "Python package that establishes a common framework for use by client libraries that interact with Seequent Evo APIs"
version = "0.5.18"
version = "0.5.19"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(18->19) is due to addition of common typed objects - poitns, boundary, sizes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume this documentation will be shown on https://developer.seequent.com/?

Copy link
Contributor Author

@denis-simo denis-simo Feb 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup , I am expecting to see it here https://developer.seequent.com/docs/sdk/evo-python-sdk . So far I was not able to get dev portal styling but html pages are the same.
The process is MD docs are used to autogenerate html pages (which also get comitted), which in turn are published.


def to_dict(self) -> dict[str, Any]:
"""Serialize to dictionary."""
if hasattr(self.attribute, "to_dict"):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on the type annotations, should this always be true?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes made to this file are quite complex, and I'm not sure how well it'll hold up over time with such custom logic. Is it necessary to document, and begin to maintain a list of "typed objects"? Regardless, parsing this file is quite difficult with most of the functionality inside on_startup, and I'm not sure that simplifying would help with its rigidity.

Comment on lines +22 to +28
| evo-sdk-common ([discovery](evo-sdk-common/discovery/DiscoveryAPIClient.md) and [workspaces](evo-sdk-common/workspaces/WorkspaceAPIClient.md)) | <a href="https://pypi.org/project/evo-sdk-common/"><img alt="PyPI - Version" src="https://img.shields.io/pypi/v/evo-sdk-common" /></a> | A shared library that provides common functionality for integrating with Seequent's client SDKs. |
| evo-files ([api](evo-files/FileAPIClient.md)) | <a href="https://pypi.org/project/evo-files/"><img alt="PyPI - Version" src="https://img.shields.io/pypi/v/evo-files" /></a> | A service client for interacting with the Evo File API. |
| evo-objects ([introduction](evo-objects/Introduction.md), [typed objects](evo-objects/TypedObjects.md), [api](evo-objects/ObjectAPIClient.md)) | <a href="https://pypi.org/project/evo-objects/"><img alt="PyPI - Version" src="https://img.shields.io/pypi/v/evo-objects" /></a> | Typed Python classes and an API client for geoscience objects — points, grids, variograms, and more. |
| evo-colormaps ([api](evo-colormaps/ColormapAPIClient.md)) | <a href="https://pypi.org/project/evo-colormaps/"><img alt="PyPI - Version" src="https://img.shields.io/pypi/v/evo-colormaps" /></a> | A service client to create colour mappings and associate them to geoscience data with the Colormap API.|
| evo-blockmodels ([introduction](evo-blockmodels/Introduction.md), [typed objects](evo-blockmodels/TypedObjects.md), [api](evo-blockmodels/BlockModelAPIClient.md)) | <a href="https://pypi.org/project/evo-blockmodels/"><img alt="PyPI - Version" src="https://img.shields.io/pypi/v/evo-blockmodels" /></a> | Typed block model interactions, reports, and an API client for managing block models in Evo. |
| evo-widgets ([introduction](evo-widgets/Introduction.md)) | <a href="https://pypi.org/project/evo-widgets/"><img alt="PyPI - Version" src="https://img.shields.io/pypi/v/evo-widgets" /></a> | Widgets and presentation layer — rich HTML rendering of typed geoscience objects in Jupyter notebooks. |
| evo-compute ([introduction](evo-compute/Introduction.md), [typed objects](evo-compute/TypedObjects.md), [api](evo-compute/JobClient.md)) | <a href="https://pypi.org/project/evo-compute/"><img alt="PyPI - Version" src="https://img.shields.io/pypi/v/evo-compute" /></a> | Run compute tasks (e.g. kriging estimation) via the Compute Tasks API.|

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Many of the links are now broken here, as they don't work with the dev portal link formatting.

This is just from this file, I haven't checked the others yet:

Exhaustive list of all broken links found:
  - Broken link on source page path = /docs/sdk/evo-python-sdk:
     -> linking to evo-sdk-common/discovery/DiscoveryAPIClient.html (resolved as: /docs/sdk/evo-sdk-common/discovery/DiscoveryAPIClient.html)
     -> linking to evo-sdk-common/workspaces/WorkspaceAPIClient.html (resolved as: /docs/sdk/evo-sdk-common/workspaces/WorkspaceAPIClient.html)
     -> linking to evo-files/FileAPIClient.html (resolved as: /docs/sdk/evo-files/FileAPIClient.html)
     -> linking to evo-objects/Introduction.html (resolved as: /docs/sdk/evo-objects/Introduction.html)
     -> linking to evo-objects/TypedObjects.html (resolved as: /docs/sdk/evo-objects/TypedObjects.html)
     -> linking to evo-objects/ObjectAPIClient.html (resolved as: /docs/sdk/evo-objects/ObjectAPIClient.html)
     -> linking to evo-colormaps/ColormapAPIClient.html (resolved as: /docs/sdk/evo-colormaps/ColormapAPIClient.html)
     -> linking to evo-blockmodels/Introduction.html (resolved as: /docs/sdk/evo-blockmodels/Introduction.html)
     -> linking to evo-blockmodels/TypedObjects.html (resolved as: /docs/sdk/evo-blockmodels/TypedObjects.html)
     -> linking to evo-blockmodels/BlockModelAPIClient.html (resolved as: /docs/sdk/evo-blockmodels/BlockModelAPIClient.html)
     -> linking to evo-widgets/Introduction.html (resolved as: /docs/sdk/evo-widgets/Introduction.html)
     -> linking to evo-compute/Introduction.html (resolved as: /docs/sdk/evo-compute/Introduction.html)
     -> linking to evo-compute/TypedObjects.html (resolved as: /docs/sdk/evo-compute/TypedObjects.html)
     -> linking to evo-compute/JobClient.html (resolved as: /docs/sdk/evo-compute/JobClient.html)

| [evo-objects](packages/evo-objects/README.md) | <a href="https://pypi.org/project/evo-objects/"><img alt="PyPI - Version" src="https://img.shields.io/pypi/v/evo-objects" /></a> | `evo.objects` | A geoscience object service client library designed to help get up and running with the Geoscience Object API. |
| [evo-colormaps](packages/evo-colormaps/README.md) | <a href="https://pypi.org/project/evo-colormaps/"><img alt="PyPI - Version" src="https://img.shields.io/pypi/v/evo-colormaps" /></a> | `evo.colormaps` | A service client to create colour mappings and associate them to geoscience data with the Colormap API.|
| [evo-blockmodels](packages/evo-blockmodels/README.md) | <a href="https://pypi.org/project/evo-blockmodels/"><img alt="PyPI - Version" src="https://img.shields.io/pypi/v/evo-blockmodels" /></a> | `evo.blockmodels` | The Block Model API provides the ability to manage and report on block models in your Evo workspaces. |
| [evo-widgets](packages/evo-widgets/README.md) | <a href="https://pypi.org/project/evo-widgets/"><img alt="PyPI - Version" src="https://img.shields.io/pypi/v/evo-widgets" /></a> | `evo.widgets` | Widgets and presentation layer — rich HTML rendering of typed geoscience objects in Jupyter notebooks. |

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PyPI link isn't rendering correctly

Comment on lines +101 to +116
**Getting started — typed objects & visualisation:**

* [`evo-objects`](evo-objects/Introduction.md): load and work with points, grids, variograms, and other geoscience objects as typed Python classes
* [`evo-blockmodels`](evo-blockmodels/Introduction.md): create, query, and report on block models with typed interactions
* [`evo-compute`](evo-compute/Introduction.md): run compute tasks such as kriging estimation
* [`evo-widgets`](evo-widgets/Introduction.md): rich HTML rendering of typed geoscience objects in Jupyter notebooks

**API clients [For developers]:**

* `evo-sdk-common` ([`discovery`](evo-python-sdk/evo-sdk-common/discovery) and [`workspaces`](evo-python-sdk/evo-sdk-common/workspaces)): providing the foundation for all Evo SDKs, as well as tools
for performing arbitrary Seequent Evo API requests
* [`evo-files`](evo-python-sdk/evo-files): for interacting with the File API
* `evo-objects`: for interacting with the Geoscience Object API
* [`evo-colormaps`](evo-python-sdk/evo-colormaps): for interacting with the Colormap API
* [`evo-blockmodels`](evo-python-sdk/evo-blockmodels): for interacting with the Block Model API
* [`evo-compute`](evo-python-sdk/evo-compute): for interacting with the Compute Tasks API
* `evo-sdk-common` ([`discovery`](evo-sdk-common/discovery/DiscoveryAPIClient.md) and [`workspaces`](evo-sdk-common/workspaces/WorkspaceAPIClient.md)): foundation for all Evo SDKs, including arbitrary API requests
* [`evo-files`](evo-files/FileAPIClient.md): low-level File API client
* [`evo-objects` API](evo-objects/ObjectAPIClient.md): low-level Geoscience Object API client
* [`evo-colormaps`](evo-colormaps/ColormapAPIClient.md): Colormap API client
* [`evo-blockmodels` API](evo-blockmodels/BlockModelAPIClient.md): low-level Block Model API client
* [`evo-compute` API](evo-compute/JobClient.md): low-level Compute Tasks API client
* [Seequent Developer Portal](https://developer.seequent.com/docs/guides/getting-started/quick-start-guide): guides, tutorials, and API references

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This formatting is a bit odd. Perhaps instead of "Introduction" pages these should simply be "index" pages, so it's not an extra link in the sidebar. That way, they can all be referenced in one set of bullet points, like before.

Comment on lines +186 to +191
def exists(self) -> bool:
"""Whether this attribute exists on the object.

:return: False for pending attributes.
"""
return False

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I have a serious case of "Friday afternoon" where this just doesn't quite make sense to me 😆
I looked at the section of code where this is used, and it made sense because you were asking the question "has this attribute been created or added before to this object/block model"

but it would really be nicer to have something like an "is pending"/"can create" etc. property. Maybe that's just getting too far in the weeds, is there any changing this confusing property name or has that ship well sailed by now?

Copy link

@PaulCaygill-Seequent PaulCaygill-Seequent left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From my perspective, the stuff to do with running a remote Kriging task seems fine. You've not (that I can see) written anything around that area that would create massive problems, just added wrappers around existing logic and clients etc.

I commented on the thing or two that I could see that felt odd, but this could be feedback driven changes for all I know

fb.progress(done_count / total, f"Running {done_count}/{total}...")
except Exception:
done_count += 1
# Cancel remaining to fail fast

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm guessing that this is based on feedback? It seems a little odd to me that you'd want to cancel all remaining tasks if just one of them errors, but I'll assume there is some clear reason for that

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 this pull request may close these issues.

4 participants