[Debichem-devel] Elpa-2015.11 interface change

Volker Blum blum at fhi-berlin.mpg.de
Mon Nov 23 14:17:49 UTC 2015


Hi Andi,

I agree that this should have been an internal discussion in ELPA. I would also not have questioned the earlier interface changes any further; I understand that they may have been necessary for other reasons. The interface change that prompted my message was the latest change. The release-fix, of course, sounds necessary after the latest change, I did not want to question that.

Best
Volker

On Nov 23, 2015, at 5:41 AM, Andreas Marek <amarek at rzg.mpg.de> wrote:

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

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