IMP-dev

imp-dev@salilab.org

868 discussions

Parallelize code
by Davide Baù 16 Jul '14

16 Jul '14

Hi, I have set up a Brownian dynamics optimizer as follow: > m = IMP.kernel.Model() > > # Brownian Dynamics > bd=IMP.atom.BrownianDynamics(m) > bd.set_maximum_time_step(1000) > > for i in range(1, nrounds): > e = bd.optimize(10) Is it possible in IMP to parallelize the code to make it faster? I have seen that there is the possibility to use OpenMP but I am not really sure how to implement it. Thanks, Davide

5 4

Fwd: [IMP-build] IMP nightly build results, 2014-06-23
by Barak Raveh 23 Jun '14

23 Jun '14

It seems the build works except with Mac. Can someone that regularly builds on Mac help? It is probably just a matter of introducing #include <Particle.h> in the right place - it was previously included through <Model.h> (and it doesn't have to). I don't know why it's Mac specific. Thanks Barak ---------- Forwarded message ---------- From: Notification of IMP build results <imp-build(a)salilab.org> Date: Mon, Jun 23, 2014 at 7:03 AM Subject: [IMP-build] IMP nightly build results, 2014-06-23 To: imp-build(a)salilab.org IMP nightly build results, 2014-06-23. At least part of IMP failed to build today. Please see http://integrativemodeling.org/nightly/results/ for full details. IMP component build summary (BUILD = failed to build; BENCH = benchmarks failed to build or run; INCOM = component did not complete building; TEST = failed tests; EXAMP = failed examples; DISAB = disabled due to wrong configuration; UNCON = was not configured; skip = not built on this platform; only components that failed on at least one platform are shown) Lin32 Lin64 M10.6 M10.8 Win64 Fst32 Fst64 OMP FstMc MPI RH5_3 RH5_6 RH6_3 RH6_6 F20 deb Cov ALL - - - BUILD - - - - - - - - - - - - - PACKAGE skip skip BUILD skip - skip skip skip skip skip skip skip skip skip skip skip skip IMP.algebra - - - TEST - - - - - - - - - - - - - IMP - - - BUILD - - - - - - - - - - - - - IMP.core - - - - - - - - - - TEST - - - - - - IMP.pmi TEST TEST TEST - TEST TEST TEST TEST TEST TEST TEST TEST TEST TEST TEST TEST TEST IMP.pmi benchmarksBENCH BENCH BENCH - BENCH - - BENCH BENCH - skip skip skip skip skip skip skip IMP.pmi examples EXAMP EXAMP EXAMP - EXAMP EXAMP EXAMP EXAMP EXAMP EXAMP skip skip skip skip skip skip EXAMP IMP.em TEST - - - - - - - - - TEST - - - - TEST - IMP.isd - - - - - - - - - TEST - - - - - - - IMP.em2d TEST TEST TEST - - - - TEST - - skip skip skip skip - - - IMP.cnmultifit - TEST TEST - TEST - TEST TEST TEST TEST - TEST - TEST TEST TEST TEST There were 4 new test failures (tests that passed yesterday but failed today) in the following components: IMP.algebra IMP.core IMP.em Changelog: 949504ef3f barak fix IMP_DOXYGEN symbol 3f986fec10 barak inline key functions in rigid_bodies ; minor document d470b6637d barak cache particles in FixedRefiner and allow access by r dfd22925cc barak minor change to Diffusion ac75660776 barak make timer statistics a bit faster by using function df5f473e4c barak add validity tracking for Decorator + slight speedup 6476de4922 barak add option to access certain refiner particles by ref a880a3d880 barak inline key accessor functions from Model and Particle fe338662ae barak add get_is_valid() checks; move destructor of Rotatio _______________________________________________ IMP-build mailing list https://salilab.org/mailman/listinfo/imp-build -- Barak

2 1

latest commits - heads up
by Barak Raveh 22 Jun '14

22 Jun '14

I made a commit that is supposed to speed up a bit some major kernel and core classes (Model, Particle). No critical changes, it was mainly inlining some methods and preventing redundant object creation. All tests seem to work as before but better wait for nightly tests before updating. Let me know if any problems arise or better yet, if things work faster :) though it might not benefit every piece of code, it is based on profiling my own code. Barak

1 0

faster RigidBody::get_reference_frame()
by Barak Raveh 18 Jun '14

18 Jun '14

Hi, right now RigidBody::get_reference_frame() is a common yet expensive operation (from profilng), especially within scores. The reason seems to be that IMP saves the quaternion, but not the rotation matrix. Would it make sense to save a cache of the rotation matrix that would update if needed? Or is it possibly that memory cost would be too high? -- Barak

2 2

GPU for polymer simulation
by Barak Raveh 11 Jun '14

11 Jun '14

up to x133 faster than on CPU, nice :) http://arxiv.org/pdf/1107.3490v1.pdf -- Barak

1 0

Object::do_destroy() public ==> protected
by Barak Raveh 03 Jun '14

03 Jun '14

before I change - anyone objects that Object::do_destroy() be made protected (instead of public) ? -- Barak

1 0

disabling swig build
by Barak Raveh 30 May '14

30 May '14

We used to have a cmake option to disable swig build - does this option still exist? If so, what should I write in cmake? Much appreciated, Barak

2 3

c++ 11
by Barak Raveh 23 May '14

23 May '14

What is our current policy regarding c++-11 - can we use (or are we already using) c++-11 features that are already well established for 3-4 years. I am particularly craving for the auto keyword :) There's a nice list by the way of c++ 11 support status by compiler versions in the following links: https://gcc.gnu.org/projects/cxx0x.html http://msdn.microsoft.com/en-us/library/hh567368.aspx http://clang.llvm.org/cxx_status.html -- Barak

2 1

Fwd: GPU programming workshop on June 11
by Barak Raveh 12 May '14

12 May '14

nice opportunity as we consider turning IMP into a GPU monster ---------- Forwarded message ---------- From: Volkan Sevim <volkan.sevim(a)ucsf.edu> Date: Fri, May 9, 2014 at 7:06 PM Subject: GPU programming workshop on June 11 To: POSTDOCS(a)listsrv.ucsf.edu Do you want to accelarate your research by harnessing the power of parallel computing? Dock, align, transform, and visualize faster? Come to this workshop for an introduction to GPU programming. Lectures will cover CUDA C/C++, the OpenACC standard, GPU architecture, and optimization techniques. (Lunch will be provided) *SEATING IS LIMITED. PLEASE REGISTER TO SECURE YOUR SPOT*: https://www.eventbrite.com/e/introduction-to-gpu-programming-tickets-115773… *Where: *Genentech Hall S271 *When: *June 11, 2014, 11:30am *Who: *Postdocs, grad students, and other UCSF affiliates. *Schedule* 11:30-12:30 CUDA 101 - a basic intro to the C/C++ CUDA language 12:45-13:45 Lunch / GPU architecture and key optimizations for performance 14:00-15:00 Introduction to GPU programming with OpenACC 15:00-17:00 Hands-on exercises *Instructor*: Robert Crovella (nVidia) Participants are expected to have a basic understanding of C programming. No prior parallel programming or HPC experience is required. A laptop with an SSH client installed is required for the hands-on session. Participants should be familiar with vi or another editor they would like to use that works in a terminal (non-graphical) setup. ------------------------------ Subscription to this UCSF Listserv list is based on affiliation, appointment, employment or registration at UCSF. Membership is updated every 24-hours. Individuals cannot be manually removed. -- Barak

1 0

bug in core::Centroid class derivative propagation to fine particles?
by Barak Raveh 14 Apr '14

14 Apr '14

I was wondering whether there is a bug in derivative propagation in the core::Centroid class - is anybody else using it? As it is now, the derivatives of the centroid are copied to the finer particles as is, using the DerivativesToRefinedas class. Shouldn't the derivatives be rescaled first according to the mass contribution of each fine particle to the centroid? For instance, let p1 and p2 be particles of masses 10 and 20 respectively. Then if a derivative of 3 units is accumulated in C, then right now, a derivative of 3 units is also copied to p1 and p2 each. Shouldn't this be reweighted such that p1 get 1 derivative units and p2 gets 2 derivative units? -- Barak

2 2

← Newer
1
...
5
6
7
8
9
10
11
...
87
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

IMP-dev