However, ECCE is open source since about a year. Sure, you may not be able to submit your changes without vetting to a sourceforge git repo, but the good folks at EMSL/PNNL are very open to receiving patches and possibly merging them with the main trunk if you do write them.
Go to the ECCE forum and post improvements if you have made them. The forum is here: http://www.nwchem-sw.org/index.php/Special:AWCforum/sf/id11/General_ECCE_Topics.html
NOTE: as always with open source projects, simply making demands for features and general improvements in the forum, unless very small or highly critical, is probably a bit impolite.
I've made a few abortive attempts at making improvements to ECCE, and as these efforts often go, my success has been rather mixed (I think the migration from getopts to Getop:std is my only real contribution so far). My main talent seems to be in writing posts about ECCE, which I suppose isn't entirely without merit.
However, I'd like to become more involved, even though a significant barrier is the fact that ECCE is written in at least four different languages (java, C, perl, python).
So here's my wish list, which I might be amending with time (hopefully with solutions...)
1. Bugs
* When creating a new directory, all open directories lower in rank auto-close.
Example. Say we have the directory /jobs/catalyst open/expanded. If we create the directory /jobs/transition, /jobs/catalyst and everything below will close. It can be quite annoying since you may lose track of what jobs you were running and where.
* Separate DFT maxiter from SCF maxiter
NOTE: what I wrote below is wrong. DFT;iterations N;end works as advertised in DFT, scf; maxiter N;end is ignored.
Old text: When setting up DFT jobs using the theory editor, section called SCF Convergence really only sets the DFT options. In other words, if you set SCF max iterations to 999, you're really setting the number of DFT iterations, not SCF. It would be nice to add an SCF section to DFT jobs, and rename the SCF section to DFT.
* Can't run command because too many files open
While in reality you actually don't have anything open.
Not sure exactly what causes it, but it's manifested by the ECCE animation (in the left-most button) in the ECCE menu thingy (the small window with buttons for Exit, Organizer, Builder, Viewer, Machine Browser etc.) not stopping, and no window launching. In the terminal the following is shown:
[..] exit; echo GOODBYE Unable to create a socket Error: java.net.SocketException: Too many open files
Doing
lsof |grep eccein one case yielded 9784 hits, most of which were of the type
java 18010 31175 me 99u REG 8,6 0 17194388 /home/me/.ecce/ecce-v6.4b/server/activemq/data/kr-store/data/hash-index-blob_ecce_url_property_data-Subscriptions java 18010 31175 me 106u REG 8,6 0 17196148 /home/me/.ecce/ecce-v6.4b/server/activemq/data/kr-store/data/hash-index-topic-data_ecce_ejs_kill java 18010 31175 me 107u REG 8,6 0 17196150 /home/me/.ecce/ecce-v6.4b/server/activemq/data/kr-store/data/hash-index-blob_ecce_ejs_kill-Subscriptions java 18010 31176 me cwd DIR 8,6 4096 16517897 /home/me/.ecce/ecce-v6.4b/apps/bin java 18010 31176 me mem REG 8,6 14014 16919807 /home/me/.ecce/ecce-v6.4b/server/activemq/bin/run.jar java 18010 31176 me mem REG 8,6 367444 16919829 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/optional/log4j-1.2.14.jar java 18010 31176 me mem REG 8,6 467331 16919826 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/optional/spring-beans-2.5.1.jar java 18010 31176 me mem REG 8,6 81403 16919823 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/activemq-console-5.1.0.jar java 18010 31176 me mem REG 8,6 455159 16919827 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/optional/spring-context-2.5.1.jar java 18010 31176 me mem REG 8,6 128051 16919828 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/optional/xbean-spring-3.3.jar java 18010 31176 me mem REG 8,6 52915 16919819 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/commons-logging-1.1.jar java 18010 31176 me mem REG 8,6 2141382 16919830 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/optional/derby-10.1.3.1.jar java 18010 31176 me mem REG 8,6 275073 16919825 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/optional/spring-core-2.5.1.jar java 18010 31176 me mem REG 8,6 16030 16919820 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/geronimo-j2ee-management_1.0_spec-1.0.jar java 18010 31176 me mem REG 8,6 32359 16919821 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/geronimo-jms_1.1_spec-1.1.1.jar java 18010 31176 me mem REG 8,6 2315247 16919822 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/activemq-core-5.1.0.jar java 18010 31176 me 12r REG 8,6 14014 16919807 /home/me/.ecce/ecce-v6.4b/server/activemq/bin/run.jar java 18010 31176 me 21r REG 8,6 2141382 16919830 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/optional/derby-10.1.3.1.jar java 18010 31176 me 22r REG 8,6 367444 16919829 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/optional/log4j-1.2.14.jar java 18010 31176 me 23r REG 8,6 467331 16919826 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/optional/spring-beans-2.5.1.jar java 18010 31176 me 24r REG 8,6 455159 16919827 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/optional/spring-context-2.5.1.jar java 18010 31176 me 25r REG 8,6 275073 16919825 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/optional/spring-core-2.5.1.jar java 18010 31176 me 26r REG 8,6 128051 16919828 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/optional/xbean-spring-3.3.jar java 18010 31176 me 27r REG 8,6 81403 16919823 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/activemq-console-5.1.0.jar java 18010 31176 me 28r REG 8,6 2315247 16919822 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/activemq-core-5.1.0.jar java 18010 31176 me 29r REG 8,6 52915 16919819 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/commons-logging-1.1.jar java 18010 31176 me 30r REG 8,6 16030 16919820 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/geronimo-j2ee-management_1.0_spec-1.0.jar java 18010 31176 me 31r REG 8,6 32359 16919821 /home/me/.ecce/ecce-v6.4b/server/activemq/lib/geronimo-jms_1.1_spec-1.1.1.jar
And it repeats. I don't know why -- I guess files are opened and never closed.
* MD bugs?
Hammering out MD related bugs. I don't understand the ECCE support for MD well enough to know what is a bug and what is a feature issue, but I do know that I've had issues getting MD sims running through simple point and click. So I'm not even sure that there are MD related bugs -- but you do get the impression that there are.
Luckily there are people putting up tutorials online: http://saccharides.blogspot.tw/2013/06/ecce-md-calculation.html
* Long lines in nwchem input
There's a bug when dealing with lines longer than 254 chars. Today (18th of June 2013) I encountered it for the first time in a situation unrelated to pasting BSE code -- this time the ecce_print line was simply too long. Read more here about the bug: http://verahill.blogspot.com.au/2013/02/347-minor-ecce-oddity-when-pasting.html
* Long lines in xterm/csh
xterm -f (invoked by alt+l) on a running calculation doesn't work is the resulting command is longer than 256 characters. e.g.
xterm -title "optimization_def2svp_boat_acetonitrile_to_start_again_g09_pcm_ts-1" -bg "#b7b8ba" -fg "#000000" -sb -geom 80x40 -e tail -f /home/calc/boron/testing/testing/catalyst/optimization_def2svp_boat_acetonitrile_to_start_again_g09_pcm_ts-1/g03.g03out
which has 257 characters doesn't work when used by ECCE (which uses (t)csh), but works fine in bash.
* Rounding in ECCE when using Coefficients and Exponents.
NOTE: this is fixed in ECCE 7.0
When you select a bass set in ECCE you can either represent it as
or you can check the 'Use Exponents and Coefficients' in the ECCE Editor. If you check that box you'll get something like this instead:basis Be library '6-31g' end
However, the 6-31G.BAS file gives the coefficients and exponents asbasis "ao basis" cartesian print Be S 1264.58570000 0.00194500 189.93681000 0.01483500 43.15908900 0.07209100 12.09866300 0.23715400 3.80632300 0.46919900 1.27289000 0.35652000 [..]
Note the higher precision (there are more extreme examples, but this one will do for demonstration).atom=Be contraction shell=S num_primitives=6 num_coefficients=1 1264.5857 0.0019448 189.93681 0.0148351 43.159089 0.0720906 12.098663 0.2371542 3.8063232 0.4691987 1.2728903 0.3565202
Finally, if you define the basis set using the * library '6-31g' way, you get
Be (Beryllium) -------------- Exponent Coefficients -------------- --------------------------------------------------------- 1 S 1.26458570E+03 0.001945 1 S 1.89936810E+02 0.014835 1 S 4.31590890E+01 0.072091 1 S 1.20986630E+01 0.237154 1 S 3.80632320E+00 0.469199 1 S 1.27289030E+00 0.356520 2 S 3.19646310E+00 -0.112649 2 S 7.47813300E-01 -0.229506 2 S 2.19966300E-01 1.186917
In other words, you get somewhat different precision depending on how you use a basis set (3.8063232 vs 3.806323). Not a major issue, but it's still somewhat odd behaviour. The issue is much more significant when I use the def2 basis sets.
In terms of the energy at b3lyp/6-31g for an isolated Be atom I get this with Coeffs/Exps:
vs this with Be library '6-31g'Total DFT energy = -14.668063062134 One electron energy = -19.130485660973 Coulomb energy = 7.245896594547 Exchange-Corr. energy = -2.783473995707 Nuclear repulsion energy = 0.000000000000 Numeric. integr. density = 3.999999797518 Total iterative time = 0.2s
Total DFT energy = -14.668063028950 One electron energy = -19.130484712269 Coulomb energy = 7.245894834880 Exchange-Corr. energy = -2.783473151561 Nuclear repulsion energy = 0.000000000000 Numeric. integr. density = 3.999999797514 Total iterative time = 0.2s
2. Features
* A script for importing/adding new basis sets, as they become supported by nwchem. I've started work on this but I'm stuck without understanding why. See part 1 here: http://verahill.blogspot.com.au/2013/06/455-adding-nwchem-basis-sets-to-ecce.html
DONE!
http://verahill.blogspot.com.au/2013/06/456-adding-nwchem-basis-sets-to-ecce.html
https://sourceforge.net/projects/nwbas2ecce/ !
Note: the source distribution of ECCE 7.0 will contain a few helper scripts for importing basis sets.
* More options when setting up COSMO calculations. Currently you can set the dielectric constant, but nothing else. being able to set at a minimum rsolv and iscren would be welcome.
NOTE: this is fixed in ECCE 7.0
* Better Gaussian input/output support. This will by necessity have to be produced by someone outside PNNL as they are banned from receiving a license for Gaussian (they are considered competitors owing to the development of nwchem).
* Adding support for more computational packages, especially GAMESS US and Dalton (since they are free/open source).
* Updated documentation/more examples in documentation. The easiest solution is having more people blogging about what they are doing -- and HOW they are doing it.
3. Other
* I'd like to see ECCE included in e.g. Debian (assuming that the license is acceptable and that EMSL/PNNL allow it+). However, not only am I not proficient in making canonical debian packages, the build script for ECCE is a bit more advanced than the usual configure/make/make install ones. So it'll take someone with a bit more expertise than myself.
+one issue is that funding is often tied to being able to demonstrate that a piece of software is being used. And the easiest way to show that it's used is to retain control over downloads/encouraging people to register.
No comments:
Post a Comment