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
Overhaul RMG-RMS Python-Julia dependencies & Add tests for many testless Arkane network algorithms #2640
base: main
Are you sure you want to change the base?
Conversation
36734da
to
56640a9
Compare
It doesn't seem that this can be removed by this PR. From here, it sees that is used to avoid compilation overhead |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2640 +/- ##
==========================================
+ Coverage 54.88% 55.45% +0.57%
==========================================
Files 125 125
Lines 37025 37057 +32
==========================================
+ Hits 20321 20551 +230
+ Misses 16704 16506 -198 ☔ View full report in Codecov by Sentry. |
All tests have passed 🥳🥳🥳 @mjohnson541 Could you review before I clean up the commits? @JacksonBurns Let's work out a plan on the merge sequence with your other PRs |
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.
Heroic effort!
Sorry, about the missing pdep algorithm tests, that's my bad.
I have a few questions about how these changes work, but it looks pretty good.
@@ -49,8 +49,8 @@ dependencies: | |||
- conda-forge::rdkit >=2022.09.1 | |||
|
|||
# general-purpose external software tools | |||
- conda-forge::julia=1.9.1 | |||
- conda-forge::pyjulia >=0.6 | |||
- conda-forge::juliaup |
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 makes sense. What does this mean as far as how we think about julia version?
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.
Chiming in with some notes from offline conversation, just to make sure I'm on the same page as well. From my understanding, juliaup
installs a Julia binary in the conda environment, but 'hides' it from conda so that that juliaup
can manage the version. I think this results in the Julia version being whatever the default provided by juliaup
is, which I think is just the latest minor release.
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.
We can also explicitly manage julia version through commands such as juliaup add 1.9.0
. I incline to let the Julia version update whenever we could and avoid sticking to an old version.
path_rms = dirname(dirname(dirname(abspath(__file__)))) | ||
from julia.api import Julia | ||
|
||
jl = Julia(sysimage=join(path_rms, "rms.so")) if exists(join(path_rms, "rms.so")) else Julia(compiled_modules=False) |
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.
Are we breaking workflows for people that use system images to avoid compilation?
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.
Also curious about this
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.
Do you mean by using a (global) Julia binary instead of the one come with the conda environment?
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.
It looks like this tool: https://github.com/MichaelHatherly/SystemImageLoader.jl allows adding of system images to juliaup.
This implies we could imagine later using some of these new tools like: https://julialang.github.io/PackageCompiler.jl/dev/index.html to generate a system image with RMS already precompiled and use the other tool to add it to juliaup during installation. The caveat being if you ever want to modify RMS you have to remove that image. However, the process doesn't look particularly difficult anymore. PackageCompiler looks pretty straightforward. Not as sure about the other package.
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 a wizard! Thanks for taking this on. A number of small-ish comments throughout.
Overall comment - I did a quick search all for python-jl
and found nothing, so I think you totally caught them all (thanks!).
.github/workflows/CI.yml
Outdated
@@ -151,8 +151,9 @@ jobs: | |||
- name: Install and link Julia dependencies | |||
timeout-minutes: 120 # this usually takes 20-45 minutes (or hangs for 6+ hours). | |||
run: | | |||
python -c "import julia; julia.install(); import diffeqpy; diffeqpy.install()" | |||
julia -e 'using Pkg; Pkg.add(PackageSpec(name="ReactionMechanismSimulator",rev="main")); using ReactionMechanismSimulator' | |||
which julia |
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.
Just a reminder that we can remove this before merging
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.
How do you feel about running juliaup status
here in the CI instead to print out the Julia version we are using? Just to make it easier for us to keep track of things.
julia -e 'using Pkg; Pkg.add(PackageSpec(name="ReactionMechanismSimulator",rev="main")); using ReactionMechanismSimulator' | ||
which julia | ||
export JULIA_CONDAPKG_EXE=$CONDA/condabin/mamba | ||
julia -e 'ENV["JULIA_CONDAPKG_BACKEND"] = "Current"; using Pkg; Pkg.add("SciMLBase"); Pkg.add("Sundials"); Pkg.add(Pkg.PackageSpec(name="ReactionMechanismSimulator", url="https://github.com/hwpang/ReactionMechanismSimulator.jl.git", rev="fix_installation")); using ReactionMechanismSimulator' |
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.
Does RMS not require sundials or SciMLBase on its own? Why do we have to specify them separately?
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.
RMS does require sundials and SciMLBase. I think it's better to install them to help distinguish the RMS dependency (used in reactors.py
) and the general Julia dependency (used in network.py
). If I don't install them explicitly here, I can still access them under RMS's dependency, but it makes network.py
seem like it depends on RMS, which can be misleading. What do you think?
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.
An overall comment/question. How can we differentiate to_julia
and to_rms
in our heads? Having some difficulty understanding from just the code which is required where.
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.
to_julia
handles general types in Julia (think about dict, arrays), and to_rms
handles custom types defined by RMS
Co-authored-by: Jackson Burns <33505528+JacksonBurns@users.noreply.github.com>
@JacksonBurns @mjohnson541 I've addressed most of the comments and have a couple of clarifying questions |
Motivation or Problem
PythonCall.jl
,CondaPkg.jl
, andPythonPlot.jl
supersedePyCall.jl
,Conda.jl
, andPyPlot.jl
packages. The latter have caused many troubles during RMS installation.Some key differences between
PythonCall
andPyCall
PythonCall
has a compatibleJuliaCall
package that provide symmetric interface going from Julia to Python and Python to JuliaPythonCall
by default never copies mutable objects when converting, but instead directly wraps the mutable object. This means that modifying the converted object modifies the original, and conversion is faster" (See here)I put together a RMG-RMS twin PR at ReactionMechanismGenerator/ReactionMechanismSimulator.jl#256 to switch to use
PythonCall.jl
,CondaPkg.jl
, andPythonPlot.jl
from their old versionsPyCall.jl
,Conda.jl
, andPyPlot.jl
.This PR makes necessary changes on the RMG end to keep the RMG-RMS compatibility.
Moreover, during working on this, I found that many new network algorithms in Arkane are not tested. I have added additional tests for them.
Description of Changes
Some major changes include
pyjuliacall
instead ofpyjulia
to call Julia modules from Python.juliaup
to install Julia instead of using thejulia
binary from conda-forge. I have found that user the latter can cause many issues on the RMG end as it doesn't check package depedencies appropriately.juliaup
is Julia's official version manager.pyrms
anddiffeqpy
. We usediffeqpy
to getCVODE_BDF
andsolve
but that is unnecessary. Now we getCVODE_BDF
from Sundials andsolve
fromSciMLBase
. This helps RMG to reduce package dependencies even more.Testing
A clear and concise description of testing that you've done or plan to do.
Reviewer Tips
Suggestions for verifying that this PR works or other notes for the reviewer.