espressomd-devel
[Top][All Lists]
Advanced

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

Re: [ESPResSo-devel] Bond-deleting strangeness


From: Rudolf Weeber
Subject: Re: [ESPResSo-devel] Bond-deleting strangeness
Date: Thu, 8 Jan 2015 10:01:34 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

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

Two points:
1. The same issue probably also affects exclusions, as they are also intlist 
based.
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?

Regards, Rudolf


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...
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=638477#c129
> > >
> > > 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...
> > >
> > > Cheers,
> > > Axel
> > >
> > >> 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>>
> > >> wrote:
> > >>
> > >>     Hi!
> > >>
> > >>     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...
> > >>
> > >>     Best,
> > >>     Axel
> > >>
> > >>>     On 07.01.2015, at 15:52, Florian Weik <address@hidden
> > >>>     <mailto:address@hidden>> wrote:
> > >>>
> > >>>     Hi,
> > >>>     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.
> > >>>
> > >>>     Florian
> > >>>
> > >>>     On Wed, Jan 7, 2015 at 3:45 PM, Rudolf Weeber
> > >>>     <address@hidden
> > >>>     <mailto:address@hidden>> wrote:
> > >>>
> > >>>         Hi,
> > >>>         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
> > particle_data.cpp:try_delete_bond()
> > >>>         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
> > >>     <mailto: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
> 
> address@hidden
> ++49 157 85939252



reply via email to

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