[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ESPResSo-devel] Bond-deleting strangeness

From: Axel Arnold
Subject: Re: [ESPResSo-devel] Bond-deleting strangeness
Date: Thu, 8 Jan 2015 10:23:01 +0100


On 08.01.2015, at 10:01, Rudolf Weeber <address@hidden> wrote:

Thanks guys. I wouldn't have figured that one out any time soon.

Well, didn’t take too long. I just put in printfs to see that the parameters were ok, then of course the problem is in the function. Well, and the manpage warns pretty directly about memcpy not being stable…

Two points:
1. The same issue probably also affects exclusions, as they are also intlist based.

Yes, it did, see my full patch. The simples thing would be to replace all memcpy by memmove, but there so many, and most really just copy from one segment to another. We also have only very few lists that actually can be shorted, so should be more or less ok now (crossing fingers). The particle lists are ok, because if I delete particles there, I just move particles from the end of the list into the gap, rather than shifting as in the bond list.

2. Might this be a reason for a bugfix release of the stable Espresso? As I understand it, this issue will affect all existing users, who happen to use a new enough linux distro?

There is actually a number of other bugfixes in the master that would be worthwhile to cherry-pick. Whoever maintainer jumps at it…


On Wed, Jan 07, 2015 at 11:26:53PM +0100, Florian Weik wrote:
Actually simply switching to memmove does the trick... Now its even
standard conform, so it will never break again *cough*

On Wed, Jan 7, 2015 at 11:24 PM, Ulf Schiller <address@hidden> wrote:

Maybe a bit dirty, but could playing around with something like

__asm__(".symver memcpy,...

do the trick?

On 01/07/2015 10:20 PM, Axel Arnold wrote:
Well, I was more polite about this change than Linus...

But I do like his statement about standards :-). The other funny thing
is that he thinks they just forgot to handle overlapping in early memcpy
and therefore introduced memmove with guaranteed behavior. I just wrote
try_delete_bond in the golden window when both were the same...


On 07.01.2015, at 23:10, Florian Weik <address@hidden
<mailto:address@hidden>> wrote:

This is a joke, right?

On Wed, Jan 7, 2015 at 10:56 PM, Axel Arnold
<address@hidden <mailto:address@hidden>>


  No, that problem is more subtle, and will probably stick around
  for a while. glibc < 2.14 aliased memcpy to memmove, which allows
  for overlapping memory regions, while memcpy doesn't. The current
  glibc versions have a more efficient memcpy, that does not allow
  for overlap, which in this case however occurs.

  I can’t test on my Mac, since Apple decided wisely that an
  unmeasurable speed gain (according to Linus) isn’t worth breaking
  hundreds of applications, but most Linux distros seem to have this
  problem. Shooting yourself (or others) in the foot seems to be
  great fun...


  On 07.01.2015, at 15:52, Florian Weik <address@hidden
  <mailto:address@hidden>> wrote:

  the function looks suspicious to me, might be an off by one
  error. I'll get back to you if I've got it figured out.


  On Wed, Jan 7, 2015 at 3:45 PM, Rudolf Weeber
  <mailto:address@hidden>> wrote:

      On Wed, Jan 07, 2015 at 02:42:27PM +0100, Rudolf Weeber wrote:
I encountered very strange behaviour when deleting
individual bonds from particles which have more than one bond.
In some cases, the code works correctly, in some cases, the
wrong bond seems to be deleted and in some cases, the bond list gets
screwed up completely.
The code, which is supposed to delete the bond is in
      And here is a case, where the bond list is screwed up entirely:

      {0 FENE 47.396 2.5 1.0} {1 angle_harmonic 473.96000000000004
      1.0471975512} {2 FENE 473960.0 2.0 1.0} {3 FENE 473960.0 0.1
      0.0} {1 1 lennard-jones 1000.0 2.672696154421018 3.0 0.25 0.0
      0.0 0.0 } {magnetic 1.0  dawaanr }
      I.e., bond 0 and 2 have one partner, bond 1 has two partners

      Initial bond configurations
      { {0 21746} {0 21747} {0 22047} {1 22047 21746} {1 22049
      21747} {1 22348 22047} {1 22349 22049} }
        Del: 0 21746
      { {0 21747} {0 22047} {1 22047 21746} {1 22049 21747} {22047
      1} {22047 1} {22349 22049} }


      The relevant code is
      proc makeBondRigid { id bond} {
      global bondMeshPairSoft 0
      global bondMeshAngleSoft 1
      global bondMeshPairStiff 2
      global bondParticleMesh 3

       puts "$id: Making bond rigid: $bond"
       # First delete the old bond
       puts "[part $id print bond]"
       puts "  Del: $bond"
       eval "part $id bond delete $bond"
       puts "[part $id print bond]"

       # Make new bond with changed type
       lset bond 0 $bondMeshPairStiff
       # Add
       puts "  Add: $bond"
       eval "part $id bond $bond"
       puts "[part $id print bond]"

      Regards, Rudolf

  Florian Weik

  address@hidden <mailto:address@hidden>
  ++49 157 85939252 <tel:%2B%2B49%20157%2085939252>

  JP Dr. Axel Arnold
  ICP, Universität Stuttgart
  Allmandring 3
  70569 Stuttgart, Germany
  Email: address@hidden
  Phone: +49 711 685 67609 <tel:%2B49%20711%20685%2067609>

Florian Weik

address@hidden <mailto:address@hidden>
++49 157 85939252

JP Dr. Axel Arnold
ICP, Universität Stuttgart
Allmandring 3
70569 Stuttgart, Germany
Email: address@hidden <mailto:address@hidden

Phone: +49 711 685 67609

Ulf D. Schiller
Centre for Computational Science
University College London
20 Gordon Street
London WC1H 0AJ
United Kingdom

Phone: +44 (0)20 7679 5300

Florian Weik

++49 157 85939252

JP Dr. Axel Arnold
ICP, Universität Stuttgart
Allmandring 3
70569 Stuttgart, Germany
Email: address@hidden
Phone: +49 711 685 67609

reply via email to

[Prev in Thread] Current Thread [Next in Thread]