[CPMD-list] Bohr length unit

[Axel Kohlmeyer]

On Thu, 2 Nov 2006, Martin Konopka wrote:

MK> Dear CPMD develpers,

dear cpmd-list subscribers and martin,

MK> The Bohr length unit expressed in Angtroms is written several times
MK> inside the code (3.11.1). What is worse there are two slightly different
MK> values:
MK> 0.529177d0 and 0.529177249D0

this is not much of a surprise in a code that big with so
many people contributing code that are not trained programmers.

[...]

MK> Sometime one needs to recalculate coordinates or cell vectors from AU to
MK> Angstroms or vice versa. Using slightly different values of the Bohr unit
MK> introduces small but annoying differences into quantities.

the canonical way of converting units in cpmd is to include cnst.inc
and use the values from the common block there. in case of your
examples the proper way for unit conversion would be to multiply
with FBOHR. this is becomes evident, if one would read a little bit
the code (outside of the one file that is related to the feature
at hand) and see how things work and what the typical style of 
doing things within the code is.

MK> Could in future CPMD releases be only one value of the Bohr unit?
MK> (And in one file only, if possible.)

well, who is going to do it? if you see it, why don't you just 
sit down, program this trivial change and send in a patch that 
fixes it? especially after you discovered it, it should be easy.


you have to realize that the number of people that are currently
able to spend time on improving the cpmd code in this way is very,
very limited. currently, there is nobody that pays anybody to do 
this kind of work. furthermore, people that have been investing
a lot of time into the code in their 'spare time' are getting
more interested into starting other new projects (as cpmd has 
matured and is becoming less experimental and more of a commodity)
or become more involved into administration or teaching or management,
but there is nobody really owning up to take over some of those
duties. and since there is almost no positive feedback from cpmd
users, there is little incentive to do this kind of work, since it is 
tedious and does not bring any other reward in terms of publications 
or something equivalent. do you think there is anybody stupid
enough to do something without having _any_ benefit from it?
or even more so, would you _trust_ code that is written by somebody
with that kind of disposition??

of course, everybody is suffering the consequences of these 
inconsistencies, but it is also understandable that researchers 
who have to do the 'legwork' of implementing new features
are rarely also expert programmers. so people with more experience
in programming (and perhaps less experience in developing new
methods or algorithms) are needed to help out here.

so let me use this opportunity to ask the cpmd 'community' for help. 
there are now several _thousands_ of people with a cpmd license and 
on this mailing list are over a thousand subscribers. if _all_ of 
you would contribute a little of your time in improving, documenting, 
testing and consolidating the code, everybody will benefit a lot,
yet it will take only a little bit of your time. even more so, you
may actually gain some time, since you won't stumble over bugs,
inconsistencies or 'undocumented features' or missing functionality.

i'm part of this effor for only a few years now, but if the trend 
that i've seen over those years continues, there will be tens of 
thousands of cpmd users, yet no developers at all and still no
proper (beginner's / user's) manual, incomplete reference documentation, 
inconsistencies and known bugs in the code and so on. 

if you don't want this, something has to happen _now_! as long as 
people with experience are still around and not yet too frustrated 
or overloaded with other work to help you getting started. if this 
so called 'residual knowledge' is lost, it will be even more difficult 
for everybody.


thanks and best regards,
   axel.

p.s.: i've been making pleas like this several times over the last
years. please consider surprising me by not ignoring it in the hope
that some other sucker will do the work you could do as well.


MK> And perhaps set to most accurate value currently known.
MK> There may be similar problem with other constants too, I did not check...

MK> 
MK> Thanks.
MK> 
MK> Greetings
MK> Martin Konopka.
MK> 
MK> 
MK> 
MK> ------------------------------------------------------------------------
MK> Dr. Martin Konopka             http://www.ccms.elf.stuba.sk/konopka.html
MK> Department of Physics, CCMS                      tel: +421 (0)2 60291714
MK> Slovak University of Technology (FEI STU)        fax: +421 (0)2 65411483
MK> Ilkovicova 3, 812 19 Bratislava, Slovakia
MK> ------------------------------------------------------------------------
MK> _______________________________________________
MK> CPMD-list mailing list
MK> CPMD-list at cpmd.org
MK> http://cpmd.org/mailman/listinfo/cpmd-list
MK> 

-- 
=======================================================================
Axel Kohlmeyer   akohlmey at cmm.chem.upenn.edu   http://www.cmm.upenn.edu
   Center for Molecular Modeling   --   University of Pennsylvania
Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
tel: 1-215-898-1582,  fax: 1-215-573-6233,  office-tel: 1-215-898-5425
=======================================================================
If you make something idiot-proof, the universe creates a better idiot.