[Debichem-devel] Elpa-2015.11 interface change

[Volker Blum]

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---