Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

{chem,lib}[intel/2018b] GlobalArrays v5.7, OpenMolcas v18.09 #7699

Merged

Conversation

arielzn
Copy link
Contributor

@arielzn arielzn commented Feb 20, 2019

(created using eb --new-pr)

@Micket
Copy link
Contributor

Micket commented Feb 21, 2019

Did you specifically need a ethernet version? Seems like some version of --with-mpi* would be more useful?

I tried building GA a while back, but I used it's CMake component. I ended up with a libcomex.a library, without specifying any particular flags for this.

@arielzn
Copy link
Contributor Author

arielzn commented Feb 21, 2019

just tested, without any armci related options, it defaults to this

--with-mpi-ts select armci network as (Comex) MPI-1 two-sided

and effectively there's a libcomex.a built

that provides an interface with the used MPI library? dropping the interconnect specification at the GA level ?

@easybuilders easybuilders deleted a comment from boegelbot Feb 23, 2019
@boegel boegel added the update label Feb 23, 2019
@boegel boegel added this to the 3.x milestone Feb 23, 2019
@arielzn
Copy link
Contributor Author

arielzn commented Feb 25, 2019

@Micket I upgraded the ebs by using --with-mpi-ts for GA, OpenMolcas is built fine on it, and a test job I was provided runs fine in an infiniband and another ethernet cluster.

@arielzn
Copy link
Contributor Author

arielzn commented Mar 12, 2019

@Micket I created the patches for GA based on the pull requests upstream you mentioned,
GlobalArrays/ga#101
and
GlobalArrays/ga#122

I added another small patch for OpenMolcas, as one script triggered during the installation, will try to force a copy of the pymolcas executable in some place on the local home folder of the user doing the install.
That's quite weird anyway, as the make install already takes care of installing it in the prefix folder, which is where it should stay in our case.
I don't get why they force that extra copy, the patch avoids that.

The build of both things goes on fine, and a small test job i was given runs fine.

@arielzn
Copy link
Contributor Author

arielzn commented Mar 12, 2019

i don't get why i got only this time the error during Travis Checks

AssertionError: '-Python-%(pyver)s' included in versionsuffix in OpenMolcas-18.09-intel-2018b.eb

despite the dep was always there before.

fixed in latest commit.

@boegel
Copy link
Member

boegel commented Mar 12, 2019

@arielzn We enhance the checks done in Travis from time to time, and for some things we only enforce them in easyconfigs being added/touched.
For this particular check, see https://github.com/easybuilders/easybuild-easyconfigs/pull/7754/files .

boegel
boegel previously requested changes Mar 12, 2019
Copy link
Member

@boegel boegel left a comment

Choose a reason for hiding this comment

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

@arielzn Please add a short description + mention author or upstream reference to where patch was obtained from at the top of every patch (and keep in mind that you'll need to update the checksums for the patch files accordingly)

@arielzn
Copy link
Contributor Author

arielzn commented Jul 22, 2019

@Micket that was what you requested , right ?
adding the options and updating this PR to force checks ?

@Micket
Copy link
Contributor

Micket commented Jul 22, 2019

@arielzn I got really busy last week. If you could do a eb --upload-test-report --from-pr 7699 --rebuild that would be great (I would do it myself, but my 2018b tree is a bit broken from some earlier experiments with python).

@arielzn
Copy link
Contributor Author

arielzn commented Jul 22, 2019

some bad news, when enabling those options for GA, I get errors when building OpenMolcas afterwards (GA finished fine).

The OpenMolcas errors are as these:

/home/ulg/xxxxxxxxxxx/.local/easybuild/software/GlobalArrays/5.7-intel-2018b/lib/libga.a(ga_diag.o): In function `gai_diag_std_':
ga_diag.F:(.text+0x7d5): undefined reference to `fmemreq_'
ga_diag.F:(.text+0x969): undefined reference to `pdspev_'
/home/ulg/xxxxxxx/.local/easybuild/software/GlobalArrays/5.7-intel-2018b/lib/libga.a(ga_diag.o): In function `gai_diag_':
ga_diag.F:(.text+0x15e6): undefined reference to `fmemreq_'
ga_diag.F:(.text+0x17a7): undefined reference to `pdspgv_'
/home/ulg/xxxxxxxxx/.local/easybuild/software/GlobalArrays/5.7-intel-2018b/lib/libga.a(ga_diag.o): In function `gai_diag_reuse_':
ga_diag.F:(.text+0x265e): undefined reference to `fmemreq_'
ga_diag.F:(.text+0x2814): undefined reference to `pdspgv_'
/home/ulg/xxxxxxxxx/.local/easybuild/software/GlobalArrays/5.7-intel-2018b/lib/libga.a(ga_diag.o): In function `gai_diag_std_':
ga_diag.F:(.text+0x7d5): undefined reference to `fmemreq_'
ga_diag.F:(.text+0x969): undefined reference to `pdspev_'
/home/ulg/xxxxxxxx/.local/easybuild/software/GlobalArrays/5.7-intel-2018b/lib/libga.a(ga_diag.o): In function `gai_diag_':
ga_diag.F:(.text+0x15e6): undefined reference to `fmemreq_'
ga_diag.F:(.text+0x17a7): undefined reference to `pdspgv_'
/home/ulg/xxxxxxx/.local/easybuild/software/GlobalArrays/5.7-intel-2018b/lib/libga.a(ga_diag.o): In function `gai_diag_reuse_':
ga_diag.F:(.text+0x265e): undefined reference to `fmemreq_'
ga_diag.F:(.text+0x2814): undefined reference to `pdspgv_'
make[2]: *** [bin/casvb.exe] Error 1
make[2]: Leaving directory `/home/users/xxxxxx/.local/easybuild/build/OpenMolcas/18.09/intel-2018b-Python-3.6.6/easybuild_obj'
make[1]: *** [CMakeFiles/casvb.exe.dir/all] Error 2

If I remove those NWChem options and rebuild GA, OpenMolcas builds fine.

any idea of what could be causing that?

@arielzn
Copy link
Contributor Author

arielzn commented Jul 22, 2019

The option to blame seems to be --enable-peigs on GA

When using that is required to build something else as prereq ?

I can't find detailed info about that PeIGS library.

@Micket
Copy link
Contributor

Micket commented Jul 22, 2019

@arielzn I looked into it, and it seems the parallel eig function in GlobalArrays expects the user to link in external symbols. NWChem implements these functions;
https://svn.pnl.gov/svn/nwchem/trunk/src/peigs/src/c/memreq_f.c

GA should have kept this addition as a separate library, so that normal users can link to just what they need, but.. they didn't. Pretty horrid design choices all around here I would say.

Our options are

  1. Create a separate GA-config for NWChem with a "-peigs" suffix.
  2. Make OpenMOLCAS statically link (as it's not using these functions, the linker wont require the symbols it uses).
  3. Patch OpenMOLCAS to add these symbols (could just be empty placeholders, so not really such an impossible task, but, very ugly)

Option 1 would mean that there are incompatible.. but, perhaps that's just what we need. It would also allow users to pick. Still though, very annoying, as this could have been so very easily avoided by GA.

@arielzn
Copy link
Contributor Author

arielzn commented Jul 22, 2019

Some info about
GlobalArrays/ga#96

I'm not sure then if we can have a GA version compatible with NWChem and OpenMolcas at the same time.

@arielzn
Copy link
Contributor Author

arielzn commented Jul 22, 2019

Just saw your message after my last comment.

We could try 2. I'm not sure how these things were handled in other cases, if something equivalent happened before.

@Micket
Copy link
Contributor

Micket commented Jul 22, 2019

I'm not sure then if we can have a GA version compatible with NWChem and OpenMolcas at the same time.

I think we could with if OpenMolcas statically linked. It's never going to call peigs().

It doesn't really build anything different; it just replaces the functionality with a dummy function (with no external deps) if you don't enable it:
https://github.com/GlobalArrays/ga/blob/1537981033d7b2e5cbeeaaf40529fbf4d414724a/global/src/peigstubs.c#L33

Question is, what is the least ugly solution? Probably just having 2 GA's and add -peigs suffix

@arielzn
Copy link
Contributor Author

arielzn commented Jul 22, 2019

Question is, what is the least ugly solution? Probably just having 2 GA's and add -peigs suffix

probably that will be the most explicit and cleaner solution, in case some other package is going ever to be built against GA

@Micket
Copy link
Contributor

Micket commented Jul 22, 2019

probably that will be the more explicit and cleaner solution, in case some other package is going ever to be built against GA

Yes. Just drop the extra flags, I will be making a new PR for 2019a with a -peigs version

Copy link
Contributor

@Micket Micket left a comment

Choose a reason for hiding this comment

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

lgtm

@arielzn
Copy link
Contributor Author

arielzn commented Jul 23, 2019

Test report by @arielzn
SUCCESS
Build succeeded for 2 out of 2 (2 easyconfigs in this PR)
dragon2-ctrl0.umons.ac.be - Linux centos linux 7.6.1810, Intel(R) Xeon(R) Gold 6130 CPU @ 2.10GHz, Python 2.7.5
See https://gist.github.com/d26ec8474363048eefc2e9dbe97fded7 for a full test report.

@Micket Micket dismissed boegel’s stale review July 23, 2019 12:34

Requested change has been made

@Micket
Copy link
Contributor

Micket commented Jul 23, 2019

Going in, thanks @arielzn!

@Micket Micket merged commit 07d30de into easybuilders:develop Jul 23, 2019
@boegel boegel modified the milestones: 3.x, next release (3.9.4?) Aug 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants