Re: [easybuild] Re: Configuring ELPA according to the cpu

2019-01-11 Thread Micael Oliveira

Hi,

 I'm planning on writing a custom easyblock for ELPA precisely to 
tackle this problem, so I guess I'm the person mentioned in Alan's 
email, although I'm still not sure I can attend the EasyBuild user meeting.


 My idea was precisely to use the FFTW easyblock as a starting point.

 Best regards,

Micael

On 1/11/19 3:34 PM, Kenneth Hoste wrote:

Dear Jakob,

I'm not sure there's much EasyBuild can do about this, unless I'm 
missing something.


You can build using different sets of configuration options in a single 
installation, but I don't think that's of much use here.


The best solution indeed seems to be to write an easyblock for ELPA that 
checks which CPU capabilities are supported, and then builds ELPA with 
the appropriate configure options.


We have some of that already in custom easyblocks, see for example the 
FFTW easyblock: 
https://github.com/easybuilders/easybuild-easyblocks/blob/master/easybuild/easyblocks/f/fftw.py#L124 
.


This really is beyond what's possible in an easyconfig file, you need 
custom code to deal with this...


regards,

Kenneth

On 11/01/2019 12:48, Jakob Schiøtz wrote:

Dear all,

I did not get any response to this before Christmas.  Does anybody 
have any ideas that might help me?


Best regards

Jakob


On 18 Dec 2018, at 15:00, Jakob Schiøtz  wrote:

Hi,

I am trying to build the newest version of ELPA (Eigenvalue SoLvers 
for Petaflop-Applications, https://elpa.mpcdf.mpg.de/).  It looks 
like ELPA builds a number of “kernels” that are chosen at runtime 
depending on the capabilities of the CPU, for example SSE, AVX, AVX2 
or AVX512.


Unfortunately, with the foss toolchain the compiler refuses to build 
these kernels if the CPU does not support them (the Intel toolchain 
happily builds them).  This means that I have to configure ELPA with 
--disable-avx2 or --disable-avx if the CPU does not support these 
instructions, and --enable-avx512 if the CPU does support that.


Is there some way to do this easily in an easyconfig?  Maybe a 
compiler flag that allows using “AVX2 gcc intrinsics” in the code, 
without otherwise turning on AVX2 instructions (as that would cause 
the rest of the code to fail if AVX2 is not supported).


Or do I have to write some complicated stuff into an easyblock?  And 
if I do the latter, do you know how to portably detect the 
capabilities of the CPU?


It seems somewhat silly that the ELPA configure script tests if these 
instructions are supported and fails if one does not manually disable 
the unsupported versions instead of just doing the right thing.  But 
that is beyond my control.


Best regards

Jakob

--
Jakob Schiøtz, professor, Ph.D.
Department of Physics
Technical University of Denmark
DK-2800 Kongens Lyngby, Denmark
http://www.fysik.dtu.dk/~schiotz/





--
Jakob Schiøtz, professor, Ph.D.
Department of Physics
Technical University of Denmark
DK-2800 Kongens Lyngby, Denmark
http://www.fysik.dtu.dk/~schiotz/







Re: [easybuild] Re: Configuring ELPA according to the cpu

2019-01-12 Thread Micael Oliveira

Hi Jakob,

 I'm going to try working on this this week. I'll let you know once 
there is a PR.


 Micael

On 1/12/19 8:17 AM, Jakob Schiøtz wrote:

Hi Michael,

That would indeed be great.  Let us keep in touch, so we don’t do it both :-)

Jakob


On 11 Jan 2019, at 16:19, Micael Oliveira  wrote:

Hi,

I'm planning on writing a custom easyblock for ELPA precisely to tackle this 
problem, so I guess I'm the person mentioned in Alan's email, although I'm 
still not sure I can attend the EasyBuild user meeting.

My idea was precisely to use the FFTW easyblock as a starting point.

Best regards,

Micael

On 1/11/19 3:34 PM, Kenneth Hoste wrote:

Dear Jakob,
I'm not sure there's much EasyBuild can do about this, unless I'm missing 
something.
You can build using different sets of configuration options in a single 
installation, but I don't think that's of much use here.
The best solution indeed seems to be to write an easyblock for ELPA that checks 
which CPU capabilities are supported, and then builds ELPA with the appropriate 
configure options.
We have some of that already in custom easyblocks, see for example the FFTW 
easyblock: 
https://github.com/easybuilders/easybuild-easyblocks/blob/master/easybuild/easyblocks/f/fftw.py#L124
 .
This really is beyond what's possible in an easyconfig file, you need custom 
code to deal with this...
regards,
Kenneth
On 11/01/2019 12:48, Jakob Schiøtz wrote:

Dear all,

I did not get any response to this before Christmas.  Does anybody have any 
ideas that might help me?

Best regards

Jakob


On 18 Dec 2018, at 15:00, Jakob Schiøtz  wrote:

Hi,

I am trying to build the newest version of ELPA (Eigenvalue SoLvers for 
Petaflop-Applications, https://elpa.mpcdf.mpg.de/).  It looks like ELPA builds 
a number of “kernels” that are chosen at runtime depending on the capabilities 
of the CPU, for example SSE, AVX, AVX2 or AVX512.

Unfortunately, with the foss toolchain the compiler refuses to build these 
kernels if the CPU does not support them (the Intel toolchain happily builds 
them).  This means that I have to configure ELPA with --disable-avx2 or 
--disable-avx if the CPU does not support these instructions, and 
--enable-avx512 if the CPU does support that.

Is there some way to do this easily in an easyconfig?  Maybe a compiler flag 
that allows using “AVX2 gcc intrinsics” in the code, without otherwise turning 
on AVX2 instructions (as that would cause the rest of the code to fail if AVX2 
is not supported).

Or do I have to write some complicated stuff into an easyblock?  And if I do 
the latter, do you know how to portably detect the capabilities of the CPU?

It seems somewhat silly that the ELPA configure script tests if these 
instructions are supported and fails if one does not manually disable the 
unsupported versions instead of just doing the right thing.  But that is beyond 
my control.

Best regards

Jakob

--
Jakob Schiøtz, professor, Ph.D.
Department of Physics
Technical University of Denmark
DK-2800 Kongens Lyngby, Denmark
http://www.fysik.dtu.dk/~schiotz/





--
Jakob Schiøtz, professor, Ph.D.
Department of Physics
Technical University of Denmark
DK-2800 Kongens Lyngby, Denmark
http://www.fysik.dtu.dk/~schiotz/





--
Jakob Schiøtz, professor, Ph.D.
Department of Physics
Technical University of Denmark
DK-2800 Kongens Lyngby, Denmark
http://www.fysik.dtu.dk/~schiotz/





Re: [easybuild] libxc-5.2.3-GCC-11.3.0.eb: Download incomplete

2023-03-28 Thread Micael Oliveira

Hi,

 The issue with the Libxc downloads should now be fixed. Unfortunately 
it took some time to track down a weird issue with the web server. Sorry 
for the inconvenience.


 Cheers,

Micael

On 28/3/23 22:18, Ole Holm Nielsen wrote:

External Email


Hi Loris,

It would be great if you could make a PR against libxc!  I'm not that
experienced with Git usage ;-)

Thanks,
Ole

On 3/28/23 13:03, Loris Bennett wrote:

Hi Ole,

Ole Holm Nielsen  writes:


Hi Loris,

I'm being hit by that libxc download problem too!  It's very bad for
the modules that we're trying to build :-(

Should EB use this download URL in stead?
https://gitlab.com/libxc/libxc/-/archive/5.2.3/libxc-5.2.3.tar.gz


Yes, I think it probably should, since, as far as I can tell, this is
probably the canonical version.  Have you already got a patched EC you
could use for a pull request, or shall I created one?

Cheers,

Loris


Thanks,
Ole

On 3/28/23 11:41, Loris Bennett wrote:

The EC libxc-5.2.3-GCC-11.3.0.eb downloads the sources from
    https://www.tddft.org/programs/libxc
However, the site seems to be having issues such that the download
gets
interrupted before it is complete.  There are other places to get the
sources from, i.e.
    https://gitlab.com/libxc/libxc
and
    https://github.com/ElectronicStructureLibrary/libxc
but the checksums for the version 5.2.3 are different in these two
cases
and both different from the checksum in the EC (the Github version is
supposed to be a mirror of the Gitlab version).
What should happen here?  Should I wait and hope that www.tddft.org
stops being so flaky, or should the EC (or at least the next version
thereof) be changed to use Gitlab as the source, since this now 
seems to

be the place were development occurs?