michellab / sire Goto Github PK

I have resolved dependencies for
-cmake
-g++
but not openmm. The build fails due to Openmm not being installed. There is a .deb package available, which needs to be whitelisted, for a container based infrastructrue build:
http://docs.travis-ci.com/user/workers/container-based-infrastructure/
This type of build is faster.
In the mean time I might try an non container based infrastructure travis build.

FESetup files produced for a sire free energy calculation may sometime cause ''NaN or Inf was produced along the simulation'' error messages. We should establish why this happens, and whether we should detect problematic setups that shouldn't be run in a non free energy simulation

I seem to notice something strange the way the temperature parameter is passed to python.
I use the default temperature value and don't overwrite with anything in my config file, i.e. this should be read:

temperature = Parameter("temperature", 25 * celsius, """Simulation temperature""")
pressure = Parameter("pressure", 1 * atm, """Simulation pressure""")

The output I get for the two variables is:

In [1]: temperature.val
Out[1]: SireUnits::Celsius

In [2]: pressure.val
Out[2]: 1 atm

Which is quite useless information for the temperature. Not sure where the problem might be.
The temperature does get correctly passed to c++ code though.

I've managed to update the CMakeLists.txt files in corelib and wrapper to build a copy of Sire into an existing miniconda distribution. This will be an additional install route for Sire that will complement the bundled python route.

The way it works is through an option "ANACONDA_BUILD", which when set tells cmake to build Sire for installation into an existing anaconda/miniconda installation. You need to supply "ANACONDA_BASE" to tell cmake where anaconda is installed, e.g. "${HOME}/miniconda3".

At the moment, the core is all compiled and built into miniconda3/pkgs/sire-0.0.1, with the Sire modules installed into miniconda3/lib/python-X.X/site-packages. I have to do some work with library paths ($ORIGIN and @rpath) as I have to copy all libraries from miniconda3/pkgs/sire-0.0.1/lib and miniconda3/pkgs/sire-0.0.1/bundled/lib into miniconda3/lib to get this to work.

I have some questions before I proceed with this and commit it to git:

(1) Do you think this is the right way to go? Does it cause issue with what you are doing?

(2) At the moment, Sire uses its own python binary. This is to handle multithreading, clusters and various tricks to allow symbolic links to the python executable to auto-route to python scripts. I think that I will need to change this so that Sire creates a sire_python executable in miniconda3/bin, and then the symbolic links can link to sire_python (and also then go into miniconda3/bin). Does this sound sensible?

(3) I think that we can turn the miniconda3/pkgs/sire-0.0.1 directory into a portable binary install, as we have for sire.app. If that is the case, do you think that it is worth putting in the effort to do this? We could then have "pip install sire" just download the correct binary that is unpacked into pkgs/sire-0.0.1.

(4) The end result of this is that people will be downloading/compiling Sire into existing installations of anaconda/miniconda. This is desirable, as it should make it easier to get Sire to work with other packages. However, do you foresee any maintenance headaches of this approach?

Corelib, in its current state only builds with g++ version 4.6 the 14.04 ubuntu standard is now 4.8. However older versions are still available on the package management system.
Easy fix is to have multiple g++ version installed and only use 4.6 for compiling corelib.

Is there a reason why the alchemical value is set like this:

void OpenMMFrEnergyST::setAlchemical_value(double lambda_value){

    Alchemical_value = max(0.0,min(1.0,lambda_value));

}

if lambda is between 0 and 1, then why is this max min notation used here?

I am trying to perform neopentane to methane free energy simulation according to this transformation:

But always in water simulation, after minimization and equilibration, I got this error:

Traceback (most recent call last):
File "/home/steboss/sire.app/share/Sire/scripts/somd-freenrg.py", line 140, in
OpenMMMD.runFreeNrg(params)
File "/home/steboss/sire.app/bundled/lib/python3.3/site-packages/Sire/Tools/init.py", line 135, in inner
retval = func()
File "/home/steboss/sire.app/bundled/lib/python3.3/site-packages/Sire/Tools/OpenMMMD.py", line 1233, in runFreeNrg
system = moves.move(system, nmoves.val, True)
RuntimeError: The periodic box size has decreased to less than twice the nonbonded cutoff.

I have played around a little bit and written down this results:

• configuration_1: no constraint
  0.5 fs timestep
  10 A cutoff
  Barostat ON
  Thermostat ON
  Minimin ON
  Equil ON
  CUDA
  CutoffPeriodic
  Error: Box decreased 👎
• configuration_2: same as configuration_1 but:
  No barostat
  Error: Nan or Inf generation 👎
• configuration_3: same as configuration_1 but:
  No barostat
  No equil
  Simulation run! 👯
• configuration_4: same as configuration_1 but:
  No barostat
  No minimization but Equilibration ON
  Simulation run! 👍
• configuration_5: same as configuration_1 but:
  No barostat
  No thermostat
  Error: Nan or Inf generation 👎
• configuration_6: same as configuration_1 but:
  Cutoff NON periodic
  Simulation run but E_total ~ 10^14 kcal/mol 👎

On the other hand, it is possible to run such a simulation if perturbation is done on the external carbon atom while the central one remain a carbon.

Make sure that a somd run will:
a) have reasonable default parameters for NPT runs.
b) does some checking of given parameter sets and either raise Runtime warnings or Errors depending on the severity of poorly chosen parameter sets.

It would be good if we can implement a consistent way of checking input parameters.
Most Sire apps will have a common set of checks and then app specific set of checks.
What would be the best way to implement this and where exactly?
To me a class structure seems useful here, having a SanityCheck Class, that would then have a set of common sanity checks implemented and can then be extended for app specific checks. Would this make sense? What would be the best place to put such checks?
I would also propose to use something like Run time warnings, and runtime errors to distinguish between severity of badly chosen parameters.

sommmd (openmmIntegrator.cpp) debug statements seem to have inherited a couple of copy paste methods from the free energy calculation method, providing information about lambdas that don't exist.

Currently the free_en_analysis branch supports the compilation of sire with both openMM and without openMM. However, if any of the OpenMM wrappers are changed, by using the automated wrapper generation script, wrapper/Move/CMakeAutogenFile.txt is updated and will be included in the CMake list and contain OpenMM files in the PYPP_SOURCES variable. For that purpose I created two additional files CMakeNoOpenMM.txt and CMakeOpenMM.txt. These will populate the SIRE_OPENMM_WRAPPERS variable and are selected based on an if statement that check if OpenMM support is turned on or not. The script that updated wrapper/Move/CMakeAutogenFile.txt, needs to respect that if the OpenMM/noOpenMM support is meant to be given.
In general I am not sure how checking for OpenMM support is done currently is the best way of doing it. Certainly there will be no warning, if somd is attempted to be called for example.
This again I think requires some tidying of the Cmake files as well as warning within the repository. I definitely need some help/discuss how to best approach this since I have very limited experience with this kind of thing.

In OpenMMfrenergyst.cpp and openmmmd.cpp make sure variable names are consistantant and correctly spelled.

On feature_HMR, but with HMR flag disabled so code should be equivalent to devel before branch.

Running
rm *.s3 *.dat *.dcd *.pdb ; ~/sire.app/bin/somd -C ../../input/freenrg.cfg
produces a segfault
(...)

Running Molecular Dynamics simulation on unknown

================Setting up calculation=====================

New run. Loading input and creating restart
Reading topology file "../../input/solvated.parm7"
Reading coordinate file "../../input/solvated.rst7"
Building 11221 molecule(s)...
...building molecule 1000 ...
...building molecule 2000 ...
...building molecule 3000 ...
...building molecule 4000 ...
...building molecule 5000 ...
...building molecule 6000 ...
...building molecule 7000 ...
...building molecule 8000 ...
...building molecule 9000 ...
...building molecule 10000 ...
...building molecule 11000 ...
Getting space information
Read space "PeriodicBox( ( 69.5294, 73.0467, 75.3992 ) )"
...complete
Creating the system...
Creating force fields...
Setting up the simulation with random seed 325675
Setting up moves...
Created a MD move that uses OpenMM for all molecules on 0
Generated random seed number 325675
Saving restart
There are 38319 atoms in the group

===========================================================

=======================Minimisation========================

Running minimisation.
Segmentation fault (core dumped)

• Doing 1 step of MD without minimisation also fails

julien@ubuntu:/mnt/hgfs/sims/somd/thrombin-HMR/bound/debug-gradients/output/debug$ rm *.s3 *.dat *.dcd *.pdb ; ~/sire.app/bin/somd -C ../../input/freenrg.cfg
(...)

Running Molecular Dynamics simulation on unknown

================Setting up calculation=====================

New run. Loading input and creating restart
Reading topology file "../../input/solvated.parm7"
Reading coordinate file "../../input/solvated.rst7"
Building 11221 molecule(s)...
...building molecule 1000 ...
...building molecule 2000 ...
...building molecule 3000 ...
...building molecule 4000 ...
...building molecule 5000 ...
...building molecule 6000 ...
...building molecule 7000 ...
...building molecule 8000 ...
...building molecule 9000 ...
...building molecule 10000 ...
...building molecule 11000 ...
Getting space information
Read space "PeriodicBox( ( 69.5294, 73.0467, 75.3992 ) )"
...complete
Creating the system...
Creating force fields...
Setting up the simulation with random seed 608133
Setting up moves...
Created a MD move that uses OpenMM for all molecules on 0
Generated random seed number 608133
Saving restart
There are 38319 atoms in the group

===========================================================

=======================somd run============================

Starting somd run...
1 moves 1 cycles, 0.002 ps simulation time

Cycle = 1
NaN or Inf has been generated along the simulation

• But running somd-freenrg works

julien@ubuntu:/mnt/hgfs/sims/somd/thrombin-HMR/bound/debug-gradients/output/debug$ rm *.s3 *.dat *.dcd *.pdb ; ~/sire.app/bin/somd-freenrg -C ../../input/freenrg.cfg
(...)
Running a somd-freenrg calculation using files ../../input/solvated.parm7, ../../input/solvated.rst7 and ../../input/MORPH.pert.

Running Single Topology Molecular Dynamics Free Energy on unknown

================Setting up calculation=====================

New run. Loading input and creating restart
lambda is 0.1
Reading topology file "../../input/solvated.parm7"
Reading coordinate file "../../input/solvated.rst7"
Building 11221 molecule(s)...
...building molecule 1000 ...
...building molecule 2000 ...
...building molecule 3000 ...
...building molecule 4000 ...
...building molecule 5000 ...
...building molecule 6000 ...
...building molecule 7000 ...
...building molecule 8000 ...
...building molecule 9000 ...
...building molecule 10000 ...
...building molecule 11000 ...
Getting space information
Read space "PeriodicBox( ( 69.5294, 73.0467, 75.3992 ) )"
...complete
Create the System...
Selecting dummy groups
Creating force fields...
Setting up the simulation with random seed 994931
Setting up moves...
Created a MD move that uses OpenMM for all molecules on 0
Generated random seed number 994931
Saving restart
There are 38319 atoms in the group

===========================================================

=======================Minimisation========================

Running minimisation.
(....)

Minimisation starts but it takes forever on CPU On my laptop. No immediate segfaults.

I can also do 1 step of MD without minimisation without error.

julien@ubuntu:/mnt/hgfs/sims/somd/thrombin-HMR/bound/debug-gradients/output/debug$ rm *.s3 *.dat *.dcd *.pdb ; ~/sire.app/bin/somd-freenrg -C ../../input/freenrg.cfg
Running a somd-freenrg calculation using files ../../input/solvated.parm7, ../../input/solvated.rst7 and ../../input/MORPH.pert.

Running Single Topology Molecular Dynamics Free Energy on unknown

================Setting up calculation=====================

New run. Loading input and creating restart
lambda is 0.1
Reading topology file "../../input/solvated.parm7"
Reading coordinate file "../../input/solvated.rst7"
Building 11221 molecule(s)...
...building molecule 1000 ...
...building molecule 2000 ...
...building molecule 3000 ...
...building molecule 4000 ...
...building molecule 5000 ...
...building molecule 6000 ...
...building molecule 7000 ...
...building molecule 8000 ...
...building molecule 9000 ...
...building molecule 10000 ...
...building molecule 11000 ...
Getting space information
Read space "PeriodicBox( ( 69.5294, 73.0467, 75.3992 ) )"
...complete
Create the System...
Selecting dummy groups
Creating force fields...
Setting up the simulation with random seed 669245
Setting up moves...
Created a MD move that uses OpenMM for all molecules on 0
Generated random seed number 669245
Saving restart
There are 38319 atoms in the group

===========================================================

====================somd-freenrg run=======================

Starting somd-freenrg run...
1 moves 1 cycles, 0.002 ps simulation time

Cycle = 1

Saving atom coordinates every 1

Simulation took 25 s

===========================================================

Clearing buffers...
Backing up previous restart
Saving new restart

• I can email input files if useful.

Should we also require numpy or avoid another dependency?

I would delete the following classes, since they are not used anywhere:
openmmintegrator.h/cpp
openmmacceleratedmdintegrator.h/cpp

What does:
integratorworspacejm.cpp/h do? Should this also be remove/incorporated?

Rewrite/tidy significantly openmmd code that would be used with somd-freenrg.

1. pass parameters from input files. (#check variable names)
2. Check if restart file exists
   -> if yes: read it and carry on with simulation
   -> if no: create system, minimize the system, anneal the system, (run equilibration at a given lambda -- if appropriate option was set), run simulation
3. write output and restart files.
   in principle this can be done already (minus the equilibration option), but in a not very easy to follow way.

Also I would suggest to adhere to python coding standard, with naming, formatting etc. of python code:
https://www.python.org/dev/peps/pep-0008/

somd-frenrg needs to be modified in a way that it can output gradients/energies in a way that it can be used in an mbar analysis allowing direct comparison between TI and MBAR..and other estimators in the future.

I was just wondering how 'current' the build directory in Sire is (corelib/build). It contains a readme and INSTALL instructions which are probably better off in the main repository, but don't seem to be quite correct.
Is information in there actually used? There are some scripts there as well. I haven't really looked at them in detail...

Command arguments are overwritten from config file arguments. There should again be a sanity check whether an argument is doubly defined as a command line parameter and a configfile parameter and whether they agree or disagree.

Would it be possible to switch the default branch on github for Sire from "master" to "devel"? All of the statistics on the front page are generated for the default branch, and it currently looks like Sire only has one contributor and few commits. Also, by default, I think that users should see the "devel" branch when they try to check out or see anything, as it shows the bleeding edge of Sire. We should use "master" for merging back stable chunks of code in preparation for release (e.g. as "trunk" was used in google code)

There should only be one interface for MD and free energy simulations using somd. For free energy simulations both a morph file and lambda value need to be given.

This makes it easy to make setup errors by for instance writing a keyword with a typo.

It may be more sensible as part of our plans to implement sanity checks to at least raise a warning if the user has passed a keyword that is unrecognised by one app.

Need to edit code in corelib/SireMove and wrapper/move/ to detect that OpenMM is not available.

I don't seem to quite understand what the difference between openmmacceleratedmdintegrator.cpp and openmmmdintegrator.cpp are? openmmacceleratedmdintegrator.cpp is not used with the wrapper, or did I not look properly?

At the moment users have to decide which app to use if they want to run MD or free energy calculations.

Internally this is because we call OpenMMMD.run() or OpenMMMD.runFreeNrg()

However both subroutines are fairly similar. Every time we implement a new feature in one subroutine that may be relevant to the other, we have to duplicate code (for instance hydrogen mass repartition).

It could be possible to have a single somd app that calls OpenMMMD.run(), and use the appropriate free energy specific subroutines if free energy keywords have been passed. Or we could require that free energy calculations are activated with a command line or config file keyword.

For instance

if freenrg:
system = createSystemFreeEnergy(molecules)
else:
system = createSystem(molecules)

Thoughts?

The current restart mechanism overrides some parameter values from the command line and input config file with parameter values that were stored in the restart.s3 files.
Config file parameter values that aren't stored in the restart files are used however.
This can lead to surprising behaviour for a user. For instance, it isn't possible to change the temperature of a simulation by reloading a restart file and passing a new temperature value in the config file. Most apps complain about a missing top/crd input even if restarting from an s3 file that contains all the necessary data. At the moment knowledge of the source code is needed to avoid setup errors.

We should discuss

• whether restart paramaters have precedence over config parameters
• whether we should issue warning or refuse to proceed if config file parameters are incompatible with restart file parameters.
• how to test whether config file options are incompatible with the state of the system.
• how to make sure users know the differences between a calculation started from scratch and restarting a simulation.

This suggests sanity checks should also be implemented after a restart file has been loaded and before a calculation starts.

Normally I wouldn't create an issue for a retractor, but this requires significant changes, but would make spelling of other variables/function names more consistent.

Hi,

Just suggesting that when you compile the python3.3 in the bundle for Sire that you add the --with-zlib option into cmake. list( APPEND PYTHON_OPTIONS "--with-zlib" ) I am getting Python version without
zlib capability so I can't install setuptools.

Thanks,
George

Despite MCBarostat set to true, I end up with virtually no boxsize fluctuation, which turned out to be problematic for a not well equilibrated initial system. (I end up with holes in the water everywhere.)

It would be nice to have an OpenMM baseclass which then can be extended to do ST/DT free energy calcualtions as well as standard MD.
This needs some thought though and will have to be an enhancement for the future.

With the current code we have in OpenMMDD.py

gradients = integrator.getGradients()
mean_gradient = np.average(gradients)
outgradients.write("%5d %20.10f\n" % (i, mean_gradient))

Thus we take an arithmetic average of values stored in gradients.

This is done around line 3500 of openmmfrenergyst.cpp

    if (sample_count != (n_samples))
    {
        energies.append(avg_pot_energy_lambda * OpenMM::KcalPerKJ);
        gradients.append(actual_gradient * OpenMM::KcalPerKJ);
    }
    if (sample_count == (n_samples))
    {
        gradients.append(actual_gradient * OpenMM::KcalPerKJ);
        energies.append(avg_pot_energy_lambda * OpenMM::KcalPerKJ);
    }

(Note that energies is a cumulative average, but gradients is not)

• Actual gradient is computed line 3475
  actual_gradient = (minv_beta * log((plus) / (minus))) / double_increment;

• plus and minus are given around line 3455-3473 with expressions of the form

   plus = exp(-beta * (potential_energy_lambda_plus_delta - potential_energy_lambda));
  

So after simplifications the gradient amounts to (\Delta Uplus - \DeltaUminus) over (2 * \Delta lambda).

It's ok but convoluted...When the code is rewritten to handle calculation of energies at other lambda values, we should just compute in C++ ensemble averages of differences in energies between a reference and perturbed state. Ideally this is all that should be needed for analysis by another code.
We should avoid averaging energies before output as we may end up with too few datapoints for various analyses (e.g. autocorrelation functions). The datastorage requirements should still be modest compared to the size of the output trajectories.

Hi there!

It appears that performing simulations with no constraints also water molecules do not have constraints and it can cause instabilities.

Hi, just noticed that dcd_writer.h and dcd_writer.cpp is under both the openmm dependent and
openmm independent cmake lists.

Thanks,
George

I've just about got the packaging (sire.app/bin/package_sire) working with the anaconda install. Now that I have done this, I have noticed that the size of the Sire directory has increased significantly. This is because the Sire test directory is now very large:

du -hs sire.app = 717 MB
du -hs sire.app/pkgs/sire-0.0.1 = 516 MB
du -hs sire.app/pkgs/sire-0.0.1/test = 397 MB

This results in a sire.run binary package that is 148 MB in size.

If we remove the test directory, then we have;

du -hs sire.app = 320 MB
du -hs sire.app/pkgs/sire-0.0.1 = 118 MB

This results in a sire.run binary package that is 111 MB in size.

The data in the Sire test directory is only likely to grow. I suggest that we create a new git repository for the sire test data and move all of the test data to there. We could then add a small command to the sire_test script that runs a git clone or git pull to download or update the test data before running any tests.

What do you think?

When I do an install of the github version of sire, I don't seem to have ~/sire.app/bundles/bin/pip available after the install. Since debugging with ipython is a lot easier, I am wondering where the packaging for this happens?

We should have a keyword to save less frequently snapshots in dcd files for intermediate states that do not correspond to chemically meaningful molecules. Many users will want to complement their free energy calculations with analysis of the end-states, but are less likely to perform such analyses on intermediate states. Storing structural data for these states less frequently will significantly reduce disk usage.

Current implementation disregards the update of the box vectors from the openMM system to Sire system after a set of equilibration steps. Instead for an NPT equilibration the old Sire boxvectors are still being used.
This needs to be fixed.

Julien and I have discussed that the default free energy analysis method should from now on be MBAR and not TI any more. I have rewritten the code to now generate output files that can be used for MBAR analysis (as well as simple TI using trapezium integration)

These output files are ascii data (preferred format for easy inspection, by both Julien and myself.)
In order to now analyse this new data format with mbar I have started sketching a free_energy_analysis_mbar file. It works fine, but still needs a lot of sanity checking/commenting. Currently free_energy_analysis is still supported and at least gradients.s3 files are written out.

So far I didn't want to interfer with the old way of analysis too much, but at some point there should be a uniform free energy analysis tool.

Are you particularly attached to the free_energy_analysis script? Do you have any ideas how to integrate this well. Should there be a backward compatibility, i.e. do we still want to support free_energy_analysis? I would like some thoughts/input on this before I make any rigorous decisions.

There is a lot of old/redundant information in the makefiles. (Such as svn version, which isn't event used anymore). This should be tidied up soon.

Furthermore some of the bundeling done is really clunky and it is difficult to add new repositories to.
In the particular case I would like to add a dependency for pymbar to the repository, which requires also a dependency of numpy and six. The latter two can be installed via pypi, pymbar cannot, or at least not a python3 supported version of it.

I would temporarily propose to replace the python3 zip with a miniconda installation. This can be downloaded online, on the fly, allowing always for the latest version, the installer is small and fast, making the repository more managable.
I had a little look at it, but since my knowledge of cmake is very limited, I couldn't quickly figure out how to do this, without breaking anything.

Naively I assumed it should be something like this:

execute_process(
  COMMAND ${CMAKE_COMMAND} -E wget https://repo.continuum.io/miniconda/Miniconda3-latest-Linux-x86_64.sh -O miniconda.sh
)
execute_process(
  COMMAND ${CMAKE_COMMAND} -E bash miniconda.sh -b -p ${BUNDLE_BUILDDIR}/miniconda
)
execute_process(
  COMMAND ${CMAKE_COMMAND} -E ${BUNDLE_BUILDDIR}/miniconda3/bin/conda install numpy scipy 
)

It clearly doesn't just work replacing the python installation with the above (or probably it does but I am missing some important bits here and there). I would probably waste quite some time to figure out, how to make a miniconda installation work as the bundled python does at the moment. It would be great if I could have some feedback/help with this.

Make sure that in trajectory output all coordinates are wrapped.

make sure that bundled pip and setuptools actually install properly and don't have to be manually installed after the initial install process.

Possibly used a bundled conda instead?

Hi,
Just posting all the compilations issues I had so far when compiling Sire without openmm on openSUSE 12.2 (x86_64):

First when compiling the corelib library in a folder called buildcorelib I get the following error after typing make install -j 7(after first configuring things in ccmake):
In file included from /usr/users/gerogiokas/Software/sire_nautilus/corelib/src/libs/SireMove/dcd_writer.cpp:1:0:
/usr/users/gerogiokas/Software/sire_nautilus/corelib/src/libs/SireMove/dcd_writer.h:3:45: fatal error: OpenMM.h: No such file or directory
compilation terminated.
make[2]: *** [src/libs/SireMove/CMakeFiles/SireMove.dir/dcd_writer.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [src/libs/SireMove/CMakeFiles/SireMove.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
Linking CXX shared library libSireAnalysis.so
[ 81%] Built target SireAnalysis
make: *** [all] Error 2

I get around this issue by deleting the dcd_writer.cpp and dcd_writer.h in the SIREMOVE lists and left them in the SIREMOVE_OPENMM lists set in the cmake lists files in SireMove folder of the source.

Once I do that the compilation has trouble finding the bundled TBB libraries:
TBB_LIBRARY
linked by target "SireMM" in directory /usr/users/gerogiokas/Software/sire_nautilus/corelib/src/libs/SireMM
TBB_MALLOC_LIBRARY
linked by target "SireMM" in directory /usr/users/gerogiokas/Software/sire_nautilus/corelib/src/libs/SireMM

I set them using ccmake then corelib is compiled properly when I use make install -j 7.

I begin compiling the wrappers in the folder buildwrappers. And get the following error:
make[2]: *** [Move/CMakeFiles/Move.dir/OpenMMIntegrator.pypp.cpp.o] Error 1
make[1]: *** [Move/CMakeFiles/Move.dir/all] Error 2
make: *** [all] Error 2

So, now it still thinks its trying to install openmm with it even though corelib compilation explictly
had openmm turned off in ccmake.

I am now stuck here.

George

Hi,

I'm puzzled by a strange behaviour of Sire that I have discovered while debugging energies of single topology morphs that have variable impropers.

I'm working with a setup where I am morphing acetone into propane. The topology is, using acetone as a starting state:

     O3
     |

C1-C2-C4
|
DU11

Leap adds to the parm file an improper term for impropers involving the carbonyl group and the dummy atom, i.e.

C1 DU11 C2 O3
C4 DU11 C2 O3

These get assigned the potential 10.5 * ( 1 + cos ( 2 phi - pi ) )

This leads to an incorrect simulation of acetone at lambda=0.0.

To address this FESetup overrides leap with variable improper definitions in the MORPH.pert file

(...)
improper
atom0 C1
atom1 DU11
atom2 C2
atom3 O3
initial_form 0.0 0.0 0.0
final_form 0.0 0.0 0.0
endimproper
improper
atom0 C4
atom1 DU11
atom2 C2
atom3 O3
initial_form 0.0 0.0 0.0
final_form 0.0 0.0 0.0
endimproper
(...)

Now when a free energy calculation would be performed, sire load first an amber parm7 file, and then 'patches' the topology according to the pert file. This should override the wrong leap impropers.

Except Sire only does it only for C1 DU11 C2 C3, so I still end up with a bad improper term for C4 DU11 C2 O3.

Eventually I realised this happened because of the code in SireMM::FourAtomPerturbation::perturbMolecule

(...)
Expression new_function = perturbExpression().substitute(idents);

Expression old_function = funcs.potential(atm0, atm1, atm2, atm3);

if (new_property or (new_function != old_function))
{
//funcs.set(atm0, atm1, atm2, atm3, new_function);
// What if this is dealing with impropers?
funcs.set( DihedralID(atm0, atm1, atm2, atm3), new_function);
molecule.setProperty(param_property, funcs);
}

The problem is easier to explain by adding the line of code
Expression old_function2 = funcs.potential(atm3, atm2, atm1, atm0);
and a few print statements.

This shows that for these two impropers (listed below by atom indices rather than atom names)

Dihedral "Dihedral( AtomIdx(3), AtomIdx(10), AtomIdx(1), AtomIdx(2) )"
new func "0"
old func "0"
old func2 "10.5 [cos(2 phi - 3.14159) + 1]"
Dihedral "Dihedral( AtomIdx(0), AtomIdx(10), AtomIdx(1), AtomIdx(2) )"
new func "0"
old func "10.5 [cos(2 phi - 3.14159) + 1]"
old func2 "0"

So in the first case 3 -10-1-2 which corresponds to C4 DU11 C2 O3 the code believes that the new and old potentials are the same because new func and old func are the same. In that case the new function is not applied.
However this happened because the FourAtomFunction that stores this improper potential is

FourAtomFunction( {CGIdx(0),Index(2)} <- {CGIdx(0),Index(1)} - {CGIdx(0),Index(10)} -> {CGIdx(0),Index(3)} : 10.5 [cos(2 phi - 3.14159) + 1] )

The order of the atoms in FourAtomFunction is the reverse of the order of the atoms in the matching FourAtomPerturbation

FourAtomPerturbation( AtomIdx(3)-AtomIdx(10)-AtomIdx(1)-AtomIdx(2) : 0 )

By default funcs.potential(atm0, atm1, atm2, atm3) returns a Expression("0") if no matching FourAtomFunction is found in funcs. Since the new_function is also Expression("0") then new_function = old_function and the new_function is not set.

This is why the definition of old_function2 (that has swapped the order of the atoms) returns the expected potential

old func2 "10.5 [cos(2 phi - 3.14159) + 1]"

This is very strange because the improper in the amber parm7 file and in the pert files are defined in the same order.

For the other improper C1 DU11 C2 C3 the code behaves as expected because the order of the atoms in the molecule's FourAtomFunction is the same as in the molecule's FourAtomPerturbation (because they are in the same order in the parm7 file and the pert file).

I really don't understand why this improper has changed the order of the atoms !

One kludge that solves the problem is to remove the final if statement, i.e.

if (new_property or (new_function != old_function))
{
    //funcs.set(atm0, atm1, atm2, atm3, new_function);
  // What if this is dealing with impropers?
    funcs.set( DihedralID(atm0, atm1, atm2, atm3), new_function);
    molecule.setProperty(param_property, funcs);
}

becomes

    //funcs.set(atm0, atm1, atm2, atm3, new_function);
  // What if this is dealing with impropers?
    funcs.set( DihedralID(atm0, atm1, atm2, atm3), new_function);
    molecule.setProperty(param_property, funcs);

Now the code sets the new_function no matter what.

Another kludge would be to have
funcs.potential(atm0, atm1, atm2, atm3) not return an Expression("0") if no matching atoms are found.

A better solution would be to figure out why funcs.potential(atm0, atm1, atm2, atm3) does not find the correct potential. I think this would involve looking at SireMM:FourAtomFunctions and figure out what is going on.

The softcore custom forcefield terms are really cryptic to me. (No I don't really want to touch them and change them right now.) I was wondering is there a paper/report something that gives detailed information what the terms are that are being passed to OpenMM::CustomNonbondedForce method? I tried Gaetano's thesis but there was nothing more than the usual, this is what a molecular forcefield looks like.

I just tested the sire install script. It supposedly installs everything correctly, but when it tries to run the test it fails:

 ./compile_sire.sh: line 73: 28270 Illegal instruction     (core dumped) ${INSTALL_DIR}/bin/python build/build_sire.py

same happens if I try and do it manually:

$:~/Projects/Sire/corelib: ~/dev_sire.app/bin/ipython
Python 3.4.3 |Continuum Analytics, Inc.| (default, Jun  4 2015, 15:29:08) 
Type "copyright", "credits" or "license" for more information.

IPython 4.0.0 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.

In [1]: import Sire.CAS
Illegal instruction (core dumped)

All I did was try to run the compile_sire bash script.

Is it possible that restarts do not work using the 'current' openMMMD.py script?

Hi I tried using the installation instructions (given for Ubuntu) to install SIRE on mac. Everything worked fine, up to point 8. When I tried installing the setuptools module from sire-python it gave me an error.

$cd /Users/Sriram/Software/Sire-master/build_wrapper/build_bundled/setuptools
$~/sire.app/bundled/bin/python3 setup.py install
Traceback (most recent call last):
  File "setup.py", line 17, in <module>
    exec(init_file.read(), command_ns)
  File "<string>", line 8, in <module>
  File "/Users/Sriram/Software/Sire-master/build_wrapper/build_bundled/setuptools/setuptools/__init__.py", line 2, in <module>
    from setuptools.extension import Extension, Library
  File "/Users/Sriram/Software/Sire-master/build_wrapper/build_bundled/setuptools/setuptools/extension.py", line 5, in <module>
    from setuptools.dist import _get_unpatched
  File "/Users/Sriram/Software/Sire-master/build_wrapper/build_bundled/setuptools/setuptools/dist.py", line 7, in <module>
    from setuptools.command.install import install
  File "/Users/Sriram/Software/Sire-master/build_wrapper/build_bundled/setuptools/setuptools/command/__init__.py", line 8, in <module>
    from setuptools.command import install_scripts
  File "/Users/Sriram/Software/Sire-master/build_wrapper/build_bundled/setuptools/setuptools/command/install_scripts.py", line 3, in <module>
    from pkg_resources import Distribution, PathMetadata, ensure_directory
  File "/Users/Sriram/Software/Sire-master/build_wrapper/build_bundled/setuptools/pkg_resources.py", line 16, in <module>
    import sys, os, time, re, imp, types, zipfile, zipimport
ImportError: No module named 'time'

Can you please tell where I am getting it wrong??

In the original version with integrate also doing a minimization/annealing, this process was called equilibration.
Question: Should there be an annealing option, as well as an equilibration option?
To me an annealing would be slowly pushing the system to the right value of lambda.
An equilibration would be a couple of picoseconds dynamics, already at the correct value of lambda, before starting any measurements.

At the moment equilibration iterations are annealing steps.
I would propose the following parameters:
``
minimization_tol.val #tolerance for minimization
minimization_maxiter.val #maximum number of iterations
anneal_steps.val #number of steps for each round of annealing
anneal_timesteps.val #timestep for the annealing
equil_steps.val #number of actual equilibration steps
equil_timestep.val #time step of the equilibration

``
The annealing of course only makes sense if there is something to be annealed (i.e. in a free energy simulation.)

By implementing hydrogen mass repartitioning.