Jaime Rodríguez-Guerra | OMM-Quansight helped a lot Significant complexity around CUDA toolkit – Need nvcc metapackage, build matrix with definitions for new versions, ways to install windows drivers (not included in docker image). Added requirements to conda-forge. Maybe some revisiting OpenCL policy issue with Isuru. CUDA toolkit packages are not being built on conda-forge, listed on testing label. Been iterating on this, looks promising. These packages will be going onto main shortly. JC and PE are working on 7.5.0 release, working on OpenCL stuff to ensure that we don’t lead incompaible deps. JRG is working on PPC package, not ready yet, don’t anticipate issues. Now we need to test c-f OpenMM package Would really help to have GPU tests run SB – I do GPU-enabled tests on lilac periodically. I’ll test out the new OpenMM there. SB – Will module add be sufficient for making CUDA available during OpenMM install? JRG – If the driver is available at install-time, it will cause a metapackage to be added to the conda env and ensure that the correct OpenMM is installed. If multiple CUDA versions are available, it will pick the highest one. After/during conda installation, theere should be a CUDA toolkit package queued for download/installed that will sow the version that it thinks your computer has.
Once OMM tests pass, then we’ll move whole OpenFF stack to c-f. How to handle OpenEye deps? MT – How to handle nonessential deps? “Developer deps” like pytest “Example deps” like ParmEd, other notebook goodies “Serialization deps” like bson SB – Agree – Would like a minimum openforcefield package, without RDKit, OpenEye, OpenMM, etc. Could have metapackages for more elaborate deps. JRG – This could work like matplotlib on c-f, where the core version is very stripped down.
JRG – Namespace planning – We need to be careful with this. SB – Could follow pattern of openff-packagename MT – Plan is for everything to be imported as openff.packagename, currently everything follows this except toolkit (which is currently openforcefield, but we plan to migrate to openff.toolkit) JRG – If we make an openforcefield package on conda-forge, we can never “take it back”, and if we make a… (General) – We will never upload an openforcefield package to conda-forge 0.8.1 release will beupladoed to c-f as openff-toolkit, but import in python will still be from openforcefield… 0.8.1 release will ALSO be uploaded on omnia, but will importtime deprecation warning that next release will only be on c-f
(General) – JRG will move forward “full steam” with openmm migration, not be concerned about whole omnia ecosystem migration. (General) – We should never release openforcefield or openforcefieldds package to conda-forge JW – Still unresolved about how to handle OE deps in OFF-toolkit repo, won’t be able to accept PRs from forks until reoslved DD – Do we want to make a formal process/planning document for the omnia migration?
|
Simon Boothroyd | SB – JRG, I had some trouble with plotly, but it turns out that it’s hard to make responsive plots WRT web browser resizing. Though I’ve since figured out how to put in some customization to make it smoother.
|