Skip to content

feat: Python interfaces to geos from Makutu repo (refactoring) #74

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

Merged

Conversation

alexbenedicto
Copy link
Contributor

Closes #52

The goal of this PR, following #47 , was to refactor the job done in this first PR #44 by Makutu development team and @av-novikov. This refactor was made by focusing on 3 main axis:

  1. Unify with functionalities developed in mesh_doctor
  2. Use vtk library implemented methods when available
  3. Clean up every method to work in general cases

For this 3rd point, efforts have been done to also keep certain methods that would work in certain workflows provided by Makutu development team, but by explicitly telling that these methods where limited to a certain scope of simulations.
More general methods have been added to work in different contexts and to complement these first methods.

I would like to thank @av-novikov , @bd713 , @sframba and @Victor-M-Gomes for their help through this work.

alexbenedicto and others added 30 commits December 23, 2024 16:52
…into origin/feature/benedicto/rework_makutu_pygeos_tools
@alexbenedicto
Copy link
Contributor Author

There seems to be an issue with the setup-python action in the CI. I did not change the Github action between #71 and the merge into origin/main commit c3edf00 today.

Looking at actions/runner-images#11101, it looks like it occurs on the same date as deprecation was announced. I will wait and rerun the jobs later to see if it changes the Cache error found in the CI.

If that does not resolve the issue, maybe upgrade the version of actions/setup-python@v3 to match what is recommended in https://github.com/actions/setup-python/blob/main/docs/advanced-usage.md#caching-packages.

Any thoughts @mlemayTTE , @untereiner ?

@paloma-martinez
Copy link
Contributor

@alexbenedicto I upgraded the checkout and setup-python github actions in PR #82, it should be fine once these modifications are merged

Copy link
Contributor

@mlemayTTE mlemayTTE left a comment

Choose a reason for hiding this comment

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

What does obl stand for in pygeos-tools/examples/obl?

Looks OK for me. Just a few suggestions.

Copy link
Contributor

Choose a reason for hiding this comment

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

Since the doc for pygeos-examples is generic and is not related to a specific python file, I am not sure having pygeos_tools_docs /Example/reservoir.rst is necessary. Maybe a example.rst file in pygeos_tools_docs is ok.

Copy link
Contributor

Choose a reason for hiding this comment

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

In the future, we may create unit converters in geos.utils using existing libraries like Pint

@av-novikov
Copy link
Contributor

What does obl stand for in pygeos-tools/examples/obl?

@mlemayTTE, OBL stands for Operator-Based Linearization, these examples are working with ReactiveCompositionalMultiphaseOBL solver in GEOS. Let me know if/how i should rename the folder.

@mlemayTTE
Copy link
Contributor

@av-novikov ok, thanks. Then, obl is another example of solver use.
It is not very important and I may have misunderstand what Example folder contains, but maybe the subfolder "solvers" is not necessary, files may be put directly in Example folder. And obl folder may be renamed reactiveCompositionalMultiphase_modeling, similarly to other examples.
Just a suggestion.

Copy link
Contributor

@av-novikov av-novikov left a comment

Choose a reason for hiding this comment

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

I checked my examples, they are working. Rest looks good to me.
Thanks @alexbenedicto !

time: float = 0.0
cycle: int = 0

solver.outputVtk( time )
Copy link
Contributor

Choose a reason for hiding this comment

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

Here and in other examples, for time=0 we are running solver.outputVtk(time) twice, before the loop and at first iteration as time is incremented after the call. For these two calls, the dt argument hidden inside is different, but not sure if it affects and resulting output is different. Anyway, running the output with the same time twice might be confusing.
@Victor-M-Gomes could you please check?

Copy link
Contributor

Choose a reason for hiding this comment

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

You're right, just taking out this line should be enough to avoid this. I am not very familiar with this example, so I couldn't spot the redundancy.

@alexbenedicto alexbenedicto merged commit 5a0f75e into main Apr 17, 2025
39 checks passed
@alexbenedicto alexbenedicto deleted the origin/feature/benedicto/rework_makutu_pygeos_tools branch April 17, 2025 20:21
@CusiniM
Copy link
Collaborator

CusiniM commented Apr 18, 2025

The merging of this PR had broken something on the GEOS CI. I would suggest that whenever you do bigger refactoring like this one, you also open a small geos PR just to make sure everything still works there.

Alternative we can stop pointing to the latest commit on main by default but it means that whenever you want to update the version used in geos you will have to update the commit hash somewhere in there.

Comment on lines +27 to +28
"geos-utils @ file:./geos-utils",
"geos-mesh @ file:./geos-mesh",
Copy link
Collaborator

Choose a reason for hiding this comment

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

this relative path is an issue.

@untereiner
Copy link

A clean decoupling would be first publishing these packages to pypi and then use packages from pypi inside the ci of geos.

@mlemayTTE
Copy link
Contributor

I confess that relative paths are not very robust. This is the only way I found to make internal dependencies between geos Python packages without publishing them on PyPi. @untereiner do know a better solution allowing to build the packages locally without side effects on GEOS repo?

It is hard to predict that modifications of this repo will have side effects on GEOS repo. So at least for geos-ats and pygeos-tools that are directly linked to GEOS repo, a small geos PR just to make sure everything still works there is a good idea.

I agree with @untereiner, GEOS should be based on published Python packages to ensure a better stability.

@untereiner
Copy link

untereiner commented Apr 22, 2025

build the packages locally without side effects on GEOS repo?

no I don't.
I think the way to go is publishing to pypi and then dependabot will open a PR on GEOS repo that launches the CI that would eventually fail.
Maybe do changes to the behavior of a function or the public API of the wrapper only with caution :) Or write unit tests with the expected behavior from the GEOS side for these repos

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Rework "feat: Python interfaces to geos from Makutu repo"
7 participants