-
Notifications
You must be signed in to change notification settings - Fork 0
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
feat: Python interfaces to geos from Makutu repo (refactoring) #74
Conversation
…into origin/feature/benedicto/rework_makutu_pygeos_tools
…ng the Solver classes
…cto/rework_makutu_pygeos_tools
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 Any thoughts @mlemayTTE , @untereiner ? |
@alexbenedicto I upgraded the checkout and setup-python github actions in PR #82, it should be fine once these modifications are merged |
…cto/rework_makutu_pygeos_tools
…amples outside of src + update docs
There was a problem hiding this 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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
@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. |
@av-novikov ok, thanks. Then, obl is another example of solver use. |
There was a problem hiding this 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 ) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
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. |
"geos-utils @ file:./geos-utils", | ||
"geos-mesh @ file:./geos-mesh", |
There was a problem hiding this comment.
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.
A clean decoupling would be first publishing these packages to pypi and then use packages from pypi inside the ci of geos. |
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. |
no I don't. |
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:
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.