ECCE suffers random segfaults sometimes when opening a window. No indication of this is given, other than that the progress animation continues and never stops, and now more windows can be opened.

This happens rarely, which makes it harder to chase down. Worth collecting data though to try to address it and improve the stability of ECCE

This bug was reported: http://www.nwchem-sw.org/index.php/Special:AWCforum/st/id2203/ecce_view_-_loads_only_fist_MO_a....html

nwchem.desc needs to be checked to make sure that the correct data is loaded for each type

Think the bundled version is 6.5 whereas current is 6.6 with a long list of patches added

I can barely find a trace of AMICA ever having existed. A few different directions to go in:

• Focus on NWChem and Gaussian only
• Replace AMICA with a current open source distro, preferrably one that has something unique compared with NW/Gau
• Do nothing

It's already patched in the development version (7.3.0). How best to get the patch into stable and branch without making a mess of things?

May or may not be easy, and would likely require that it be done by someone with actual experience of using Dalton

Almost every C++ file generates at least one warning like this:

/usr/ports/science/ecce/work/ECCE-7.3.4-beta-8-gaf79f45/include/util/CommandParameter.H:75:52: warning: dynamic exception specifications are deprecated in C++11 [-Wdeprecated]
       vector<string> *getDefaultStringList() const throw(MismatchedTypeException);
                                                    ^~~~~

gcc7, FreeBSD 11.2

If the output file contains "Standard orientation" but not "Framework group", parsing will fail and cause abnormal exit.
Example input:

  1 %nprocshared=8
  2 %Mem=800000000
  3 %Chk=G09_nosymm_acetone.chk
  4 #P rPBE1PBE/6-31g 6D 10F  Punch=(MO) Pop=()
  5 
  6 G09_nosymm_acetone
  7 
  8 0 1 ! charge and multiplicity
  9  C     0.00000     0.00000     0.00000
 10  O     0.00000     1.50000     0.00000
 11  C     1.33368     -0.770000     0.00000
 12  H     1.94720     -0.487349     0.955301
 13  H     1.11989     -1.92030     2.01805e-08
 14  H     1.94720     -0.487350     -0.955301
 15  C     -1.33368     -0.770000     8.32667e-17
 16  H     -1.39566     -1.44265     0.955301
 17  H     -2.22297     -0.00969901     -1.61456e-08
 18  H     -1.39566     -1.44265     -0.955301
 19 

Location of issue in output:

                       Standard orientation:                         
---------------------------------------------------------------------
Center     Atomic      Atomic             Coordinates (Angstroms)
Number     Number       Type             X           Y           Z
---------------------------------------------------------------------
     1          6           0        0.000000    0.094687    0.000000
     2          8           0        0.000000    1.594687    0.000000
     3          6           0        1.333680   -0.675313    0.000000
     4          1           0        1.947200   -0.392662    0.955301
     5          1           0        1.119890   -1.825613    0.000000
     6          1           0        1.947200   -0.392662   -0.955301
     7          6           0       -1.333680   -0.675313    0.000000
     8          1           0       -1.395660   -1.347963    0.955301
     9          1           0       -2.222970    0.084988    0.000000
    10          1           0       -1.395660   -1.347963   -0.955301
---------------------------------------------------------------------
Rotational constants (GHZ):      8.1138964      7.8743040      4.2430149
Leave Link  202 at Tue Jun 27 15:11:58 2017, MaxMem=   800000000 cpu:         0.0
(Enter /opt/gaussian/g09d/g09/l301.exe)
Standard basis: 6-31G (6D, 10F)

See gaussian-03.desc:

 40 [GEOMTRACE1]
 41 Script=gaussian-03.geomtrace-input
 42 Begin=Standard orientation\:
 43 Skip=5
 44 Frequency=all
 45 End=Framework group
 46 [END]

ECCE cannot be compiled on OSX. Porting it to OS X might widen the user base.
I'm guessing it should be easier to port it to OS X than to Windows given the BSD-origins of OS X.

Assuming work is done on other codes, adding support for ORCA could be interesting.

The code is both fast, offers many good new methods that will be interesting (e.g. look at Paulechka and Kazakov 2017 who used DLPNO) and has excellently structured output.

There is a more in depth description of how ECCE works floating around, and that should be added to the github repo.
However, even more important is a short description that works for laymen describing what files to look at if you want to fix an issue/add a feature e.g. scripts/parsers for reading out, scripts/codereg/*theory.py and *runtype.py for modifying input options etc.

G98 has been replaced by G03, G09 and G16, so might be worth removing in anticipation of adding support for other computational codes that are more current.

The parser files don't necessarily need to be removed, and in other places the referring code can simply be commented out.

G09 uses fine by default, whereas G16 uses ultrafine.

The dialogue in ECCE defaults to fine -- but this just means that if the default, fine, is selected the grid size will not be explicitly defined in the input. The dialogue for G16 should be set to ultrafine to default.

[example was due to other bug]

The current MP2 dialogue is more rudimentary than the DFT dialogue and does not include e.g. options for SCRF

This bug was reported: http://www.nwchem-sw.org/index.php/Special:AWCforum/st/id2203/ecce_view_-_loads_only_fist_MO_a....html

gaussian-03.desc needs to be checked to make sure that the correct data is loaded for each type

Maybe a ./configure/make(/install?) chain?

It will also help when building binaries for release

May or may not be easy, given that there is already support for Gamess UK -- I don't know how similar the syntax of G-US is to G-UK.

Best done by someone with actual experience of using the code.

Ideally, things that Gamess US can do that the other codes -- nwchem and gaussian -- can't do are the things that must be supported.

A list of simple tests that we can carry out to make sure that ECCE works more or less as intended even after changes have been made.

Need suggestions.

E.g.

• Start
• Open Organizer
• Create nwchem job (draw water, default XC with 6-31G, frequency calc)
  ** visualise frequencies
• Import ecce.out file from an agreed upon computation
• Import gaussian 09 file from an agreed upon computation

Comments?

Need to diagnose.
Seems to relate in part to the size of the molecule (e.g. 109 atoms/406 electrons, singlet doesn't show the trace correctly)

Just some very quick comments on ECCE on openSUSE.

I am running up to date openSUSE Tumbleweed.
As openSUSE is rpm based, I chose the CentOS release which I would expect to be the most related Linux OS amongst those on offer.

The installation worked smoothly without any issues.

To start ECCE, I had to add localhost.localdomain to my hosts file. (I am only running it locally on my laptop). - While "localhost" on its own would work, the localdomain caused an issue if it wasn't available in the hosts file.

I was missing one library, namely libpng15 which I had to install manually from here:
https://download.opensuse.org/repositories/graphics/openSUSE_Tumbleweed/

Otherwise, all looks well so far.
I'm not sure how much in depth I will go with testing, but as far as I can tell, the code works fine.

NOTE: Bug is triggered ONLY on importing a gaussian log file. I.e. if the calc is run and managed by ECCE it does not show up. This should indicate that the issue lies in parsers/Gaussian-03.expt

Triggering code:

%nprocshared=8
%Mem=800000000
%Chk=plaincctvz.chk
#P rPBE1PBE/GEN 5D 7F  NoSymm  Punch=(MO) Pop=(full) 

plaincctvz

0 1 ! charge and multiplicity
 C     0.00000     0.00000     0.00000
 H     -0.675500     -0.675500     0.675500
 H     0.675500     -0.675500     -0.675500
 H     -0.675500     0.675500     -0.675500
 C     0.889119     0.889119     0.889119
 H     0.213620     1.56462     1.56462
 H     1.56462     1.56462     0.213620
 C     1.77824     0.00000     1.77824
 H     2.45374     -0.675500     1.10274
 H     2.45374     0.675500     2.45374
 H     1.10274     -0.675500     2.45374

 C  H 0 
 cc-pvtz
****

Code that DOES NOT trigger the issue (also using cc-pvtz):

%nprocshared=8
%Mem=800000000
%Chk=plaincctvz.chk
#P rPBE1PBE/GEN 5D 7F  NoSymm  Punch=(MO) Pop=(full) 

plaincctvz

0 1 ! charge and multiplicity
 C     0.00000     0.00000     0.00000
 H     -0.675500     -0.675500     0.675500
 H     0.675500     -0.675500     -0.675500
 H     -0.675500     0.675500     -0.675500
 C     0.889119     0.889119     0.889119
 H     0.213620     1.56462     1.56462
 H     1.56462     1.56462     0.213620
 C     1.77824     0.00000     1.77824
 H     2.45374     -0.675500     1.10274
 H     2.45374     0.675500     2.45374
 H     1.10274     -0.675500     2.45374

 C  0
 S  10  1.00
    8236.00000000      0.00053100
    1235.00000000      0.00410800
     280.80000000      0.02108700
      79.27000000      0.08185300
      25.59000000      0.23481700
       8.99700000      0.43440100
       3.31900000      0.34612900
       0.90590000      0.03937800
       0.36430000     -0.00898300
       0.12850000      0.00238500
 S  10  1.00
    8236.00000000     -0.00011300
    1235.00000000     -0.00087800
     280.80000000     -0.00454000
      79.27000000     -0.01813300
      25.59000000     -0.05576000
       8.99700000     -0.12689500
       3.31900000     -0.17035200
       0.90590000      0.14038200
       0.36430000      0.59868400
       0.12850000      0.39538900
 S   1  1.00
       0.90590000      1.00000000
 S   1  1.00
       0.12850000      1.00000000
 P   5  1.00
      18.71000000      0.01403100
       4.13300000      0.08686600
       1.20000000      0.29021600
       0.38270000      0.50100800
       0.12090000      0.34340600
 P   1  1.00
       0.38270000      1.00000000
 P   1  1.00
       0.12090000      1.00000000
 D   1  1.00
       1.09700000      1.00000000
 D   1  1.00
       0.31800000      1.00000000
 F   1  1.00
       0.76100000      1.00000000
 ****
 H  0
 S   5  1.00
      33.87000000      0.00606800
       5.09500000      0.04530800
       1.15900000      0.20282200
       0.32580000      0.50390300
       0.10270000      0.38342100
 S   1  1.00
       0.32580000      1.00000000
 S   1  1.00
       0.10270000      1.00000000
 P   1  1.00
       1.40700000      1.00000000
 P   1  1.00
       0.38800000      1.00000000
 D   1  1.00
       1.05700000      1.00000000
****

I have just tried to build ECCE on a Linux machine and found that a bunch of app Makefiles do not include -ljpeg and -lfreetype on the link line. This results in many undefined functions. The apps in question are:

• basistool
• builder
• calced
• dirdyed
• gateway
• launcher
• machbrowser
• machregister
• mddynamics
• mdenergy
• mdoptimize
• mdprepare
• messagedialog
• metadyn
• organizer
• passdialog
• pertable
• polyrate
• solvate
• symmetry
• vizthumbnail
  I have fixed all these Makefiles by hand (although I suppose they should be regenerated by genmake) and am happy to contribute these changes. Any suggestions as to how to best contribute these fixes?

ECCE compiles an ASCII only version of wxWidgets 2.8 while CentOS and Ubuntu/Debian ship with the unicode version of 2.8 which is incompatible. Because ECCE subclasses and extends much of wxWidgets (demarcated with the "ewx" prefix), updating the wx 2.8 code to be unicode compliant will be very time consuming.

We could

1. Bite the bullet and fix the hundreds of unicode incompatibilities.
2. Strip out as much ewx code as possible. The main reason cited for this code in the header files is "styling", though some of it does other things like field validation and selecting correct bitmap paths.
3. Try compiling against wx 3.0 which is more forgiving for unicode use but may also be incompatible with ewx.

This will probably be a major project and I'm leaning towards a combination 2 and 3.

ECCE currently builds and bundles 3rd party packages. Using versions of these libraries provided by yum/dnf or apt-get would decrease the size of the distributable and make it easier to bundle ECCE into .rmp or .dep packages. This effort would likely be part of issue #16 and will include issue #10.

The file build/build_details.doc (not a MS Word doc BTW) details the reasons for these packages being bundled in order of perceive ease of replacement.

1. NWChem -- This issue is already covered in issue #10. ECCE allows custom computational backends to be registered (http:ecce.pnl.gov/docs/2864B-server_reg.pdf), so this should be a relatively simple change.
2. Perl CGI -- The version proved by ECCE is the most current version, so we simply need to ensure ECCE's perl can find the system version.
3. httpd -- Apache 2.2 is used for fear of small breaking changes with 2.4. From the Apache docs, there were not major deprecations and most changes are limited to some small configuration quirks.
4. MesaLib -- Mesa has been kept at 6.5 simply because it has fewer dependencies. Also, the bundled wxPython requires Mesa to build, so we must ensure the system mesa-dev libraries are referenced instead.
5. wxPython/wxWidgets -- The bundled wxWidgets contains ECCE-specific widgets for the builder. I am unable to comment on whether these custom widgets can be decoupled from the main wxWidget source.
6. apache-activemq -- 5.1 is bundled but 5.5 is the most recent version. CentOS does not provide this through YUM (Ubuntu and RedHat do) so this package may need to be bundled.
7. Xerces -- The included version is 2.8 while CentOS provides 3.11. ECCE relies on deprecated xerces classes such as DOMWriter so parts of ECCE, such as ECCE/srs/dsm/xml/BasicDOMWriter.C will need to be ported to newer APIs.

ECCE depends on bundled packages, instead of distro provided ones.
These include wxwidgets, wxpython, mesa, xerces and httpd (apache)

Sounds like someone with experience of Xerces is needed:
From build/build_details.doc
"ECCE uses version 2.x of the C++ source code distribution available from
http://xerces.apache.org. Note that ECCE is not API compatible with the
Xerces 3.x releases and thus only 2.x releases should not be used."

Seems like dumping Mesa should be easy:
build/build_details.doc
"Both the local OpenGL libraries and the Mesa source code distribution bundled
with ECCE will more than likely work fine. It has been observed though that
one or the other may cause Builder/Viewer application crashes on certain
platforms and thus support for both is provided. Environment variables
described in the $ECCE_HOME/siteconfig/site_runtime file specify which OpenGL
libraries are used."

Looks like
ECCE_MESA_OPENGL false
is the default (i.e. use the distro version)

However,
"Finally, note that Mesa must be built before attempting to build wxWidgets or the wxWidgets build will fail."

wxWidgets:
"Note that one of the two sets of instructions (copying or compiling) for Mesa OpenGL must have been done before attempting to build wxWidgets."
but
"Although wxWidgets and wxPython distributions are available separately, ECCE uses a wxPython distribution that itself bundles a wxWidgets C++ distribution so that only a single version of the wxWidgets C++ libraries is shared between wxWidgets and wxPython."

" ECCE uses version 2.2.x series of the Apache HTTP Server available from
http://httpd.apache.org. ECCE has not been tested with the newer 2.4.x
release series and it is likely that some level of porting would be needed
before ECCE would function and thus only 2.2.x releases should be used."

"For this reason no ActiveMQ compilation is needed and the ActiveMQ 5.1.0 binary distribution is installed directly from the $ECCE_HOME/build/3rdparty-dists directory "

cygwin is a linux-like environment that runs on windows

• Would compiling/installing on cygwin increase the number of users?
• Is working with cygwin easier than working in a virtual machine?
• Do users who can set up a cygwin environment on their own need prebuilt binaries?
• Is the 'overhead' less when running in cygwin than in a virtual machine?
• Is time spent working with cygwin better spent putting together a tutorial for how to set up a virtual machine?

Need to diagnose.

clang-6 fails to build it on FreeBSD 11.2:

c++ -O2 -pipe -fno-omit-frame-pointer  -fstack-protector -isystem /usr/local/include -fno-strict-aliasing -I/usr/ports/science/ecce/work/ECCE-7.3.4-beta-8-gaf79f45/include -I/usr/include/freetype2/freetype -I/usr/local/lib/wx/include/gtk2-unicode-3.0 -I/usr/local/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread -D_THREAD_SAFE -I/usr/ports/science/ecce/work/ECCE-7.3.4-beta-8-gaf79f45/3rdparty/xerces/include -c BookmarkEditor.C -o /usr/ports/science/ecce/work/ECCE-7.3.4-beta-8-gaf79f45/obj/organizer/BookmarkEditor.o
BookmarkEditor.C:85:28: error: no viable conversion from 'wxCStrData' to 'std::__1::string' (aka 'basic_string<char, char_traits<char>, allocator<char> >')
      setBookmarkName(pos, value.c_str());
                           ^~~~~~~~~~~~~

NWChem forum user bjhanson reported an error on selecting DirDyVTST -- http://www.nwchem-sw.org/index.php/Special:AWCforum/st/id2122/ECCE_error_when_selecting_DirDyV....html

Check if this is reproducible

See development of feature_g09 for an example.

Debian 9 has transitioned to stable.

Fails on wxwidget build:

Makefile:23903: recipe for target 'coredll_gtk_dcclient.o' failed
make: *** [coredll_gtk_dcclient.o] Error 1
The wxWidgets 'make' command failed.  The issue(s)
identified must be resolved before wxWidgets can be built.

Few people are using G03 these days. Time to add G09 -- and specific support -- to ECCE

If nosymm is used with g09 calcs it's impossible to see whether orbitals are occupied or virtual

Example input that triggers bug:

%nprocshared=8
%Mem=800000000
%Chk=plaincctvz.chk
#P rPBE1PBE/GEN 5D 7F  NoSymm  Punch=(MO) Pop=(full) 

plaincctvz

0 1 ! charge and multiplicity
 C     0.00000     0.00000     0.00000
 H     -0.675500     -0.675500     0.675500
 H     0.675500     -0.675500     -0.675500
 H     -0.675500     0.675500     -0.675500
 C     0.889119     0.889119     0.889119
 H     0.213620     1.56462     1.56462
 H     1.56462     1.56462     0.213620
 C     1.77824     0.00000     1.77824
 H     2.45374     -0.675500     1.10274
 H     2.45374     0.675500     2.45374
 H     1.10274     -0.675500     2.45374

 C  0
 cc-pvdz
  ****
 H  0
cc-pvtz
****

Input that DOES NOT trigger bug:

%nprocshared=8
%Mem=800000000
%Chk=plaincctvz.chk
#P rPBE1PBE/GEN 5D 7F  NoSymm  Punch=(MO) Pop=(full) 

plaincctvz

0 1 ! charge and multiplicity
 C     0.00000     0.00000     0.00000
 H     -0.675500     -0.675500     0.675500
 H     0.675500     -0.675500     -0.675500
 H     -0.675500     0.675500     -0.675500
 C     0.889119     0.889119     0.889119
 H     0.213620     1.56462     1.56462
 H     1.56462     1.56462     0.213620
 C     1.77824     0.00000     1.77824
 H     2.45374     -0.675500     1.10274
 H     2.45374     0.675500     2.45374
 H     1.10274     -0.675500     2.45374

 C  H 0 
 cc-pvtz
****

To trigger bug, open viewer after job completion, click on MOs, pick e.g. MO 13 and 'Compute'.

It will freeze first at at 'AO 8C(f) - 8 of 11 for MO13', then at '9H(s), 9 of 11 for MO 13 ' etc.
while returning
...
ASSERTION PropTable.C:102 Assertion (false) failed trying to acces out of bounds index in PropTable
...
Even when the dialogue disappears, the viewer remains frozen for quite a while.

Need a 'quick start' guide.

1. Installation -- in particular if they download the binaries users need to know what packages to install.
2. How to/the need to modifying the CONFIG.x files may not be obvious the first time you use ECCE
3. Nice glossy little tutorial showing how to do a few basic computations

I've noticed that geomtrace is still missing for some calcs that use symmetry. Earlier we fixed an issue that caused ALL symm calcs to lack GEOMTRACE, so this is something different.

Digging deeper, the issue is when molecular geometries are given as Standard orientation, which is a trigger for GEOMTRACE1 in the gaussian-xx.desc file. This trigger hands over parsing to gaussian-xx.geomtrace-input, as opposed to gaussian-xx.geomtrace, which is what is called when 'Input orientation' or 'Z-Matrix orientation' is called.

The differences between the two scripts are small:

<   $tossit = "true";
<   while (<STDIN>) {
<     chop;
<     if (/Symmetry turned off/) {
<       $tossit = "false";
<     }
<   }
< 
66c56,57
<   if ($tossit ne "true") {
---
>   $size = ($#coordlines + 1);
>   if ($size >= 1) {
80d70
< 

Quick fix: call gaussian-xx.geomtrace instead of gaussian-xx.geomtrace-input
Better fix: fix geomtrace-input. However, looking at the code it seems that the programming of geomtrace-input was never finished.

Will apply quick fix, and closing.
Report any issues with how geomtraces are displayed for calculations with symm, and which report the 'Standard orientation'

With gcc-7 compiler on FreeBSD 11.2, the build fails:

g++7 -O2 -pipe -fno-omit-frame-pointer  -fstack-protector -Wl,-rpath=/usr/local/lib/gcc7 -isystem /usr/local/include -fno-strict-aliasing -I/usr/ports/science/ecce/work/ECCE-7.3.4-beta-8-gaf79f45/include -I/usr/include/freetype2/freetype -I/usr/local/lib/wx/include/gtk2-unicode-3.0 -I/usr/local/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread -D_THREAD_SAFE -I/usr/ports/science/ecce/work/ECCE-7.3.4-beta-8-gaf79f45/3rdparty/mesa/include -c SoWxViewer.C -o /usr/ports/science/ecce/work/ECCE-7.3.4-beta-8-gaf79f45/obj/wxinv/SoWxViewer.o
SoWxViewer.C: In static member function 'static void SoWxViewer::drawViewerRollFeedback(SbVec2s, SbVec2s)':
SoWxViewer.C:1809:10: error: 'GLUquadricObj' does not name a type
   static GLUquadricObj *quad = NULL;
          ^~~~~~~~~~~~~
SoWxViewer.C:1810:9: error: 'quad' was not declared in this scope
   if (! quad) quad = gluNewQuadric();
         ^~~~
SoWxViewer.C:1810:9: note: suggested alternative: 'read'
   if (! quad) quad = gluNewQuadric();
         ^~~~
         read
SoWxViewer.C:1810:22: error: 'gluNewQuadric' was not declared in this scope
   if (! quad) quad = gluNewQuadric();
                      ^~~~~~~~~~~~~
SoWxViewer.C:1815:11: error: 'quad' was not declared in this scope
   gluDisk(quad, RADIUS, RADIUS+LINE_THICK, 20, 2);
           ^~~~
SoWxViewer.C:1815:11: note: suggested alternative: 'read'
   gluDisk(quad, RADIUS, RADIUS+LINE_THICK, 20, 2);
           ^~~~
           read
SoWxViewer.C:1815:3: error: 'gluDisk' was not declared in this scope
   gluDisk(quad, RADIUS, RADIUS+LINE_THICK, 20, 2);
   ^~~~~~~
SoWxViewer.C:1815:3: note: suggested alternative: 'glIsList'
   gluDisk(quad, RADIUS, RADIUS+LINE_THICK, 20, 2);
   ^~~~~~~
   glIsList
SoWxViewer.C:1816:3: error: 'gluPartialDisk' was not declared in this scope
   gluPartialDisk(quad, dist-2, dist+LINE_THICK-2, 20, 2, cirAng - ANGLE_LEN, 2 * ANGLE_LEN);
   ^~~~~~~~~~~~~~

Further, the build this continues after this error.

A git checkout on Windows or modern MacOS causes problems due to case-sensitive naming.

warning: the following paths have collided (e.g. case-sensitive paths
on a case-insensitive filesystem) and only one from the same
colliding group is in the working tree:

  'data/admin/basissets/CC-PV5Z.BAS'
  'data/admin/basissets/cc-pV5Z.BAS'
  'data/admin/basissets/CC-PV5Z.BAS.meta'
  'data/admin/basissets/cc-pV5Z.BAS.meta'
  'data/admin/basissets/CC-PVDZ.BAS'
  'data/admin/basissets/cc-pVDZ.BAS'
  'data/admin/basissets/CC-PVDZ.BAS.meta'
  'data/admin/basissets/cc-pVDZ.BAS.meta'
  'data/admin/basissets/CC-PVQZ.BAS'
  'data/admin/basissets/cc-pVQZ.BAS'
  'data/admin/basissets/CC-PVQZ.BAS.meta'
  'data/admin/basissets/cc-pVQZ.BAS.meta'
  'data/admin/basissets/CC-PVTZ.BAS'
  'data/admin/basissets/cc-pVTZ.BAS'
  'data/admin/basissets/CC-PVTZ.BAS.meta'
  'data/admin/basissets/cc-pVTZ.BAS.meta'

If ECCE is used continuously for a long time (weeks) it crashes due to 'too many open files'.

Example error message:
[..]
exit; echo GOODBYE
Unable to create a socket
Error: java.net.SocketException: Too many open files

ECCE is currently not particularly well documented -- a lot of the better documents are out of date by a decade or more, and most of the more recent documentation has been in the form of release notes