Re: [easybuild] Is there a way to discover which toolchains are currently installed and what modules they comprise of ?

[Maxime Boissonneault]

In any case: Maxime, please open a feature request to support this 
more easily via --list-toolchains or some derivative.



Done here:

https://github.com/hpcugent/easybuild-framework/issues/2118


Maxime

Re: [easybuild] Is there a way to discover which toolchains are currently installed and what modules they comprise of ?

[Kenneth Hoste]

Hi Maxime,

On 14/02/2017 20:27, Maxime Boissonneault wrote:

On 17-02-14 14:13, Kenneth Hoste wrote:

On 06/02/2017 17:58, Maxime Boissonneault wrote:

Hi all,

Is there a way for easybuild to tell me what are the toolchains 
which it currently sees as installed on the system ?


Note that we have a custom naming scheme, and that we hide 
toolchains to users.


Well, there are several options, although none of them are probably 
the answer you are looking for.


EasyBuild will symlink modules back to modules/all based on the 
moduleclass, so (at least with the default module naming scheme) you 
could use something like:


find $EASYBUILD_PREFIX/modules/toolchain | sed 's@.*/\(.*/.*\)@\1@g'


We don't have a modules/toolchain folder.
Another way is to compose a list of all toolchain easyconfigs, and 
then use "eb -D  | grep '\[x\]' ".
Although that would also include all toolchain components (and their 
dependencies).



Maybe it helps if you provide some more context?
Why do you need this exactly?

I want to be able to tell our staff what are the toolchains (and 
sub-toolchains) they can install a software with without having to 
install a new toolchain. With the toolchain components, it becomes a 
pretty long list pretty quickly.


For example, we currently have:
*

The following toolchains are currently available to use:

 *

Core toolchain:

 o

dummy,dummy : “Core” uses only components provided by Nix (GCC
5.4.0)

 *

Compiler only toolchains:

 o

iccifort,2016.4.258

 o

iccifort,2017.1.132

 o

GCC,4.8.5

 o

GCC,5.4.0

 *

Compiler + MKL toolchains:

 o

iimkl,2016.4 : (Intel 2016.4 + MKL)

 o

iimkl,2017a : (Intel 2017 + MKL)

 *

Compiler + MPI toolchains:

 o

iompi,2016.4 (Intel compiler 2016.4, OpenMPI 2.0.2)

 o

iompi,2017a (Intel compiler 2017, OpenMPI 2.0.2)

 o

gompi,2017a (GCC Compiler 5.4.0, OpenMPI 2.0.2)

 *

Compiler + MPI + MKL toolchains:

 o

iomkl,2016.4 : (Intel 2016.4, OpenMPI 2.0.2, MKL)

  o iomkl,2017a : (Intel 2017, OpenMPI 2.0.2, MKL)

*
and the list will keep growing.


The proper way would be making --list-toolchains a bit more intelligent, 
and maybe support the notion of --list-available-toolchains or something 
like that.


For now, this seems to be doing what you're after:

module avail $(eb --list-toolchains | grep -v "List of known" | cut 
-f1 -d: | sed 's@$@/@g' | tr '\n' ' ')


i.e.:

i) obtain a list of known toolchain names via --list-toolchains
ii) make sure to append a / after each name
iii) check which modules are available for those toolchains


I'm not sure whether this will work for you since you're hiding 
toolchains from users. Maybe "module avail --show-hidden" suffices?



In any case: Maxime, please open a feature request to support this more 
easily via --list-toolchains or some derivative.



regards,

Kenneth

Re: [easybuild] Is there a way to discover which toolchains are currently installed and what modules they comprise of ?

[Maxime Boissonneault]

On 17-02-14 14:13, Kenneth Hoste wrote:

On 06/02/2017 17:58, Maxime Boissonneault wrote:

Hi all,

Is there a way for easybuild to tell me what are the toolchains which 
it currently sees as installed on the system ?


Note that we have a custom naming scheme, and that we hide toolchains 
to users.


Well, there are several options, although none of them are probably 
the answer you are looking for.


EasyBuild will symlink modules back to modules/all based on the 
moduleclass, so (at least with the default module naming scheme) you 
could use something like:


find $EASYBUILD_PREFIX/modules/toolchain | sed 's@.*/\(.*/.*\)@\1@g'


We don't have a modules/toolchain folder.
Another way is to compose a list of all toolchain easyconfigs, and 
then use "eb -D  | grep '\[x\]' ".
Although that would also include all toolchain components (and their 
dependencies).



Maybe it helps if you provide some more context?
Why do you need this exactly?

I want to be able to tell our staff what are the toolchains (and 
sub-toolchains) they can install a software with without having to 
install a new toolchain. With the toolchain components, it becomes a 
pretty long list pretty quickly.


For example, we currently have:
*

The following toolchains are currently available to use:

 *

   Core toolchain:

 o

   dummy,dummy : “Core” uses only components provided by Nix (GCC
   5.4.0)

 *

   Compiler only toolchains:

 o

   iccifort,2016.4.258

 o

   iccifort,2017.1.132

 o

   GCC,4.8.5

 o

   GCC,5.4.0

 *

   Compiler + MKL toolchains:

 o

   iimkl,2016.4 : (Intel 2016.4 + MKL)

 o

   iimkl,2017a : (Intel 2017 + MKL)

 *

   Compiler + MPI toolchains:

 o

   iompi,2016.4 (Intel compiler 2016.4, OpenMPI 2.0.2)

 o

   iompi,2017a (Intel compiler 2017, OpenMPI 2.0.2)

 o

   gompi,2017a (GCC Compiler 5.4.0, OpenMPI 2.0.2)

 *

   Compiler + MPI + MKL toolchains:

 o

   iomkl,2016.4 : (Intel 2016.4, OpenMPI 2.0.2, MKL)

 o iomkl,2017a : (Intel 2017, OpenMPI 2.0.2, MKL)

*
and the list will keep growing.

Maxime

Re: [easybuild] configure: error: cannot run C compiled programs.

[Kenneth Hoste]

On 30/01/2017 16:03, Satish Sherikar wrote:

Hi,

I dont understand where it is coming from. I have manually configured 
HDF5 with same command as used by easybuild while configuration. But 
at this time it ran successfully. By using eb command only it is 
giving me an error.


If you required any other data i'll provide you.


Try running the 'eb' command you're using with '-x'. The resulting 
output will include a set of commands to define the build environment as 
it is set up by EasyBuild.

Maybe something in there is messing up the build?



I have attached config.log of manual configuration with same 
configuration command.


The config.log you provided doesn't seem to be the correct one; that 
configure command exited with exit status 0, and there was no mention of 
libbat.so at all.


And can you please provide me how to create my own/dummy toolchain for 
this cluster. ( Preffered intel toolchain)


There's (outdated) documentation available at 
https://github.com/hpcugent/easybuild/wiki/Compiler-toolchains, but you 
should reconsider this probably.


It's recommended to use a toolchain that is commonly used in the 
community, see for example 
http://easybuild.readthedocs.io/en/latest/Common-toolchains.html.


It seems like you also want to just use readily available 
compilers/libraries rather than installing the toolchain itself using 
EasyBuild?



regards,

Kenneth



Regards,
Satish

On Mon, Jan 30, 2017 at 6:19 PM, Robert Schmidt > wrote:


libbat.so is part of LSF. It is probably included somewhere in the
environment. It is pretty "messy" so perhaps there is an
LD_LIBRARY_PATH that was set before easybuild took over that
normally handled making sure it is available?

On Mon, Jan 30, 2017 at 7:48 AM Ward Poelmans > wrote:

Hi Satish,

On Mon, Jan 30, 2017 at 1:36 PM, Satish Sherikar
> wrote:
> Hi Ward,
>
> I have attached config.log for HDF5.
>
> We are using mpiicc, mpiifort and mpiif90 in our cluster.
But it is taking
> FC=mpif90.
>
> I didnt understand how to change all these.

You are building HDF5 with the `goolf` toolchain. This
combines GCC
with OpenMPI and that's the reason why EB is using mpif90.

If you want to use the intel compilers, you must use the `intel`
toolchain. I see both have it in your PATH already. EB cannot
use this
directly: it wants a intel installation done by EB itself.


The HDF5 configure scripts fails because of:
configure:4476: mpicc -o conftest  -O2 -march=native -fPIC

-I/gpfs1/home/ibm/.local/easybuild/software/OpenBLAS/0.2.6-gompi-1.4.10-LAPACK-3.4.2/include

-I/gpfs1/home/ibm/.local/easybuild/software/ScaLAPACK/2.0.2-gompi-1.4.10-OpenBLAS-0.2
.6-LAPACK-3.4.2/include

-I/gpfs1/home/ibm/.local/easybuild/software/FFTW/3.3.3-gompi-1.4.10/include

-I/gpfs1/home/ibm/.local/easybuild/software/zlib/1.2.7-goolf-1.4.10/include
-I/gpfs1/home/ibm/.local/easybuild/software/Szip/2.1-goolf-1.4
.10/include 
-L/gpfs1/home/ibm/.local/easybuild/software/GCC/4.7.2/lib64

-L/gpfs1/home/ibm/.local/easybuild/software/GCC/4.7.2/lib

-L/gpfs1/home/ibm/.local/easybuild/software/OpenBLAS/0.2.6-gompi-1.4.10-LAPACK-3.4.2/lib
-L/gpfs1/home/ibm/

.local/easybuild/software/ScaLAPACK/2.0.2-gompi-1.4.10-OpenBLAS-0.2.6-LAPACK-3.4.2/lib
-L/gpfs1/home/ibm/.local/easybuild/software/FFTW/3.3.3-gompi-1.4.10/lib
-L/gpfs1/home/ibm/.local/easybuild/software/zlib/1.2.7-goolf-1.4.10/lib
-L/gpfs
1/home/ibm/.local/easybuild/software/Szip/2.1-goolf-1.4.10/lib
conftest.c -lm -lpthread >&5
configure:4480: $? = 0
configure:4487: ./conftest
./conftest: error while loading shared libraries: libbat.so:
cannot
open shared object file: No such file or directory


I've never heard of `libbat.so` and it doesn't get linked in.
Any idea
where it comes from?

Ward

Re: [easybuild] Is there a way to discover which toolchains are currently installed and what modules they comprise of ?

[Kenneth Hoste]

On 06/02/2017 17:58, Maxime Boissonneault wrote:

Hi all,

Is there a way for easybuild to tell me what are the toolchains which 
it currently sees as installed on the system ?


Note that we have a custom naming scheme, and that we hide toolchains 
to users.


Well, there are several options, although none of them are probably the 
answer you are looking for.


EasyBuild will symlink modules back to modules/all based on the 
moduleclass, so (at least with the default module naming scheme) you 
could use something like:


find $EASYBUILD_PREFIX/modules/toolchain | sed 's@.*/\(.*/.*\)@\1@g'

Another way is to compose a list of all toolchain easyconfigs, and then 
use "eb -D  | grep '\[x\]' ".
Although that would also include all toolchain components (and their 
dependencies).



Maybe it helps if you provide some more context?
Why do you need this exactly?


regards,

Kenneth

Re: [easybuild] Extended package documentation

[Kenneth Hoste]

Hi Markus,

On 10/02/2017 16:40, Markus Geimer wrote:

Hi all,

Following up on my proposal for extended package documentation options
sent to the list recently [1], I have a question to the community.
During the hackathon part of the User Group Meeting, I implemented the
proposal (cfr. [2]) for `module help`.  Now, the question came up
which of the information should also be included in the `whatis`
output and how.  Would something in key/value style, like

 Description: Bla bla
 Usage: More bla
 Homepage: http://foo.org
 Documentation: $EBROOTFOO/some/path
 Documentation: http://some.url
 Support: supp...@foo.org
 Contact: Jim Admin
 Contact: Jane Admin
 Extensions: ext1-0.1, ext2-42.7

work for the community?

Looking forward to your feedback.


I feel this sort of terse key/value style could be useful, but only for 
single-line info (e.g. homepage, contact, etc.).


For things like 'description' and 'usage', I'm not sure this would be 
useful or sensible.


So, maybe what you're looking for is some hybrid approach, where aspects 
like 'description' and 'usage' (and 'examples') are properly fleshed out 
sections, where all the other info is packed together in an easy to 
digest (for machines) form, like the key-value style you showed.


In an ideal world, we would have a sensible default output format, and 
you would support the necessary knobs and dials to tweak the output to 
your liking.
We briefly discussed this with the 'module template' idea, but I suspect 
this may be a lot of (tedious) work...



K.



Markus


[1] https://www.mail-archive.com/easybuild@lists.ugent.be/msg03050.html
[2] https://github.com/hpcugent/easybuild-framework/pull/2113

--
Dr. Markus Geimer
Juelich Supercomputing Centre
Institute for Advanced Simulation
Forschungszentrum Juelich GmbH
52425 Juelich, Germany

Phone:  +49-2461-61-1773
Fax:+49-2461-61-6656
E-Mail: m.gei...@fz-juelich.de
WWW:http://www.fz-juelich.de/jsc




Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt

Re: [easybuild] Clang failed test

[Kenneth Hoste]

Hi Danilo,

On 14/02/2017 16:01, Danilo Guerrera wrote:

Dear list,

I tried to install a Clang-3.4-GCC-4.9.3-2.25 (I need to install a 
software that relies on that particular version of Clang). It resulted 
in an error while making the test (the Clang test that 
takes place after every phase, not the sanity checking). A partial log 
of the error can be found here:

http://pastebin.com/qVZFPTDp

I tried locally and everything works. It just fails when installing on 
NFS.


Googling a little bit I found an issue with a previous Clang version 
and EB:

https://github.com/hpcugent/easybuild-easyconfigs/issues/466

We do not use noatime, and we have a bind mount. So all the 
things/possible solutions discussed in that issue do not work for us.


Interestingly, the only other info related to this error comes from a 
clang developers mailing list:

http://clang-developers.42468.n3.nabble.com/3-7-Release-RC1-has-been-tagged-Testing-Phase-I-begins-td4046646i20.html#a4046725
There you find this comment:
“clang+llvm-3.7.0-rc1-mipsel-linux-gnu.tar.xz
Failing Tests (4):
AddressSanitizer-mipsel-linux :: 
TestCases/Linux/kernel-area.cc 
Clang :: Modules/prune.m <- expected since this system uses an 
NFS mount with noatime.”


But again, we do not use noatime.

Any idea? Is there a way to let EB skip that “error”?


In the past, we have disabled individual quirky tests for Clang with a 
patch, see for example 
https://github.com/hpcugent/easybuild-easyconfigs/blob/master/easybuild/easyconfigs/c/Clang/Clang-3.4-failing-sanitizer-tests.patch 
.


Maybe that's a reasonable way out?


regards,

Kenneth

Re: [easybuild] building mxnet

[Kenneth Hoste]

Hi Jurij,

On 06/02/2017 14:55, Jure Pečar wrote:

On Sat, 28 Jan 2017 17:43:42 +0100
Kenneth Hoste  wrote:


If there are releases available for each of the submodules, you can make
EB pulls those in, and then you could reassemble things in the build dir
using symlinks via 'preconfigopts' for example in the easyconfig?

That would be one way to automate this while retaining control over
which sources are actually used...
  
Interesting idea. Will play with it when I get some time.
  

You could just get that R library built via the extensions mechanism in
EasyBuild, and just make it part of the same installation?

I'm exploring this now ... and have a bit of a chicken-and-egg issue.

If you check mxnet docs at 
http://mxnet.io/get_started/ubuntu_setup.html#install-the-mxnet-package-for-r
you'll see that the steps to install the R-package of mxnet are:
* build mxnet
* Rscript install_deps (which installs about 11 additional R packages beside 
the ones listed in R eb)
* make rpkg (which installs mxnet R package and only then creates a tarball ... 
and tarball is created by R from mxnet:::mxnet.export ... grrr)
* at that point I have a tarball that I can push to sources dir and use as a 
source of R extension

I don't see how I could simply map this to existing easybuild facilities.

Maybe I can tear apart the "make rpkg" thing and try to reimplement it in .eb 
file ... But still I have to get those required R packages installed first. Any 
suggestions?

Maybe we can discuss this on Thursday ...


Balázs (who is now also subscribed to this list) was working on mxnet 
during the hackathon, maybe he has some useful information on this...



regards,

Kenneth

[easybuild] Clang failed test

[Danilo Guerrera]

Dear list,

I tried to install a Clang-3.4-GCC-4.9.3-2.25 (I need to install a software 
that relies on that particular version of Clang). It resulted in an error while 
making the test (the Clang test that takes place after every phase, not the 
sanity checking). A partial log of the error can be found here:
http://pastebin.com/qVZFPTDp

I tried locally and everything works. It just fails when installing on NFS.

Googling a little bit I found an issue with a previous Clang version and EB:
https://github.com/hpcugent/easybuild-easyconfigs/issues/466

We do not use noatime, and we have a bind mount. So all the things/possible 
solutions discussed in that issue do not work for us.

Interestingly, the only other info related to this error comes from a clang 
developers mailing list:
http://clang-developers.42468.n3.nabble.com/3-7-Release-RC1-has-been-tagged-Testing-Phase-I-begins-td4046646i20.html#a4046725
There you find this comment:
“clang+llvm-3.7.0-rc1-mipsel-linux-gnu.tar.xz
Failing Tests (4):
AddressSanitizer-mipsel-linux :: 
TestCases/Linux/kernel-area.cc
Clang :: Modules/prune.m <- expected since this system uses an NFS 
mount with noatime.”

But again, we do not use noatime.

Any idea? Is there a way to let EB skip that “error”?

Danilo

Departement Mathematik & Informatik
High Performance and Web Computing Group
Universität Basel
Spiegelgasse 1
CH-4051 Basel Switzerland
email: danilo.guerr...@unibas.ch
Phone:+41 (0)61 207 14 73
IEEE Student Member 94015916
ACM Student Member 2185920
https://ch.linkedin.com/in/daniloguerrera

Re: [easybuild] Intel v16 vs RHEL 7.3 (was: [ANN] EasyBuild v3.1.0)

[Kenneth Hoste]

Hi Joachim,

On 03/02/2017 15:59, Joachim Hein wrote:

Hi Kenneth,

Cool, congratulations on getting this out.   From the discussions on this list 
(and the meeting minutes) I figured that the Intel 16 RHEL 7.3 issues is (about 
to be) resolved.  I was expecting a mention here in the “EB 3.1 release email”. 
 Can you elaborate?  Do I just rebuild my Intel 2016a/b toolchains or do I (an 
my users) need to recompile all applications build against this?  Is there any 
“official EB statement/instructions”?

Thanks and have a nice weekend - you deserve it (so answer on Monday is fine ;) 
)


It's Monday, but maybe not the one you had in mind. ;-)
Last week was crazy busy with FOSDEM and the EasyBuild User Meeting, I'm 
slowly regaining control of my inbox again now...


EasyBuild v3.1.0 does not include a fix for the Intel v16 vs RHEL 7.3 
problem out of the box, and I'm not sure it should (although I'm open to 
feedback here).


The official workaround is posted at 
https://software.intel.com/en-us/articles/intel-compiler-version-16-not-compatible-with-recent-libcso6, 
which boils down to copying the broken library from a newer version of 
the Intel compilers.



regards,

Kenneth



Best wishes
Joachim


  

On 3 Feb 2017, at 15:37, Kenneth Hoste  wrote:

Dear EasyBuilders,

I'm happy to announce the release of EasyBuild version 3.1.0 [1].
I'm not going to say this is the best EasyBuild release ever this time. Or 
maybe I will. This is the best EasyBuild release ever.

This is a feature release, which includes:

* support for --check-style to check 'code' style in easyconfig files (more 
on that later...)

* architecture-specific optimization flags can now be specified on a 
per-compiler basis via --optarch
* see 
http://easybuild.readthedocs.io/en/latest/Controlling_compiler_optimization_flags.html

* improved toolchain support on ARM and POWER systems

* a custom easyblock for FFTW that maximizes use of processor features (by 
default)

* updates to the CP2K and WPS easyblocks for the latest versions

* toolchain definitions for the foss/2017a and intel/2017a common toolchains
* see http://easybuild.readthedocs.io/en/latest/Common-toolchains.html 
for more informatio

* support for 16 new software packages, incl. QIIME (via conda) and 
Tensorflow


This brings the total number of supported software packages to 1,152 [2]!
A detailed overview of all changes is available in the release notes [3].


Thanks to everyone who contributed to this release in one way or another!


To upgrade to EasyBuild v3.1.0, there are several options, see [4].
Two particularly easy options include:

* eb --install-latest-eb-release  # requires EasyBuild v2.9.0

* eb --from-pr 4100   # use easyconfig from PR #4100 [5]



Enjoy!

regards,

Kenneth (a.k.a. boegel)
EasyBuild release manager


[1] https://pypi.python.org/pypi/easybuild/3.1.0
[2] 
http://easybuild.readthedocs.io/en/latest/version-specific/Supported_software.html
[3] http://easybuild.readthedocs.io/en/latest/Release_notes.html
[4] 
http://easybuild.readthedocs.io/en/latest/Installation.html#updating-an-existing-easybuild-installation
[5] https://github.com/hpcugent/easybuild-easyconfigs/pull/4100/files

Re: [easybuild] Extended package documentation

[Inge Gutheil]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,
perhaps one more suggestion:
Examples:

Is there a way to make the module command show different parts of this
depending on whether you say
module spider
or module help?
And for
module spider
Is there a chance that
module spider blabla foe examples only shows which versions of blabla
are available whereas
module spider blabla1.2 shows additional information for version 1.2?
Usually it is a too much information if
module spider blabla
not only shows what blabla is and which versions are avaialble but
also the complete description of one of the versions. I even do not
know how the version is chosen.
Inge Gutheil

On 02/10/17 16:40, Markus Geimer wrote:
> Hi all,
>
> Following up on my proposal for extended package documentation
> options sent to the list recently [1], I have a question to the
> community. During the hackathon part of the User Group Meeting, I
> implemented the proposal (cfr. [2]) for `module help`.  Now, the
> question came up which of the information should also be included
> in the `whatis` output and how.  Would something in key/value
> style, like
>
> Description: Bla bla Usage: More bla Homepage: http://foo.org
> Documentation: $EBROOTFOO/some/path Documentation: http://some.url
> Support: supp...@foo.org Contact: Jim Admin Contact: Jane Admin
> Extensions: ext1-0.1, ext2-42.7
>
> work for the community?
>
> Looking forward to your feedback.
>
> Markus
>
>
> [1]
> https://www.mail-archive.com/easybuild@lists.ugent.be/msg03050.html
>
>
[2] https://github.com/hpcugent/easybuild-framework/pull/2113
>
> -- Dr. Markus Geimer Juelich Supercomputing Centre Institute for
> Advanced Simulation Forschungszentrum Juelich GmbH 52425 Juelich,
> Germany
>
> Phone:  +49-2461-61-1773 Fax:+49-2461-61-6656 E-Mail:
> m.gei...@fz-juelich.de WWW:http://www.fz-juelich.de/jsc
>
>
> 
>
>
-

> Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft:
> Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr.
> HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen
> Huthmacher Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt
> (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof.
> Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt
> 
>
>
-

>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJYosc2AAoJEAMTTHwPbmtK+gkP/jgDtFpxmJ66/Me3qxyLlPA+
Bl8SaDw1Uf1n3OmwHc+fisiojtj5nXPfcNPgpz5XJT/UomJiz8gqntVsPgugF/PI
X42E9WPMnfe/vpJy+1FaoFnVQkblN/2hctKTBmlrkbChZrdRDcbuHKt47HfAwrds
85+3TtnIrQzT6yqJhfiD/e46mihtxDDXlDVJyIeTKSccV0CgEgAqNyjg6x2T0+pO
b3Apz3w+j5LM12UoT6A3Uxhwrn2SJthOfZEdjVc+uUWol62ti2mCjJgv1kW5p6+G
/3RXIfiKJFpZCPCr4pTFBDYM0cjYTwhLqoDC58h24fUazcEIBgWirIbFU9SVMbSX
lB+vBqmeGr16b+BuyXj+1J8TUw0ZUqT1E/a5CLr3XfTHXuEDVEAFlVGmXk3Nt/ee
vAvfDnP+dswadWLZpgWYpK/+FYCT3G8DXOmsQ+5pMBMJTHIwdmijCeZxBgSG/u6I
aNwqH/8ZVF6p24K/y9IAIYvum5zPxjcOpc+8WWFY4xHg4Nsj2eUmoJtlcaQgH8LT
zcY9L16Oz9p4Jv23QjXE2qc2HOcXfMh5BxCXLMKYeIy8h3YZ+XWSjlx9NBnktEvO
7deITf/rIz3zrQ63yWobXvty8s/Q3nxTWRYjb+rlIK6av8VDQrvfiNQGqTfta26D
dv7NV4faG29VBdqe22/Y
=QSSP
-END PGP SIGNATURE-




Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt