From NWChem
You are viewing a single post from the thread title above
|
Gets Around
Threads 2
Posts 82
|
|
11:58:23 AM PDT - Mon, Jun 4th 2012 |
|
Hi Andy,
I think your suggested fix will correct the problem you are seeing, but my guess is that the underlying problem isn't the length of $PATH, but the same thing as the previous issue I was noting about having a space in the $PATH (the "channel 1" issue). Having paths with spaces is going to cause lots of havoc and somehow your path coming into ECCE is set that way as part of the environment on the cluster where you are launching ECCE jobs. You might want to spend a bit of time looking into that to see if you can track it down (it may be something setup by the administrators of that cluster as a default for everyone) because I can't think of a valid reason to have a directory specification with a space in it for a Linux box. It will actually work if all the spaces are properly escaped, but it's very easy not to do that and the result can only be trouble when running shell commands/scipts (inside or outside ECCE) as we've found.
Regardless, I don't see a reason why your suggested change is unsafe so I went ahead and made the change. It's probably a good idea anyway to quote the expression just to insure it's treated as a single value should there be spaces or other unusual syntax. I did this for when both $PATH and $LD_LIBRARY_PATH are specified via setenv since the latter could also be an issue.
There are now updated binary distributions and a new source code distribution for ECCE 6.3 with this change. This new ECCE 6.3 also includes the change I was mentioning last week where I don't try to find if xterm is already in $PATH before invoking it, which means you shouldn't see that little csh syntax error related to "channel 1". Actually, I could go back and put quotes around those as well and it would fix that syntax error too. But, I really don't think there is much value in the check for xterm anyway because with modern Linux operating systems, I can't imagine xterm not being in a standard directory. Finally note that there are no code changes related to the other couple fixes you requested (SCF max. iterations for DFT and order of atoms printed for MD systems). Those are going to take more time than I have available right now.
Thanks,
Gary
|
|
|
AWC's:
2.5.10 MediaWiki - Stand Alone Forum Extension
Forum theme style by: AWC