Skip to content

Adding package namd#4321

Merged
adamjstewart merged 6 commits intospack:developfrom
epfl-scitas:packages/namd
Jun 14, 2017
Merged

Adding package namd#4321
adamjstewart merged 6 commits intospack:developfrom
epfl-scitas:packages/namd

Conversation

@nrichart
Copy link
Copy Markdown
Contributor

This adds the package for namd. To download the source it uses a login password, but if I got it right anyone can ask for it for non-commercial uses.

I did not test all the possible installation, just gcc with and without tcl/python interfaces and fftw=3,
and intel with intel-mpi and fftw=mkl
In both case with charm backend=mpi

While testing this package for intel tools (compiler, mpi, mkl), I add to tweak the package charm and intel-mpi.

It should be only additions and corrections on the way the backends where checked. @eschnett can you check that I did not break anything in charm ?
For intel-mpi @davydden and @alalazo you are the one that wrote it.

@nrichart nrichart requested review from alalazo, davydden and eschnett May 23, 2017 12:59
)

@property
def mpi_headers(self):
Copy link
Copy Markdown
Member

@davydden davydden May 23, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

supposedly that's how one overrides spec['mpi'].headers which returns HeaderList object which by default looks for * headers and is recursive. Looking for mpi.h in include64 looks ok to me. Hopefully include64 always exists.

# recurse from self.prefix will find too many things for all the
# supported sub-architectures like 'mic'
return find_headers(
'mpi', root='{0}64'.format(self.prefix.include), recurse=False)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Never seen an include64 before, but Intel does some weird things. If you want, you can add it to lib/spack/spack/util/prefix.py so that you can use self.prefix.include64.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I do this I will have to check which mpi it is to now which include to use. This way it is transparent for the dependents to mpi. And is is the equivalent to what is done for mpi_libs
In fact <prefix>/include64 in this case is a symbolic link to <prefix>/linux64/include

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh yes, I'm not suggesting you get rid of mpi_headers, just saying you could replace '{0}64'.format(self.prefix.include) with self.prefix.include64.

high-performance simulation of large biomolecular systems."""

homepage = "http://www.ks.uiuc.edu/Research/namd/"
url = "file://NAMD_2.12_Source.tar.gz"
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this actually work? For most other packages I've used:

url = 'file://{0}/NAMD_2.12_Source.tar.gz'.format(os.getcwd())

This allows Spack to download the file if it is present in the current directory.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does not find it and take it from the mirror. But I can change it so there is no need to add it first to a mirror.

depends_on('fftw@3:', when="fftw=3")

# depends_on('fftw@3:', when="fftw=mkl")
depends_on('intel-mkl', when="fftw=mkl")
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should make fftw a virtual provider.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not totally sure but I think that mkl as a different interface but when you install it you can compile the a part to have the proper interface.
And if we add provide('fftw') the package fftw should be renamed.

description='Enable the use of FFTW/FFTW3/MKL FFT')

variant('interface', default='none', values=('none', 'tcl', 'python'),
description='Enables TCL and/or python interface')
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if this should be a multi-valued variant or not. It wouldn't be hard to have +tcl and +python variants. Multi-valued variants are useful when there are too many possible values to create variants for or if the values are mutually exclusive.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did it because they are kind of exclusive, according to the help of the build script +python enforce +tcl if it is 2 separated variant I have to also add a check because ~tcl+python is not valid.


def build(self, spec, prefix):
with working_dir('{0}-spack'.format(self.arch)):
make()
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you override build_directory, you won't have to do this for every phase:

@property
def build_directory(self):
    return '{0}-spack'.format(self.arch)

@ifelsefi
Copy link
Copy Markdown
Contributor

ifelsefi commented May 27, 2017

Hell yes!!!!

Has anyone started VMD?


def build(self, spec, prefix):
with working_dir(self.build_directory):
make()
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you need to define build anymore as this is the default implementation.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think @adamjstewart is right here.

Copy link
Copy Markdown
Member

@alalazo alalazo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Only a couple very minor comments.

s.sbin = join_path(s, 'sbin')
s.etc = join_path(s, 'etc')
s.include = join_path(s, 'include')
s.include64 = join_path(s, 'include64')
Copy link
Copy Markdown
Member

@alalazo alalazo Jun 1, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OT: I wonder why in this file we have +12/-11 lines diff, while at a first glance it seems you added only one line...

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I kept the alignment of spaces before the =


def build(self, spec, prefix):
with working_dir(self.build_directory):
make()
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think @adamjstewart is right here.

@nrichart
Copy link
Copy Markdown
Contributor Author

ping @adamjstewart

@adamjstewart adamjstewart merged commit f06c23e into spack:develop Jun 14, 2017
nrichart added a commit to epfl-scitas/spack that referenced this pull request Jun 15, 2017
* Initial version of the namd package

* Modified charm to consider compile against intel/intel-mpi

* Correction of namd to compile with intel-mkl and intel compiler

* Adding inclue64 in the prefix

* adding property for the build directory

* removing useless function build
xavierandrade pushed a commit to xavierandrade/spack that referenced this pull request Jun 16, 2017
* Initial version of the namd package

* Modified charm to consider compile against intel/intel-mpi

* Correction of namd to compile with intel-mkl and intel compiler

* Adding inclue64 in the prefix

* adding property for the build directory

* removing useless function build
EmreAtes pushed a commit to EmreAtes/spack that referenced this pull request Jul 10, 2017
* Initial version of the namd package

* Modified charm to consider compile against intel/intel-mpi

* Correction of namd to compile with intel-mkl and intel compiler

* Adding inclue64 in the prefix

* adding property for the build directory

* removing useless function build
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants