2013/11/26 Axel Arnold <address@hidden>:
On 26.11.13 11:20, Olaf Lenz wrote:
As long as ADResS in ES doesn' have any advantage over highres simulations,
why should we even try to maintain the code?
For testing purposes, for example, if one needs to try a new scheme. Matej
is still using Espresso for that, although a really old version. Apart from
that, even Espresso's ADRes can be a bit faster than a highres simulation,
depending on how complex the potentials are.
Again, if no one wants to maintain the code, of course we have to remove it,
but about that I would first ask Christoph as the main contributor.
Of course, I don't want to see the/our AdResS code go, but considering
the fact it hasn't been used for years it might be not very useful to
keep it. The C part is still okay, but the tcl sample script needs
update. So, if Pierre and Jakub want to make the tcl part work again
or write a python version of the script for the upcoming new python
interface, I am happy to help.
Concerning Olaf's point of the performance, all AdResS implementations
so far only attack the force part of the simulation, so the speed-up
is bound by Amdahl's law. If the force calculating takes X% of the
time, the max speed-up is 1/(1-X) or more accurately 1/(1-X+X/N^2),
where N is the number of atoms coarse-grained away. X is around 75%
for water, which leads to performance gain of max. 3. Espresso++ and
Gromacs get a bit closer to that bound as they use separate neighbor
lists for the different resolutions and hence have a bit less
overhead. But this is nothing, which couldn't be done in Espresso,
too, we were just not as smart when we first implemented AdResS in
Espresso.
So overall, doing AdResS for better performance seems a pretty weak
reason with the available implementations.
Christoph
Axel
2013/11/26 Axel Arnold <address@hidden>
Hi!
Before we bury ADResS, I would actually like to hear Christoph's opinion.
We cannot provide support for ADResS in Espresso, but on the other hand, it
is not that difficult to maintain. Ok, there will be a switch to Python...
If Christoph is willing to care a bit for ADResS, it might be worthwhile
to keep it. Otherwise, we indeed will have to remove the code.
Axel
On 26.11.13 10:45, Olaf Lenz wrote:
At least at the moment, ADResS does not have much of a future in ESPResSo.
The code is currently not well-suited for an ADResS implementation that
actually has a performance gain. I don't think it makes sense to put any
effort into the old implementation.
In fact, this thread probably tells me that it is best to remove ADResS
from the code altogether, as otherwise people might be tempted to use it.
Olaf
2013/11/26 Pierre de Buyl <address@hidden>
Hi Christoph
On Mon, Nov 25, 2013 at 10:10:05AM -0700, Christoph Junghans wrote:
2013/11/21 Pierre de Buyl <address@hidden>:
If anyone knowledgeable with Espresso/AdResS would be willing to have
a look and
comment on
https://github.com/pdebuyl/espresso_work/commits/add_nregime I'd be
happy, if appropriate, to file a PR.
The branch add_nregime works with the scripts attached, Adress_t.tcl
and
auxiliary.tcl. These are not clean enough to commit, however.
I am happy to review your changes, but first Olaf has to decide if
AdResS has a future in Espresso, otherwise this will be just a neat
exercise.
Thanks for proposing :-)
Given Olaf's last message I understand that this will not be necessary.
Best,
Pierre
--
Dr. rer. nat. Olaf Lenz
Institut für Computerphysik, Allmandring 3, D-70569 Stuttgart
Phone: +49-711-685-63607
--
JP Dr. Axel Arnold
ICP, Universität Stuttgart
Allmandring 3
70569 Stuttgart, Germany
Email: address@hidden
Tel: +49 711 685 67609
--
Dr. rer. nat. Olaf Lenz
Institut für Computerphysik, Allmandring 3, D-70569 Stuttgart
Phone: +49-711-685-63607
--
JP Dr. Axel Arnold
ICP, Universität Stuttgart
Allmandring 3
70569 Stuttgart, Germany
Email: address@hidden
Tel: +49 711 685 67609