sommmd & analyse_freenrg integration
29 views
Skip to first unread message
julien
Aug 12, 2014, 4:49:53 AM8/12/14
to sire-de...@googlegroups.com
Hi Chris,
I have studied the code you sent me last week.
- What do you think of renaming sommmd to somd ? I find it difficult to type sommmd as it is difficult to remember how many times the letter ‘m’ must be typed. some = Sire + OpenMM + Molecular Dynamics seems just as fine.
- For the free energy analysis, I think a way to go is to have:
A) The user runs as many somd-freenrg calculations at different lambda values as desired. At the moment each lambda value is done by a different somd-freenrg process. Each somd-freenrg process writes in a lam-X.XXX folder the value of the gradients at each iteration in ascii e.g.
1 0.504
2 0.485
(…)
B) The user decides to calculate free energies by calling analyse_freenrg
I do not have an analyse-freenrg script in my branch. Can I just merge your python/branches/devel/python/scripts folder or do I also need to update the code elsewhere (corelib/src/libs/SireAnalysis ? )
Assuming this is the right place, then I need to add a command line argument to the script to trigger collection of the lambda values from the different subfolders. This could be
--collect lam-* —> Will look in every subfolder of the current working directory for a folder that starts with the string lam- . Inside each folder, will look for a file called ‘ gradients.dat'' (override default with —gradients_file XXXXX).
This should give me what I need to write a function that will create a TI object.
From there I just execute the rest of analyse-freenrg.
An alternative is to write a separate script to collect the gradients and dump a freenrg.s3 file and then call analyse_freenrg.
However I think the analyse will be more consistent with your free energy analyses if this is all done by analyse_freenrg in one step? I don’t think the user needs to think about what the file freenrg.s3 contains.
- At the moment the SireOpenMM free energy module returns to Sire gradients that have been estimated by finite difference. The code could be simplified to just return forwards and backwards free energies, which would be then converted in gradients by SireAnalysis::TI(). Alternatively we pretend that these are analytic gradients. This looks a bit clumsy but one advantage is that we do not have to know the delta lambda value that was used when collecting the gradients.
Christopher Woods
Aug 12, 2014, 5:17:18 AM8/12/14
to Sire Developers
Hi Julien,
> What do you think of renaming sommmd to somd ? I find it difficult to type
> sommmd as it is difficult to remember how many times the letter ‘m’ must be
> typed. some = Sire + OpenMM + Molecular Dynamics seems just as fine.
I am happy to rename sommmd to somd. To rename, just rename sommmd.py
in the python/scripts directory, and everything will take care of
itself.
> For the free energy analysis, I think a way to go is to have:
>
> A) The user runs as many somd-freenrg calculations at different lambda
> values as desired. At the moment each lambda value is done by a different
> somd-freenrg process. Each somd-freenrg process writes in a lam-X.XXX
> folder the value of the gradients at each iteration in ascii e.g.
>
> 1 0.504
>
> 2 0.485
>
> (…)
Sounds like a good plan.
> B) The user decides to calculate free energies by calling analyse_freenrg
>
> I do not have an analyse-freenrg script in my branch. Can I just merge your
> python/branches/devel/python/scripts folder or do I also need to update the
> code elsewhere (corelib/src/libs/SireAnalysis ? )
Yes, you can merge from my python/scripts directory, but you will also
need to merge in changes from src/libs/SireAnalysis. This is to pull
in bug fixes that caused problems with the FEP and Bennetts code,
which I think changed the API slightly for TI.
> Assuming this is the right place, then I need to add a command line argument
> to the script to trigger collection of the lambda values from the different
> subfolders. This could be
>
> --collect lam-* —> Will look in every subfolder of the current working
> directory for a folder that starts with the string lam- . Inside each
> folder, will look for a file called ‘ gradients.dat'' (override default with
> —gradients_file XXXXX).
>
> This should give me what I need to write a function that will create a TI
> object.
>
> From there I just execute the rest of analyse-freenrg.
>
> An alternative is to write a separate script to collect the gradients and
> dump a freenrg.s3 file and then call analyse_freenrg.
>
> However I think the analyse will be more consistent with your free energy
> analyses if this is all done by analyse_freenrg in one step? I don’t think
> the user needs to think about what the file freenrg.s3 contains.
I agree. Collecting together and analysing the gradients should be
performed all in one step using analyse_freenrg. At the moment,
analyse_freenrg takes a single input file, via the "-i" option. If we
changed this so that it could take in lots of option files, then it
could load up all of the TI objects in one go. Perhaps the best thing
would be to write the gradients from each lambda as
SireAnalysis.Gradients objects (e.g. as lam-0.0/gradients.s3). Each
gradients object would contain just the gradients for that lambda
value (including the lambda and delta lambda value, as this is held in
SireAnalysis.Gradients). Then, if analyse_freenrg was called with,
e.g. analyse_freenrg -i lam*/gradients.s3, then it would load up each
gradient object, extract the gradients via "analyticData",
"forwardsData" or "backwardsData" functions, merge them all into a
single python dictionary, and then create a new Gradients object using
the merged python dictionary. You could then use this new merged
Gradients object to create the TI object for analysis, e.g.
(pseudocode)
if num_inputfiles == 1:
# load up freenrgs.s3 file as we current do and analyse freenrgs
else:
# assume we have a lot of gradients files and load them up
grads = {}
fwds_grads = {}
bwds_grads = {}
delta_lambda = None
for i in range(0,num_inputfiles):
grad = Sire.Stream.load(input_file[i])
analytic_data = grad.analyticData()
fwds_data = grad.forwardsData()
bwds_data = grad.backwardsData()
if not analytic_data.isEmpty():
# analytic gradients
lamval = analytic_data.keys()[0]
grads[ lamval ] = analytic_data[lamval]
else:
# finite difference gradients
lamval = fwds_data.keys()[0]
fwds_grads[lamval] = fwds_data[lamval]
bwds_grads[lamval] = bwds_data[lamval]
delta_lambda = grad.deltaLambda()
ti = None
if not grads.isEmpty():
ti = TI( Gradients(grads) )
else:
ti = TI( Gradients(fwds_grads,bwds_grads,delta_lambda) )
pmf = TI.merge(...).integrate() etc. etc.
> At the moment the SireOpenMM free energy module returns to Sire gradients
> that have been estimated by finite difference. The code could be simplified
> to just return forwards and backwards free energies, which would be then
> converted in gradients by SireAnalysis::TI(). Alternatively we pretend that
> these are analytic gradients. This looks a bit clumsy but one advantage is
> that we do not have to know the delta lambda value that was used when
> collecting the gradients.
Saving the gradients data as SireAnalysis.Gradients objects solves
this problem as the delta_lambda data is included. Another advantage
is that you don't need to write parsers to read and write gradient
data to and from text files, and you don't have to worry about users
accidentally damaging the text file. The downside is that the
gradients are not human readable, but the advantage is that it is very
easy to load them up and manipulate them in python.
Cheers,
Christopher
> What do you think of renaming sommmd to somd ? I find it difficult to type
> sommmd as it is difficult to remember how many times the letter ‘m’ must be
> typed. some = Sire + OpenMM + Molecular Dynamics seems just as fine.
in the python/scripts directory, and everything will take care of
itself.
> For the free energy analysis, I think a way to go is to have:
>
> A) The user runs as many somd-freenrg calculations at different lambda
> values as desired. At the moment each lambda value is done by a different
> somd-freenrg process. Each somd-freenrg process writes in a lam-X.XXX
> folder the value of the gradients at each iteration in ascii e.g.
>
> 1 0.504
>
> 2 0.485
>
> (…)
> B) The user decides to calculate free energies by calling analyse_freenrg
>
> I do not have an analyse-freenrg script in my branch. Can I just merge your
> python/branches/devel/python/scripts folder or do I also need to update the
> code elsewhere (corelib/src/libs/SireAnalysis ? )
need to merge in changes from src/libs/SireAnalysis. This is to pull
in bug fixes that caused problems with the FEP and Bennetts code,
which I think changed the API slightly for TI.
> Assuming this is the right place, then I need to add a command line argument
> to the script to trigger collection of the lambda values from the different
> subfolders. This could be
>
> --collect lam-* —> Will look in every subfolder of the current working
> directory for a folder that starts with the string lam- . Inside each
> folder, will look for a file called ‘ gradients.dat'' (override default with
> —gradients_file XXXXX).
>
> This should give me what I need to write a function that will create a TI
> object.
>
> From there I just execute the rest of analyse-freenrg.
>
> An alternative is to write a separate script to collect the gradients and
> dump a freenrg.s3 file and then call analyse_freenrg.
>
> However I think the analyse will be more consistent with your free energy
> analyses if this is all done by analyse_freenrg in one step? I don’t think
> the user needs to think about what the file freenrg.s3 contains.
performed all in one step using analyse_freenrg. At the moment,
analyse_freenrg takes a single input file, via the "-i" option. If we
changed this so that it could take in lots of option files, then it
could load up all of the TI objects in one go. Perhaps the best thing
would be to write the gradients from each lambda as
SireAnalysis.Gradients objects (e.g. as lam-0.0/gradients.s3). Each
gradients object would contain just the gradients for that lambda
value (including the lambda and delta lambda value, as this is held in
SireAnalysis.Gradients). Then, if analyse_freenrg was called with,
e.g. analyse_freenrg -i lam*/gradients.s3, then it would load up each
gradient object, extract the gradients via "analyticData",
"forwardsData" or "backwardsData" functions, merge them all into a
single python dictionary, and then create a new Gradients object using
the merged python dictionary. You could then use this new merged
Gradients object to create the TI object for analysis, e.g.
(pseudocode)
if num_inputfiles == 1:
# load up freenrgs.s3 file as we current do and analyse freenrgs
else:
# assume we have a lot of gradients files and load them up
grads = {}
fwds_grads = {}
bwds_grads = {}
delta_lambda = None
for i in range(0,num_inputfiles):
grad = Sire.Stream.load(input_file[i])
analytic_data = grad.analyticData()
fwds_data = grad.forwardsData()
bwds_data = grad.backwardsData()
if not analytic_data.isEmpty():
# analytic gradients
lamval = analytic_data.keys()[0]
grads[ lamval ] = analytic_data[lamval]
else:
# finite difference gradients
lamval = fwds_data.keys()[0]
fwds_grads[lamval] = fwds_data[lamval]
bwds_grads[lamval] = bwds_data[lamval]
delta_lambda = grad.deltaLambda()
ti = None
if not grads.isEmpty():
ti = TI( Gradients(grads) )
else:
ti = TI( Gradients(fwds_grads,bwds_grads,delta_lambda) )
pmf = TI.merge(...).integrate() etc. etc.
> At the moment the SireOpenMM free energy module returns to Sire gradients
> that have been estimated by finite difference. The code could be simplified
> to just return forwards and backwards free energies, which would be then
> converted in gradients by SireAnalysis::TI(). Alternatively we pretend that
> these are analytic gradients. This looks a bit clumsy but one advantage is
> that we do not have to know the delta lambda value that was used when
> collecting the gradients.
this problem as the delta_lambda data is included. Another advantage
is that you don't need to write parsers to read and write gradient
data to and from text files, and you don't have to worry about users
accidentally damaging the text file. The downside is that the
gradients are not human readable, but the advantage is that it is very
easy to load them up and manipulate them in python.
Cheers,
Christopher
julien
Aug 12, 2014, 11:56:06 AM8/12/14
to sire-de...@googlegroups.com
Hi Chris,
I merged SireAnalysis but had compilation errors because of missing objects from SireMaths (bennettsfreeaverage). So I merged SireMaths as well. Now I have this error at compilation and I am not sure what needs to be merged to fix it.
[ 34%] Building CXX object src/libs/SireMol/CMakeFiles/SireMol.dir/evaluator.cpp.o
/home/julien/software/devel/sirejulien/corelib/src/libs/SireMol/evaluator.cpp: In function ‘void getPrincipalAxes(SireMaths::Matrix&, SireMaths::Vector)’:
/home/julien/software/devel/sirejulien/corelib/src/libs/SireMol/evaluator.cpp:430:57: error: conversion from ‘boost::tuples::tuple<SireMaths::Vector, SireMaths::Matrix>’ to non-scalar type ‘std::pair<SireMaths::Vector, SireMaths::Matrix>’ requested
/home/julien/software/devel/sirejulien/corelib/src/libs/SireMol/evaluator.cpp: In function ‘SireMaths::AxisSet getPrincipalAxes(const AtomCoords&, const SireMol::AtomProperty<T>&, const SireMol::AtomSelection&, SireMaths::Vector&) [with T = SireUnits::Dimension::PhysUnit<1, 0, 0, 0, 0, -0x00000000000000001, 0>, SireMol::AtomCoords = SireMol::AtomProperty<SireMaths::Vector>]’:
/home/julien/software/devel/sirejulien/corelib/src/libs/SireMol/evaluator.cpp:969:52: instantiated from here
/home/julien/software/devel/sirejulien/corelib/src/libs/SireMol/evaluator.cpp:502:21: error: call of overloaded ‘Matrix(int)’ is ambiguous
/home/julien/software/devel/sirejulien/corelib/src/libs/SireMol/evaluator.cpp:502:21: note: candidates are:
/home/julien/software/devel/sirejulien/corelib/src/libs/SireMaths/matrix.h:94:5: note: SireMaths::Matrix::Matrix(const SireMaths::Matrix&)
/home/julien/software/devel/sirejulien/corelib/src/libs/SireMaths/matrix.h:92:5: note: SireMaths::Matrix::Matrix(const gsl_matrix*)
/home/julien/software/devel/sirejulien/corelib/src/libs/SireMaths/matrix.h:82:5: note: SireMaths::Matrix::Matrix(double)
/home/julien/software/devel/sirejulien/corelib/src/libs/SireMol/evaluator.cpp: In function ‘SireMaths::AxisSet getPrincipalAxes(const AtomCoords&, const SireMol::AtomProperty<T>&, const SireMol::AtomSelection&, SireMaths::Vector&) [with T = SireMol::Element, SireMol::AtomCoords = SireMol::AtomProperty<SireMaths::Vector>]’:
/home/julien/software/devel/sirejulien/corelib/src/libs/SireMol/evaluator.cpp:976:52: instantiated from here
/home/julien/software/devel/sirejulien/corelib/src/libs/SireMol/evaluator.cpp:502:21: error: call of overloaded ‘Matrix(int)’ is ambiguous
/home/julien/software/devel/sirejulien/corelib/src/libs/SireMol/evaluator.cpp:502:21: note: candidates are:
/home/julien/software/devel/sirejulien/corelib/src/libs/SireMaths/matrix.h:94:5: note: SireMaths::Matrix::Matrix(const SireMaths::Matrix&)
/home/julien/software/devel/sirejulien/corelib/src/libs/SireMaths/matrix.h:92:5: note: SireMaths::Matrix::Matrix(const gsl_matrix*)
/home/julien/software/devel/sirejulien/corelib/src/libs/SireMaths/matrix.h:82:5: note: SireMaths::Matrix::Matrix(double)
/home/julien/software/devel/sirejulien/corelib/src/libs/SireMaths/constants.h: At global scope:
/home/julien/software/devel/sirejulien/corelib/src/libs/SireMaths/constants.h:88:14: warning: ‘SireMaths::smallest’ defined but not used [-Wunused-variable]
/home/julien/software/devel/sirejulien/corelib/src/libs/SireMaths/constants.h:97:14: warning: ‘SireMaths::largest’ defined but not used [-Wunused-variable]
make[2]: *** [src/libs/SireMol/CMakeFiles/SireMol.dir/evaluator.cpp.o] Error 1
make[1]: *** [src/libs/SireMol/CMakeFiles/SireMol.dir/all] Error 2
make: *** [all] Error 2
I worry that I will end up pulling all your branch in (including unstable code) !
best wishes,
Julien
Christopher Woods
Aug 12, 2014, 12:07:45 PM8/12/14
to Sire Developers
Hi Julien,
The SireMaths code you merged included my new code for aligning
molecules. This has broken the code in 'getPrincipalAxes' that is in
SireMol/evaluator.cpp. The old code in getPrincipalAxes is not used in
Sire and is a bit buggy, so you can safely either comment out the
function, or you can replace code such as;
Matrix inertia( 0 );
with
Matrix inertia( double(0) );
(i.e. tell the Matrix to use the 'double' constructor rather than the
gsl_matrix pointer constructor - as 0 can be interpreted as a pointer)
Christopher
> --
> You received this message because you are subscribed to the Google Groups
> "Sire Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sire-develope...@googlegroups.com.
> To post to this group, send email to sire-de...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sire-developers.
> For more options, visit https://groups.google.com/d/optout.
--
---------------------------------------------------------
Christopher Woods
Centre for Computational Chemistry
School of Chemistry
University of Bristol, BS8 1TS, UK
+44 (0) 7786 264562
http://chryswoods.com
http://uk.linkedin.com/in/chryswoods
The SireMaths code you merged included my new code for aligning
molecules. This has broken the code in 'getPrincipalAxes' that is in
SireMol/evaluator.cpp. The old code in getPrincipalAxes is not used in
Sire and is a bit buggy, so you can safely either comment out the
function, or you can replace code such as;
Matrix inertia( 0 );
with
Matrix inertia( double(0) );
(i.e. tell the Matrix to use the 'double' constructor rather than the
gsl_matrix pointer constructor - as 0 can be interpreted as a pointer)
Christopher
> You received this message because you are subscribed to the Google Groups
> "Sire Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sire-develope...@googlegroups.com.
> To post to this group, send email to sire-de...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sire-developers.
> For more options, visit https://groups.google.com/d/optout.
--
---------------------------------------------------------
Christopher Woods
Centre for Computational Chemistry
School of Chemistry
University of Bristol, BS8 1TS, UK
+44 (0) 7786 264562
http://chryswoods.com
http://uk.linkedin.com/in/chryswoods
julien
Aug 12, 2014, 4:04:32 PM8/12/14
to sire-de...@googlegroups.com
You didn't think it would stop here :-)
So I commented out ::getPrincipalAxes
I then got this error
/home/julien/software/devel/sirejulien/corelib/src/libs/SireAnalysis/ticomponents.cpp: In constructor ‘SireAnalysis::ComponentGradients::ComponentGradients(const QMap<double, SireSystem::FreeEnergyMonitor>&, bool)’:
/home/julien/software/devel/sirejulien/corelib/src/libs/SireAnalysis/ticomponents.cpp:153:48: error: ‘const class SireSystem::FreeEnergyMonitor’ has no member named ‘nSamples’
/home/julien/software/devel/sirejulien/corelib/src/libs/SireAnalysis/ticomponents.cpp:166:57: error: ‘const class SireSystem::FreeEnergyMonitor’ has no member named ‘nSamples’
/home/julien/software/devel/sirejulien/corelib/src/libs/SireAnalysis/ticomponents.cpp: In constructor ‘SireAnalysis::ComponentGradients::ComponentGradients(const QList<SireSystem::FreeEnergyMonitor>&, bool)’:
/home/julien/software/devel/sirejulien/corelib/src/libs/SireAnalysis/ticomponents.cpp:188:49: error: ‘const class SireSystem::FreeEnergyMonitor’ has no member named ‘nSamples’
So I merged SireSystem
julien@ubuntu:~/software/devel/sirejulien/corelib/src/libs/SireSystem$ svn merge https://sire.googlecode.com/svn/corelib/branches/devel/src/libs/SireSystem .
--- Merging r1374 through r1546 into '.':
C energymonitor.cpp
C idassigner.h
C energymonitor.h
C idassigner.cpp
--- Merging r2391 through r2670 into '.':
U constraints.cpp
A volmapmonitor.cpp
U freeenergymonitor.h
U polarisecharges.h
U system.cpp
U delta.h
U freeenergymonitor.cpp
A volmapmonitor.h
U polarisecharges.cpp
U system.h
U delta.cpp
U CMakeLists.txt
U constraint.cpp
Summary of conflicts:
Tree conflicts: 4
julien@ubuntu:~/software/devel/sirejulien/corelib/src/libs/SireSystem$ svn resolved energymonitor.cpp
Resolved conflicted state of 'energymonitor.cpp'
julien@ubuntu:~/software/devel/sirejulien/corelib/src/libs/SireSystem$ svn resolved energymonitor.h
Resolved conflicted state of 'energymonitor.h'
julien@ubuntu:~/software/devel/sirejulien/corelib/src/libs/SireSystem$ svn resolved idassigner.h
Resolved conflicted state of 'idassigner.h'
julien@ubuntu:~/software/devel/sirejulien/corelib/src/libs/SireSystem$ svn resolved idassigner.cpp
Resolved conflicted state of 'idassigner.cpp'
And now I get this error
[ 67%] Building CXX object src/libs/SireSystem/CMakeFiles/SireSystem.dir/anglecomponent.cpp.o
In file included from /home/julien/software/devel/sirejulien/corelib/src/libs/SireSystem/geometrycomponent.h:32:0,
from /home/julien/software/devel/sirejulien/corelib/src/libs/SireSystem/anglecomponent.h:32,
from /home/julien/software/devel/sirejulien/corelib/src/libs/SireSystem/anglecomponent.cpp:29:
/home/julien/software/devel/sirejulien/corelib/src/libs/SireSystem/constraint.h:112:12: error: invalid abstract return type for member function ‘SireSystem::System SireSystem::Constraint::apply(const SireSystem::System&)’
/home/julien/software/devel/sirejulien/corelib/src/libs/SireSystem/system.h:109:25: note: because the following virtual functions are pure within ‘SireSystem::System’:
/home/julien/software/devel/sirejulien/corelib/src/libs/SireMol/moleculegroups.h:320:18: note: virtual void SireMol::MolGroupsBase::update(const SireMol::MoleculeData&)
/home/julien/software/devel/sirejulien/corelib/src/libs/SireMol/moleculegroups.h:323:18: note: virtual void SireMol::MolGroupsBase::update(const SireMol::Molecules&)
/home/julien/software/devel/sirejulien/corelib/src/libs/SireMol/moleculegroups.h:324:18: note: virtual void SireMol::MolGroupsBase::update(const SireMol::MoleculeGroup&)
In file included from /home/julien/software/devel/sirejulien/corelib/src/libs/SireSystem/system.h:36:0,
from /home/julien/software/devel/sirejulien/corelib/src/libs/SireSystem/delta.h:33,
from /home/julien/software/devel/sirejulien/corelib/src/libs/SireSystem/anglecomponent.cpp:30:
/home/julien/software/devel/sirejulien/corelib/src/libs/SireSystem/constraints.h:125:12: error: invalid abstract return type for member function ‘SireSystem::System SireSystem::Constraints::apply(const SireSystem::System&)’
/home/julien/software/devel/sirejulien/corelib/src/libs/SireSystem/system.h:109:25: note: since type ‘SireSystem::System’ has pure virtual functions
In file included from /home/julien/software/devel/sirejulien/corelib/src/libs/SireSystem/anglecomponent.cpp:30:0:
/home/julien/software/devel/sirejulien/corelib/src/libs/SireSystem/delta.h:178:12: error: invalid abstract return type for member function ‘SireSystem::System SireSystem::Delta::apply()’
/home/julien/software/devel/sirejulien/corelib/src/libs/SireSystem/system.h:109:25: note: since type ‘SireSystem::System’ has pure virtual functions
/home/julien/software/devel/sirejulien/corelib/src/libs/SireSystem/delta.h:182:12: error: cannot declare field ‘SireSystem::Delta::delta_system’ to be of abstract type ‘SireSystem::System’
/home/julien/software/devel/sirejulien/corelib/src/libs/SireSystem/system.h:109:25: note: since type ‘SireSystem::System’ has pure virtual functions
I
It looks like I need to merge SireMol to progress. But I am going to wait for feedback here as I worry I am bringing the branch too close to the bleeding edge ... If I can I'd rather not risking breaking the MC code or energy evaluation by merging in your work in progress.
(On the flip side it looks like you will have less work to do to keep our branches in sync in the future :-) )
Julien
Christopher Woods
Aug 12, 2014, 5:06:42 PM8/12/14
to sire-de...@googlegroups.com
Hi Julien,
Don't worry about being near the bleeding edge. I use unit tests now with all development so nothing I am doing will break existing code. All development at the moment is in the new force field system that is in addition to the old force fields (so doesn't break old code). The released versions of Sire are devel versions that pass all unit tests and that are spaced out in time so that there aren't too many releases a year. Feel free to merge SireMol - there's lots of new code in there that I think you will like, e.g, the align code based on finding the maximum common substructure.
Christopher
julien
Aug 13, 2014, 7:11:58 AM8/13/14
to sire-de...@googlegroups.com
Progressing....had to merge a newer qt bundle and recompile. I have been merging many times now. I have now hit this hurdle
[ 54%] Building CXX object src/libs/SireFF/CMakeFiles/SireFF.dir/patches.cpp.o
In file included from /home/julien/software/devel/sirejulien/corelib/src/libs/SireError/exception.h:39:0,
from /home/julien/software/devel/sirejulien/corelib/src/libs/SireError/version_error.h:32,
from /home/julien/software/devel/sirejulien/corelib/src/libs/SireStream/version_error.h:32,
from /home/julien/software/devel/sirejulien/corelib/src/libs/SireStream/datastream.h:38,
from /home/julien/software/devel/sirejulien/corelib/src/libs/SireBase/sharedpolypointer.hpp:32,
from /home/julien/software/devel/sirejulien/corelib/src/libs/SireBase/property.h:32,
from /home/julien/software/devel/sirejulien/corelib/src/libs/SireFF/ffparameters.h:32,
from /home/julien/software/devel/sirejulien/corelib/src/libs/SireFF/patch.h:32,
from /home/julien/software/devel/sirejulien/corelib/src/libs/SireFF/patches.h:32,
from /home/julien/software/devel/sirejulien/corelib/src/libs/SireFF/patches.cpp:29:
/home/julien/software/devel/sirejulien/corelib/src/libs/sireglobal.h: In constructor ‘Sire::RegisterMetaType<T>::RegisterMetaType() [with T = SireFF::FFBead]’:
/home/julien/software/devel/sirejulien/corelib/src/libs/SireFF/patches.cpp:47:39: instantiated from here
/home/julien/software/devel/sirejulien/corelib/src/libs/sireglobal.h:274:9: error: no type named ‘ROOT’ in ‘class SireFF::FFBead’
/home/julien/software/devel/sirejulien/corelib/src/libs/sireglobal.h: In constructor ‘Sire::RegisterMetaType<T>::RegisterMetaType() [with T = SireFF::FFBeadChange]’:
/home/julien/software/devel/sirejulien/corelib/src/libs/SireFF/patches.cpp:125:45: instantiated from here
/home/julien/software/devel/sirejulien/corelib/src/libs/sireglobal.h:274:9: error: no type named ‘ROOT’ in ‘class SireFF::FFBeadChange’
Trying to use merge to update just sireglobal.h doesn't work.
julien@ubuntu:~/software/devel/sirejulien/corelib/src/libs$ svn merge https://sire.googlecode.com/svn/corelib/branches/devel/src/libs/sireglobal.h
svn: '/svn/!svn/bc/8/branches/devel/src/libs/sireglobal.h' path not found
Also I may have missed something, but I don't think my copy of sireglobal.h differs from the version in devel.
To unsubscribe from this group and stop receiving emails from it, send an email to sire-developers+unsubscribe@googlegroups.com.
To post to this group, send email to sire-developers@googlegroups.com.
julien
Aug 13, 2014, 7:42:57 AM8/13/14
to sire-de...@googlegroups.com
Ok, this is weird. I merged SireFF but the file patches.cpp still differed from your branch.
You have
static const RegisterMetaType<FFBead> r_ffbead(NO_ROOT);
I had
static const RegisterMetaType<FFBead> r_ffbead;
Adding back NO_ROOT fixes the problem.
I will keep my eyes open for partial merges then.
Christopher Woods
Aug 13, 2014, 7:55:15 AM8/13/14
to sire-de...@googlegroups.com
You beat me to the fix :-)
Yes, be careful of partial merges. I wrote a perl script that runs diff between two branches to find differences (called finddiff.pl and in the corelib/build directory).
The error is because now base classes have to tell Sire if they are derived from Property, e.g. they have a typedef ROOT in their base class, e.g.
| typedef Property ROOT; |
is in property.h
For classes with a simple or unknown base class, their registration changes to require NO_ROOT to be added to the constructor of the registration class. This change allows Sire to load objects from s3 files and to automatically work out what they are without having to rely on the user supplying the type. If you see this error again, just add NO_ROOT.
Christopher
--
You received this message because you are subscribed to the Google Groups "Sire Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sire-develope...@googlegroups.com.
To post to this group, send email to sire-de...@googlegroups.com.
julien
Aug 13, 2014, 8:42:09 AM8/13/14
to sire-de...@googlegroups.com
Ah this is becoming a nightmare ;-(
I persevered, fixed a few times NO_ROOT and partial merge problems. Now I have a linking error that puzzles m.
interff and intergroupff cannot find SireBase::BooleanProperty. Yet the cpp files of these two objects contain #include "SireBase/booleanproperty.h"
julien@ubuntu:~/software/devel/sirejulien/buildcorelib$ make
[ 1%] Built target SireError
[ 4%] Built target SireStream
[ 4%] Built target libFoo
[ 4%] Built target libBar
[ 5%] Built target test_template_rtti
[ 6%] Built target test_exception_packing
[ 6%] Built target test_qhash_lookup
[ 7%] Built target SireUnits
[ 8%] Built target SireID
[ 14%] Built target SireBase
[ 22%] Built target SireMaths
[ 24%] Built target SireVol
[ 31%] Built target SireCAS
[ 51%] Built target SireMol
[ 51%] Built target test_stream
[ 51%] Built target test_openmp
[ 56%] Built target SireFF
Scanning dependencies of target SireMM
[ 56%] Building CXX object src/libs/SireMM/CMakeFiles/SireMM.dir/interff.cpp.o
In file included from /home/julien/software/devel/sirejulien/corelib/src/libs/SireMM/interff.h:35:0,
from /home/julien/software/devel/sirejulien/corelib/src/libs/SireMM/interff.cpp:29:
/home/julien/software/devel/sirejulien/corelib/src/libs/SireMM/multicljcomponent.h: In member function ‘double SireMM::MultiCLJEnergy::coulomb(quint32) const’:
/home/julien/software/devel/sirejulien/corelib/src/libs/SireMM/multicljcomponent.h:285:34: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
/home/julien/software/devel/sirejulien/corelib/src/libs/SireMM/multicljcomponent.h: In member function ‘double SireMM::MultiCLJEnergy::lj(quint32) const’:
/home/julien/software/devel/sirejulien/corelib/src/libs/SireMM/multicljcomponent.h:298:35: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
[ 57%] Building CXX object src/libs/SireMM/CMakeFiles/SireMM.dir/intergroupff.cpp.o
In file included from /home/julien/software/devel/sirejulien/corelib/src/libs/SireMM/intergroupff.h:35:0,
from /home/julien/software/devel/sirejulien/corelib/src/libs/SireMM/intergroupff.cpp:29:
/home/julien/software/devel/sirejulien/corelib/src/libs/SireMM/multicljcomponent.h: In member function ‘double SireMM::MultiCLJEnergy::coulomb(quint32) const’:
/home/julien/software/devel/sirejulien/corelib/src/libs/SireMM/multicljcomponent.h:285:34: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
/home/julien/software/devel/sirejulien/corelib/src/libs/SireMM/multicljcomponent.h: In member function ‘double SireMM::MultiCLJEnergy::lj(quint32) const’:
/home/julien/software/devel/sirejulien/corelib/src/libs/SireMM/multicljcomponent.h:298:35: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Linking CXX shared library libSireMM.so
CMakeFiles/SireMM.dir/interff.cpp.o: In function `SireMM::InterFF::setFixedOnly(bool)':
interff.cpp:(.text+0x1706): undefined reference to `SireBase::BooleanProperty::BooleanProperty(bool)'
interff.cpp:(.text+0x1742): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
interff.cpp:(.text+0x1772): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
CMakeFiles/SireMM.dir/interff.cpp.o: In function `SireMM::InterFF::setUseReproducibleCalculation(bool)':
interff.cpp:(.text+0x3f49): undefined reference to `SireBase::BooleanProperty::BooleanProperty(bool)'
interff.cpp:(.text+0x3f85): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
interff.cpp:(.text+0x3f99): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
CMakeFiles/SireMM.dir/interff.cpp.o: In function `SireMM::InterFF::setUseParallelCalculation(bool)':
interff.cpp:(.text+0x4019): undefined reference to `SireBase::BooleanProperty::BooleanProperty(bool)'
interff.cpp:(.text+0x4058): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
interff.cpp:(.text+0x40a4): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
CMakeFiles/SireMM.dir/interff.cpp.o: In function `SireMM::InterFF::setUseGrid(bool)':
interff.cpp:(.text+0x4256): undefined reference to `SireBase::BooleanProperty::BooleanProperty(bool)'
interff.cpp:(.text+0x4296): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
interff.cpp:(.text+0x42f8): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
CMakeFiles/SireMM.dir/interff.cpp.o: In function `SireMM::InterFF::rebuildProps()':
interff.cpp:(.text+0x48ca): undefined reference to `SireBase::BooleanProperty::BooleanProperty(bool)'
interff.cpp:(.text+0x4919): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
interff.cpp:(.text+0x4a40): undefined reference to `SireBase::BooleanProperty::BooleanProperty(bool)'
interff.cpp:(.text+0x4a8f): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
interff.cpp:(.text+0x4aa8): undefined reference to `SireBase::BooleanProperty::BooleanProperty(bool)'
interff.cpp:(.text+0x4af7): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
interff.cpp:(.text+0x4b10): undefined reference to `SireBase::BooleanProperty::BooleanProperty(bool)'
interff.cpp:(.text+0x4b61): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
interff.cpp:(.text+0x4cab): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
interff.cpp:(.text+0x4cd5): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
interff.cpp:(.text+0x4cff): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
interff.cpp:(.text+0x4d7d): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
CMakeFiles/SireMM.dir/interff.cpp.o: In function `SireMM::InterFF::setProperty(QString const&, SireBase::Property const&)':
interff.cpp:(.text+0x567d): undefined reference to `SireBase::BooleanProperty::value() const'
interff.cpp:(.text+0x56f6): undefined reference to `SireBase::BooleanProperty::BooleanProperty(bool)'
interff.cpp:(.text+0x5736): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
interff.cpp:(.text+0x59a5): undefined reference to `SireBase::BooleanProperty::value() const'
interff.cpp:(.text+0x5a5d): undefined reference to `SireBase::BooleanProperty::value() const'
interff.cpp:(.text+0x5ffc): undefined reference to `SireBase::BooleanProperty::value() const'
interff.cpp:(.text+0x6282): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
CMakeFiles/SireMM.dir/interff.cpp.o: In function `SireBase::BooleanProperty const& SireBase::Property::asA<SireBase::BooleanProperty>() const':
interff.cpp:(.text._ZNK8SireBase8Property3asAINS_15BooleanPropertyEEERKT_v[SireBase::BooleanProperty const& SireBase::Property::asA<SireBase::BooleanProperty>() const]+0x23): undefined reference to `typeinfo for SireBase::BooleanProperty'
interff.cpp:(.text._ZNK8SireBase8Property3asAINS_15BooleanPropertyEEERKT_v[SireBase::BooleanProperty const& SireBase::Property::asA<SireBase::BooleanProperty>() const]+0x78): undefined reference to `SireBase::BooleanProperty::typeName()'
interff.cpp:(.text._ZNK8SireBase8Property3asAINS_15BooleanPropertyEEERKT_v[SireBase::BooleanProperty const& SireBase::Property::asA<SireBase::BooleanProperty>() const]+0x94): undefined reference to `SireBase::BooleanProperty::typeName()'
CMakeFiles/SireMM.dir/intergroupff.cpp.o: In function `SireMM::InterGroupFF::setFixedOnly(bool)':
intergroupff.cpp:(.text+0x17e6): undefined reference to `SireBase::BooleanProperty::BooleanProperty(bool)'
intergroupff.cpp:(.text+0x1822): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
intergroupff.cpp:(.text+0x1852): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
CMakeFiles/SireMM.dir/intergroupff.cpp.o: In function `SireMM::InterGroupFF::setUseReproducibleCalculation(bool)':
intergroupff.cpp:(.text+0x3a29): undefined reference to `SireBase::BooleanProperty::BooleanProperty(bool)'
intergroupff.cpp:(.text+0x3a65): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
intergroupff.cpp:(.text+0x3a79): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
CMakeFiles/SireMM.dir/intergroupff.cpp.o: In function `SireMM::InterGroupFF::setUseParallelCalculation(bool)':
intergroupff.cpp:(.text+0x3af9): undefined reference to `SireBase::BooleanProperty::BooleanProperty(bool)'
intergroupff.cpp:(.text+0x3b38): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
intergroupff.cpp:(.text+0x3b84): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
CMakeFiles/SireMM.dir/intergroupff.cpp.o: In function `SireMM::InterGroupFF::setUseGrid(bool)':
intergroupff.cpp:(.text+0x3d36): undefined reference to `SireBase::BooleanProperty::BooleanProperty(bool)'
intergroupff.cpp:(.text+0x3d76): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
intergroupff.cpp:(.text+0x3dd8): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
CMakeFiles/SireMM.dir/intergroupff.cpp.o: In function `SireMM::InterGroupFF::rebuildProps()':
intergroupff.cpp:(.text+0x43aa): undefined reference to `SireBase::BooleanProperty::BooleanProperty(bool)'
intergroupff.cpp:(.text+0x43f9): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
intergroupff.cpp:(.text+0x4520): undefined reference to `SireBase::BooleanProperty::BooleanProperty(bool)'
intergroupff.cpp:(.text+0x456f): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
intergroupff.cpp:(.text+0x4588): undefined reference to `SireBase::BooleanProperty::BooleanProperty(bool)'
intergroupff.cpp:(.text+0x45d7): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
intergroupff.cpp:(.text+0x45f0): undefined reference to `SireBase::BooleanProperty::BooleanProperty(bool)'
intergroupff.cpp:(.text+0x4641): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
intergroupff.cpp:(.text+0x478b): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
intergroupff.cpp:(.text+0x47b5): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
intergroupff.cpp:(.text+0x47df): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
intergroupff.cpp:(.text+0x485d): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
CMakeFiles/SireMM.dir/intergroupff.cpp.o: In function `SireMM::InterGroupFF::setProperty(QString const&, SireBase::Property const&)':
intergroupff.cpp:(.text+0x52cd): undefined reference to `SireBase::BooleanProperty::value() const'
intergroupff.cpp:(.text+0x5346): undefined reference to `SireBase::BooleanProperty::BooleanProperty(bool)'
intergroupff.cpp:(.text+0x5386): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
intergroupff.cpp:(.text+0x55f5): undefined reference to `SireBase::BooleanProperty::value() const'
intergroupff.cpp:(.text+0x56ad): undefined reference to `SireBase::BooleanProperty::value() const'
intergroupff.cpp:(.text+0x5c4c): undefined reference to `SireBase::BooleanProperty::value() const'
intergroupff.cpp:(.text+0x5ed2): undefined reference to `SireBase::BooleanProperty::~BooleanProperty()'
collect2: ld returned 1 exit status
make[2]: *** [src/libs/SireMM/libSireMM.so.0.0.1] Error 1
make[1]: *** [src/libs/SireMM/CMakeFiles/SireMM.dir/all] Error 2
Christopher Woods
Aug 13, 2014, 9:08:41 AM8/13/14
to Sire Developers
Hi Julien,
Have you checked that SireBase is listed as one of the target link
libraries in src/libs/SireMM/CMakeLists.txt, e.g.
target_link_libraries (SireMM
SireFF
SireMol
SireCAS
SireBase
SireMaths
SireUnits
SireStream
${TBB_LIBRARY}
${TBB_MALLOC_LIBRARY}
)
Also, make sure that SIREBASE_EXPORT is included in the class
definition of BooleanProperty, in booleanproperty.h, e.g.
class SIREBASE_EXPORT BooleanProperty
and also that the CMakeLists.txt in src/libs/SireBase contains
booleanproperty.cpp and booleanproperty.h (sometimes the merge will
add the file but won't add it into CMakeLists.txt)
Cheers,
Christopher
Have you checked that SireBase is listed as one of the target link
libraries in src/libs/SireMM/CMakeLists.txt, e.g.
target_link_libraries (SireMM
SireFF
SireMol
SireCAS
SireBase
SireMaths
SireUnits
SireStream
${TBB_LIBRARY}
${TBB_MALLOC_LIBRARY}
)
Also, make sure that SIREBASE_EXPORT is included in the class
definition of BooleanProperty, in booleanproperty.h, e.g.
class SIREBASE_EXPORT BooleanProperty
and also that the CMakeLists.txt in src/libs/SireBase contains
booleanproperty.cpp and booleanproperty.h (sometimes the merge will
add the file but won't add it into CMakeLists.txt)
Cheers,
Christopher
> --
> You received this message because you are subscribed to the Google Groups
> "Sire Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sire-develope...@googlegroups.com.
> To post to this group, send email to sire-de...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sire-developers.
> For more options, visit https://groups.google.com/d/optout.
> You received this message because you are subscribed to the Google Groups
> "Sire Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sire-develope...@googlegroups.com.
> To post to this group, send email to sire-de...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sire-developers.
> For more options, visit https://groups.google.com/d/optout.
Christopher Woods
Aug 13, 2014, 9:11:50 AM8/13/14
to Sire Developers
p.s. InterFF and InterGroupFF are the two things that I am working on
at the moment. They are the drop-in replacements for InterCLJFF,
InterGroupCLJFF, InterSoftCLJFF and InterGroupSoftCLJFF that are much
faster, easier to work with and easier to understand for new
developers. They will also make it easier to write new cutoff code or
to write new soft-core or other weird non-bonded functions. All of the
classes that start with "CLJ???" are part of this new scheme, e.g.
CLJFunction, CLJWorkspace, CLJGroup etc. If you get any compile errors
for these make sure that you are merging to a version of devel where I
have explicitly said that the code compiles, links runs and passes
unit tests.
at the moment. They are the drop-in replacements for InterCLJFF,
InterGroupCLJFF, InterSoftCLJFF and InterGroupSoftCLJFF that are much
faster, easier to work with and easier to understand for new
developers. They will also make it easier to write new cutoff code or
to write new soft-core or other weird non-bonded functions. All of the
classes that start with "CLJ???" are part of this new scheme, e.g.
CLJFunction, CLJWorkspace, CLJGroup etc. If you get any compile errors
for these make sure that you are merging to a version of devel where I
have explicitly said that the code compiles, links runs and passes
unit tests.
julien
Aug 13, 2014, 9:24:14 AM8/13/14
to sire-de...@googlegroups.com
Hi Chris,
and also that the CMakeLists.txt in src/libs/SireBase contains
booleanproperty.cpp and booleanproperty.h (sometimes the merge will
add the file but won't add it into CMakeLists.txt)
Thanks Chris, that's exactly what was going on. I can now compile corelib (including interff and intergroupff). Hurray...Alas my faith in svn merge has been shattered.
Now let's see how well I fare with the python wrappers :-)
Cheers,
Julien
Christopher Woods
Aug 13, 2014, 10:39:40 AM8/13/14
to Sire Developers
Hi Julien,
Good luck :-). It may be easiest to just merge in
AutoGenerate/scanheaders.py and AutoGenerate/create_wrappers.py and
use these to regenerate the wrappers from scratch. svn merge is pretty
poor (it is as good as it can be...) but it will likely fail
spectacularly for the wrappers. I always regenerate myself, partly
also because I don't trust svn merge to not break the wrapper
generation...
Cheers,
Christopher
Good luck :-). It may be easiest to just merge in
AutoGenerate/scanheaders.py and AutoGenerate/create_wrappers.py and
use these to regenerate the wrappers from scratch. svn merge is pretty
poor (it is as good as it can be...) but it will likely fail
spectacularly for the wrappers. I always regenerate myself, partly
also because I don't trust svn merge to not break the wrapper
generation...
Cheers,
Christopher
julien
Aug 14, 2014, 6:46:12 AM8/14/14
to sire-de...@googlegroups.com
Hi Chris,
Good news, I was able to compile all the wrappers. I had to merge updated versions of special_code.py in several places but at least the compilations completes without error.
However...some of the wrappers are incomplete. For instance if I try to run somd-freenrg I get this error message
### Running Single Topology Molecular Dynamics Free Energy on unknown ###
New run. Loading input and creating restart
lambda is 0.0
Reading topology file "SYSTEM.top"
Reading coordinate file "SYSTEM.crd"
Building 1 molecule(s)...
Getting space information
Read space "Infinite cartesian space"
...complete
Create the System...
Selecting dummy groups
Creating force fields...
Setting up the simulation with random seed 546515
Setting up moves...
Traceback (most recent call last):
File "/home/julien/sire.app/share/Sire/scripts/somd-freenrg.py", line 140, in <module>
OpenMMMD.runFreeNrg(params)
File "/home/julien/sire.app/bundled/lib/python3.3/site-packages/Sire/Tools/__init__.py", line 135, in inner
retval = func()
File "/home/julien/sire.app/bundled/lib/python3.3/site-packages/Sire/Tools/OpenMMMD.py", line 1150, in runFreeNrg
moves = setupMovesFreeEnergy(system, ranseed, gpu.val, lambda_val.val)
File "/home/julien/sire.app/bundled/lib/python3.3/site-packages/Sire/Tools/OpenMMMD.py", line 911, in setupMovesFreeEnergy
Integrator_OpenMM = OpenMMFrEnergyST(molecules,solute,solute_hard,solute_todummy,solute_fromdummy)
Boost.Python.ArgumentError: Python argument types in
OpenMMFrEnergyST.__init__(OpenMMFrEnergyST, MoleculeGroup, MoleculeGroup, MoleculeGroup, MoleculeGroup, MoleculeGroup)
did not match C++ signature:
__init__(_object*)
I looked up the contents of python/Move/OpenMMFrEnergySt.pypp.cpp and it is strangely short, see below
julien@ubuntu:~/software/devel/sirejulien/python2/Move$ grep '//' OpenMMFrEnergyST.pypp.cpp
// This file has been generated by Py++.
// (C) Christopher Woods, GPL >= 2 License
{ //::SireMove::OpenMMFrEnergyST
{ //::SireMove::OpenMMFrEnergyST::typeName
Whereas the wrappers from Gaetano's branch include several other methods
julien@ubuntu:~/software/devel/siregac/python/Move$ grep '//' OpenMMFrEnergyST.pypp.cpp
{ //::SireMove::OpenMMFrEnergyST
{ //::SireMove::OpenMMFrEnergyST::createWorkspace
{ //::SireMove::OpenMMFrEnergyST::createWorkspace
{ //::SireMove::OpenMMFrEnergyST::ensemble
{ //::SireMove::OpenMMFrEnergyST::getAlchemical_value
{ //::SireMove::OpenMMFrEnergyST::getAndersen
{ //::SireMove::OpenMMFrEnergyST::getAndersen_frequency
{ //::SireMove::OpenMMFrEnergyST::getBufferFrequency
{ //::SireMove::OpenMMFrEnergyST::getCMMremoval_frequency
{ //::SireMove::OpenMMFrEnergyST::getConstraintType
{ //::SireMove::OpenMMFrEnergyST::getCoulomb_power
{ //::SireMove::OpenMMFrEnergyST::getCutoffType
{ //::SireMove::OpenMMFrEnergyST::getCutoff_distance
{ //::SireMove::OpenMMFrEnergyST::getDeltaAlchemical
{ //::SireMove::OpenMMFrEnergyST::getDeviceIndex
{ //::SireMove::OpenMMFrEnergyST::getEnergies
{ //::SireMove::OpenMMFrEnergyST::getEnergyFrequency
{ //::SireMove::OpenMMFrEnergyST::getEquilib_iterations
{ //::SireMove::OpenMMFrEnergyST::getEquilib_time_step
{ //::SireMove::OpenMMFrEnergyST::getField_dielectric
{ //::SireMove::OpenMMFrEnergyST::getFriction
{ //::SireMove::OpenMMFrEnergyST::getGradients
{ //::SireMove::OpenMMFrEnergyST::getIntegration_tollerance
{ //::SireMove::OpenMMFrEnergyST::getIntegrator
{ //::SireMove::OpenMMFrEnergyST::getMCBarostat
{ //::SireMove::OpenMMFrEnergyST::getMCBarostat_frequency
{ //::SireMove::OpenMMFrEnergyST::getMinimizeIterations
{ //::SireMove::OpenMMFrEnergyST::getMinimizeTol
{ //::SireMove::OpenMMFrEnergyST::getPlatform
{ //::SireMove::OpenMMFrEnergyST::getPotentialEnergy
{ //::SireMove::OpenMMFrEnergyST::getPrecision
{ //::SireMove::OpenMMFrEnergyST::getPressure
{ //::SireMove::OpenMMFrEnergyST::getRestraint
{ //::SireMove::OpenMMFrEnergyST::getShift_delta
{ //::SireMove::OpenMMFrEnergyST::getTemperature
{ //::SireMove::OpenMMFrEnergyST::getTimetoSkip
{ //::SireMove::OpenMMFrEnergyST::initialise
{ //::SireMove::OpenMMFrEnergyST::integrate
{ //::SireMove::OpenMMFrEnergyST::isTimeReversible
{ //::SireMove::OpenMMFrEnergyST::operator=
{ //::SireMove::OpenMMFrEnergyST::setAlchemical_value
{ //::SireMove::OpenMMFrEnergyST::setAndersen
{ //::SireMove::OpenMMFrEnergyST::setAndersen_frequency
{ //::SireMove::OpenMMFrEnergyST::setBufferFrequency
{ //::SireMove::OpenMMFrEnergyST::setCMMremoval_frequency
{ //::SireMove::OpenMMFrEnergyST::setConstraintType
{ //::SireMove::OpenMMFrEnergyST::setCoulomb_power
{ //::SireMove::OpenMMFrEnergyST::setCutoffType
{ //::SireMove::OpenMMFrEnergyST::setCutoff_distance
{ //::SireMove::OpenMMFrEnergyST::setDeltatAlchemical
{ //::SireMove::OpenMMFrEnergyST::setDeviceIndex
{ //::SireMove::OpenMMFrEnergyST::setEnergyFrequency
{ //::SireMove::OpenMMFrEnergyST::setEquilib_iterations
{ //::SireMove::OpenMMFrEnergyST::setEquilib_time_step
{ //::SireMove::OpenMMFrEnergyST::setField_dielectric
{ //::SireMove::OpenMMFrEnergyST::setFriction
{ //::SireMove::OpenMMFrEnergyST::setIntegration_tollerance
{ //::SireMove::OpenMMFrEnergyST::setIntegrator
{ //::SireMove::OpenMMFrEnergyST::setMCBarostat
{ //::SireMove::OpenMMFrEnergyST::setMCBarostat_frequency
{ //::SireMove::OpenMMFrEnergyST::setMinimization
{ //::SireMove::OpenMMFrEnergyST::setMinimizeIterations
{ //::SireMove::OpenMMFrEnergyST::setMinimizeTol
{ //::SireMove::OpenMMFrEnergyST::setPlatform
{ //::SireMove::OpenMMFrEnergyST::setPrecision
{ //::SireMove::OpenMMFrEnergyST::setPressure
{ //::SireMove::OpenMMFrEnergyST::setReinitializeContext
{ //::SireMove::OpenMMFrEnergyST::setRestraint
{ //::SireMove::OpenMMFrEnergyST::setShift_delta
{ //::SireMove::OpenMMFrEnergyST::setTemperature
{ //::SireMove::OpenMMFrEnergyST::setTimetoSkip
{ //::SireMove::OpenMMFrEnergyST::toString
{ //::SireMove::OpenMMFrEnergyST::typeName
The same is true for other OpenMM objects. But not for other objects in Move/
Most likely the code is not scanning the OpenMM headers correctly.
I'm pretty sure the source code is correct, e.g.
julien@ubuntu:~/software/devel/sirejulien/corelib/src/libs/SireMove$ diff openmmmdintegrator.h ~/software/devel/siregac/corelib/src/libs/SireMove/openmmmdintegrator.h
--> no difference
julien@ubuntu:~/software/devel/sirejulien/corelib/src/libs/SireMove$ diff CMakeLists.txt ~/software/devel/siregac/corelib/src/libs/SireMove/CMakeLists.txt
--> no difference
julien@ubuntu:~/software/devel/sirejulien/python2$ diff CMakeLists.txt ~/software/devel/siregac/python/CMakeLists.txt
julien@ubuntu:~/software/devel/sirejulien/python2$ diff create_all_wrappers.py ~/software/devel/siregac/python/create_all_wrappers.py
julien@ubuntu:~/software/devel/sirejulien/python2$ diff AutoGenerate/scanheaders.py ~/software/devel/siregac/python/AutoGenerate/scanheaders.py
julien@ubuntu:~/software/devel/sirejulien/python2$ diff AutoGenerate/create_wrappers.py ~/software/devel/siregac/python/AutoGenerate/create_wrappers.py
--> no differences
So next I regenerated the python wrappers in a local copy of Gaetano's branch. And sure enough the OpenMM wrappers are updated, and no longer include any of the methods contained in the object. You can check yourself in the google code repositories, comparing the branches julien and nividic if you wish.
I must have something set incorrectly in my build environment, but I don't know what? I am using ScientificLinux 5.10.
Best wishes,
Julien
Christopher Woods
Aug 14, 2014, 7:20:52 AM8/14/14
to Sire Developers
Hi Julien,
Excellent news that corelib and the wrappers have compiled. You are
very nearly there ;-)
The problem is that the AutoGenerate/create_wrappers.py script in the
devel branch does not include the code necessary to scan for the
OpenMM headers. You need to copy the AutoGenerate/create_wrappers.py
script from Gaetano's branch and use that. This contains an 'if' block
that switches between generating wrappers with OpenMM and without
OpenMM (in case OpenMM is not installed). e.g.
if openmm_include_dirs is None:
#construct a module builder that will build all of the
wrappers for this module
mb = module_builder_t( files = [ "active_headers.h" ],
cflags = "-m64",
include_paths = sire_include_dirs + qt_include_dirs +
boost_include_dirs +
gsl_include_dirs,
define_symbols = ["GCCXML_PARSE",
"SIRE_SKIP_INLINE_FUNCTIONS",
"SIREN_SKIP_INLINE_FUNCTIONS",
"SIRE_INSTANTIATE_TEMPLATES",
"SIREN_INSTANTIATE_TEMPLATES"] )
else:
#construct a module builder that will build all of the
wrappers for this module
mb = module_builder_t( files = [ "active_headers.h" ],
cflags = "-m64",
include_paths = sire_include_dirs + qt_include_dirs +
boost_include_dirs +
gsl_include_dirs +
openmm_include_dirs,
define_symbols = ["GCCXML_PARSE",
"SIRE_USE_OPENMM",
"SIRE_SKIP_INLINE_FUNCTIONS",
"SIREN_SKIP_INLINE_FUNCTIONS",
"SIRE_INSTANTIATE_TEMPLATES",
"SIREN_INSTANTIATE_TEMPLATES"] )
The key here is that, if OpenMM is found, then it adds the path to the
include files and sets the definition "SIRE_USE_OPENMM". This allows
Py++ to see the OpenMM capable code. If SIRE_USE_OPENMM is not defined
then Py++ sees only stubbed code that contains just a constructor
(hence why the generated wrappers are very small and don't work). This
is why the OpenMM-specific code in corelib is hidden behind an "#ifdef
SIRE_USE_OPENMM #else #endif block.
You will also find this in the CMakeLists.txt in python/Move.
Gaetano's branch has modified CMakeLists.txt files that test if OpenMM
has been found, and if so, sets the definition SIRE_USE_OPENMM. This
is at the top of the file, e.g.
if (${SIRE_OpenMM_FOUND})
include_directories( ${SIRE_OpenMM_INCLUDE_DIR} )
add_definitions( "-DSIRE_USE_OPENMM" )
set( SIRE_OPENMM_LIBRARIES ${SIRE_OpenMM_LIBRARIES} )
set( SIRE_OPENMM_WRAPPERS
OpenMMIntegrator.pypp.cpp
)
else()
set( SIRE_OPENMM_LIBRARIES "" )
endif()
You can see here that we even skip compiling the
OpenMMIntergrator.pypp.cpp file if OpenMM has not been found.
I hope this helps,
Cheers,
Christopher
Excellent news that corelib and the wrappers have compiled. You are
very nearly there ;-)
The problem is that the AutoGenerate/create_wrappers.py script in the
devel branch does not include the code necessary to scan for the
OpenMM headers. You need to copy the AutoGenerate/create_wrappers.py
script from Gaetano's branch and use that. This contains an 'if' block
that switches between generating wrappers with OpenMM and without
OpenMM (in case OpenMM is not installed). e.g.
if openmm_include_dirs is None:
#construct a module builder that will build all of the
wrappers for this module
mb = module_builder_t( files = [ "active_headers.h" ],
cflags = "-m64",
include_paths = sire_include_dirs + qt_include_dirs +
boost_include_dirs +
gsl_include_dirs,
define_symbols = ["GCCXML_PARSE",
"SIRE_SKIP_INLINE_FUNCTIONS",
"SIREN_SKIP_INLINE_FUNCTIONS",
"SIRE_INSTANTIATE_TEMPLATES",
"SIREN_INSTANTIATE_TEMPLATES"] )
else:
#construct a module builder that will build all of the
wrappers for this module
mb = module_builder_t( files = [ "active_headers.h" ],
cflags = "-m64",
include_paths = sire_include_dirs + qt_include_dirs +
boost_include_dirs +
gsl_include_dirs +
openmm_include_dirs,
define_symbols = ["GCCXML_PARSE",
"SIRE_USE_OPENMM",
"SIRE_SKIP_INLINE_FUNCTIONS",
"SIREN_SKIP_INLINE_FUNCTIONS",
"SIRE_INSTANTIATE_TEMPLATES",
"SIREN_INSTANTIATE_TEMPLATES"] )
The key here is that, if OpenMM is found, then it adds the path to the
include files and sets the definition "SIRE_USE_OPENMM". This allows
Py++ to see the OpenMM capable code. If SIRE_USE_OPENMM is not defined
then Py++ sees only stubbed code that contains just a constructor
(hence why the generated wrappers are very small and don't work). This
is why the OpenMM-specific code in corelib is hidden behind an "#ifdef
SIRE_USE_OPENMM #else #endif block.
You will also find this in the CMakeLists.txt in python/Move.
Gaetano's branch has modified CMakeLists.txt files that test if OpenMM
has been found, and if so, sets the definition SIRE_USE_OPENMM. This
is at the top of the file, e.g.
if (${SIRE_OpenMM_FOUND})
include_directories( ${SIRE_OpenMM_INCLUDE_DIR} )
add_definitions( "-DSIRE_USE_OPENMM" )
set( SIRE_OPENMM_LIBRARIES ${SIRE_OpenMM_LIBRARIES} )
set( SIRE_OPENMM_WRAPPERS
OpenMMIntegrator.pypp.cpp
)
else()
set( SIRE_OPENMM_LIBRARIES "" )
endif()
You can see here that we even skip compiling the
OpenMMIntergrator.pypp.cpp file if OpenMM has not been found.
I hope this helps,
Cheers,
Christopher
julien
Aug 14, 2014, 7:59:49 AM8/14/14
to sire-de...@googlegroups.com
Hi Chris,
somd-freenrg is running. So I'm back to where I was last week, but this time I have analyse_freenrg. And I understand a bit better how the wrappers generation works.
Ok got it. I couldn't understand at first because create_wrappers.py and Move/CMakeLists.txt
are identical to those in Gaetano's branch. The problem was that openmm_include_dirs is set with os.getenv(OPENMMDIR). However I hadn't set this environment variable in shell. Maybe in the future we can find a way to have the code detect OPENMMDIR automatically.
somd-freenrg is running. So I'm back to where I was last week, but this time I have analyse_freenrg. And I understand a bit better how the wrappers generation works.
Will keep you posted about the progress...
Best wishes,
Julien
> email to sire-developers+unsubscribe@googlegroups.com.
> To post to this group, send email to sire-developers@googlegroups.com.
julien
Aug 19, 2014, 10:16:53 AM8/19/14
to sire-de...@googlegroups.com
Hi Chris,
Progressing whenever I get a chance !
So I have modified somd so that a gradients.s3 file is written by each process.
The relevant code in OpenMMMD.py is
(...)
grads = {}
grads[lambda_val.val] = AverageAndStddev()
for i in range(cycle_start,cycle_end):
print("\nCycle = ",i,"\n")
#print("Energy before = %s kJ mol-1" % (system.energy().to(kJ_per_mol)))
# import ipdb; ipdb.set_trace()
system = moves.move(system, nmoves.val, True)
#print("Energy after = %s kJ mol-1" % (system.energy().to(kJ_per_mol)))
if (save_coords.val):
writeSystemData(system, moves, trajectory, i)
mdmoves = moves.moves()[0]
integrator = mdmoves.integrator()
gradients = integrator.getGradients()
outgradients.write("%5d %20.10f\n" % (i, gradients[i-1]))
grads[lambda_val.val].accumulate( gradients[i-1] )
s2 = timer.elapsed()/1000.
print("Simulation took %d s " % ( s2 - s1))
if os.path.exists("gradients.s3"):
siregrads = Sire.Stream.load("gradients.s3")
else:
siregrads = Gradients()
siregrads = siregrads + Gradients(grads)
Sire.Stream.save(siregrads, "gradients.s3")
I now have a set of gradients.s3 files stored in different folders
julien@ubuntu:~/sims/stefano/reproducibility/e2m/simulation/ethane~methanol/run001/vacuum$ ll lambda-*/gradients.s3
-rw-rw-r-- 1 501 dialout 973 Aug 19 11:24 lambda-0.0000/gradients.s3
-rw-rw-r-- 1 501 dialout 986 Aug 19 11:27 lambda-0.1000/gradients.s3
-rw-rw-r-- 1 501 dialout 981 Aug 19 11:27 lambda-0.2000/gradients.s3
-rw-rw-r-- 1 501 dialout 982 Aug 19 11:28 lambda-0.3000/gradients.s3
-rw-rw-r-- 1 501 dialout 984 Aug 19 15:03 lambda-1.000/gradients.s3
Next I modified python2/python/scripts/analyse_freenrg.py
# Changed nargs to '*' for --input
(...)
parser.add_argument('-i', '--input', nargs='*',
help="Supply the name of the Sire Streamed Save (.s3) file(s) containing the "
"free energies to be analysed.")
(...)
# Because now may have multiple arguments in args.input
if args.input:
input_file = args.input
else:
input_file = None
# Commented out since input_file is now a list of input_files
#elif not os.path.exists(input_file):
# parser.print_help()
# print("\nPlease supply the name of the .s3 file containing the free energies to be analysed.")
# print("(cannot find file %s)" % input_file)
# sys.exit(-1)
#input_file = os.path.realpath(input_file)
FILE.write("Analysing free energies contained in file(s) \"%s\"\n" % input_file)
num_inputfiles = len(input_file)
if num_inputfiles == 1:
# Only one input file provided, assumes it contains freenrgs
freenrgs = Sire.Stream.load(input_file)
else:
# Multiple input files provided. Assume we have several gradients files that must be combined
grads = {}
fwds_grads = {}
bwds_grads = {}
delta_lambda = None
for i in range(0,num_inputfiles):
grad = Sire.Stream.load(input_file[i])
#print(grad)
analytic_data = grad.analyticData()
fwds_data = grad.forwardsData()
bwds_data = grad.backwardsData()
#print(analytic_data)
#print(fwds_data)
#print(bwds_data)
if len(analytic_data) > 0:
# analytic gradients
#print(analytic_data.keys())
lamval = list(analytic_data.keys())[0]
grads[ lamval ] = analytic_data[lamval]
else:
# finite difference gradients
lamval = list(fwds_data.keys())[0]
fwds_grads[lamval] = fwds_data[lamval]
bwds_grads[lamval] = bwds_data[lamval]
delta_lambda = grad.deltaLambda()
ti = None
if len(grads) > 0 :
ti = TI( Gradients(grads) )
else:
ti = TI( Gradients(fwds_grads,bwds_grads,delta_lambda) )
freenrgs = ti
If I try to analyse the input I get this error message
julien@ubuntu:~/sims/stefano/reproducibility/e2m/simulation/ethane~methanol/run001/vacuum$ ~/sire.app/bin/analyse_freenrg -i lambda-*/gradients.s3
"/home/julien/sire.app/share/Sire/scripts/analyse_freenrg.py"
Starting /home/julien/sire.app/bin/analyse_freenrg: number of threads equals 1
Writing all output to stdout
Analysing free energies contained in file(s) "['lambda-0.0000/gradients.s3', 'lambda-0.1000/gradients.s3', 'lambda-0.2000/gradients.s3', 'lambda-0.3000/gradients.s3', 'lambda-1.000/gradients.s3']"
Traceback (most recent call last):
File "/home/julien/sire.app/share/Sire/scripts/analyse_freenrg.py", line 236, in <module>
results.append( processFreeEnergies(freenrgs, FILE) )
File "/home/julien/sire.app/share/Sire/scripts/analyse_freenrg.py", line 187, in processFreeEnergies
nrgs.merge(0,1)
StopIteration: Exception 'SireError::invalid_index' thrown by the thread 'master:main'.
Cannot access item at index 1 as there is only item in the container.
Thrown from FILE: /home/julien/software/devel/sirejulien/corelib/src/libs/SireID/index.cpp, LINE: 113, FUNCTION: void SireID::IndexBase::throwInvalidIndex(qint32) const
__Backtrace__
( 0) /home/julien/sire.app/bin/../lib/libSireError.so.0 ([0x7f825381658c] ++0x2c)
-- SireError::getBackTrace()
( 1) /home/julien/sire.app/bin/../lib/libSireError.so.0 ([0x7f825381368e] ++0x9e)
-- SireError::exception::exception(QString, QString)
( 2) /home/julien/sire.app/bin/../lib/./libSireID.so.0 ([0x7f8250c43794] ++0xa44)
-- SireID::IndexBase::throwInvalidIndex(int) const
( 3) /home/julien/sire.app/bin/../lib/./libSireID.so.0 ([0x7f8250c43ed3] ++0x13)
-- SireID::IndexBase::map(int) const
( 4) /home/julien/sire.app/bin/../lib/libSireAnalysis.so.0 ([0x7f824d35d617] ++0x77)
-- SireAnalysis::TI::merge(int, int) const
/home/julien/sire.app/bundled/lib/python3.3/site-packages/Sire/Analysis/_Analysis.so(+0x3b1c0) [0x7f824d5c71c0]
( 6) /home/julien/sire.app/bin/../bundled/lib/libboost_python.so ([0x7f824ef09e15] ++0x1b5)
-- boost::python::objects::function::call(_object*, _object*) const
/home/julien/sire.app/bin/../bundled/lib/libboost_python.so(+0x29048) [0x7f824ef0a048]
( 8) /home/julien/sire.app/bin/../bundled/lib/libboost_python.so ([0x7f824ef12953] ++0x43)
-- boost::python::detail::exception_handler::operator()(boost::function0<void> const&) const
/home/julien/sire.app/bundled/lib/python3.3/site-packages/Sire/Error/_Error.so(+0x2491) [0x7f824ecde491]
( 10) /home/julien/sire.app/bin/../bundled/lib/libboost_python.so ([0x7f824ef12936] ++0x26)
-- boost::python::detail::exception_handler::operator()(boost::function0<void> const&) const
/home/julien/sire.app/bundled/lib/python3.3/site-packages/Sire/Error/_Error.so(+0x244f) [0x7f824ecde44f]
( 12) /home/julien/sire.app/bin/../bundled/lib/libboost_python.so ([0x7f824ef12739] ++0x29)
-- boost::python::handle_exception_impl(boost::function0<void>)
/home/julien/sire.app/bin/../bundled/lib/libboost_python.so(+0x27544) [0x7f824ef08544]
( 14) /home/julien/sire.app/bin/../bundled/lib/libpython3.3m.so.1.0 ([0x7f82533d198e] ++0x7e)
-- PyObject_Call
( 15) /home/julien/sire.app/bin/../bundled/lib/libpython3.3m.so.1.0 ([0x7f8253494048] ++0x5878)
-- PyEval_EvalFrameEx
( 16) /home/julien/sire.app/bin/../bundled/lib/libpython3.3m.so.1.0 ([0x7f8253495f8e] ++0x77be)
-- PyEval_EvalFrameEx
( 17) /home/julien/sire.app/bin/../bundled/lib/libpython3.3m.so.1.0 ([0x7f8253496c3c] ++0x8ac)
-- PyEval_EvalCodeEx
( 18) /home/julien/sire.app/bin/../bundled/lib/libpython3.3m.so.1.0 ([0x7f8253496d0b] ++0x3b)
-- PyEval_EvalCode
( 19) /home/julien/sire.app/bin/../bundled/lib/libpython3.3m.so.1.0 ([0x7f82534ba37d] ++0xbd)
-- PyRun_FileExFlags
( 20) /home/julien/sire.app/bin/../bundled/lib/libpython3.3m.so.1.0 ([0x7f82534bafe9] ++0x119)
-- PyRun_SimpleFileExFlags
( 21) /home/julien/sire.app/bin/../bundled/lib/libpython3.3m.so.1.0 ([0x7f82534d1fe9] ++0xb89)
-- Py_Main
/home/julien/sire.app/bin/analyse_freenrg() [0x40374c]
( 23) /lib/x86_64-linux-gnu/libc.so.6 ([0x7f8251c7776d] ++0xed)
-- __libc_start_main
/home/julien/sire.app/bin/analyse_freenrg() [0x4045fd]
__EndTrace__
Exception 'SireError::invalid_index' thrown by the thread 'master:main'.
Cannot access item at index 1 as there is only item in the container.
Thrown from FILE: /home/julien/software/devel/sirejulien/corelib/src/libs/SireID/index.cpp, LINE: 113, FUNCTION: void SireID::IndexBase::throwInvalidIndex(qint32) const
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/julien/sire.app/share/Sire/scripts/analyse_freenrg.py", line 239, in <module>
results.append( processFreeEnergies(freenrg, FILE) )
File "/home/julien/sire.app/share/Sire/scripts/analyse_freenrg.py", line 187, in processFreeEnergies
nrgs.merge(0,1)
Boost.Python.ArgumentError: Python argument types in
Gradients.merge(int, int)
did not match C++ signature:
merge(QList<SireAnalysis::Gradients> gradients)
I must have misunderstood how to construct freenrgs? I am trying to figure out what is incorrect...Each gradients file contains 6 gradients.
Best wishes,
Julien
Christopher Woods
Aug 19, 2014, 11:43:25 AM8/19/14
to Sire Developers
Hi Julien,
I've been taking a look at your question around various distractions
and am not sure what is going wrong. Could you email a tgz of the
lambda-*/gradients.s3 files and I will try to reproduce the error on
my machine. Looking at your script, you are almost there ;-)
Thanks,
Christopher
> To post to this group, send email to sire-de...@googlegroups.com.
I've been taking a look at your question around various distractions
and am not sure what is going wrong. Could you email a tgz of the
lambda-*/gradients.s3 files and I will try to reproduce the error on
my machine. Looking at your script, you are almost there ;-)
Thanks,
Christopher
> --
> You received this message because you are subscribed to the Google Groups
> "Sire Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sire-develope...@googlegroups.com.
> You received this message because you are subscribed to the Google Groups
> "Sire Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> To post to this group, send email to sire-de...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages