[Open Babel] Anyone using the parallel implementation of MMFF94 forcefield (via OpenMP)

[ovalerio]

Hi list,

In the ChangeLog I found Tim wrote about the GCC compilation options to
be used in order to enable MMFF94 parallelization. His entry reads as
follows.

2008-04-28 Tim Vandermeersch <***@gmail.com>

* src/forcefields/forcefieldmmff94.cpp: OpenMP version of MMFF94. Does
not affect normal compilation. Only used with GCC options "-lgomp
-fopenmp".

This is from the time before OpenBabel moved to CMake. I look at the
CMakeLists.txt and there is no OpenMP flags there (-fopenmp, -lgomp).
Which is the preferred way to do it. Should I create a custom
CMakeLists.txt or should I opt for the custom static binary approach as
suggested in the project Wiki. http://openbabel.org/wiki/CMake

Thanks & regards,
--
Omar V.M.
***@ichec.ie

[Geoff Hutchison]

Post by ovalerio
This is from the time before OpenBabel moved to CMake. I look at the
CMakeLists.txt and there is no OpenMP flags there (-fopenmp, -lgomp).
Which is the preferred way to do it.

Either edit you CMakeCache.txt (e.g., "ccmake .") after setting up the cmake build directory, or declare these as CXX_FLAGS, e.g.,

CXXFLAGS="-fopenmp -lgomp" cmake /path/to/source/dir

Hope that helps,
-Geoff

[ovalerio]

Hi Geoff,

Thanks. I'm aiming to use OpenBabel as a platform to learn about
parallelization using GPU and multicore CPU. I want also to contribute
the code I develop to the OpenBabel project. Following Noel suggestion I
am first looking at the forcefields used in energy calculation and in
particular MMFF94.

I followed your advise. After editing the CMakeCache.txt and adding the
compiler flags OpenMP is working for me. However, I would like to avoid
this additional step by adding some conditional compilation lines to the
CMakeLists.txt

#Find if OpenMP support is enable
find_package(OpenMP)
if(OPENMP_FOUND)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${OpenMP_C_FLAGS}")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS}")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS}
${OpenMP_EXE_LINKER_FLAGS}")
endif()

I tried this lines with a fresh development version of OpenBabel and it
seems to be working. I tried both having a setup with GOMP libraries
installed and one without. I also run the ctest for MMFF94 just to be
sure everything was working.

***@gpu0:/hpcws/obeclipse$ export OMP_NUM_THREADS = 1
bash: export: `=': not a valid identifier
bash: export: `1': not a valid identifier
***@gpu0:/hpcws/obeclipse$ export OMP_NUM_THREADS=1
***@gpu0:/hpcws/obeclipse$ ctest -I 36,36
Test project /hpcws/obeclipse
Start 36: ffmmff94_Test
1/1 Test #36: ffmmff94_Test .................... Passed 2.37 sec

100% tests passed, 0 tests failed out of 1

Total Test time (real) = 2.39 sec
***@gpu0:/hpcws/obeclipse$ export OMP_NUM_THREADS=4
***@gpu0:/hpcws/obeclipse$ ctest -I 36,36
Test project /hpcws/obeclipse
Start 36: ffmmff94_Test
1/1 Test #36: ffmmff94_Test .................... Passed 1.41 sec

100% tests passed, 0 tests failed out of 1

Total Test time (real) = 1.43 sec


There is something else I want to ask/understand. While running the
obminimize command for the forcefield.sdf validation set (the same one
used by Open Babel automated test) I realized each time the command is
run two instances of OBForceFieldMMFF94 are being created. I would like
to understand why is that, because I thought only one was necessary and
therefore I am confused about this.

That's it for today. Thanks again for the help last time.

Cheers,
--
Omar Valerio M.

Post by Geoff Hutchison

Post by ovalerio
This is from the time before OpenBabel moved to CMake. I look at the
CMakeLists.txt and there is no OpenMP flags there (-fopenmp,
-lgomp).
Which is the preferred way to do it.

Either edit you CMakeCache.txt (e.g., "ccmake .") after setting up
the cmake build directory, or declare these as CXX_FLAGS, e.g.,
CXXFLAGS="-fopenmp -lgomp" cmake /path/to/source/dir
Hope that helps,
-Geoff
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond.
Discussions
will include endpoint security, mobile security and the latest in
malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
OpenBabel-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/openbabel-discuss

[Geoffrey Hutchison]

Post by ovalerio
I followed your advise. After editing the CMakeCache.txt and adding the
compiler flags OpenMP is working for me. However, I would like to avoid
this additional step by adding some conditional compilation lines to the
CMakeLists.txt

This seems reasonable, since OMP_NUM_THREADS is needed before the OpenMP portion actually runs.

Post by ovalerio
I tried this lines with a fresh development version of OpenBabel and it
seems to be working. I tried both having a setup with GOMP libraries
installed and one without. I also run the ctest for MMFF94 just to be
sure everything was working.

Good, thanks. I'll try adding it to the SVN development code and we can see how it does on the other test machines:
http://my.cdash.org/index.php?project=Open+Babel&display=project

Post by ovalerio
run two instances of OBForceFieldMMFF94 are being created. I would like
to understand why is that, because I thought only one was necessary and
therefore I am confused about this.

I don't know. You'd need to run a debugger or something like Valgrind to figure out what part of the code is creating each instance. In this particular code, only one instance should be created.

-Geoff

[ovalerio]

Hi Geoff,

Post by Geoffrey Hutchison

Post by ovalerio
I followed your advise. After editing the CMakeCache.txt and adding the
compiler flags OpenMP is working for me. However, I would like to avoid
this additional step by adding some conditional compilation lines to the
CMakeLists.txt

This seems reasonable, since OMP_NUM_THREADS is needed before the
OpenMP portion actually runs.

In the email that I sent you, I explicitly declared how many cores to
use by setting the OMP_NUM_THREADS variable in my environment. However
the default behaviour for OpenMP is to use the maximum number of cores
available (in case no OMP_NUM_THREADS is enabled and code has been
compiled with OpenMP support and running in a multicore system with
GOMP)

So what I'm saying is that by adding those lines in CMakeLists.txt and
suggesting users to install OpenMP in their multicore computers, they
will benefit from multicore performance even if they don't set
OMP_NUM_THREADS.

Post by Geoffrey Hutchison

Post by ovalerio
I tried this lines with a fresh development version of OpenBabel and it
seems to be working. I tried both having a setup with GOMP
libraries
installed and one without. I also run the ctest for MMFF94 just to be
sure everything was working.

Good, thanks. I'll try adding it to the SVN development code and we
http://my.cdash.org/index.php?project=Open+Babel&display=project

Good thanks. I saw that you already added the lines and I also see the
test failed for some of the test machines:

http://my.cdash.org/testSummary.php?project=57&name=ffmmff94_Test&date=2012-06-20

However, I cannot see any particular information on why the test is
failing. Anyway I saw one of the systems failing is a MacOS X running
GCC. I will borrow a MAC laptop here at work and try to replicate this
setting to find out if I can gain more insight.

Post by Geoffrey Hutchison

Post by ovalerio
run two instances of OBForceFieldMMFF94 are being created. I would like
to understand why is that, because I thought only one was necessary and
therefore I am confused about this.

I don't know. You'd need to run a debugger or something like Valgrind
to figure out what part of the code is creating each instance. In
this
particular code, only one instance should be created.

Yes. That's also what I thought and that's the reason why I asked you.
I created an static variable in OBForceFieldMMFF94 to count how many
times the class is being instantiated and I found it was two every time.
Either when running obminimize or the ctest for mmff94. I will try the
debugger and see if I can figure out what is going on.

--
Omar V.M.

[Noel O'Boyle]

Post by ovalerio

Post by Geoffrey Hutchison

Post by ovalerio
run two instances of OBForceFieldMMFF94 are being created. I would like
to understand why is that, because I thought only one was necessary and
therefore I am confused about this.

I don't know. You'd need to run a debugger or something like Valgrind
to figure out what part of the code is creating each instance. In
this
particular code, only one instance should be created.

Yes. That's also what I thought and that's the reason why I asked you.
I created an static variable in OBForceFieldMMFF94 to count how many
times the class is being instantiated and I found it was two every time.
Either when running obminimize or the ctest for mmff94.  I will try the
debugger and see if I can figure out what is going on.

Is this because of the use of a templated class? There is one version
with <true> and one with <false> or something like this.

- Noel

[Tim Vandermeersch]

Post by Noel O'Boyle

Post by ovalerio

Post by Geoffrey Hutchison

Post by ovalerio
run two instances of OBForceFieldMMFF94 are being created. I would like
to understand why is that, because I thought only one was necessary and
therefore I am confused about this.

I don't know. You'd need to run a debugger or something like Valgrind
to figure out what part of the code is creating each instance. In
this
particular code, only one instance should be created.

Yes. That's also what I thought and that's the reason why I asked you.
I created an static variable in OBForceFieldMMFF94 to count how many
times the class is being instantiated and I found it was two every time.
Either when running obminimize or the ctest for mmff94.  I will try the
debugger and see if I can figure out what is going on.

Is this because of the use of a templated class? There is one version
with <true> and one with <false> or something like this.

The reason for this is probably because there is an instance for
MMFF94 and one for MMFF94s.

Cheers,
Tim

Post by Noel O'Boyle
- Noel
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
OpenBabel-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/openbabel-discuss

[ovalerio]

Post by Tim Vandermeersch

Post by Noel O'Boyle

Post by ovalerio

Post by Geoffrey Hutchison

Post by ovalerio
run two instances of OBForceFieldMMFF94 are being created. I
would
like
to understand why is that, because I thought only one was
necessary
and
therefore I am confused about this.

I don't know. You'd need to run a debugger or something like Valgrind
to figure out what part of the code is creating each instance. In
this
particular code, only one instance should be created.

Yes. That's also what I thought and that's the reason why I asked you.
I created an static variable in OBForceFieldMMFF94 to count how many
times the class is being instantiated and I found it was two every time.
Either when running obminimize or the ctest for mmff94.  I will try the
debugger and see if I can figure out what is going on.

Is this because of the use of a templated class? There is one
version
with <true> and one with <false> or something like this.

The reason for this is probably because there is an instance for
MMFF94 and one for MMFF94s.

You spotted correctly Tim. I used the ID that is sent when the class is
created as an argument and find out one of the running instances is
effectively MMFF94s. Now my question is why this happens, even when I
run obminimize and I explicitly ask to use MMFF94 (not MMFF94s)

$ time obminimize -ff MMFF94 -n 1000 forcefield.sdf

INSTANCE: 1 ID: MMFF94 - RUNNING THREADS = 4
INSTANCE: 2 ID: MMFF94s - RUNNING THREADS = 4

...

Post by Tim Vandermeersch
Cheers,
Tim

Post by Noel O'Boyle
- Noel
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond.
Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
OpenBabel-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/openbabel-discuss

[Geoff Hutchison]

Post by ovalerio
Now my question is why this happens, even when I
run obminimize and I explicitly ask to use MMFF94 (not MMFF94s)

The forcefieldmmff94.cpp file (and thus the resulting library) include global objects for both MMFF94 and MMFF94s. If you split the code, you could obviously do away with the "duplication," but for logical reasons, the underlying code is identical for both methods -- just slight differences in the parameters.

Hope that helps,
-Geoff

[ovalerio]

Hi Noel,

There is one of the systems in the testbed which is apparently unable
to find the datafiles for the OpenBabel MMFF94 forcefields test and it
is giving us a false positive (saying it pass the test when in fact it
didn't run it)

Test: ffmmff94_Test (Passed)
Build: Win7 MSVC++ 2008 Express 32b (Opti755.Noel) on 2012-06-20
02:02:58

Test Timing: Passed

Show Command Line
Show Test Time Graph
Show Failing/Passing Graph

Test output

# Testing MMFF94 Force Field...
Bail out! Cannot load force field!
Bail out! Cannot load force field!
1..0

--
Omar

[Noel O'Boyle]

Well spotted. I'll sort it out. First of all, the test should be failing.

Post by ovalerio
Hi Noel,
There is one of the systems in the testbed which is apparently unable
to find the datafiles for the OpenBabel MMFF94 forcefields test and it
is giving us a false positive (saying it pass the test when in fact it
didn't run it)
Test: ffmmff94_Test (Passed)
Build: Win7 MSVC++ 2008 Express 32b (Opti755.Noel) on 2012-06-20
02:02:58
Test Timing: Passed
Show Command Line
Show Test Time Graph
Show Failing/Passing Graph
Test output
# Testing MMFF94 Force Field...
Bail out! Cannot load force field!
Bail out! Cannot load force field!
1..0
--
Omar
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
OpenBabel-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/openbabel-discuss

[Geoff Hutchison]

Hi Omar,

A few notes on the OpenMP code -- which is presently just for the MMFF94 implementation. I don't think Tim spent a whole lot of time trying to optimize how the OpenMP blocks were arranged. So it works, and validates, but I suspect with a bit of tweaking, better speed-ups could be found. Right now, the block sizes are pretty small, so there's a lot of overhead in forking off lots of threads.

-Geoff

[My Th]

Post by ovalerio
Hi Geoff,
Thanks. I'm aiming to use OpenBabel as a platform to learn about
parallelization using GPU and multicore CPU. I want also to contribute
the code I develop to the OpenBabel project. Following Noel suggestion I
am first looking at the forcefields used in energy calculation and in
particular MMFF94.
I followed your advise. After editing the CMakeCache.txt and adding the
compiler flags OpenMP is working for me. However, I would like to avoid
this additional step by adding some conditional compilation lines to the
CMakeLists.txt
#Find if OpenMP support is enable
find_package(OpenMP)
if(OPENMP_FOUND)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${OpenMP_C_FLAGS}")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS}")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS}
${OpenMP_EXE_LINKER_FLAGS}")
endif()

IMHO this should be wrapped in a cmake flag to enable/disable during
configuration so it can be explicitly turned on/off as needed, not just
rely on automagick feature discovery.


Reinis

[Geoffrey Hutchison]

Post by My Th
IMHO this should be wrapped in a cmake flag to enable/disable during
configuration so it can be explicitly turned on/off as needed, not just
rely on automagick feature discovery.

My apologies -- I had the same thought earlier today. In SVN trunk, you'll now need -DENABLE_OPENMP=true when running Cmake to turn this on.

Cheers,
-Geoff

[ovalerio]

Geoff & Reinis,

Thank you both for taking the time to discuss and implement this the
best way possible. I am in a steep learning curve here but with your
help I will catch up soon. Noel has asked me to move further discussion
on this topic to the developers list.

Post by Geoffrey Hutchison

Post by My Th
IMHO this should be wrapped in a cmake flag to enable/disable during
configuration so it can be explicitly turned on/off as needed, not just
rely on automagick feature discovery.

My apologies -- I had the same thought earlier today. In SVN trunk,
you'll now need -DENABLE_OPENMP=true when running Cmake to turn this
on.
Cheers,
-Geoff

Regards,
--
Omar Valerio