[Debichem-devel] Elpa-2015.11 interface change
Andreas Marek
amarek at rzg.mpg.de
Mon Nov 23 10:41:51 UTC 2015
Am Sonntag, 22. November 2015, 18:16:04 schrieb Volker Blum:
Hi Michael,
there seems to be some discussion now involved. My release-fix will have to
wait, I will not publish it as promised today.
Best regards, Andreas
> Dear Andi, dear all,
>
> We also noticed the repeated API changes here in our work.
>
> I agree that we should by all means get the versions to be consistent.
>
> At present my main concern is that we had a stable and working interface
> that was used in many packages, but this interface is now changed to
> something different, to my knowledge without announcements or discussion.
>
> We appreciate the maintenance work done but going forward I would like to
> suggest two things:
>
> 1) We should revisit the present interfaces and make sure that they are
> really what we want for a final version. Even the present interfaces, I
> understand, return different variable types between different situations.
> It would be good to return to a consistent interface definition that has
> the prospect of long-term stability over decades, similar to lapack.
>
> 2) After the interfaces for the routines that are stable in ELPA are changed
> we should refrain from API changes unless absolutely necessary. Stability
> of APIs is important.
>
> We spent a substantial amount of time in 2013 to document the interfaces of
> the ELPA subroutines in an overview publication (J. Phys: Cond Matter).
> This publication appeared in 2014, and by 2015 this information is
> essentially outdated. Every single user code that used ELPA will need to
> update their code base every time this happens. This is a measurable
> investment. We should keep such changes to a minimum.
>
> Best wishes
> Volker
>
> On Nov 22, 2015, at 1:55 PM, Andreas Marek <amarek at rzg.mpg.de> wrote:
> > Am Sonntag, 22. November 2015, 18:56:03 schrieb Michael Banck:
> > Dear Michael,
> >
> >> Hrm, so it's
> >>
> >> $ grep ELPA_SO_VERSION elpa-2015.*/configure.ac
> >> elpa-2015.05.001/configure.ac:AC_SUBST([ELPA_SO_VERSION], [3:1:0])
> >> elpa-2015.11.001/configure.ac:AC_SUBST([ELPA_SO_VERSION], [3:2:0])
> >>
> >> The numeric library version members are "[current:revision:age]". The
> >> above page says:
> >>
> >> "If any interfaces have been added, removed, or changed since the last
> >> update, increment current, and set revision to 0."
> >>
> >> and
> >>
> >> "If any interfaces have been removed or changed since the last public
> >> release, then set age to 0."
> >>
> >> So incrementing current and setting age to 0 would lead to "[4:0:0]" I
> >> believe. And I think both should be done as solve_evp_real_2stage() has
> >> been changed.
> >
> > I have checked it and I agree with your analysis. The API should have been
> > changed from 3.1.0 to 4.0.0 in the latest release, and not to 3.2.0.
> > I will correct this tomorrow and replace with an appropiate comment the
> > release tar ball.
> >
> > Best regards, Andreas
> >
> >> Michael
>
> --------------------------------------------------
> Dr. Volker Blum
> Associate Professor of Materials Science and Chemistry
> Duke University, MEMS Department
> Ab Initio Materials Simulations
> http://aims.pratt.duke.edu
>
> Office: 1111 Hudson Hall
> +1-919-660-5279
> volker.blum at duke.edu
>
> Postal:
> Department of Mechanical Engineering and Materials Science
> and Center for Materials Genomics
> Duke University, 144 Hudson Hall, Box 90300
> Durham, NC 27708, USA
> ---key:1-0.0735-11600-23.05:fhi---
More information about the Debichem-devel
mailing list