DALTON2016.2 Is Built on macOS Sierra Although C Compiler...

Problems with Dalton installation? Find answers or ask for help here
Post Reply
xiongyan21
Posts: 120
Joined: 24 Sep 2014, 08:36
First name(s): yan
Last name(s): xiong
Affiliation: CENTRAL CHINA NORMAL UNIVERSITY
Country: China

DALTON2016.2 Is Built on macOS Sierra Although C Compiler...

Post by xiongyan21 » 11 Dec 2016, 16:27

Dear All:
It seems that something is unusual, i.e., although C compiler is broken and the configration is incomplete, Dalton2016.2 is successfully built on macOS Sierra(10.12.1) with Cmake3.7.1, GCC6.2.0, Xcode8.0 and mpich3.2_2, and with the original parameters, all the tests except 163 - rsp_soppapolarsymm can pass using ctest -j4.

Even ./setup --mpi is used, it is said mpi is off (perhaps it is not correctly exported)and a parallel run can finish but encounters the following

Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation,

whereas a sequential run goes smoothly

What should I do to remedy this?


Very Best Regards!
Last edited by xiongyan21 on 12 Dec 2016, 04:07, edited 1 time in total.

hjaaj
Posts: 247
Joined: 27 Jun 2013, 18:44
First name(s): Hans Jørgen
Middle name(s): Aagaard
Last name(s): Jensen
Affiliation: Universith of Southern Denmark
Country: Denmark

Re: DALTON2016.2 Is Built on macOS Sierra Although C Compile

Post by hjaaj » 11 Dec 2016, 20:06

My guess would be it is a minor problem with that test. But to be sure, could you upload the file rsp_soppapolarnosymm.log which should be in the test_rsp_soppapolarnosym_failed_<something> subdirectory to your build directory.

And with respect to the other issue, I need you to upload the outputs from both the sequential and the mpi calculation to have a chance to answer.

-- Hans Jørgen.

xiongyan21
Posts: 120
Joined: 24 Sep 2014, 08:36
First name(s): yan
Last name(s): xiong
Affiliation: CENTRAL CHINA NORMAL UNIVERSITY
Country: China

Re: DALTON2016.2 Is Built on macOS Sierra Although C Compile

Post by xiongyan21 » 14 Dec 2016, 11:13

Dear All
I have updated the operating system to macOS Sierra 10.12.2, and reinstalled Cmake3.7.1,GCC6.2.0, and mpich3.2_2, but still got
"Check for working C compiler: /usr/local/bin/mpicc -- broken".

The C compiler identification is AppleClang 8.0.0.8000038
-- The CXX compiler identification is AppleClang 8.0.0.8000038

How can I correct this mistake?

Very Best Regards!

taylor
Posts: 519
Joined: 15 Oct 2013, 05:37
First name(s): Peter
Middle name(s): Robert
Last name(s): Taylor
Affiliation: Aarhus University
Country: Denmark

Re: DALTON2016.2 Is Built on macOS Sierra Although C Compile

Post by taylor » 14 Dec 2016, 11:28

Since I do not compile on my Mac I don't have an immediate answer (and because I believe that all recent Mac OS releases suck I am anyway still on Mountain Lion...). But my first question is if you don't build parallel, that is, you invoke a purely single-processor build, does it build? If so your gcc/gfortran (and maybe your cmake) would then seem to be OK. If it does not, you have bigger problems!

I myself have no recent experience with MPICH: we use OpenMPI on our cluster at home. But MPICH should come with some sort of hello.c test program where you can verify that MPICH is actually working? Just something that prints "Hello, world" N times, where is the number of MPI tasks, would be usual. Does this work? If not, then MPI is probably your problem. If it does work, then your software stack would appear to be consistent, and unless someone is running a configuration similar to yours it will be difficult to track down what is happening.

Can I repeat something I have said before, more than once? It is in my view a grave error to jump on the latest-and-greatest released of system software/compilers/libraries. The old adage is "if it ain't broke, don't fix it". Other than possible security issues with Mac OS, what was wrong with your previous software setup? If things worked under the previous software why do all this upgrading? What is the gain? If you are compelled to do it by your computing support people, well, yes, I've seen enough of that over the years! But if it's your own Mac, why not stick with what works?

Best regards
Pete

xiongyan21
Posts: 120
Joined: 24 Sep 2014, 08:36
First name(s): yan
Last name(s): xiong
Affiliation: CENTRAL CHINA NORMAL UNIVERSITY
Country: China

Re: DALTON2016.2 Is Built on macOS Sierra Although C Compile

Post by xiongyan21 » 14 Dec 2016, 12:56

Dear All
Something is really wrong, because the sequential build of LSDalton1.2 encounters the following errors
...
.../lsdalton/src/deccc/rimp2.F90:170:14:

type(c_ptr), target :: handle_cptr
1
Error: Type name 'c_ptr' at (1) is ambiguous
.../lsdalton/src/deccc/rimp2.F90:171:14:

type(c_ptr) :: cublas_handle
1
Error: Type name 'c_ptr' at (1) is ambiguous
.../lsdalton/src/deccc/rimp2.F90:3211:14:

type(c_ptr) :: cublas_handle
1
Error: Type name 'c_ptr' at (1) is ambiguous
.../lsdalton/src/deccc/rimp2.F90:1055:108:

& int((i8*K)*M,kind=8),int(K*(N*i8),kind=8),int(M*(N*i8),kind=8),async_id,cublas_handle)
1
Error: Symbol 'cublas_handle' at (1) has no IMPLICIT type
make[3]: *** [CMakeFiles/declib.dir/src/deccc/rimp2.F90.o] Error 1
make[2]: *** [CMakeFiles/declib.dir/src/deccc/rimp2.F90.o.provides] Error 2
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/declib.dir/all] Error 2
make: *** [all] Error 2


What should I do?
Very Best Regards!
Last edited by xiongyan21 on 15 Dec 2016, 03:28, edited 2 times in total.

taylor
Posts: 519
Joined: 15 Oct 2013, 05:37
First name(s): Peter
Middle name(s): Robert
Last name(s): Taylor
Affiliation: Aarhus University
Country: Denmark

Re: DALTON2016.2 Is Built on macOS Sierra Although C Compile

Post by taylor » 14 Dec 2016, 14:09

I fear this response may sound unsympathetic, but to me the solution is obvious. The Dalton/LSDalton code has remained exactly the same as what you were running before, yes? In that case your "system/software upgrade" has broken something. I cannot see how it can be a Dalton/LSDalton problem if something that worked on yesterday's operating system no longer works! I do not say there is no fault in Dalton/LSDalton, but the fact that it worked one day and does not work after some sort of significant system upgrade is going to be very difficult to analyze from a Dalton perspective. I myself cannot do more than repeat what I said earlier: users should not jump on the latest-and-greatest software releases. I have never tried to "downgrade" the system on a Mac, so I do not even know if this is possible, but that would be the immediate solution, would it not?

Best regards
Pete

taylor
Posts: 519
Joined: 15 Oct 2013, 05:37
First name(s): Peter
Middle name(s): Robert
Last name(s): Taylor
Affiliation: Aarhus University
Country: Denmark

Re: DALTON2016.2 Is Built on macOS Sierra Although C Compile

Post by taylor » 14 Dec 2016, 14:23

A solution that we use at home for this sort of thing, but which may not be available to you (and may not be available to install Mac OS anyway --- I've never tried because I have no need in this context) is to use virtual machines (VMs). This lets you test systems, software releases, libraries, compilers, in a closed environment where you do not affect/compromise your entire system. We can switch between six different variants of Linux (and multiple releases of those variants) as well as Windows. Note that we do not run (in the sense of production calculations) on VMs! But they are indispensable for trying things out before you commit to them in production.

Best regards
Pete

xiongyan21
Posts: 120
Joined: 24 Sep 2014, 08:36
First name(s): yan
Last name(s): xiong
Affiliation: CENTRAL CHINA NORMAL UNIVERSITY
Country: China

Re: DALTON2016.2 Is Built on macOS Sierra Although C Compile

Post by xiongyan21 » 14 Dec 2016, 15:41

Dear Prof. Peter
I just have successfully compiled NWChem6.6 on the same environment.

The sequential compilation of DALTON2016.2 is successful on macOS Sierra 10.12.2 with Cmake 3.7.1, Xcode 8.0, GCC6.2 and mpich3.2_2 installed, making all the tests having the original parameters pass, except 163 - rsp_soppapolarsymm, using ctest -j4.

By the way, the sequential building of DIRAC16 has been successful on the same environment, and all the tests can pass with the original parameters except the following

9 - krci_energy (Failed)
13 - reladc_sip (Failed)
14 - reladc_sipeigv (Failed)
15 - reladc_dip (Failed)
36 - lucita_large (Failed)
37 - mcscf_energy (Failed)
44 - krci_energy_q_corrections (Failed)
52 - bss_energy (Failed)
68 - krci_properties_perm_dipmom (Failed)
70 - mcscf_properties (Failed)
87 - lucita_short (Failed)
93 - krci_properties_omega_tdm (Failed)
102 - lucita_q_corrections (Failed)

Very Best Regards!
Last edited by xiongyan21 on 17 Dec 2016, 05:57, edited 1 time in total.

xiongyan21
Posts: 120
Joined: 24 Sep 2014, 08:36
First name(s): yan
Last name(s): xiong
Affiliation: CENTRAL CHINA NORMAL UNIVERSITY
Country: China

Re: DALTON2016.2 Is Built on macOS Sierra Although C Compile

Post by xiongyan21 » 17 Dec 2016, 05:19

Dear all

If ./setup --mpi is used, an mpirun will give

--> ERROR (GPOPEN) UPON TRYING TO OPEN FILE ON UNIT 2

--> IOSTAT ERROR CODE RETURNED 17


QTRACE dump of internal trace stack

========================
level module
========================
2 GPOPEN
1 DALTON main
========================


Node 0: --- SEVERE ERROR, PROGRAM WILL BE ABORTED ---
ERROR (GPOPEN) UPON OPENING A FILE

Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.

Backtrace for this error:
#0 0x10eddcb99
#1 0x10eddbf65
#2 0x7fff92aa2bb9
#3 0x103cb5f6f
#4 0x103d02d62
#5 0x103d0c1c6
#6 0x1024b33c6
#7 0x1046d10ce

SERIOUS ERROR:
DALTON finished with non-zero exit code: 136

nevertheless the run can get results but with the following in the bash

===================================================================================
= BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
= PID 36011 RUNNING AT appledeMac-mini.local
= EXIT CODE: 136
= CLEANING UP REMAINING PROCESSES
= YOU CAN IGNORE THE BELOW CLEANUP MESSAGES
===================================================================================

What should be patched?

Thanks!

Very Best Regards!
Last edited by xiongyan21 on 17 Dec 2016, 05:52, edited 1 time in total.

taylor
Posts: 519
Joined: 15 Oct 2013, 05:37
First name(s): Peter
Middle name(s): Robert
Last name(s): Taylor
Affiliation: Aarhus University
Country: Denmark

Re: DALTON2016.2 Is Built on macOS Sierra Although C Compile

Post by taylor » 17 Dec 2016, 05:46

What part of the header to this forum "please post your output file(s)" is not clear? Please do not assume that excerpting things you think are significant necessarily includes all the things that are, to an expert, significant! Further, pasting things into a posting body invariably produces a malformed document that is sometimes close to impossible to read as Email, especially in browser-based Email systems.

What is "the bash"?

Do you get the correct answer (compared to if you repeat the run without MPI)? Are you sure you have deleted any scratch directories left from previous runs?

Best regards
Pete

xiongyan21
Posts: 120
Joined: 24 Sep 2014, 08:36
First name(s): yan
Last name(s): xiong
Affiliation: CENTRAL CHINA NORMAL UNIVERSITY
Country: China

Re: DALTON2016.2 Is Built on macOS Sierra Although C Compile

Post by xiongyan21 » 17 Dec 2016, 08:14

Dear all
I reinstall GCC6.2.0, mpich3.2_2, Cmake2.7 and Python2.7, make the mpicc work, and let the mpi compilation of Dalton2016.2 built on macOS Sierra 10.12.2 with Xcode 8.0.

taylor
Posts: 519
Joined: 15 Oct 2013, 05:37
First name(s): Peter
Middle name(s): Robert
Last name(s): Taylor
Affiliation: Aarhus University
Country: Denmark

Re: DALTON2016.2 Is Built on macOS Sierra Although C Compile

Post by taylor » 17 Dec 2016, 08:36

I admit now to be absolutely baffled! Are you telling us that Dalton built successfully? You post about MPI problems and then ignore responses: if this is all fixed it would be good to know!

How is Xcode relevant to a Dalton build? Dalton/LSDalton relies on a compiler and a library/software stack for a code that will be run most likely from a shell. What does Xcode have to do with it?

My own simple-minded view is that trying to run production code on a Mac (whether it's an Air or some super-desktop that costs a fortune) is a waste of time/effort (and I speak as someone who got their first Mac in 1987), although I can readily sympathize if this is the only platform available. The machine/operating system has a particular target, as does Windows: an end-user who is not a "computer person" but an "ordinary user...". I use my Mac almost every minute of every day that I am awake for Email, browsing, spreadsheets, word processing, LaTeX, and other elements of my business (we run a modest consulting agency). But when I want to do any quantum chemistry, I ssh to our compute farm, which is entirely Linux based. An operating system that is designed for a multiuser environment and is robust enough to support real computational activity.

So to return to my initial question: are you telling us that things work, or that they don't? And it's not clear why some of these specific software versions are in any way relevant, or useful to others? I repeat what I have said more than once: if someone is relying on a system to do development and/or production in quantum chemistry (or indeed in any discipline of computational science) never upgrade to the latest versions of anything as soon as they are released! This is asking for trouble! Wait for the waves to subside first, to put it poetically...

Best regards
Pete

xiongyan21
Posts: 120
Joined: 24 Sep 2014, 08:36
First name(s): yan
Last name(s): xiong
Affiliation: CENTRAL CHINA NORMAL UNIVERSITY
Country: China

Re: DALTON2016.2 Is Built on macOS Sierra Although C Compile

Post by xiongyan21 » 17 Dec 2016, 08:43

Dear Prof. Taylor

MPI compilation works!
Actually, GCC has patches which should be installed.
On the latest Dalton manual, it is stated the current release of the program supports Linux,Cray, SGI, and MacOS using GNU or Intel compilers.
Don't many authors use mac to develop programs, and what is the real difference for quantum calculation between a linux based workstation and a mac?
Please show us the difference with the same machine configuration.
GAMESS, an eminent and power general ab initio quantum chemistry package, can also be compiled on Microsoft Windows HPC Server.

I cannot see your comments helpful.
Last edited by xiongyan21 on 19 Dec 2016, 04:06, edited 3 times in total.

xiongyan21
Posts: 120
Joined: 24 Sep 2014, 08:36
First name(s): yan
Last name(s): xiong
Affiliation: CENTRAL CHINA NORMAL UNIVERSITY
Country: China

Re: DALTON2016.2 Is Built on macOS Sierra Although C Compile

Post by xiongyan21 » 17 Dec 2016, 12:45

Dear all

Now the errors for a MPI run become
Fatal error in MPI_Init: Other MPI error, error stack:
MPIR_Init_thread(474)..............:
MPID_Init(190).....................: channel initialization failed
MPIDI_CH3_Init(89).................:
MPID_nem_init(320).................:
MPID_nem_tcp_init(173).............:
MPID_nem_tcp_get_business_card(420):
MPID_nem_tcp_init(379).............: gethostbyname failed,
(errno 1)
although I modified the content of file host.

What should I do to correct this?

Thanks very much for your advice.

Very Best Regards!

taylor
Posts: 519
Joined: 15 Oct 2013, 05:37
First name(s): Peter
Middle name(s): Robert
Last name(s): Taylor
Affiliation: Aarhus University
Country: Denmark

Re: DALTON2016.2 Is Built on macOS Sierra Although C Compile

Post by taylor » 19 Dec 2016, 14:10

Just checking, is this a Dalton build problem? Or a GAMESS build problem on Windows HPC server, which it seemed you already had working?

This is the Dalton mailing list! It is not the MPI mailing list, it is not the Mac OS mailing list, it is not the GAMESS mailing list, and it is not the Windows HPC blah blah mailing list!

GAMESS is a fine code, but why should any of the Dalton developers care about it? Windows HPC server may be a fine operating system (but I gotta tell you I got some considerable scepticism about that...) but since it is specific in the Dalton documentation which operating systems it can be built for (which implicitly then specifically excludes any version of Windows or indeed any Microsoft operating system) I find it very difficult to understand what your point is?

It seems that every time you post, the respondent (often me, looking at the thread...) tries to help by asking you what you are actually doing. Your response is to post something completely new that seems to have no overlap with your previous problems! And despite repeated attempts posting a clip from your build/run that you think is significant. Which in reality may or may not be significant, which is why we plead with posters to post their outputs!

To conclude, let me reminisce about a posting some time ago by someone who was seriously perturbed that the code could not be built under Windows. Indeed, he was vociferously aggressive that the "Dalton mob" should fix this. None of us are paid to look after the code! None of us are paid to support users! We do it because this is what we do: this is the people that we are. The code (with the possible exception of an early fork that ran under Windows NT, some twenty years ago...) has never been ported to Windows, and will likely never be (in part, because why? Why should anyone put effort into a crap operating system that costs a fortune for a licence?).

My point about machines and operating systems is the following (and trust me: I spent enough time running computer facilities that I know all about how people need Mac Pro desktops the size of a suitcase, so they can do graphics and whatever and whatever...). Such machines are totally targetted as a single-user platform where someone will use a preloaded, completely defined windowing environment with all the icons and clicky things and menus and whatevers. Even if this sounds disparaging, it is not intended to be. But there is an Australian saying "horses for courses", which means that you should view what you need to do (win a particular horse race, be it steeplechase, flat, jumps, whatever) and then find the right tool to solve that problem. If that target is code development, then maybe (although it's not the path I walk down) a Mac or whatever is fine. For production calculation I want a system that supports queueing, batch processing, scratch storage, or at least can be configured to do so. I felt we had such systems forty years ago, but while I have been forced to abandon CDC's SCOPE2, Cray's COS, etc., I still have UNIX and UNIX variants like Linux. I can accept that "under the hood" MacOS is OpenBSD UNIX, but really...? I use my Air for everything: Email, LaTeX, music, and most especially handling my digital photos. But I don't see why I would ever run production quantum chemistry on it. Not (just) because it would interfere with what else I do. But because, well, horses for courses...

As I said, I was totally confused after your last posting about what you were asking us. If you have an MPI problem, well, they got their own mailing list! And if you're happy running GAMESS on Windows: that's great and the GAMESS mob would be delighted to hear it, but how is it relevant to the Dalton forum?

Best regards
Pete

xiongyan21
Posts: 120
Joined: 24 Sep 2014, 08:36
First name(s): yan
Last name(s): xiong
Affiliation: CENTRAL CHINA NORMAL UNIVERSITY
Country: China

Re: DALTON2016.2 Is Built on macOS Sierra Although C Compile

Post by xiongyan21 » 20 Dec 2016, 04:07

Can you understand if a run is not able to be initiated because of the error gethostbyname failed there will be no log or out file produced?

Very Best Regards!

hjaaj
Posts: 247
Joined: 27 Jun 2013, 18:44
First name(s): Hans Jørgen
Middle name(s): Aagaard
Last name(s): Jensen
Affiliation: Universith of Southern Denmark
Country: Denmark

Re: DALTON2016.2 Is Built on macOS Sierra Although C Compile

Post by hjaaj » 20 Dec 2016, 08:14

I can only think of one possibility. If you have both openMPI and MPICH installed, then the dalton script will use mpirun from openMPI and not mpiexec from MPICH. We have not taken into account that both may be available. If this is the case, edit the dalton script, find these lines:

Code: Select all

which mpirun > /dev/null # check if mpirun exists, if not, then assume mpiexec
if [ $? -eq 0 ]; then
   MPIEXEC=mpirun
else
   MPIEXEC=mpiexec
fi
and change them to

Code: Select all

   MPIEXEC=mpiexec
-- Hans Jørgen.

xiongyan21
Posts: 120
Joined: 24 Sep 2014, 08:36
First name(s): yan
Last name(s): xiong
Affiliation: CENTRAL CHINA NORMAL UNIVERSITY
Country: China

Re: DALTON2016.2 Is Built on macOS Sierra Although C Compile

Post by xiongyan21 » 20 Dec 2016, 08:34

Dear Prof. Jensen
Thanks a lot for your advice.
Although only mpich is installed, it seems that the error is caused by this, because the command with > /dev/null gives blank.
I will try it, but I am afraid I do not know where it is without your guide.

Very Best Regards!

xiongyan21
Posts: 120
Joined: 24 Sep 2014, 08:36
First name(s): yan
Last name(s): xiong
Affiliation: CENTRAL CHINA NORMAL UNIVERSITY
Country: China

Re: DALTON2016.2 Is Built on macOS Sierra Although C Compile

Post by xiongyan21 » 29 Dec 2016, 16:01

Dear Prof. Jensen

I reinstalled macOS Sierra 10.12.2, with GCC6.3.0, and modified file hosts, previously missing, and found parallel runs OK!

...
MPI | ON
Fortran compiler | /usr/local/bin/mpif90
Fortran compiler version | GNU Fortran (Homebrew GCC 6.3.0) 6.3.0
C compiler | /usr/local/bin/mpicc
C compiler version | Apple LLVM version 8.0.0 (clang-800.0.38)
C++ compiler | /usr/local/bin/mpicxx
C++ compiler version | unknown
BLAS | /usr/lib/libblas.dylib
LAPACK | /usr/lib/liblapack.dylib
Static linking | OFF

...

All the tests except 163 - rsp_soppapolarsymm can pass with the original parameters using ctest -j4.

Very Best Regards!

xiongyan21
Posts: 120
Joined: 24 Sep 2014, 08:36
First name(s): yan
Last name(s): xiong
Affiliation: CENTRAL CHINA NORMAL UNIVERSITY
Country: China

Re: DALTON2016.2 Is Built on macOS Sierra Although C Compiler...

Post by xiongyan21 » 20 Mar 2017, 12:34

DALTON2016. 2 can be successfully mpi built on macOS Sierra 10.12.3, with GCC6.3.0, Cmake3.7.1, mpich3.2_2 and Xcode8.0 and all the tests
can pass with the original parameters except the following
163 - rsp_soppapolarsymm

Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 1 guest