Hi,
I have big problems in getting a smooth visualisation of moving atoms.
Let me explain.
I’m hooking-up the core of my molecular dynamics programs as an
extension to Avogadro.
While I do get the MD engine working and timestepping satisfactory, the
visualisation of the process is cumbersome.
This is what I do:
1a. I copy the molecular geometry and other data from Avogadro into the
data structures of my MD extension.
b. I ensure that my MD extension is completely initialised (choice of
ensemble, pressure, temperature etc.) so that it si ready to go.
- Then I let the configuration do timestepping. This is all done in
the MD extension.
- Let’s say that I want to take 1000 timesteps. Every 5 timesteps I
emit a QT signal that triggers a function (slot) to upload the changed
geometry back to the Avogadro::molecule, using the funtion
Avogadro::Molecule::SetAtomPos(). This upload function ends with a
mol->update(), with the intention to redraw the molecule on the screen…
Now the engine works as expected. By printing-out tracing commands, I
see that indeed every 5 timesteps a new configuration is pumped over.
But the visualisation lags behind! Whereas I was expecting a smoothly
changing configuration, I see a bumpy behaviour. Or just a static
picture, waiting for me to click on the screen to refresh the view and
display the last configuration. Apparently, the mol->update() is not
enforced, but waits for some other redraw event?
What should I do? Any suggestions are welcome.
I followed the procedure followed by the geometry optimisation in the
forcefield extension as an example/guidance.
Kind Regards,
Bertwim
geometry back to the Avogadro::molecule, using the funtion
Avogadro::Molecule::SetAtomPos(). This upload function ends with a
mol->update(), with the intention to redraw the molecule on the screen…
I don’t know how your MD code works – do you end up with a set of coordinates? If so, you should probably look at the Animation or Vibration extensions.
Now the engine works as expected. By printing-out tracing commands, I
see that indeed every 5 timesteps a new configuration is pumped over.
…
What should I do? Any suggestions are welcome.
I’d move the entire set of timesteps over as conformers (see, for example, the vibration code) and then you’re just flipping between conformer sets.
I followed the procedure followed by the geometry optimisation in the
forcefield extension as an example/guidance.
This is an OK example if you’re doing your MD on-the-fly in another thread. Instead, it sounds like you want to visualize an already-existing trajectory. I think you’ll get smoother animation if you look at the vibration code. You can even go so far as to use the Animation class to handle the updates for you.
Cheers,
-Geoff
Please see below.
Geoffrey Hutchison wrote:
geometry back to the Avogadro::molecule, using the funtion
Avogadro::Molecule::SetAtomPos(). This upload function ends with a
mol->update(), with the intention to redraw the molecule on the screen…
I don’t know how your MD code works – do you end up with a set of coordinates? If so, you should probably look at the Animation or Vibration extensions.
BwvB:
No, it is MD on the fly. I do not save the trajectory of the system in
phase space. At any moment in tim, I only have available 1
configuration. And I sample data over time to get statistical data of
the ensemble.
Now the engine works as expected. By printing-out tracing commands, I
see that indeed every 5 timesteps a new configuration is pumped over.
…
What should I do? Any suggestions are welcome.
I’d move the entire set of timesteps over as conformers (see, for example, the vibration code) and then you’re just flipping between conformer sets.
I followed the procedure followed by the geometry optimisation in the
forcefield extension as an example/guidance.
This is an OK example if you’re doing your MD on-the-fly in another thread. Instead, it sounds like you want to visualize an already-existing trajectory. I think you’ll get smoother animation if you look at the vibration code. You can even go so far as to use the Animation class to handle the updates for you.
BwvB:
No, see above. I wonder how the vibration extension works. When I press
the menu entry, I always get the message that no vibrations have been
calculated, which no doubt is true, but I have not found the
documentation where that is explained. Can you give a hint?
Regards,
Bertwim
Cheers,
-Geoff
David C. Lonie wrote:
From: “B.W.H. van Beest” bwvb@xs4all.nl
Subject: [Avogadro-devel] visualisation of moving atoms: to fast to follow?
Date: Mon, 18 Jan 2010 19:52:55 +0100
Now the engine works as expected. By printing-out tracing commands, I
see that indeed every 5 timesteps a new configuration is pumped over.
But the visualisation lags behind! Whereas I was expecting a smoothly
changing configuration, I see a bumpy behaviour. Or just a static
picture, waiting for me to click on the screen to refresh the view and
display the last configuration. Apparently, the mol->update() is not
enforced, but waits for some other redraw event?
What should I do? Any suggestions are welcome.
There may be a better solution, but this might work until someone else
chimes in: include <avogadro/glwidget.h> and run
Avogadro::GLWidget::current()->renderNow();
I’m not 100% sure if that would work, but it may be worth a try!
Does the MD simulation use a lot of threads, or Qt signal and slots?
Keep in mind that the GUI can only be updated from the thread with the
application’s event loop, and if this thread is tied up doing other
work the updates won’t happen as expected. Getting GUI updates to
happen when you want them in Qt isn’t as simple as one might think 
HTH,
Dave
When I run the MD simulation, this is done in a separate thread. When
the simulation is done, this thread terminates. So there are not many
threads. Just one extra for the MD. But you may be right: the number of
signals that is emitted is potentially enormous! So I reckon that using
the signal/slot approach is maybe not a good idea. My initial attempts
were to do everything in the same (main) thread, but. that gave the same
(bad) behaviour, but that may then be caused by the signals trying to
update the GUI. It was the example of the forcefield extension that made
me switch to a threaded solution. From you remarks I understand that
before trying the GLWidget::current()->renderNow() trick, I must get rid
of this separate thread first!?
Kind Regards,
Bertwim
On Mon, Jan 18, 2010 at 5:19 PM, B.W.H. van Beest bwvb@xs4all.nl wrote:
When I run the MD simulation, this is done in a separate thread. When the
simulation is done, this thread terminates. So there are not many threads.
Just one extra for the MD. But you may be right: the number of signals that
is emitted is potentially enormous! So I reckon that using the
signal/slot approach is maybe not a good idea. My initial attempts were to
do everything in the same (main) thread, but. that gave the same (bad)
behaviour, but that may then be caused by the signals trying to update the
GUI. It was the example of the forcefield extension that made me switch to a
threaded solution. From you remarks I understand that before trying the
GLWidget::current()->renderNow() trick, I must get rid of this separate
thread first!?
So long as the simulation is done in a new thread and all GUI updates
are triggered by signals/slots, there shouldn’t be a problem. I’d try
adding the renderNow() call in the slot that updates the molecule
object – so long as it’s not being called from the background thread.
Dave
David C. Lonie wrote:
From: “B.W.H. van Beest” bwvb@xs4all.nl
Subject: [Avogadro-devel] visualisation of moving atoms: to fast to follow?
Date: Mon, 18 Jan 2010 19:52:55 +0100
Now the engine works as expected. By printing-out tracing commands, I
see that indeed every 5 timesteps a new configuration is pumped over.
But the visualisation lags behind! Whereas I was expecting a smoothly
changing configuration, I see a bumpy behaviour. Or just a static
picture, waiting for me to click on the screen to refresh the view and
display the last configuration. Apparently, the mol->update() is not
enforced, but waits for some other redraw event?
What should I do? Any suggestions are welcome.
There may be a better solution, but this might work until someone else
chimes in: include <avogadro/glwidget.h> and run
Avogadro::GLWidget::current()->renderNow();
I’m not 100% sure if that would work, but it may be worth a try!
Does the MD simulation use a lot of threads, or Qt signal and slots?
Keep in mind that the GUI can only be updated from the thread with the
application’s event loop, and if this thread is tied up doing other
work the updates won’t happen as expected. Getting GUI updates to
happen when you want them in Qt isn’t as simple as one might think
HTH,
Dave
Well, I tried
Avogadro::GLWidget::current()->renderNow();
immediately after updating the geometry. Unfortunately it didnt work.
Apperently even the "renderNow() function has to wait for an overarching
repaint event or something of the like: the update is only there after I
activate the screen by clicking with the mouse, or moving a window.
Are there any more suggestions?
Regards,
Bertwim.