Skip to content
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

Merged
merged 14 commits into from
May 10, 2023
Merged

Upgrade to OpenMOPAC #2417

merged 14 commits into from
May 10, 2023

Conversation

JacksonBurns
Copy link
Contributor

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.

@codecov
Copy link

codecov bot commented May 9, 2023

Codecov Report

Merging #2417 (ddf97ee) into main (f4d7e9c) will increase coverage by 0.01%.
The diff coverage is 58.82%.

@@            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     
Impacted Files Coverage Δ
rmgpy/qm/gaussian.py 26.00% <25.00%> (ø)
rmgpy/qm/symmetry.py 80.48% <61.11%> (ø)
rmgpy/qm/molecule.py 80.81% <72.54%> (ø)
rmgpy/qm/mopac.py 73.97% <75.47%> (+6.15%) ⬆️

... and 1 file with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@JacksonBurns JacksonBurns requested review from hwpang and rwest May 9, 2023 15:51
@JacksonBurns JacksonBurns marked this pull request as ready for review May 9, 2023 16:00
hwpang
hwpang previously approved these changes May 9, 2023
Copy link
Contributor

@hwpang hwpang left a 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.

Copy link
Member

@rwest rwest left a 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
Copy link
Member

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?)

Copy link
Contributor Author

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

outputFileExtension = '.out'

executablesToTry = ('MOPAC2016.exe', 'MOPAC2012.exe', 'MOPAC2009.exe', 'mopac')
inputFileExtension = ".mop"
Copy link
Member

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 Show resolved Hide resolved
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)")
Copy link
Member

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?

Copy link
Contributor Author

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.

@JacksonBurns
Copy link
Contributor Author

@rwest I made the requested changes, I uploaded PyDAS and PyDQED for Linux to the RMG channel, and @hwpang and I uploaded the conda packages for PyDAS and PyDQED for MacOS.

Most of the edits shown in the diff are just from applying PEP8.

@rwest
Copy link
Member

rwest commented May 10, 2023

Regression test error TypeError: quantum_mechanics() got an unexpected keyword argument 'fileStore' ?

JacksonBurns and others added 13 commits May 10, 2023 13:24
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>
@rwest
Copy link
Member

rwest commented May 10, 2023

I think I see the problem. Your gigantic PEP8 refactor for all things touching QMSettings commit has changed some things that are part of input file syntax, not just internal variable names. I think we shouldn't make breaking changes like this to an input file format just for style consistency, especially through blindly applying an automated tool, on a PR that's unrelated.

To preserve things in case I messed up I have pushed your branch to a new one called new-mopac-backup which we can delete once everything is resolved. I have then rebased a few times, merging some commits, trying to tidy up a bit, and dropped the gigantic PEP8 refactor commit. I have force-pushed the result to this new-mopac branch, and we'll see if the test suite runs. If I've messed up, feel free to revert to new-mopac-backup and try to fix things yourself.

@JacksonBurns
Copy link
Contributor Author

@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.

@rwest
Copy link
Member

rwest commented May 10, 2023

Not yet sure if it's the changes on this branch, or a problem already in main, but making a new conda environment on my mac is faling:

git:(new-mopac) ✗ conda env create -f environment.yml 
Channels:
 - defaults
 - rmg
 - conda-forge
 - cantera
 - pr-omethe-us
 - kyleniemeyer
Platform: osx-64
Collecting package metadata (repodata.json): done
Solving environment: | error    libmamba Selected channel specific (or force-reinstall) job, but package is not available from channel. Solve job will fail.
- error    libmamba Selected channel specific (or force-reinstall) job, but package is not available from channel. Solve job will fail.
failed
Channels:
 - defaults
 - rmg
 - conda-forge
 - cantera
 - pr-omethe-us
 - kyleniemeyer
Platform: osx-64
Collecting package metadata (repodata.json): done
Solving environment: \ error    libmamba Selected channel specific (or force-reinstall) job, but package is not available from channel. Solve job will fail.
| error    libmamba Selected channel specific (or force-reinstall) job, but package is not available from channel. Solve job will fail.
failed

LibMambaUnsatisfiableError: Encountered problems while solving:
  - unsupported request

@hwpang
Copy link
Contributor

hwpang commented May 10, 2023

@rwest

This is probably because of this package version specification

conda-forge::libgfortran-ng>=10.0

@JacksonBurns
Copy link
Contributor Author

Not yet sure if it's the changes on this branch, or a problem already in main, but making a new conda environment on my mac is faling:

git:(new-mopac) ✗ conda env create -f environment.yml 
Channels:
 - defaults
 - rmg
 - conda-forge
 - cantera
 - pr-omethe-us
 - kyleniemeyer
Platform: osx-64
Collecting package metadata (repodata.json): done
Solving environment: | error    libmamba Selected channel specific (or force-reinstall) job, but package is not available from channel. Solve job will fail.
- error    libmamba Selected channel specific (or force-reinstall) job, but package is not available from channel. Solve job will fail.
failed
Channels:
 - defaults
 - rmg
 - conda-forge
 - cantera
 - pr-omethe-us
 - kyleniemeyer
Platform: osx-64
Collecting package metadata (repodata.json): done
Solving environment: \ error    libmamba Selected channel specific (or force-reinstall) job, but package is not available from channel. Solve job will fail.
| error    libmamba Selected channel specific (or force-reinstall) job, but package is not available from channel. Solve job will fail.
failed

LibMambaUnsatisfiableError: Encountered problems while solving:
  - unsupported request

Can you try deleting - conda-forge::libgfortran-ng>=10.0 from the environment file and running again? @hwpang and I ran into a problem while building PyDAS and PyDQED on MacOS yesterday that this package is not available on mac, but that conda finds a different one that fits the requirements. I had only added this to the list to be explicit, but I only ever dev on ubuntu.

This package can't be found on MacOS, and apparently doesn't need 
to be specified explicitly for linux.
@rwest
Copy link
Member

rwest commented May 10, 2023

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.

@rwest
Copy link
Member

rwest commented May 10, 2023

This looks promising. Seems to build on my mac, and the CI tests haven't failed.
But we updated these in the environment.yml

   - rmg::pydas >=1.0.3
   - rmg::pydqed >=1.0.3

but the .conda/meta.yaml still has

    - pydas >=1.0.2
    - pydqed >=1.0.1

should that be updated too? Any other changes to conda stuff?
(I'm not up to date with how the conda binary building works)

@JacksonBurns
Copy link
Contributor Author

This looks promising. Seems to build on my mac, and the CI tests haven't failed.
But we updated these in the environment.yml

   - rmg::pydas >=1.0.3
   - rmg::pydqed >=1.0.3

but the .conda/meta.yaml still has

    - pydas >=1.0.2
    - pydqed >=1.0.1

should that be updated too? Any other changes to conda stuff?
(I'm not up to date with how the conda binary building works)

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)?

@rwest
Copy link
Member

rwest commented May 10, 2023

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 .conda folder in a separate PR. I notice the cantera version got left behind too. Then this PR is more nearly ready to merge (as soon as tests pass?)

@JacksonBurns
Copy link
Contributor Author

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 .conda folder in a separate PR. I notice the cantera version got left behind too. Then this PR is more nearly ready to merge (as soon as tests pass?)

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!

@rwest
Copy link
Member

rwest commented May 10, 2023

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 make check.

(rmg_env) ➜  RMG-Py git:(new-mopac) ✗ conda list pydqed
# packages in environment at /opt/miniconda3/envs/rmg_env:
#
# Name                    Version                   Build  Channel
pydqed                    1.0.3            py37h41275ba_6    rmg

(rmg_env) ➜  RMG-Py git:(new-mopac) ✗ make check

Checking vital dependencies...

Package        Version        Location
lpsolve55                     /opt/miniconda3/envs/rmg_env/lib/python3.7/site-packages/lpsolve55.cpython-37m-darwin.so
OpenBabel      3.1.0          /opt/miniconda3/envs/rmg_env/lib/python3.7/site-packages/openbabel/openbabel.py
pydqed         1.0.1          /opt/miniconda3/envs/rmg_env/lib/python3.7/site-packages/pydqed.cpython-37m-darwin.so
pyrdl                         /opt/miniconda3/envs/rmg_env/lib/python3.7/site-packages/py_rdl/__init__.py
RDKit          2020.03.3      /opt/miniconda3/envs/rmg_env/lib/python3.7/site-packages/rdkit/__init__.py
symmetry       1.16           /opt/miniconda3/envs/rmg_env/bin/symmetry

Everything was found :)


@hwpang
Copy link
Contributor

hwpang commented May 10, 2023

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 make check.

(rmg_env) ➜  RMG-Py git:(new-mopac) ✗ conda list pydqed
# packages in environment at /opt/miniconda3/envs/rmg_env:
#
# Name                    Version                   Build  Channel
pydqed                    1.0.3            py37h41275ba_6    rmg

(rmg_env) ➜  RMG-Py git:(new-mopac) ✗ make check

Checking vital dependencies...

Package        Version        Location
lpsolve55                     /opt/miniconda3/envs/rmg_env/lib/python3.7/site-packages/lpsolve55.cpython-37m-darwin.so
OpenBabel      3.1.0          /opt/miniconda3/envs/rmg_env/lib/python3.7/site-packages/openbabel/openbabel.py
pydqed         1.0.1          /opt/miniconda3/envs/rmg_env/lib/python3.7/site-packages/pydqed.cpython-37m-darwin.so
pyrdl                         /opt/miniconda3/envs/rmg_env/lib/python3.7/site-packages/py_rdl/__init__.py
RDKit          2020.03.3      /opt/miniconda3/envs/rmg_env/lib/python3.7/site-packages/rdkit/__init__.py
symmetry       1.16           /opt/miniconda3/envs/rmg_env/bin/symmetry

Everything was found :)

We probably need to update this line: https://github.com/ReactionMechanismGenerator/PyDQED/blob/libfortran-update/pydqed.pyx#L48 to 1.0.3

@JacksonBurns
Copy link
Contributor Author

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.

Copy link
Member

@rwest rwest left a 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")
Copy link
Member

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).

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

Successfully merging this pull request may close these issues.

mopac issues Stop using (and maybe remove) the old Mopac from RMG's conda channel MOPAC Not running
3 participants