[Q-e-developers] qe package

Nicola Marzari nicola.marzari at epfl.ch
Thu Aug 18 22:21:23 CEST 2016



Dear all,

many times these codes are installed centrally once for all
by a sysad, and users are discouraged to run/compile independently
their own executables - a good policy, if you think.

Noone suggested an even more baroque set up - my desire was to simplify
things, and I am convinced a single file or a single script
that installs everything would benefit everyone. The argument that it
costs more to download seems just too hard to take - I'm happy to provide
free mirrors where everyone is redirected to at download time.


				nicola





On 18/08/2016 22:05, Layla Martin-Samos wrote:
> Dear all, I agree with Stefano. The present mechanism is simple and only
> thinks that are very general and very core (PW, Modules, install) are
> downloaded. Making a distinction between core , second shell, third
> shell, half shell, made at somewhere or elsewhere ...  may be even more
> confusing, and maybe will bring some issues. Moreover, some 'core' (lets
> call it 'historical') are very specific (like neb) and used only in
> particular applications, why to download them by default? at the moment
> if a user wants to use neb, he only needs to type make neb, and that's
> all, like for the other 'packages' irrespectively of who, how, when, why
> and what. boh!
>
> cheers
>
> Layla
>
>
> 2016-08-18 11:20 GMT+02:00 Stefano Baroni <baroni at sissa.it
> <mailto:baroni at sissa.it>>:
>
>     Possiamo graduare la distinzione fra pacchetti “core” e gli altri
>     (ad esempio distribuendo per default neb.x, ph.x, e pochi altri), ma
>     secondo me il meccanismo attuale va mantenuto. SB
>
>>     On 18 Aug 2016, at 11:13, Filippo Spiga
>>     <filippo.spiga at quantum-espresso.org
>>     <mailto:filippo.spiga at quantum-espresso.org>> wrote:
>>
>>     I am *PERSONALLY* aligned with Nicola's way of thinking. A single
>>     package would simplify a lot, including the perception to the
>>     public about what QE is and what is part of QE distribution. We
>>     can continue to have third-part packages following this
>>     "on-demand" model (West? EPW? SaX?) but NEB, PH, TDDFT and others
>>     packages that exist since ages can be collected under the same
>>     umbrella.
>>
>>     I have always believed that the reason we had many packages is to
>>     avoid a monolithic heavy distribution. Based on what I see, the
>>     core source code is not "that big" in size.
>>
>>     I personally see some beauty and some practicality in changing the
>>     packaging process. The 6.0 will continue to follow the current
>>     process unless the majority of contributors agree differently. But
>>     because 6.0 is going to introduce already some new stuff, I
>>     personally think this is a good time to review the packaging
>>     process as well.
>>
>>     Just my 2 cents ...
>>
>>     On 18 Aug 2016, at 09:51, Stefano Baroni <baroni at sissa.it
>>     <mailto:baroni at sissa.it>> wrote:
>>>     Then we have simply to beat the drum by claiming that our
>>>     “virtual” (or whatever fancy adjective you may find) distribution
>>>     model is “innovative” and much better than the old-fashioned tar
>>>     balls … SB
>>
>>     --
>>     Filippo SPIGA
>>     * Sent from my iPhone, sorry for typos *
>
>
>     _______________________________________________
>     Q-e-developers mailing list
>     Q-e-developers at qe-forge.org <mailto:Q-e-developers at qe-forge.org>
>     http://qe-forge.org/mailman/listinfo/q-e-developers
>     <http://qe-forge.org/mailman/listinfo/q-e-developers>
>
>
>
>
> _______________________________________________
> Q-e-developers mailing list
> Q-e-developers at qe-forge.org
> http://qe-forge.org/mailman/listinfo/q-e-developers
>

-- 
----------------------------------------------------------------------
Prof Nicola Marzari, Chair of Theory and Simulation of Materials, EPFL
Director, National Centre for Competence in Research NCCR MARVEL, EPFL
http://theossrv1.epfl.ch/Main/Contact http://nccr-marvel.ch/en/project



More information about the developers mailing list