Windows 10

[agilemolecule]

Hi,

I can not run Dalton under Windows 10:

Code: Select all

--> ERROR (GPOPEN) UPON TRYING TO OPEN FILE ON UNIT  1
--> with filename DALTON.STAT
--> IOSTAT ERROR CODE RETURNED       6

Under WindowsXP and Windows8 it works.
Any suggestions?

[taylor]

Yes. Clearly, you should use Windows XP or Win8!

Come on, do you really think that the Dalton users and developers are capable of responding usefully to such an inadequate posting? That "it doesn't work and here is the error message"? How are we supposed to have any knowledge of your build environment, your software stack, the calculation you are trying to run?

I have written this so many times I am past being tired of it: the Dalton community, including, I like to think myself, is always willing to help anyone with issues with the program or their calculations. But we are not telepathic! You must surely see that more information is needed about what you are doing, under what software environment, and how you built the code, for anyone, not telepathic, to assist.

Incidentally, while I try to help wherever and whenever I can, I will not be able to assist personally, I'm afraid. I've been Windows-free for well over a decade...

Best regards
Pete

[agilemolecule]

You must surely see that more information is needed about what you are doing, under what software environment, and how you built the code, for anyone, not telepathic, to assist.

Dear Pete,

Environment is Windows 10. It was compiled with Cygwin compiler in accordance with the instructions.

[arnfinn]

If someone with windows 10 running dalton (which I guess is not many, at least not among the developers) wants to reproduce your error, they need much more information (for instance output files). Otherwise you will not get much help I am afraid. I have never used Cygwin myself, but I am pretty sure there is several version/setups etc. Besides, Cygwin is not a compiler (gfortran is).

[agilemolecule]

The complete output is

Code: Select all

E:\Dalton2011\bin>set BASDIR=E:\Dalton2011\basis 

E:\Dalton2011\bin>dalton.exe -d 


--> ERROR (GPOPEN) UPON TRYING TO OPEN FILE ON UNIT  1
--> with filename DALTON.STAT
--> IOSTAT ERROR CODE RETURNED       6


 QTRACE dump of internal trace stack

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


  --- SEVERE ERROR, PROGRAM WILL BE ABORTED ---
     Date and time (Linux)  : Thu Oct 01 11:20:19 2015
     Host name              : Ascalaph                                

 Reason: ERROR (GPOPEN) UPON OPENING A FILE

 >>>> Total CPU  time used in DALTON:   0.00 seconds
 >>>> Total wall time used in DALTON:   0.00 seconds


 QTRACE dump of internal trace stack

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

This output is independent of the input file, and whether it was as such.
Unfortunately, I can not find out the version of the Cygwin, so that I erased it after compiling.
Since the site claims that Dalton supports Windows, I would like to ask what compiler use developers?
Can they provide a binary file?

[taylor]

You have added almost zero information content to your previous posting. "Almost" because you say you erased "it" after compiling. What is "It"? Your operating system? In that case you could install WinXP, or Win8, which you already know work. If Cygwin, why? Is you disk so small you cannot accommodate the few GB that Cygwin requires? Is it the compiler suite, which you for whatever reason are unwilling to identify?

You are wasting our time. Two of us have already asked you to provide details of your setup so that someone can try to help. You have provided no details whatsoever. It is clear that either you are not seriously interested in assistance, or you somehow think we can magically solve your problems with a wave of the magician's wand. In the first case, well, no-one pays us, so why should we, when you don't even answer our attempts to find out what it is you are doing? In the second, we would be fabulously well-paid magicians and would not need to be wasting our time trying to help completely unresponsive individuals such as yourself.

Best regards
Pete

[agilemolecule]

You have added almost zero information content to your previous posting. "Almost" because you say you erased "it" after compiling. What is "It"? Your operating system? In that case you could install WinXP, or Win8, which you already know work. If Cygwin, why? Is you disk so small you cannot accommodate the few GB that Cygwin requires? Is it the compiler suite, which you for whatever reason are unwilling to identify?

You are wasting our time. Two of us have already asked you to provide details of your setup so that someone can try to help. You have provided no details whatsoever. It is clear that either you are not seriously interested in assistance, or you somehow think we can magically solve your problems with a wave of the magician's wand. In the first case, well, no-one pays us, so why should we, when you don't even answer our attempts to find out what it is you are doing? In the second, we would be fabulously well-paid magicians and would not need to be wasting our time trying to help completely unresponsive individuals such as yourself.

Best regards
Pete

Site http://daltonprogram.org/www/features.html said that:

Dalton has been tested on the following platforms:
* Linux
* Darwin (Mac OS X)
* Windows-cygwin

From what you said, I realized that no one tested Dalton under the current operating system (Windows 10).
In such case it makes а sense to change the declaration.

[bast]

Since the site claims that Dalton supports Windows, I would like to ask what compiler use developers?
Can they provide a binary file?

our current support for Windows is limited due to the fact
that we support the code mostly in our free time and due
to the fact that probably 0% of the developers develop
and test the code on Windows or even use Windows.
most, if not all of the developers use Linux or Mac OS X.

with CMake we in principle can build for native Windows
but this is largely untested in Dalton to my knowledge
but it can be done.

i would recommend you to run a Linux image through
Virtualbox and install Dalton into it. i think this might
be less hassle than wrestling with Dalton to run it on Windows
directly.

[arnfinn]

From what you said, I realized that no one tested Dalton under the current operating system (Windows 10).
In such case it makes а sense to change the declaration.

We have not tested it on every flavor of Linux either, and I am not sure we have tested it on OSX 10.11 yet. Do you want us to change these declarations as well?

I am guessing you just had some problems with your setup, and that it had nothing to do with Windows 10 vs Windows 8.

[jfurness]

I've got a Windows 10 box at home, so this evening I booted up Cygwin and cloned a fresh copy of DALTON from the repo and gave it a go.

I built dalton as simply as possible by running the setup script, then cd-ing to the build directory and running make. This compiled without problem using GCC version 4.9.3 and cmake 3.3.1 installed from the Cygwin setup package.

I then ran the test suite and at the time of writing 469/697 tests have run without error. So I feel ok in saying that Dalton works on windows 10/cygwin.

To try to help with your problem I would guess that Windows' odd permission rules regarding "Program Files" directory may be causing an issue. An issue with permissions would explain why dalton was unable to open a file (suggested by the output message). I'm not sure what your current setup is, but to test I would suggest you make a clean install of Cygwin in a non-protected directory like your Desktop or Documents and not within Program Files. I've encountered windows being funny about writing files there before so this is something to try.

Run the clean cygwin install as administrator and build a fresh version of Dalton using gcc-4.9.3. Then try your calculations again.

As the others have said, this seems to me to be an issue with your setup, rather than with dalton, as such it should be easily fixed!

Best of luck.

James

[agilemolecule]

I've got a Windows 10 box at home, so this evening I booted up Cygwin and cloned a fresh copy of DALTON from the repo and gave it a go.

I built dalton as simply as possible by running the setup script, then cd-ing to the build directory and running make. This compiled without problem using GCC version 4.9.3 and cmake 3.3.1 installed from the Cygwin setup package.

I setup the yesterday Cygwin.
Could you help setup it correctly?

Code: Select all

$ ./setup
 FC=gfortran CC=gcc CXX=g++ cmake -DENABLE_MPI=OFF -DENABLE_SGI_MPT=OFF -DENABLE_OMP=OFF -DENABLE_64BIT_INTEGERS=OFF -DENABLE_OPENACC=OFF -DENABLE_COLLAPSE=OFF -DENABLE_CSR=OFF -DENABLE_SCALASCA=OFF -DENABLE_VAMPIRTRACE=OFF -DENABLE_TIMINGS=OFF -DENABLE_XCFUN=OFF -DENABLE_INTEREST=OFF -DENABLE_ICHOR=OFF -DENABLE_STATIC_LINKING=OFF -DENABLE_SCALAPACK=OFF -DCMAKE_BUILD_TYPE=release /home/amnikitin/DALTON-Source

CMake Error at /usr/share/cmake-3.3.1/Modules/CMakeTestFortranCompiler.cmake:54 (message):
  The Fortran compiler "/usr/bin/gfortran.exe" is not able to compile a
  simple test program.

  It fails with the following output:

   Change Dir: /home/amnikitin/DALTON-Source/build/CMakeFiles/CMakeTmp



  Run Build Command:"/usr/bin/make.exe" "cmTC_bde8b/fast"

  /usr/bin/make -f CMakeFiles/cmTC_bde8b.dir/build.make
  CMakeFiles/cmTC_bde8b.dir/build

  make[1]: Entering directory
  '/home/amnikitin/DALTON-Source/build/CMakeFiles/CMakeTmp'

  Building Fortran object CMakeFiles/cmTC_bde8b.dir/testFortranCompiler.f.o

  /usr/bin/gfortran.exe -c
  /home/amnikitin/DALTON-Source/build/CMakeFiles/CMakeTmp/testFortranCompiler.f
  -o CMakeFiles/cmTC_bde8b.dir/testFortranCompiler.f.o

  CMakeFiles/cmTC_bde8b.dir/build.make:65: recipe for target
  'CMakeFiles/cmTC_bde8b.dir/testFortranCompiler.f.o' failed

  make[1]: Leaving directory
  '/home/amnikitin/DALTON-Source/build/CMakeFiles/CMakeTmp'

  C:/cygwin/lib/gcc/i686-pc-cygwin/4.9.3/f951.exe: error while loading shared
  libraries: cygisl-10.dll: cannot open shared object file: No such file or
  directory

  make[1]: *** [CMakeFiles/cmTC_bde8b.dir/testFortranCompiler.f.o] Error 1

  Makefile:126: recipe for target 'cmTC_bde8b/fast' failed

  make: *** [cmTC_bde8b/fast] Error 2





  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:18 (project)


-- Changed cmake policy to version 3.0, except for policy CMP037
-- The Fortran compiler identification is unknown
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
-- Check for working Fortran compiler: /usr/bin/gfortran.exe
-- Check for working Fortran compiler: /usr/bin/gfortran.exe  -- broken
-- Configuring incomplete, errors occurred!
See also "/home/amnikitin/DALTON-Source/build/CMakeFiles/CMakeOutput.log".
See also "/home/amnikitin/DALTON-Source/build/CMakeFiles/CMakeError.log".

Why not deliver binary, as is customary in the Windows?
Perhaps in the Linux binary are incompatible, however in the Windows they work tens of years.
I'm not a Linux programmer and compile Dalton require weeks of work for me, as usual.

[taylor]

I suggest that you read (for example) the licensing terms for Cygwin to understand "why we don't make a binary available?". And against what software stack should we build it? GNU compilers? Intel compilers? Which runtime libraries? Intel? MKL? ATLAS? What about AMD? And we should do this because one user cannot install code that they have already admitted worked/works under WinXP and Win8? And since not a single one of us is paid a dime to look after Dalton for Windows, we should do all this because one user can't build the code, despite clear instructions as to how to do it?

I repeat what I said earlier. You are wasting our time. As well, as you have already admitted, your own.

Best regards
Pete

[taylor]

I suggest that you read (for example) the licensing terms for Cygwin to understand "why we don't make a binary available?". And against what software stack should we build it? GNU compilers? Intel compilers? Which runtime libraries? Intel? MKL? ATLAS? What about AMD? And we should do this because one user cannot install code that they have already admitted worked/works under WinXP and Win8? And since not a single one of us is paid a dime to look after Dalton for Windows, we should do all this because one user can't build the code, despite clear instructions as to how to do it?

I repeat what I said earlier. You are wasting our time. As well, as you have already admitted, your own.

Best regards
Pete
P.S. Any developers who think initially that they might willing to help here, please read carefully the Cygwin license terms. Unless the code being built is GPL'ed (and Dalton currently is not) you can only distribute binaries if you buy the appropriate license from Cygwin/Red Hat for the code you are building. I do not feel anyone associated with the Dalton project should violate such a license.

[jfurness]

I'll reiterate what others have said. I can really recommend you install a linux distro for work like this. Windows can be nice for a leisure PC, but for getting work done linux or OSX really can't be beaten. You'll save yourself time in the long run.

Re: distributing a binary. As Pete has pointed out there are legal considerations, but on a practical note understanding how to build and maintain the programs you rely on is a vital skill for working in this domain. If for example you upgrade your system and can't rebuild, you might hit problems...

With that said, if and only if you are dead set on this course...

The lines that are concerning are:

-- The Fortran compiler identification is unknown
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown

This suggests the compilers are missing. Confirm they are present and up to date by running

gcc -v
g++ -v
gfortran -v

If they are out of date or missing then there is the problem.

However, Looking at this line

C:/cygwin/lib/gcc/i686-pc-cygwin/4.9.3/f951.exe: error while loading shared
libraries: cygisl-10.dll: cannot open shared object file: No such file or
directory

I can see your Cygwin root directory is C:/cygwin/. I'm not an expert in Windows, but this is still right down in the root directory where the operating system can get really funny about allowing you to write files. Please have another go at following my previous advice of installing Cygwin to an area in your User folder. Uninstal your current Cygwin completely and run the installer (the latest one from the Cygwin site) and point it to a folder like:

C:\Users\<YOUR_USERNAME_HERE>\cygwin

Also, when you run the installer and are selecting the packages you want make sure you have selected All->Devel->gcc-core, gcc-g++ and gcc-fortran as well as All->Libs->libgcc1. You may also need Devel->cmake, binutils, cygwin-devel and make, along with any dependencies these may have.

I'd like to add as well, that even if you manage to build a working version of Dalton this way it will be nowhere near optimal. Building on Linux against optimized math libraries will significantly speed up your calculations.

James

[bast]

thanks James for very useful information!

[agilemolecule]

I repeat what I said earlier. You are wasting our time. As well, as you have already admitted, your own.

On the contrary, it is you have spent my time. At the same time you get a salary for this work.

Your program is not working. Why it does not matter. Entering the World of Windows you are required to maintain our quality standards.

[Bernd S.]

Apologies for entering the discussion at such a late time:

I see two main points of view: 1. We do this as a spare-time job so be happy with what we give you
2. Newbies read it works on whatever machine ..

Perhaps the advertisement should become more honest and indicate which hardware / software versions are
rather experimental with negligible support. I remember the times when running on Linux with g77 was advertised but it n fact you needed Fortran90 to get the full suite running.

We simply don't just attract needs like us happily spending a day or more in order to find the right set-up but people who essiantially want to press a button and get an answer. In that sense, distributing binaries might help to clean up the forum.

Greetings from lovely Karlsruhe,

Bernd

[bast]

I agree that distributing binaries would be nice. It's something I would
like to do or help with one day but also this takes some spare time.
Until then, please let's be nice to each other. We are all trying to do our
best here and I confirm that most if not all developers get no salary
directly related to this work.

[kennethruud]

On the contrary, it is you have spent my time. At the same time you get a salary for this work.

Your program is not working. Why it does not matter. Entering the World of Windows you are required to maintain our quality standards.

Dear Alexei,

As Radovan, I hope that the tone in forum can be nice. Apart from this, I will only reiterate what others have said already:

• Most of those behind the Dalton program are paid to teach and do research. We have no support for making Dalton available to other users, and because of this, none of use paid to do so (I wish we had that kind of money, but we don't).
• Because we allow you to download the program for free, we make no money to provide the services you expect. Instead, we hope that users help each other, which is what James has been trying to do (thanks, James!)
• The Dalton developers try to help whenever we have the time to do so, and this is what Arnfinn, Bernd, Peter and Radovan has tried to do with the information provided (thanks!). However, reiterating, nobody pays us for this work, and thus helping will often have to get second priority to other tasks we are expected to do by our employers. Although not visible, the Dalton developers invest a lot of effort into making the code useful and available for the general community free of charge, although we of course always could do better.
• When signing the Dalton license agreement, you agreed to the following:

  "You accept that the experimental nature of the Dalton2015 programs means that there is no warranty of correctness of results nor fitness for a particular purpose. You understand that the authors of Dalton2015 cannot be held responsible in any way for any consequences arising from the use of a Dalton2015 program."

Thus, you accepted that it might be that Dalton may not be fitted for your purposes (which it apparently isn't since it does not work out of the box as you expect and since you do not want to invest the time needed to make it work based on the suggestions from users and developers). You also accepted that we cannot be held responsible for you, in your own word, having wasted your time. We are thus by no means "required to maintain our quality standards when entering the World of Windows", as you claim.

I am sorry to note that Dalton does not meet your expectations. I trust you will find a suitable software out there that will meet your expectations.


Best regards,

Kenneth

[agilemolecule]

As Radovan, I hope that the tone in forum can be nice.

Dear Kenneth,

Do you mean that we should use such tone:

I repeat what I said earlier. You are wasting our time. As well, as you have already admitted, your own.

Best wishes

[kennethruud]

No, I do not, which is why I started my posting the way I did. This of course applies both ways.

Kenneth

[agilemolecule]

Dear James,

Thank you for your help.

I'll reiterate what others have said. I can really recommend you install a linux distro for work like this. Windows can be nice for a leisure PC, but for getting work done linux or OSX really can't be beaten. You'll save yourself time in the long run.

Re: distributing a binary. As Pete has pointed out there are legal considerations, but on a practical note understanding how to build and maintain the programs you rely on is a vital skill for working in this domain. If for example you upgrade your system and can't rebuild, you might hit problems...

Interestingly about the "leisure PC".
Please look at the moment that you point out:

If for example you upgrade your system and can't rebuild, you might hit problems...

The point is that when we update Windows, we do not compile anything. On most machines, we do not even have a compiler. Once compiled programs run for decades, across the line of operating systems. What has happened now is certainly greetings from the world of Linux.
And this is not the last reason why I am:

With that said, if and only if you are dead set on this course...

Sorry to trouble you.

The lines that are concerning are:

-- The Fortran compiler identification is unknown
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown

This suggests the compilers are missing. Confirm they are present and up to date by running

gcc -v
g++ -v
gfortran -v

Code: Select all

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-cygwin/4.9.3/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with: /cygdrive/i/szsz/tmpp/gcc/gcc-4.9.3-1.i686/src/gcc-4.9.3/configure --srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-4.9.3-1.i686/src/gcc-4.9.3 --prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc --docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C --build=i686-pc-cygwin --host=i686-pc-cygwin --target=i686-pc-cygwin --without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib --enable-shared --enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit --with-dwarf2 --with-arch=i686 --with-tune=generic --disable-sjlj-exceptions --enable-languages=ada,c,c++,fortran,java,lto,objc,obj-c++ --enable-graphite --enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm --enable-libquadmath --enable-libquadmath-support --enable-libssp --enable-libada --enable-libjava --enable-libgcj-sublibs --disable-java-awt --disable-symvers --with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix --without-libintl-prefix --with-system-zlib --enable-linker-build-id
Thread model: posix
gcc version 4.9.3 (GCC)


$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-cygwin/4.9.3/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with: /cygdrive/i/szsz/tmpp/gcc/gcc-4.9.3-1.i686/src/gcc-4.9.3/configure --srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-4.9.3-1.i686/src/gcc-4.9.3 --prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc --docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C --build=i686-pc-cygwin --host=i686-pc-cygwin --target=i686-pc-cygwin --without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib --enable-shared --enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit --with-dwarf2 --with-arch=i686 --with-tune=generic --disable-sjlj-exceptions --enable-languages=ada,c,c++,fortran,java,lto,objc,obj-c++ --enable-graphite --enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm --enable-libquadmath --enable-libquadmath-support --enable-libssp --enable-libada --enable-libjava --enable-libgcj-sublibs --disable-java-awt --disable-symvers --with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix --without-libintl-prefix --with-system-zlib --enable-linker-build-id
Thread model: posix
gcc version 4.9.3 (GCC)


$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-cygwin/4.9.3/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with: /cygdrive/i/szsz/tmpp/gcc/gcc-4.9.3-1.i686/src/gcc-4.9.3/configure --srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-4.9.3-1.i686/src/gcc-4.9.3 --prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc --docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C --build=i686-pc-cygwin --host=i686-pc-cygwin --target=i686-pc-cygwin --without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib --enable-shared --enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit --with-dwarf2 --with-arch=i686 --with-tune=generic --disable-sjlj-exceptions --enable-languages=ada,c,c++,fortran,java,lto,objc,obj-c++ --enable-graphite --enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm --enable-libquadmath --enable-libquadmath-support --enable-libssp --enable-libada --enable-libjava --enable-libgcj-sublibs --disable-java-awt --disable-symvers --with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix --without-libintl-prefix --with-system-zlib --enable-linker-build-id
Thread model: posix
gcc version 4.9.3 (GCC)

So I think that they are present.

However, Looking at this line

C:/cygwin/lib/gcc/i686-pc-cygwin/4.9.3/f951.exe: error while loading shared
libraries: cygisl-10.dll: cannot open shared object file: No such file or
directory

It seems to me that the problem here. I do not know what is cygisl-10.dll, but I have another version - cygisl-13.dll.

Also, when you run the installer and are selecting the packages you want make sure you have selected All->Devel->gcc-core, gcc-g++ and gcc-fortran as well as All->Libs->libgcc1. You may also need Devel->cmake, binutils, cygwin-devel and make, along with any dependencies these may have.

Is there a list of things that are required during the installation? How to ensure that the true versions were delivered?

Sorry, I'm a Windows programmer and little know about these things.

[agilemolecule]

Thank you James.

It has been successfully compiled and starts. The problem really was in a newer library version.
However, it does not pass any test.

Code: Select all

$ ctest
Test project /home/amnikitin/DALTON-Source/build
        Start   1: dft_ac_grac
  1/609 Test   #1: dft_ac_grac ......................................***Failed    0.70 sec
        Start   2: dft_b3lyp_cart
  2/609 Test   #2: dft_b3lyp_cart ...................................***Failed    0.67 sec
        Start   3: dft_b3lyp_magsus_nosym
  3/609 Test   #3: dft_b3lyp_magsus_nosym ...........................***Failed    0.67 sec

[kennethruud]

Could you please upload an example output file, and possibly also the error file if you have it?

Kenneth

[agilemolecule]

Could you please upload an example output file, and possibly also the error file if you have it?

Kenneth

Unfortunately, I do not see the error file and attached scratch folder.
In fact Dalton works. I compared it for a real task with other programs - the results are the same.

One more question. There is some discrepancy on the site and in the manual.
In the Features page - Molecular gradients, and thus geometry optimization using analytical gradients (CCS, CC2, MP2, CCSD)
In the manual - Gradient calculation, geometry optimization Available for CCS, CC2, MP2, CCSD and CCSD(T)
Are there really CCSD(T) analytical gradients?

Best wishes,
Alexei