-
Notifications
You must be signed in to change notification settings - Fork 230
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
Upgrade to OpenMOPAC #2417
Upgrade to OpenMOPAC #2417
Conversation
Codecov Report
@@ Coverage Diff @@
## main #2417 +/- ##
==========================================
+ Coverage 48.12% 48.13% +0.01%
==========================================
Files 110 110
Lines 30653 30625 -28
Branches 7995 7988 -7
==========================================
- Hits 14751 14741 -10
+ Misses 14371 14358 -13
+ Partials 1531 1526 -5
... and 1 file with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
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.
Looks good to me. Would like @rwest's comments in 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.
Haven't tried compiling or running (but I presume you have). Just read it on github. Looks ok. Please can you push the binaries to the official rmg channel and refer to that in the conda environment file?
environment.yml
Outdated
@@ -34,9 +35,9 @@ dependencies: | |||
- conda-forge::openbabel >= 3 | |||
- pandas | |||
- psutil | |||
- rmg::pydas >=1.0.2 | |||
- jacksonburns::pydas >=1.0.3 |
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.
can you push these PyD* conda binaries to the official rmg channel?
(better: is the recipe to build them in an official repo, and even better run automatically?)
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 will move them over now, as well as build on a mac.
The recipes are in the ReactionMechanismGenerator/PyD* repos, but are not being built automatically
rmgpy/qm/mopac.py
Outdated
outputFileExtension = '.out' | ||
|
||
executablesToTry = ('MOPAC2016.exe', 'MOPAC2012.exe', 'MOPAC2009.exe', 'mopac') | ||
inputFileExtension = ".mop" |
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.
should we be making these snake_case?
rmgpy/qm/mopac.py
Outdated
mopacEnv = os.getenv("MOPAC_DIR", default="/opt/mopac") | ||
executablePath = os.path.join(mopacEnv, "mopac") | ||
if not os.path.exists(executablePath): | ||
executablePath = os.path.join(mopacEnv, "(MOPAC 2009 or 2012 or 2016)") |
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.
Think this line needs revision?
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 entire block does not make sense to me, I left it in to spark some discussion.
I think in the previous versions we may have allowed users to specify a different MOPAC executable and then retrieved it from there, but this isn't something we are interested in now since we ship with the latest release.
I will just remove this. It's dead and untested anyway.
Regression test error |
this might end up being blocked by the same PRs as before
I have rebuilt pydas and pydqd in an environment with an updated version of libgfortran-ng in hopes that pydas can be resolved with a modern version of MOPAC. this process will need to be repeated for pydqed
- allowed difference is now 0.01% instead of zero decimal places (we can't expect that between different versions anyway)
…lways I think the executable finding thing in mopac.py is going to fail
Comment from review by @rwest Co-authored-by: Richard West <r.west@northeastern.edu>
I think I see the problem. Your To preserve things in case I messed up I have pushed your branch to a new one called |
@rwest thanks for resolving that - I tried to get all the instances fixed but apparently missed some. Agreed that it would be a bad idea to change input file format for something like this. Thanks for taking care of the fix! Should pass. |
Not yet sure if it's the changes on this branch, or a problem already in
|
This is probably because of this package version specification
|
Can you try deleting |
This package can't be found on MacOS, and apparently doesn't need to be specified explicitly for linux.
I removed that line as you suggest. It seems to solve OK on my mac (though haven't yet checked the resulting environment works). Have pushed it to see if the CI tests pass. |
This looks promising. Seems to build on my mac, and the CI tests haven't failed.
but the
should that be updated too? Any other changes to conda stuff? |
I think they should be updated, I also don't know anything about actually building the RMG binaries - but we don't need to build anaconda RMG binaries anymore since we moved to docker. We could update them for now, with a separate PR to remove the file (likely .conda as a whole)? |
Let's update the |
Ok, I will open a PR to update .conda following this. You are correct, we missed this in the Canter 2.6 PR as well. Yes, assuming this passes it can be merged! |
A slight confusion - at least confused me for a while - is that the new pydqed 1.0.3 binary you built reports that it is 1.0.1 when you run
|
We probably need to update this line: https://github.com/ReactionMechanismGenerator/PyDQED/blob/libfortran-update/pydqed.pyx#L48 to 1.0.3 |
The anaconda package is 1.0.3 but we made no changes to PyDQED itself so it still shows the old version. We can update the version in PyDQED to match the conda package, but it does not affect performance. |
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.
Not a huge fan of the code churn from autoformatting, but there's no good answer really. At least once it's done it's done. I noticed one inconsistency but it's minor. I think this is fine to merge, in my opinion.
|
||
executablesToTry = ('g16', 'g09', 'g03') | ||
executablesToTry = ("g16", "g09", "g03") |
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.
if we're going through all the code churn of running black on the file and changing ' to " etc., should we also change executablesToTry
and possibleDirs
(below) to snake_case?
(I'm not a huge far of the un-necessarry code churn of black).
The current version of MOPAC used by RMG is semi-closed source and requires an key. The new version, OpenMOPAC, is freely available and maintained by the community.
This PR will attempt to switch to this newer version. Doing so will fix some issues on the user side (see below) and also allow forked repositories to run the continuous integration testing (which currently fails due to the requirement for a license key, not present on forks).
Resolves #2328 which originally discussed the possibility of moving to OpenMOPAC.
Resolves #2251 which was facing issues with running the outdated version of MOPAC and attempted to install this new version without success.
Resolves #2407 also facing licensing issues.
PR #2322 attempted to do this in the past but also attempted to upgrade other packages and ran into difficulties; this PR will only address MOPAC->OpenMOPAC and those packages that are directly affected. This PR seemed to also be blocked by #2272 which fixed an issue with RDKit (see this comment from @xiaoruiDong) that has since been merged.
PR #2386 also attempted to loosen the environment restrictions but was blocked by other PRs that added support for updated versions of Cantera.